Re: RDF API

Sergey Melnik wrote:

> void assert(Resource subject, Resource predicate, RDFNode object) {
>   myModel.add( new MyTriple( createMyResource(subject.getURI()),
>                              createMyResource(predicate.getURI()),
>                              object instanceof Literal ?
> createMyLiteral((Literal)object.getString())
>                                                        :
> createMyResource((Resource)object.get ) );
> }

This is basically the code I have in my "Adapter" between SiRPAC and my RDF
Consumer/Stream interface.  I can see the possibility of there being a plethora
or RDF Producers available. Some will be extracting statements from a DOM, some
from an XML/RDF source, some from a Mozilla in-memory graph. Each will
potentially have its own idea of what a Resource/Literal is.  RDF dictates that
the lowest common denominator will be 3 or 4 strings.

> On the other hand, a string-based consumer exhibits the following
> problem:
>
> 1) what if the RDF parser has to pass a DOM element to the consumer?
> 2) what if the lang parameter in your declarations will be removed in a
> subsequent RDF spec? (it's flaky anyway...)

I'm not sure about the first one. I would think that how the producer represents
the RDF data should be transparent to the consumer.  As for the second, forward
compatability seems like a hard problem. I would certainly want higher level API
to be more robust in the face of change but the "raw" API should be 1-to-1 with
the underlying system. OTOH, I would sure like to ignore aboutEach :-)

> As to implementation: in the current (unreleased) version of GINF, the
> interface Model (see below) has methods
>
> createResource(String) and
> createLiteral(String)

How about getResource and getLiteral? In many cases you are requesting a
reference to an existing wrapper.  What about the fact that the RDFSchema Schema
uses bi-lingual label literals throughout? Are people comfortable with losing
this information?  I don't know what the right answer is.

> BTW: what's the deal with XML embedded in RDF anyway? Does anyone on
> earth uses/needs this feature? I tried a Gedankenexperiment where I
> imagined an RDF description containing XML literals with, say,
> presentation markup in them, but I could not arrive at anything useful
> having this combination.

Sure. If you transform existing markup into RDF you may have nodes that are XML.
An example is Bookmarks. Netscape bookmarks currently have description fields
that are basically straight text but can include a "<BR>" for maintaining simple
formating information.  Why wouldn't the description be full markup?

Its hard for me not to imagine statement targets that are XML markup :-) This is
especially the case if you consider RDF a complete replacement for XLink where
you then will have RDF fragments either embedded or external to XML documents
that then in turn might have objects/targets that are XML.  These
objects/targets can themselves be either inline of standoff. Things that are so
baroque or impossible in XLink become trivial with RDF. OTOH, baroque is in the
eye/ear of the beholder :-)

> So what about the following:
>
> org.w3c.rdf.core: defines the core interfaces Literal, Resource, Triple
> and Model
> org.w3c.rdf.stream (isn't "stream" a bit misleading?): RDFConsumer etc.

Maybe event? It can be thought of as an event channel between the producer and
consumer. SAX calls itself an event driven API even though there aren't any
events :-). It is also commonly referred to as stream oriented. Pick your
favorite nomenclature.

> >I'm asking myself why the Mozilla folks defined such a verbose
> datasource API. The current GINF Model interface has only *one* search
> method:
>
> Model find(Resource subject, Resource predicate, RDFNode object);
>
> where a null parameter matches everything.

Perfect :-! This is exactly the single API that my model has. I have convenience
interfaces  such as:

ArcIter getArcsForSubject(Node subject);
ArcIter getArcsForSubject(Node predicate, Node subject);

that then turn around and call the general getArcs interface.

> Mozilla's composite RDF sources [2] as well as commands look very
> application specific to me. Note that the notion of a datasource has
> inherent specificity in it. I prefer speaking of RDF models at a more
> fundamental level. You can always have:
>
> interface ObservableModel extends Model {
>    void addObserver(...);
>    ...
> }
> interface ActiveModel extends Model {
>    void executeCommand(...);
>    ...
> }

Looks clean to me.

> In principle, every (Java) object could implement the Resource
> interface. Why *must* a Model be Resource?

Because a model is a first class concept and all first class concepts should
have a URI. because I want to be able to have a property on a arc/statement that
says what model it was lexically/structurally contained in.  Because I want to
have remote models and then how do I refer to them?

What do you see as the negative repercussions of giving a model a URI? In the
case of pure XML/RDF documents its simply the URI of the document.

I'll try for comments on the Model API at a later time.

Cordially from Corvallis,

Gabe
http://www.jfinity.com/gabe

Received on Monday, 15 November 1999 11:42:09 UTC