- From: Steve Harris <steve.harris@garlik.com>
- Date: Wed, 29 May 2013 19:47:59 +0200
- To: RDF WG <public-rdf-wg@w3.org>
- Message-ID: <2602681D-839B-4B6A-AD56-D429983AB941@garlik.com>
[ as a side note I find it bizarre that I'm having to advocate NOT changing a 14 year old, industrially deployed spec, at the 11th hour of the standardisation process, to add a feature that's used by a tiny minority of deployed systems - if anything was to strike an outsider as peculiar about this WGs process, it would surely be this feature ] TL;DR: don't mess. We know that bNode graph identifiers are possible (I've designed a system myself that had them) and that there are usecases that are addressed by it, but I've not heard anything yet that can't already be addressed using RDF/SPARQL as it stands. It is the opinion of some people that bNodes as graph identifiers address it better, in some way, but that's another matter. There are however some costs to extending RDF (datasets) to require that bNodes be usable as graph identifiers: * We (Experian) have invested millions of dollars in our RDF engine - it's very tightly optimised to the current specs, and opening up the space of graph identifiers from a single class (URIs) to two classes (URIs and bNodes) would have a significant engineering, and storage cost. Put simply, we wouldn't do it, and would just step away from later RDF specs, becoming an RDF/SPARQL flavoured graph database. * RDF is already too complex for people coming into it to learn easily. Every time we add a new feature to the language we increase the barrier to entry. * There's no practical way to refer to long lived bNodes in SPARQL (without enforced skolemisation), people will import datasets with bNode graphs, and then realise they can't isolate their data (presumably after posting on stack overflow or similar :) ). The following will not retrieve your original data* and this will just promote more confusion: Data: _:abc { :s :p :o } Query: SELECT * WHERE { GRAPH _:abc { :s ?p ?o } } you could possibly do something like: SELECT * WHERE { GRAPH ?g { :s ?p ?o } } FILTER(STR(?g) =abc") That's pretty inconvenient, in many ways, and isn't required to work by SPARQL 1.1. It is only possible at all in systems that preserve bNode labels, which is not required. * Confusion with bNodes-in-graphs, and bNodes-as-graph-identifiers - the discussion seems to assume that they're separate kinds of thing, maybe with identifier bNodes not being existential variables? Which ever way it goes the relationship between bNodes-in-graphs, and bNodes-identifying-graphs is going to be complex. * Of all the extensions that are implemented by a small number of systems as an extension, this seems like an odd one to pick. IMHO there are far more serious problems with RDF. There is a cost (to this group, and the wider community) of any changes, so lets pick our battles wisely. * There's very little implementation experience - compared to the other things we're standardising: URI quads, bNode skolemisation, Turtle, NQuads. It's not clear how far the existential variable-ness should extend - do we sanction graph leaning? Do URI-identified graphs infer identical graphs identified by bNodes? If not, why not? What do bNodes with a given label, in graphs identified by a bNode with a different label refer to, etc. _:abc { } _:def ( } One graph, or two, or undefined? I don't think we know the right answer yet. So, in summary, I think the cost is high, and the benefit is vanishingly small. Nothing stops people that feel they really need it adding them to RDF systems, as they have in the past. One counter argument is that JSON-LD will do it anyway, but that's fine - if it is widely used, it can be adopted into RDF 1.2, with plenty of implementation experience. In the meantime JSON-LD serialisers can skolemise when transforming JSON-LD into RDF - there's other places where the transform is lossy anyway, as far as I understand it. - Steve * this was possibly an error in the SPARQL 1.0 spec, but sadly the bNodes as variables feature is quite widely used, and many people argued in favour of the feature. -- Steve Harris Experian +44 20 3042 4132 Registered in England and Wales 653331 VAT # 887 1335 93 80 Victoria Street, London, SW1E 5JL
Received on Thursday, 30 May 2013 06:28:42 UTC