Semantics of RDF API

As part of an exercise in understanding RDF, I have been implementing the
RDF API with the models stored in a relational database.

The current API proposes that the result of a query on a model is another
model.  Consider the following code fragment:

void f(Model m1, Statement s, Resource r)
{
	// create a new model by querying m1

	Model m2 = m1.find(null, r, null);

	// add statement s to m2

	m2.add(s);

	// is statement s in m2?

	if (m2.contains(s))
		print("m2 contains s");

	// is statement s in m1?

	if (m2.contains(s))
		print("m1 contains s");
}

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?

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?

Brian McBride
Hewlett Packard Laboratories, Bristol.

Received on Wednesday, 22 March 2000 17:05:23 UTC