Re: RDF API 1.0 Draft / Triple vs. Statement?

Sergey Melnik wrote:
> 
> But: personally I like your proposal and I'd change Triple into
> Statement and RDFModel into Model, if nobody has objections.
> 
> RDF IG, are these names specific enough: Resource, Literal, Statement,
> Model?? Pro/contra votes?

I experimented a bit with names in my RDF schema editor:
	http://paranormal.o.se/perl/proj/rdf/schema_editor/

I soon changed the names to nodes and arcs, like:
	get_nodes_of_type( $type )
	get_node_by_uri( $uri )
	arc_exist( $uri )
etc...

The reason is that the names is shorter, they are unambigous, and they
help me to visualize the graphs while programming.


I have some vested intrest in the solution I settled for in my
prototype.

I would not hesitate to use the Perl way of doing things, if that
differed from the Java way. I would prefer practical experience of
what is desired, rather than the minimal implementation. The API would
not have to be identical between the java platform and the perl
platform.  But it would help if there was a common interpretation of
the RDF spec, and how certain problems should be handled.

I wonder how much you looked at the perl RDF API...



is_instance_of


> Thus, a SchemaModel (which will extend the VirtualModel), could be asked
> for something like
> 
>         boolean isProperty = sm.find(r, RDF.type, RDF.Property).size() > 0;

That would not work. A resource could be an instance of property
without having the type Property. Take a look at this, for example:
   
http://paranormal.o.se/perl/proj/rdf/schema_editor/devel/latest/rdf.cgi?state=inventory&uri=rdfs%3AConstraintProperty

Ok. I see that you are doing something about this:
    // special case: predicate might be rdfs:subPropertyOf something

But this special case should only be handled in the schema layer.
 

My code is not commented, but is_instance_of() can be seen here:
   
http://paranormal.o.se/perl/proj/rdf/schema_editor/devel/latest/RDF/Schema/Resource.pm

And your isProperty() would be defined as:

sub is_Property
{
    my( $self ) = @_;
    return $self->is_instance_of( $self->model->rdfs('Property')->uri );
}

As a comment: 

I am using the URI strings rather than the objects in every
comparsion.  One object in the program can not be certain if another
object has retrieved the resource. 

You could think that if a URI is turned into an object, it should be
registred so that all references would be to the same object if it has
the same URI. You could also think that the object for RDFS:Property
could be a static method, rather than being derived from the resource
object.

But I was thinking of the case there the program has multipple
sources. In the DBI, all resources has an internal id.  The object
could be created in the schema layer, but it is ultimatly done by
initializations methods in the source level.  If there were multipple
sources, the particular object would be a diffrent variable if it
would originate from a diffrent source. ... Or would it? Maby I could
change this. The cache should be located in the simple layer.

The reason for "$self->model->rdfs('Property')" is that I am refering
to an object. This object has to be created if it hasn't been
retrieved yet. It would have to be retrieved from the source. This
source (the database connection) is specified in the creation of the
model. A pointer to that model is given in the creation of the
resource object. This DB connection is used in the creation of the
'Property' object. I had to specify the source in one way or another.

Do you have another suggestion for how the rdfs method/class should
know what source to use for the creation of the object? 

My thought is that I maby should have a global cache taht would be
source independent, and that could make the decission of what source
to use. (You know: In perl, you can invent the way you want to build
your programs. There is no restrictions...)


-- 
/ Jonas  -  http://paranormal.o.se/perl/proj/rdf/schema_editor/

Received on Sunday, 12 December 1999 16:10:53 UTC