Sergey Melnik wrote:
> 
> Could you give an example of IDs that you generate for the reified
> statements?

The two tables are STATEMENTS and RESOURCES. And there is only one 
sequence.

If you would store the triple (A, B, C), where would be three
resources and one statement:

1. Resource A
2. Resource B
3. Resource C
4. Statement (A, B, C)

If the local namespace is "L#", there would be an implicit resource,
not stored in the database, with the URI "L#4", that would represent
the statement.

If you later have a triple (L#4, D, C), there would be one more
resource and one more statement in the database:

5. Resource D
6. Statement (L#4, D, C)


The API has a mothod to get a resource object (written in Perl):

    $res = get_node_by_uri("C");

This object can be used to get all statement that has the resource as
its object:

    $list_ref = $res->get_arcs_by_object();

The list ref is now a reference to a list of statement objects. Lets
put them in two separate variables:

    ($first, $second) = @$list_ref;

Suppose that the second statement object returned by the method is the
statement with the database id 6. Now get the subject for this
statement:

    $subj = $second->subj();

Now. This subject has the internal id 6. The subject object got
created by the get_arcs_by_object() method call. That triggerd the SQL
select statement in the resource table. That query found no
records. It then did a second query in the statement table, and found
the id there. The object knows therefore that the resource is a
statement. It's implicit properties will be handled by the objects own
method.  

I do not see the use for allowing reification of isolated properties
for the reified statement. But that COULD be supported by a second
layer of autogenerated numbers, I suppose...




The RDF Schema Editor uses a design with three layers. 

1. The Source layer. This layer has the class for the DBI
   interface. Interfaces for other types of RDF storage could be added
   later. The application will never use the internal database id's,
   and will not depend on the way the triples are accessed.

2. The Simple layer. This layer implements the core RDF, with the
   basic methods and constructors. This layer will inherit from the
   chosen Source layer.

3. The Schema layer. This implemets all the methods that needs the RDF
   schema. Thngs like determining a objects properties by recursivly
   examining each parent object, etc.

Each of these layers have three classes. a) The Model class, b) the
Resource class, and c) the Statement class.

Take a look at:
     http://paranormal.o.se/perl/proj/rdf/schema_editor/