Re: RDF API 1.0 Draft / signing RDF content

> Looks nice. I like how you've made a "triple" be a "resource".

Credits for that go to Ron Daniel.

> 1. Why is resource (and literal) creation bound to the model? Can a
> resource or literal that is created in one model be used in a different
> model? If not, why not? If so, should these be moved to RDFUtil, or
> another interface that is used for resource management?

Better to say, the creation is not bound, but rather supported by the
model. And yes, resources and literals can be used in different models.
The motivation behind the methods createResource etc. in a model is that
different model implementations may have different strategies for
managing resources, literals, etc. Two examples: (1) your model
implementation maintains an in-memory pool of frequently used resources
and literals to save memory. Thus, if you attempt to create a resource
that is cached, you'll get the same object (2) your model is stored in a
database. This model may use a different implementation of resources,
literals and triples e.g. using pointers to the corresponding
fields/objects in your RDB/OODB. Note that for interoperability
resources and literals are required to produce the same hashCode() (e.g.
you can put them in the same Hashtable).

It is easier to pass to an application just the RDFModel that it can
query and manipulate, rather than passing some extra factory object for
creating RDF nodes. The application should use the factory methods
provided by the model, rather than directly creating new ResourceImpl()
etc. In this way individual implementations can better optimize storage
and access.

> 2. Also, it seems like you might want to be able to compose models
> without combining them, at least for read-only operations. Compare
> pseudo-SQL

Interface org.w3c.rdf.model.VirtualModel is meant to serve this purpose.
A straightforward implementation of the union view for m1 and m2 would
be:

RDFModel find(s, p, o) {
  return RDFUtil.union( m1.find(s, p, o), m2.find(s, p, o) );
}

Once we have a comprehensive querying for RDF, we can define
QueryableModel that supports richer queries than the current scan-like
interface. On the other hand, a query processor could use the find()
method as a low-level access to the underlying model.

Sergey

Received on Monday, 6 December 1999 18:07:06 UTC