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

Jonas Liljegren wrote:

> 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...

In order to avoid a combinatorial explosion of the number of methods to
implement by an RDF model, the API [1] contains a single generic access
method find(s, p, o). If a parameter is left null, it matches
everything. Specific methods like the ones above can be provided as
static methods on top of the generic one.

> > 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:

Sure it could. But if there is a "ground fact" (s, p, o) in the schema
model, the information (p, RDF.type, RDF.Property) can be easily
derived. A "virtual model" can deliver triples not explicitly contained
as facts.

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

Oops. Sorry, VirtualModelImpl.java is just mistakingly in the source
distribution, it would not compile. This code would go into
org.w3c.rdf.schema.impl.SchemaModelImpl.

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

True.

> 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.

This is desirable, but can hardly be enforced. You cannot prevent other
third-party modules create instances of Resources.

> You could also think that the object for RDFS:Property
> could be a static method, rather than being derived from the resource
> object.

This is how it is implemented right now. RDFS.Property is a static
variable.

> 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.

Correct. This was my original motivation behind introducing CRCs and,
later, MD5 digests *and* requiring hashCode() -- a standard Java method
implemented by every object -- to be based on the digest of the RDF
node. The API also suggests that resources, literals, triples and models
implement the Digestable interface. Thus, the nodes can be easily
compared using their digests. A database application could for example
retrieve only 128-bit MD5 hashes of literals (that can be as large as
many MB) and compare them with other implementations of literals etc.

> 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?

Currently, RDFS resources are static variables. Using hashes allows
mixing different implementations.

> 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...)

Again, I think different implementations and instances of the same
resources can peacefully coexist in the same runtime environment. It is
hard to prevent it given the design autonomy of individual developers.

Sergey

Received on Tuesday, 14 December 1999 09:49:51 UTC