Re: RDF dataset semantics again

On Aug 23, 2012, at 8:08 AM, Antoine Zimmermann wrote:

> Le 23/08/2012 13:11, Sandro Hawke a écrit :
>> On 08/23/2012 05:57 AM, Antoine Zimmermann wrote:
>>> 
>>> 
>>> Le 22/08/2012 18:37, Sandro Hawke a écrit :
>>>> On 08/22/2012 12:30 PM, Antoine Zimmermann wrote:
>>>>> 
>>>>>> 
>>>>>> I could live with it if there were a syntactic sugar, probably
>>>>>> involving
>>>>>> curly braces. :-)
>>>>> 
>>>>> Yes, the syntax is not really practical.
>>>>> 
>>>> 
>>>> Indeed. But, yes, it's a nice way to think about the semantics. I
>>>> understood it to be a way the WG was not okay with.
>>> 
>>> 
>>> My impression was that the group found the idea reasonable, possibly
>>> appealing, but due to a total absence of implementation of this
>>> solution, and no experience with it thereby, it was not a good idea to
>>> standardise such a thing.
>>> 
>>> 
>> 
>> I don't recall hearing that, but it makes sense.
> 
> It's my own interpretation of the situation at that time, but I don't think we formalised this as a resolution.
> 
> 
>>>> One bit that doesn't quite work is that some of the use cases require
>>>> blank nodes to be shared between named graphs. That would be rather
>>>> strange with this literal-strings model.
>>> 
>>> 
>>> It is in principle possible to define the datatype such that the value
>>> space is not exactly the set of RDF Graphs, but rather "RDF Graphs
>>> where some bnodes can be labelled". The bnode labels are made disjoint
>>> from URIs, so they can be distinguished apart from normal names, but
>>> they would not be purely local to the graph.
>>> 
>> 
>> I'm not sure you'd need to change the value space. Existing (2004)
>> g-snaps can share bnodes, it's just the way the syntaxes are parsed
>> doesn't currently allow one to indicate that.
> 
> But it's never possible to know that two graphs share the same bnodes, as it is impossible to identify them in a RDF Graph.

Sandro is right, so we have to allow for the possibility that two graphs *might* contain the same bnodes (IMO, this is a bug in the 2004 specs). And we can even know this, if both graphs are found as subgraphs of one larger graph defined in a document whose scope covers bnode identifiers. 

> 
>> So, those graphs-in-quotes
>> would have to be parsed as some new kind of thing -- a
>> document-fragments, instead of a document. A little problem, IMHO, not a
>> big one.
> 
> For me, "bnode sharing" is not exactly about sharing bnodes in RDF Graphs. It is a case when you want to identify two bnodes in two distinct RDF graphs

By which I think you mean, two graphs found on the Web which do not have a common origin inside a single bnode identifier scope.

> , and consider that they can be unified when combining the two RDF graphs. In fact, it does not much matter whether the two bnodes are different, as long as you can indicate that they can be unified in a union/merge operation.
> 
> If I have { _:b  prop  _:c } and you have { :x  foo  _:b } and we decide that the two (_:b)s are unifiable, then it does not matter that they actually identify the same bnode. As long as you're cool with the fact that you want to unify them.
> 
> Think of bnodes as black marbles that have the exact same atomic structure. You cannot distinguish them, apart from their position. If you separate out a marble from a graph, and fix another marble there instead, nothing changes. The result is still a black marble at the same position. Anyway, they only indicate the existence of a thing, so one bnode is as good as any other.

Bose-Einstein versus Fermi-Dirac. I guess the Pauli exclusion principle works here also.

> 
> However, if I play with these marbles, building a very big graph, that I later record as Turtle, then put back the marbles in their pouch. And I'd like the day after to extend that big graph with more triples, I may have to assume that some of the marbles I'm using can be identified to the marbles I used the day before. And still it does not matter that I reuse the exact same marbles.

Except that you don't actually have a pouch to put them in, you just toss them back into the great big bag of marbles in the sky. And then when you come to get some more out, you *just might* get that very same marble again. So you have to be ready for this possibility when you write the formal definitions. (ThIs is why we had to define merging versus unioning and all that stuff, even though we didn't have bnode identifiers in the abstract syntax. LIke I said, a bug in the 2004 conceptual model.) 

Pat


> 
> 
>> IMHO we should at some point sketch out this solution and its
>> isomorphism to whatever we settle on. Maybe not actually assign a
>> vocabulary to it, lest people use it and not be interoperable.
>> Alternatively, it might be the way RDF/XML folks play in the named-graph
>> space. (That's a Time Permitting deliverable in our charter.)
> 
> Ivan drafted something a while ago where he defined a datatype for graphs. However, what I think made the document problematic, is that it was trying to address too many things at the same time. We could take out of Ivan's draft the part on defining the graph datatype, together with portions of the discussions in there, and propose it as a WG Note, maybe.
> 
> 
> AZ
> 
> 
>> 
>> -- Sandro
>> 
>>> 
>>> 
>>>> 
>>>> -- Sandro
>>>> 
>>>>>> 
>>>>>> - s
>>>>>> 
>>>>>>>> 
>>>>>>>> Another (uglier!) representation would be
>>>>>>>> <g> ex:hasGraph
>>>>>>>> <data:text/turtle;charset=UTF-8,%3Cs%3E%20%3Cp%3E%20%3Co%3E> .
>>>>>>>> 
>>>>>>>> Which would also allow you to make statements about the quoted graph
>>>>>>>> <data:text/turtle;charset=UTF-8,%3Cs%3E%20%3Cp%3E%20%3Co%3E> dc:date
>>>>>>>> "2012-08-22T14:29:23Z"^^xsd:dateTime .
>>>>>>> 
>>>>>>> +1
>>>>>>> 
>>>>>>>> 
>>>>>>>> - Steve
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>> 
>> 
>> 
> 
> -- 
> Antoine Zimmermann
> ISCOD / LSTI - Institut Henri Fayol
> École Nationale Supérieure des Mines de Saint-Étienne
> 158 cours Fauriel
> 42023 Saint-Étienne Cedex 2
> France
> Tél:+33(0)4 77 42 66 03
> Fax:+33(0)4 77 42 66 66
> http://zimmer.aprilfoolsreview.com/
> 
> 

------------------------------------------------------------
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 Thursday, 23 August 2012 19:32:07 UTC