Re: TriG and default graphs

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 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.

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).

	Andy

>
> Pat
>
>>
>> Best, Yves
>>
>>
>> ----------------------------- 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
>
>
>
>
>
>

Received on Wednesday, 24 October 2012 20:47:33 UTC