- From: Steve Harris <steve.harris@garlik.com>
- Date: Thu, 25 Oct 2012 15:31:45 +0100
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: public-rdf-wg@w3.org
On 24 Oct 2012, at 21:47, Andy Seaborne wrote: > > On 24/10/12 18:25, Pat Hayes wrote: >> >> On Oct 24, 2012, at 11:29 AM, Yves Raimond wrote: >> >>> Hello! >>> >>> Just jumping on the last point that was mentioned in today's >>> telecon, about possibly not providing any statements about what to >>> do with a TriG default graph. I have the feeling that not doing >>> that actually defeats the point of having a default graph at all. >>> >>> If we can't get to an agreement on that first point, I'd really >>> like to understand what the rationale is behind supporting default >>> graphs in TriG, apart from backward-compatibility. When used at the >>> BBC, default graphs have proven to be a very confusing feature, and >>> not having any statement on what do with them would only add to the >>> confusion. > > You don't have to use the default graph. I've never been a fan of this argument… every feature in a spec adds to the complexity of teaching it. >> I think the rationale was that SPARQL queries might just be directed >> to a dataset without specifying a graph name, and the default was >> there to catch those queries. (The entire idea of datasets was >> introduced by the SPARQL group, so it reflects their concerns more >> than those of publishers.) The "default=metadata" meme came along >> later, and doesn't fit so well with the original motivation. > > Yes. The common case is query of one graph. So as have a uniform treatment of query, datasets have a default graph. A dataset of just the default graph is the way to query a single graph. > > Also, the default-graph-as-union-graph fits this model. If it (the union) were a named graph then life gets confusing, albeit finite. I would hope/imagine that default-graph-as-union implementations wouldn't publish the union in TriG anyway. > Like all good things, the design is a compromise. > >>> All the dataset metadata that is supposed to go in that default >>> graph could perfectly go in another named graph, e.g. identified by >>> the URI of the sd:Dataset in the SPARQL end-point you're generating >>> a TriG dump from, or the URI of the TriG file itself. Personally, >>> I'd favour a 'flat' version of TriG, where everything is a named >>> graph. > > Yes - you can do that. Nothing stops you. At least it isn't a fixed "name" (which wouldn't be a name). > > It has to worry about the fact there there isn't a URI for the dataset - there are many; there always are - or forcing the app to also go look in the service description as well. > >> Which also aligns better with the quad store model of datasets, of >> course. But again, quad stores were a new implementation detail when >> SPARQL was being conceptualized. > > And systems can be a quad table and a triple table. (Some apparently use a hidden name in the quad table which works equally well). Quad stores were an old idea when SPARQL 1.0 was started, but not all RDF query systems we're/are quad based. I get the impression that triple-table based stores are becoming increasingly unusual, but that may well not be correct. - Steve >>> >>> ----------------------------- http://www.bbc.co.uk This e-mail (and >>> any attachments) is confidential and may contain personal views >>> which are not the views of the BBC unless specifically stated. If >>> you have received it in error, please delete it from your system. >>> Do not use, copy or disclose the information in any way nor act in >>> reliance on it and notify the sender immediately. Please note that >>> the BBC monitors e-mails sent or received. Further communication >>> will signify your consent to this. ----------------------------- >>> >> >> ------------------------------------------------------------ IHMC >> (850)434 8903 or (650)494 3973 40 South Alcaniz St. >> (850)202 4416 office Pensacola (850)202 >> 4440 fax FL 32502 (850)291 0667 >> mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes >> >> >> >> >> >> > -- Steve Harris, CTO Garlik, a part of Experian +44 7854 417 874 http://www.garlik.com/ Registered in England and Wales 653331 VAT # 887 1335 93 Registered office: Landmark House, Experian Way, Nottingham, Notts, NG80 1ZZ
Received on Thursday, 25 October 2012 14:32:13 UTC