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

Le 08/04/2011 16:00, Richard Cyganiak a écrit :
> On 8 Apr 2011, at 14:29, Antoine Zimmermann wrote:
>> how one can say that the content of a g-box at a certain point in time is a certain g-snap?
>> If named graphs are in fact named g-box, then how can one relate this name to the content at a certain point in time (for instance, to talk about a certain version of the g-box)?
>
> <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>.

> (Or use another vocabulary with stronger versioning semantics instead of DC)
>
>> 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?

>> 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 opinion at the moment is that we use graph literals for g-snaps (so we don't have to give them names, they are fully defined by their lexical value)
>
> How do I say that a certain unnamed literal g-snap contains 123 triples?

You don't. The idea is that we only refer to g-boxes. g-snaps are given 
by their triples explicitly.

>
>> and we name g-boxes. That is, in TriG:
>>
>> :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.

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

Received on Friday, 8 April 2011 14:13:47 UTC