- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Wed, 19 Dec 2012 12:34:16 +0000
- To: public-rdf-wg@w3.org
On 19/12/12 10:25, Pierre-Antoine Champin wrote: > > > > On Thu, Dec 13, 2012 at 8:07 PM, Ivan Herman <ivan@w3.org > <mailto:ivan@w3.org>> wrote: > > > On Dec 13, 2012, at 12:28 , Sandro Hawke wrote: > > > On 12/13/2012 06:35 AM, Ivan Herman wrote: > >> I find this a sensible compromise... > >> > > > > Me too. It seems to me basically what SPARQL does, and why it's > called the "default graph". > > > >> For Trig/Turtle this may not be formally relevant because, > afaik, Trig will have its own media type. > > > Well, I think it *does* have an impact, especially because Trig has its > own media type: > if you GET something from the web, expecting a single graph, and getting > some Trig (which you can tell immediately from the media-type), > then this gives you guidance on how to handle it. I think the issue is specific to JSON-LD which is trying to be a graph format and a dataset format, depending on whether there are any named graphs in a JSON-LD document. Treating a graph as a dataset has an issue about reading it into another dataset e.g. record the source location. Treating a JSON-LD document as a graph (because the app expects a graph), and, after some triples, gettign quads, is breaking the application assumption but conneg does not allow the app to specific in the JSON-LD case. Some systems (most?) differentiate between quads and triples, for example, always using quads with the location as graph slot. If you expect a graph and, after getting a lot of single graph data, you start getting quads/named graphs, your application has a problem. But if the app is dataset aware always, recording source location is different. Andy > > > >> But, for example, if an extension of RDFa is defined some day > including facilities for graphs, this is probably an approach to follow. > >> > > > > If we agree with this resolution of ISSUE-105, I might suggest > this is new information and warrants briefly re-visiting this issue: > > RESOLVED: In TriG, triples of the dataset's default graph MUST be > surrounded by curly braces. > > > > http://www.w3.org/2011/rdf-wg/meeting/2012-10-17#resolution_2 > > > > ... because with this approach it's much more natural to treat > the name-graph pairs as an ignorable addition to turtle. > > > > +1 > > > I would tend to agree, but I think I remember someone (Steve?) arguing > against it as they would like their parser to know from the start if > they are dealing with a graph or a dataset, even in the absence of > media-type... Which sounds like a reasonable use-case... > > pa > > > Ivan > > > -- Sandro > > > >> Ivan > >> > >> On Dec 5, 2012, at 13:13 , Markus Lanthaler wrote: > >> > >> > >>> While JSON-LD is a dataset syntax we expect that in most cases > it will be > >>> used to express simple graphs. This might become problematic if > a consumer > >>> is unable to process datasets -- even in the case where the > dataset consists > >>> of only the default graph. In JSON-LD we resolved this issue by > specifying > >>> that a consumer expecting a graph, MUST ignore everything but > the default > >>> graph. > >>> > >>> This allows publishers to expose their graphs in, e.g., both > JSON-LD and > >>> Turtle. Summarized, the behavior of a consumer would be as follows: > >>> > >>> Exposed | Expected | behavior > >>> ---------+------------+----------- > >>> Data set | graph | use default graph as graph, ignore rest > >>> Data set | data set | exposed = expected > >>> Graph | data set | use graph as default graph in dataset > >>> Graph | graph | exposed = expected > >>> > >>> > >>> This might have consequences on how data should be modeled > (what should be > >>> put in the default graph and what in a named graph) but that's > beyond the > >>> scope of a syntax. > >>> > >>> I would therefore like to propose to standardize this behavior > for all RDF > >>> data set syntaxes. > >>> > >>> > >>> Regards, > >>> Markus > >>> > >>> > >>> -- > >>> Markus Lanthaler > >>> @markuslanthaler > >>> > >>> > >>> > >> > >> ---- > >> Ivan Herman, W3C Semantic Web Activity Lead > >> Home: > >> http://www.w3.org/People/Ivan/ > >> > >> mobile: +31-641044153 <tel:%2B31-641044153> > >> FOAF: > >> http://www.ivan-herman.net/foaf.rdf > >> > >> > >> > >> > >> > >> > >> > > > > > ---- > Ivan Herman, W3C Semantic Web Activity Lead > Home: http://www.w3.org/People/Ivan/ > mobile: +31-641044153 <tel:%2B31-641044153> > FOAF: http://www.ivan-herman.net/foaf.rdf > > > > > >
Received on Wednesday, 19 December 2012 12:34:46 UTC