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

Re: Putting metadata in the "default" graph Re: Dataset Syntax - checking for consensus

From: Steve Harris <steve.harris@garlik.com>
Date: Thu, 27 Sep 2012 12:52:49 +0100
Cc: public-rdf-wg@w3.org
Message-Id: <318C5CFE-A066-44E9-848B-B643FCDDE27E@garlik.com>
To: Andy Seaborne <andy.seaborne@epimorphics.com>
On 2012-09-27, at 12:24, Andy Seaborne wrote:
> On 27/09/12 12:13, Steve Harris wrote:
>> On 2012-09-27, at 12:08, Andy Seaborne wrote:
>>> On 26/09/12 17:41, Lee Feigenbaum wrote:
>>>> We need to support it for compatibility, but I think it's a
>>>> mistake to specify that anything important be put in that graph.
>>> There are two uses cases: you and Steve emphasis the complicated
>>> case of multiple graphs collected from many places.
>> If that's not the case, why are you bothering with named graphs?
> Because different customers have different requirements.  I come across both cases, but not necessary with the same data.

I can imagine that situation in theory, but what real-world usecase leads you to use named graph, but where the metadata applied to the whole document?

It seems like a corner case.

Database dumps are one possibility (but then you'd often have both dataset-level and graph-level metadata), but those are more commonly in nquads formant, from what I've seen.

>>> The simple case is one graph.  For that, making the publisher go
>>> through "naming" is just overhead for them.
>> But that's "just" RDF, isn't it? In that case I don't see the issue.
> Yes, it is, and SPARQL is an RDF query language.
> Requirement - publish data.
> The idea of a "TriG" sub-ecosystem and an "RDF" sub-ecosystem is not a happy thought.

Strongly agreed, though I don't think many people share this concern.

- Steve

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
80 Victoria Street, London, SW1E 5JL
Received on Thursday, 27 September 2012 11:53:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:07 UTC