- From: Ivan Herman <ivan@w3.org>
- Date: Wed, 28 Mar 2012 12:05:54 +0200
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: public-rdf-wg@w3.org
- Message-Id: <1444DB1A-011B-4DF1-8DA0-3D7A76E17D62@w3.org>
On Mar 28, 2012, at 11:36 , Andy Seaborne wrote: > Looks very interesting. > > I think it can usefully be decoupled from syntax. It could be expressed in terms of an RDF dataset, a set of default graph and zero or more (label, graph) pairs. Or a set of quads, but grouping quads-of-the-same label into graphs is likely to be easier. > > I don't think the syntax is an important part of the idea - it's good to explain it in syntax, and tests, but the essence is not syntax and While grounded in syntax, it's going to be hard to bridge the gap with other discussions. > > So we could have parallel strands of work: > > 1/ Define TriG, N-Quads as syntax for bytes -> quads -> datasets > > 2/ Define 6.1 as datasets -> entailments and semantics. And the question is how far should this working group go, in view of the various differences in opinion and such. I think Sandro's proposal is a bit more than syntax. It is - notion of (label,Graph) - a rough categorization of what 'label' may be in terms of RDF classes, with very shallow and informal semantics of what that really means One way to go is to adopt that line as part of a Rec, ie, - define those 2-3 classes that are in the text as part of the RDF concepts - define a syntax for this in term of TriG, maybe N-quads as a separate rec and leave the semantic discussion (eg, Antoine and Pat's long thread) out of the Rec, though it would be great to capture that as a Note. I just try to be realistic here: is there any way we can go beyond that, considering the track record of the past months? Ivan > > Andy > > > > On 28/03/12 03:23, Sandro Hawke wrote: >> I've written up design 6 (originally suggested by Andy) in more >> detail. I've called in 6.1 since I've change/added a few details that >> Andy might not agree with. Eric has started writing up how the use >> cases are addressed by this proposal. >> >> This proposal addresses all 15 of our old open issues concerning graphs. >> (I'm sure it will have its own issues, though.) >> >> The basic idea is to use trig syntax, and to support the different >> desired relationships between labels and their graphs via class >> information on the labels. In particular, according to this proposal, >> in this trig document: >> >> <u1> {<a> <b> <c> } >> >> ... we only know that<u1> is some kind of label for the RDF Graph<a> >> <b> <c>, like today. However, in his trig document: >> >> {<u2> a rdf:Graph } >> <u2> {<a> <b> <c> } >> >> we know that<u2> is an rdf:Graph and, what's more, we know that<u2> >> actually is the RDF Graph {<a> <b> <c> }. That is, in this case, we >> know that URL "u2" is a name we can use in RDF to refer to that g-snap. >> >> Details are here: http://www.w3.org/2011/rdf-wg/wiki/Graphs_Design_6.1 >> >> That page includes answers to all the current GRAPHS issues, including >> ISSUE-5, ISSUE-14, etc. >> >> Eric has started going through Why Graphs and adding the examples as >> addressed by Proposal 6.1: >> http://www.w3.org/2011/rdf-wg/wiki/Why_Graphs_6.1 >> >> -- Sandro (with Eric nearby) >> >> > ---- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 FOAF: http://www.ivan-herman.net/foaf.rdf
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Wednesday, 28 March 2012 10:04:59 UTC