W3C home > Mailing lists > Public > public-rdf-wg@w3.org > April 2012

Re: Labelled graphs

From: Pat Hayes <phayes@ihmc.us>
Date: Mon, 30 Apr 2012 02:24:53 -0500
Cc: Sandro Hawke <sandro@w3.org>, Steve Harris <steve.harris@garlik.com>, public-rdf-wg WG <public-rdf-wg@w3.org>
Message-Id: <BE66369C-052D-497F-9C48-DC98EB0F9690@ihmc.us>
To: Ivan Herman <ivan@w3.org>

On Apr 25, 2012, at 6:34 AM, 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.
>> 
>> 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. 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?

Exactly what it says. There is nothing in the 2004 RDF specs that prevents two different and distinct graphs from sharing a blank node. (As to whether there SHOULD have been something preventing this, maybe so: but in fact, there isn't.) 

> 
> 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?

Again, exactly what you would expect. There are two graphs each with one triple, and the first item in both triples is the same blank node. In this example you have two graphs, two triples, and a total of five nodes (ignoring the graph names).

Pat

> Unless of course all blank nodes are skolemized by TriG before generating a dataset
> 
> Ivan
> 
> 
> 
>> 
>>> <G1> {
>>> <a> <b> _:b1 .
>>> }
>>> ...
>>> <G1> {
>>> <c> <d> _:b1 .
>>> }
>>> ...
>>> <G2> {
>>> <c> <d> _:b1 .
>>> }
>>> 
>>> Is that one, two, or three bNodess, an error, undefined, or...?
>> 
>> Under 6.1 with complete- or partial- graph semantics, it's one bNode.
>> Under complete-graph semantics it's an inconsistent dataset.
>> 
>>   -- Sandro
>> 
>>> If it's an RDF Union between graphs then there's one bNode, between graphs with the same label, then there's two, if it's a Merge, then there's three (I believe).
>>> 
>>> Internally our systems maintain a map from bNode labels to internal skolem constants when parsing (noting that not all systems do this, but many do), and it would be good to be able to discard that map when we hit a "}" token.
>>> 
>>> If we have either kind of union semantics that map can get extremely large when parsing a large TriG file, and more to the point you have to maintain a set of maps for all graphs in the document, just incase the graph is mentioned again further down the document.
>>> 
>>> - Steve
>>> 
>>>>>> The appears to be in line to the 6.1 design, with some
>>>>>> modifications/specializations.
>>>> 
>>>> I wonder if we can't adopt something close to 6.1, close pretty much all
>>>> the open GRAPHS issues, then open a few new ones, like
>>>> partial-vs-complete-graph semantics and whether/how to define
>>>> GraphContainer.
>>>> 
>>>>  -- Sandro
>>>> 
>>>>>> Guus
>>>>> 
>>>>> (sorry for the delay - was not at work)
>>>>> 
>>>>> Guus - nice summary.
>>>>> 
>>>>> 	Andy
>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
> 
> 
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf
> 
> 
> 
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Monday, 30 April 2012 07:30:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:04 UTC