- From: Steve Harris <steve.harris@garlik.com>
- Date: Thu, 27 Sep 2012 12:52:49 +0100
- To: Andy Seaborne <andy.seaborne@epimorphics.com>
- Cc: public-rdf-wg@w3.org
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