Re: RDF dataset semantics again

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.

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

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.


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

Received on Thursday, 23 August 2012 13:08:49 UTC