Arguing against quads

On Saturday, January 4, 2003, at 06:03 AM, Seth Russell wrote:
> I think you're on the something here.   But what does "it" in your 
> paragraph above refer to ?  Does "it" refer to a Jena Model ?   And if 
> so, and we have made ~it~ is a resource, well then ~it~ should have a 
> URI (if only internally), right?   But then the problem is you don't 
> have a triple anymore, you got a quad.    So why not just cop to it .. 
> we need quads ... not triples.

Nope, no quads.  'Quad' implies that instead of 3-place pattern
matches, we perform 4-place pattern matches.  However, we don't
want the 4-th place argument (the 'it'), to have first class status.

We want the access to the 'it' argument to be abstracted,
so that implementers can experiment with implementations without
making their applications overly dependent on the way the 'it'
is handled.  In general,  indexing on the 'it' place will be different 
--
more sophisticated uses will involve matching against ranges or
taxonomies.   Also, the notion of context is not well-defined --
it  might involve temporal ranges, probabilities, positioning within
a taxonomy of worlds, fuzzy trapezoids,  combinations of these, etc.

So the argument is that triple stores should provide a handle (the 'it')
that will enable implementors working one level up to add
mechanisms that would be less efficient without it.  Ideally, we
would just let the triple store implementers do all of the work
for us, but at the rate progress on contexts is progressing, we
will all be dead before we have them built into the triple store
manager.

There are two ways that progress happens in the KR field.  One
is that nice theoretical models are devised, and then implementers
figure out efficient implementations for them.  The other is that
implementers play around with various things, and find out
experimentally what users find useful, and then later (possibly much
later), the resulting semantics gets formalized.  Contexts fall into 
this
latter category.  Outer joins for databases are a good example of
a case where the second approach prevailed.

Note that what we are arguing for may be trivial from an implementation
standpoint.   All we want is a new pair of  'getIt' and 'setIt methods 
on
RDF statement objects.  I say 'may' because statement identity 
considerations
could mean that internal maintenance of the storage for the 'it' values 
is
not completely trivial.

Cheers, Bob

Received on Saturday, 4 January 2003 16:09:17 UTC