- From: Andy Seaborne <andy.seaborne@epimorphics.com>
- Date: Thu, 27 Sep 2012 12:59:02 +0100
- To: public-rdf-wg@w3.org
On 27/09/12 12:52, Steve Harris wrote: > 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. Lee's claim was that the default graph was "perhaps not widely used." and "it's a mistake to specify that anything important be put in that graph." I was commenting that it's not "compatibility" when there is an important use case. Andy > >>>> 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 >
Received on Thursday, 27 September 2012 11:59:30 UTC