Re: Labelled graphs

On Wed, 2012-04-25 at 09:02 -0400, David Wood wrote:
> Hi all,
> 
> On Apr 25, 2012, at 07:59, Sandro Hawke wrote:
> 
> > On Wed, 2012-04-25 at 13:34 +0200, Ivan Herman wrote:
> >> On Apr 25, 2012, at 12:51 , Sandro Hawke wrote:
> >> 
> >>> On Wed, 2012-04-25 at 11:08 +0100, Steve Harris wrote:
> >>>> On 24 Apr 2012, at 13:04, Sandro Hawke wrote:
> >>>>> 
> >>>>>>> * When the same label is used multiple times in the same dataset, the
> >>>>>>> graph is
> >>>>>>> assumed to be the union of the graphs labeled with it
> >>>>> 
> >>>>> This is the "partial-graph semantics" view, which I can live with, but
> >>>>> some people have expressed opposition.  We should probably try some
> >>>>> straw polling on it.
> >>>> 
> >>>> The choice here needs to be made carefully, to avoid unintended consequences on implementations, and data generation processes.
> >>>> 
> >>>> The corner cases are around bNodes (aren't they always), e.g.
> >>> 
> >>> I believe you're talking about a different issue here.  The question of
> >>> the scope of bNode labels comes up whether we have partial- or
> >>> complete-graph semantics.
> 
> Can this be resolved by stating that blank nodes have a scope of the default graph where the default graph is a union and a scope limited to their own graphs if there is no union graph?

Hmmm.  That addresses some use cases, but not all.   For instance, if
you're using named graphs to track the provenance of a single graph,
then it'll work, because that single graph can be the default graph.
But if you want to track the provenance of several graphs, without
asserting them, then it doesn't work.

   -- Sandro

> Regards,
> Dave
> 
> >>> 
> >>> 6.1 says the scope of bNode labels is the document (or dataset, I
> >>> suppose).  I know that gives you a memory cost, but it's important for
> >>> several use cases, such as Keeping Inferred Triples Separate.
> >>> 
> >>> There are some SPARQL test cases for this here:
> >>>       http://www.w3.org/2011/rdf-wg/wiki/Graphs_Design_6.1#Blank_Nodes
> >>> 
> >>> I don't think you can test for it with trig entailment unless you have a
> >>> way to get at the triples inside the named graphs and exposing them to
> >>> RDF semantics.  Folks have been proposing doing that by flagging the
> >>> dataset as a default-is-union dataset; if you can do that, then you
> >>> could ask:
> >>> 
> >>>       Does
> >>>               @default-is-union
> >>>               <u1> { _:x <b> <c> }
> >>>               <u2> { _:x <b> <d> }
> >>>       entail
> >>>               { _:y <b> <c>,<d> }
> >>> 
> >>> I claim the answer should be "yes".
> >> 
> >> 
> >> I must admit I am not sure what http://www.w3.org/2011/rdf-wg/wiki/Graphs_Design_6.1#Blank_Nodes (ie, that blank nodes have a file scope) mean eg, in terms of semantics. 
> > 
> > I don't know how the scope of blank node labels is expressed in the RDF
> > semantics.   If you want, I can try to figure it out.
> > 
> >> If I look at the more abstract level
> >> 
> >> (D, (<u>,G), (<v>,H))
> >> 
> >> with G and H being different graphs, what does it mean that they share a blank node?
> > 
> > If I understand right, in the RDF Semantics, two "graphs" can't share a
> > blank node.  That's why in 6.1 I said you can/should think about D, G,
> > and H as subgraphs of some other graph that contains them all.   I could
> > draw a diagram that made it pretty clear how they shared a node --
> > they'd have arcs going to/from the same little node-circle in the
> > diagram, and the different graphs would be indicated by D being drawn
> > with blue arcs, G with green arcs, and H with yellow arcs. 
> > 
> >> Put it another way: if you have a TriG file  
> >> 
> >> <u1> { _:x <b> <c> }
> >> <u2> { _:x <q> <r> }
> >> 
> >> what is the abstract RDF dataset for this? 
> > 
> > I don't know how to type that dataset in ascii.  As a diagram, it looks
> > like the diagram for { [] <b> <c>; <q> <r> } except that the "b" arc is
> > colored so we know it's in u1 and the "q" arc is colored so we know it's
> > in u2.
> > 
> >> Unless of course all blank nodes are skolemized by TriG before generating a dataset
> > 
> > This global-scope-blank-nodes rule would show up in a skolemizing test
> > case.   I'm not sure how we're going to write down these test cases, or
> > if we're going to define Skolemizing for trig.  But if we did:
> > 
> > your example TriG file COULD be Skolemized to:
> > 
> >  <u1> { <http://example.org/.well-known/genid/1 <b> <c> }  
> >  <u2> { <http://example.org/.well-known/genid/1 <b> <c> }
> > 
> > but it COULD NOT be Skolemized to:
> > 
> >  <u1> { <http://example.org/.well-known/genid/1 <b> <c> }  
> >  <u2> { <http://example.org/.well-known/genid/2 <b> <c> }
> > 
> >    -- Sandro
> > 
> > 
> > 
> 
>

Received on Wednesday, 25 April 2012 13:23:10 UTC