- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Fri, 8 Apr 2011 16:34:19 +0100
- To: antoine.zimmermann@insa-lyon.fr
- Cc: public-rdf-wg@w3.org, Ian Davis <me@iandavis.com>
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/
Received on Friday, 8 April 2011 15:34:47 UTC