RE: SOURCE - Choosing what to query and querying the origin of statements

Andy Seaborne wrote:
> -------- Original Message --------
>> From: jos.deroo@agfa.com <>
>> Date: 12 November 2004 00:28
>> 
>> Dan Connolly wrote:
>> [...]
>> 
>>> I don't understand "Any variable that is not bound must not
>>> match..."
>>> below.
>> [...]
>> 
>>>> Any variable that is not bound must not match another variable
>>>> that is not bound.
>>> 
>>> I don't understand that sentence, even after studying the example
>>> a few times. Hmm.
>> 
>> I also don't understand that sentence.. rather I'am sure that
>> "Any variable that is not bound must match another variable that
>> is not bound."
>> 
>> 
>> The main issue I see with SOURCE is where Dave writes
>> 
>>>>  SOURCE ?var (?s ?p ?o)
>>>> 
>>>> When SOURCE ?var is given before a triple, the variable will be
>>>> bound to all of the known *Graph Names* for that triple.
>> 
>> i.e. to implement SOURCE we use a bound ?var in
>> ?var.log:semantics log:includes {?s ?p ?o}.
>> I have explored alternative implementations
>> but was loosing..
> 
> Jos,
> 
> I find this feedback very useful - thanks.
> 
> How do you approach the issue that the triples in the subgraphs appear
> both as a subgraph and in the RDF merge of the collection of graphs?  I
> can't see a way in N3 to have this effect.

In for instance proofs we have many subgraphs and we basically
relate them using properties such as e.g. log:implies, e:evidence
such as in

{{:CRAB rdfs:subClassOf :SEAFOOD}
     e:evidence <http://www.agfa.com/w3c/euler/deb.n3#_5>. 
 {:Tony a :CRAB}
     e:evidence <http://www.agfa.com/w3c/euler/deb.n3#_4>} => {
{:Tony a :SEAFOOD}
    e:evidence <http://www.agfa.com/w3c/euler/rdfs-rules.n3#_59>}. 

where e:evidence is used to say that subject graph has an evident
relationship with object graph either as fact or as conclusion of rule
(so it is kind of implementation of SOURCE)


> A way of modeling it might be:
> 
> Initialization:
> Read all graphs and also create formulae for all subgraphs (yes -
> duplication :-()
> Assert the relationships between the collection of graphs.
> 
> This isn't log:semantics for the reasons you point out.
> 
>   <uri> log:semantics ?g .
>   <uri> q:semantics ?g .
> 
> now q:semantics is a regular property (not understood by the system) and
> can be handled as usual.  Conveniently, these ?g are not variables
> mentioned in the SPARQL query so can be any kind of object - like a
> formula.
> 
> I tried:
> -----------------
> @prefix : <#> .
> @prefix log: <http://www.w3.org/2000/10/swap/log#> .
> 
> ## Data
> :a :b :c .
> :d :e :f .
> <u1> :semantics { :a :b :c }  .
> <u2> :semantics { :d :e :f }  .
> 
> ## Query 1
> @forAll :C .
> { ?v.:semantics log:includes { :a :b :C } } => { :xx :b  :C } .
> ## Query 2
> { :d :e ?D } => { :yy :e  ?D } .
> 
> -----------------
> with cwm -think -data 
> and got:
>     :a     :b :c .
>     :d     :e :f .
>     :xx     :b :c .
>     :yy     :e :f .
> 
> 
> 
> I can't see a way of removing the duplication of reading into the global
> graph and the formulae as N3 keeps these distinct.  A "log:merge"
> property that did the right thing might be a way to go.
> 
> Just a thought.

am still thinking :)
thanks Andy

jos
 
>                Andy
> 
>> 
>> --
>> Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/

-- 
Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/

Received on Saturday, 13 November 2004 22:24:14 UTC