Re: Labelled graphs

On Apr 30, 2012, at 09:24 , Pat Hayes wrote:
[snip]

> 
>> 
>> 
>> 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.) 
> 

I am surprised but I of course believe you:-)

However... Are we sure that existing systems (RDFLib, Jena, you-name-it) are prepared for this? Many of those have some sort of a named graph/quad store implemented already, possibly with TriG input, and it would be good to know whether this would force them to re-engineer their blank node processing workflow...

Ivan



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


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

Received on Monday, 30 April 2012 07:36:28 UTC