W3C home > Mailing lists > Public > www-rdf-interest@w3.org > March 2000

Re: Semantics of RDF API

From: Sergey Melnik <melnik@db.stanford.edu>
Date: Thu, 23 Mar 2000 15:23:03 -0800
Message-ID: <38DAA757.3BADE3D3@db.stanford.edu>
To: "McBride, Brian" <bwm@hplb.hpl.hp.com>
CC: "'www-rdf-interest@w3.org'" <www-rdf-interest@w3.org>
"McBride, Brian" wrote:
> As part of an exercise in understanding RDF, I have been implementing the
> RDF API with the models stored in a relational database.
> [...]
> In the case of an in-memory implementation of a model, it would be natural
> to implement a model as a 'set' of statements.  When executing the find
> call, a new 'set' would be created and returned.  When the add call is made,
> statement s would be added to the set and m2.contains(s) would return true.
> In a relational database implementation where the model may contain a very
> large number of statements, it seems natural to create a view onto the
> database which encodes the query.  This enables the application to
> efficiently refine the query and in-memory structures need only be created
> when the application enumerates a model.  In this case however, after the
> add call is made, m2.contains(s) will only return true if s satisfies the
> original query - i.e. if it has r as its predicate.
> Further, in my RDBMS implementation, adding s to m2, may also add it to m1,
> which may not be the case for an in memory implementation.
> The consequence is that an RDBMS implementation done this way will have
> different behaviour from an in memory implementation.  What do folks think
> about this?

You hit a typical view maintenance problem. The simplest solution
probably would be to introduce read-only models to prevent such
anomalies from happening. A more general solution would subclass
VirtualModel to provide methods necessary to distinguish between
different update behaviors.

> I'm also interested in more powerful queries than the current API can
> support.  Is there any past or ongoing work I should be aware of in this
> area?

This particular API (see Dan's comments about its position in the RDF
world) does not address querying. In the API this would be reflected
having an interface like "QueryableModel" with the corresponding
As to powerful queries: some months ago I implemented a Datalog-like
query language for RDF. The queries themselves are represented in RDF.
Execution is done using Stefan Decker's SiLRI engine. Current
implementation operates only on in-memory models though.

BTW: a neat proposal for an SQL-like RDF query language was mentioned on
this list a while ago...

Received on Thursday, 23 March 2000 18:15:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:29 UTC