W3C home > Mailing lists > Public > public-rdf-wg@w3.org > October 2012

Re: TriG and default graphs

From: Steve Harris <steve.harris@garlik.com>
Date: Thu, 25 Oct 2012 15:31:45 +0100
Cc: public-rdf-wg@w3.org
Message-Id: <CA71CDCC-250B-456C-A4D6-FA9C99185471@garlik.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:04:22 UTC