Re: Observations (named graphs, blank node closures)

If i understand right, it  is  not the same as in my example

In my example I was binding the reification node, something defined in 
the standard, and that can be used to define the context of that triple 
with ease (you got a node, you can attach metadata to it, simple).

In the example you give the fuzzy value  must be the same for each 
triple in the graph. So in case of continuous values you would might end 
up with single GRAPH per triple. Evan admitting this was ok (And useful) 
i get the impression things complicate much more.
For example if one had to define another context called "color" (on top 
of the fuzzy on).

By using the RDF standard reification you just add the property red 
where appropriate and when querying for fuzzy >0.7 and not red you 
simply add "and not (?r hasColor "Red")" to the previous query in my 

in the named graph + graph keyword...
First you have to duplicate the triples. They must appear both in each 
of their individual graphs related to their fuzzy value then in each 
graph related to the color. (since of course color and fuzzy value are 
independent from each other).
Then when querying you must come up with support for intelligent merging 
of results,
First you ask from the graphs who have fuzzyvalue>5 a list of candidate 
triples, then you ask from the graphs with the color a list of red 
triples, then you must subtract the 2 sets.
.. I hope i am exaggerating and is really much simpler than this  :-)


 >>Wouldnt it be fairly simple to add an automatic binding to the
 >> "statement" as a 4th node for each triple and this to bind this to the
 >> reification node/s?
 >> Example
 >> SELECT ?name ?mbox ?date WHERE
 >> (?g dc:publisher ?name ?triplecontext)
 >> (?g dc:date ?date )
 >> (?triplecontext fuzzyont:certainty ?fuzzyval) and ?fuzzyval <0.8
 >> with ?triplecontext binding to the reification node of the said triple.
 >> (if any)

 >The named graphs stuff asside, this is what the GRAPH keyword does.
 >eg. your example above becomes:
 >SELECT ?name ?mbox ?date WHERE
 >       GRAPH ?triplecontext (?g dc:publisher ?name)
 >      (?g dc:date ?date ) (?triplecontext fuzzyont:certainty 
?fuzzyval) and ?fuzzyval <0.8
 >My store is one of those that supports triple context via quads, 
currently using exactly the syntaxic construct you give abover. However 
I >prefer the GRAPH keyword for readability, unambiguity and 
extensibility. - Steve

Received on Sunday, 20 February 2005 15:58:43 UTC