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

Right, I was expecting this.
Then the question is, how do we define immutable g-boxes.

There have been several emails saying that:

<my-gbox/2011-04-08>  { :a :b :c }

means that <my-gbox/2011-04-08> contains *at least* ":a :b :c." Some 
saying that it contains *exactly* ":a :b :c." And some saying that it 
should mean <my-gbox/2011-04-08> *entails* { :a :b :c }.
If the gbox is immutable, it should be "exactly", and maybe "at least" 
or "entails" otherwise.

Perhaps we need a vocabulary for this: rdf:MutableGraph, rdf:ImmutableGraph.

Then, what is a graph which is not declared as mutable/immutable?

I don't find the answer "use immutable gbox" completely satisfying 
because it leads to several unanswered questions.


Le 08/04/2011 17:34, Richard Cyganiak a écrit :
> On 8 Apr 2011, at 15:13, Antoine Zimmermann wrote:
>>> <my-gbox>   dc:hasVersion<my-gbox/2011-04-08>   .
>>> <my-gbox/2011-04-08>   dc:date "2011-04-08"^xsd:date
>>
>> This does not tell me what is in<my-gbox/2011-04-08>.
>
> 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 Friday, 8 April 2011 15:51:08 UTC