- From: Bob MacGregor <macgregor@ISI.EDU>
- Date: Sat, 4 Jan 2003 13:11:08 -0800
- To: seth@robustai.net
- Cc: www-rdf-interest@w3.org
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