Re: A use case for graph literals: Schemapedia (ISSUE-5)

Hi Antoine,

On 11 Apr 2011, at 12:47, Antoine Zimmermann wrote:
> If I have:
> 
> <a-gbox>  { :x :y :z . :a :b :c }
> 
> how do I know that <a-gbox> is referring to exactly those two triples and not to some graph which contains them at the moment (but may change), or even to some graph that entails these 2 triples at the moment?

For your convenience, I'll copy-paste the answer *again* ;-)

>> <my-immutable-g-box>  { ... content of the immutable g-box ...}
>> 
>> <my-immutable-g-box>  a ex:VersionedSnapshot; ex:timestamp "2011-04-08"^^xsd:date
>> 
>> (where ex: is a use case specific vocabulary that we don't have to define in this WG)


> If <a-gbox> is immutable, the relation between the name and the 2 triples must be strict: it has to be exactly those triples, not a superset, not a set which entails them. I understand how mutable and immutable can be handled in the same way, just by taking care that the immutable g-boxes never change. But I do not see how you can do it if the syntax expresses a subset of the underlying graph.

I don't suggest that the syntax should express a subset of the underlying graph. My position is that it should express exactly the graph associated with the IRI.

Best,
Richard



> 
> 
> AZ.
> 
>> 
>> Sorry, I thought that was clear:
>> 
>> <my-gbox/2011-04-08>  { ... content goes here ... }
>> 
>>>>> Another question is, how can one specify the differences between two versions of a g-box? For instance, g-box@2011-04-01 extends g-box@2010-04-01 by adding the triples { :x :y :z . :a :b :c .}.
>>>>> How can I explicit refer to these specific 2 triples if I can only talk about g-boxes?
>>>> 
>>>> Make a new g-box containing these two triples, and use some vocabulary to say that A=B+C
>>> 
>>> How do you make a gbox containing those two triples?
>> 
>> <name-of-the-g-box>  { ... two triples ... }
>> 
>>>>> As other people suggested, I have the impression that there are use cases for identifying g-boxes and use cases for identifying g-snaps.
>>>> 
>>>> I assert that all these use cases can be addressed by declaring some g-boxes immutable. One can have use case specific vocabularies that state which g-boxes are mutable and which not. Note that there is an isomorphism between g-snaps and immutable g-boxes.
>>> 
>>> Perhaps but you don't say how I define the content of an immutable gbox.
>> 
>> <my-immutable-g-box>  { ... content of the immutable g-box ...}
>> 
>> <my-immutable-g-box>  a ex:VersionedSnapshot; ex:timestamp "2011-04-08"^^xsd:date
>> 
>> (where ex: is a use case specific vocabulary that we don't have to define in this WG)
>> 
>>>>> :G1 { :a :b :c . :x :y "{:u :v :w.}"^^rdf:gsnap }
>>>> 
>>>> I don't understand what this is supposed to mean.
>>> 
>>> This is just a TriG document. At the moment, there is no well defined semantics for it, so I'm just using it at a syntax to somehow connect the URI of the g-box (G1) to a certain g-snap (between the outermost curly brackets). The literal inside that g-snap is just a typed literal, perfectly valid in RDF. A system does not necessarily need to understand that specific datatype, but the idea is to interpret this as a g-snap.
>>> 
>>>> You cannot write down a g-box. You can only write down a g-snap. The best you can do is saying that a g-box of a certain name has a certain g-snap as its content right now. Having two different syntactic constructs for writing down g-boxes and g-snaps is a confusing mess that solves no problem.
>>> 
>>> At some point either you should be able to talk about specific triples in g-boxes or in g-snaps. It is fine for me to have immutable g-boxes to be able to talk about fixed g-snaps, but I still need a way to make explicit the triples inside.
>> 
>> Right. For making explicit the triples inside a g-box (mutable or not), all you really need is the ability to write down<IRI, g-snap>  pairs.
>> 
>> Best,
>> Richard
>> 
>> 
>>> 
>>>> 
>>>> Best,
>>>> Richard
>>>> 
>>>> 
>>>>> 
>>>>> :G1 identifies a g-box which somehow is related^{1} to the g-snap:
>>>>> 
>>>>> :a :b :c .
>>>>> :x :y "{:u :v :w.}"^^rdf:gsnap
>>>>> 
>>>>> and "{:u :v :w.}"^^rdf:gsnap is identifying exactly the g-snap:
>>>>> 
>>>>> :u :v :w.
>>>>> 
>>>>> I can also say:
>>>>> 
>>>>> :G1 :earlierVersion [
>>>>>   :content "{:a :b :c .}"^^rdf:gsnap .
>>>>>   :atTime "2010-04-01"^^xsd:date .
>>>>> ]
>>>>> 
>>>>> 
>>>>> ----Footnote----
>>>>> {1}  I leave the relationship between :G1 and the content inside the curly brackets to a later email.
>>>>> 
>>>>> 
>>>>> AZ.
>>> 
>>> --
>>> Antoine Zimmermann
>>> Researcher at:
>>> Laboratoire d'InfoRmatique en Image et Systèmes d'information
>>> Database Group
>>> 7 Avenue Jean Capelle
>>> 69621 Villeurbanne Cedex
>>> France
>>> Tel: +33(0)4 72 43 61 74 - Fax: +33(0)4 72 43 87 13
>>> Lecturer at:
>>> Institut National des Sciences Appliquées de Lyon
>>> 20 Avenue Albert Einstein
>>> 69621 Villeurbanne Cedex
>>> France
>>> antoine.zimmermann@insa-lyon.fr
>>> http://zimmer.aprilfoolsreview.com/
>> 
> 
> 
> -- 
> Antoine Zimmermann
> Researcher at:
> Laboratoire d'InfoRmatique en Image et Systèmes d'information
> Database Group
> 7 Avenue Jean Capelle
> 69621 Villeurbanne Cedex
> France
> Tel: +33(0)4 72 43 61 74 - Fax: +33(0)4 72 43 87 13
> Lecturer at:
> Institut National des Sciences Appliquées de Lyon
> 20 Avenue Albert Einstein
> 69621 Villeurbanne Cedex
> France
> antoine.zimmermann@insa-lyon.fr
> http://zimmer.aprilfoolsreview.com/
>

Received on Monday, 11 April 2011 17:35:29 UTC