W3C home > Mailing lists > Public > public-linked-json@w3.org > February 2013

Re: Blank Node Identifiers and RDF Dataset Normalization

From: Steve Harris <steve.harris@garlik.com>
Date: Tue, 26 Feb 2013 11:35:03 +0000
Cc: public-linked-json@w3.org
Message-Id: <2DEC9643-8CFA-4F95-82F1-87577EBC3503@garlik.com>
To: Dave Longley <dlongley@digitalbazaar.com>
On 2013-02-25, at 18:30, Dave Longley <dlongley@digitalbazaar.com> wrote:

> On 02/25/2013 12:09 PM, Steve Harris wrote:
>> There is categorically no valid argument that something along these lines is essential for such-and-such usecase, frankly that's nonsense as those usecases are already addressed by production systems in much more demanding environments, without those features.
> I'm not aware of production systems functioning in demanding environments that are using RDF datasets expressed in idiomatic JSON; the JSON-LD specification is about making that possible. I do believe the use case where developers would strongly prefer to refer to a graph without having to create and maintain a global identifier is a valid one. I would also argue that denying developers the ability to do this because it changes the way certain optimizations are implemented in existing systems isn't a very strong argument.

JSON-LD is just a surface syntax, it shouldn't have any bearing on the semantics unless something is wrong - RDF/XML is (supposed to be) idiomatic XML, and is also a natively tree format. I don't see how that's any different. If it is then there's likely some issue.

As a company we use a lot of JSON documents, both internally and externally, so I have a reasonable amount of indirect experience of it.

> I'm in a similar position to you with respect to another related use case: where an author would like to use a graph label to do something other than denote a graph. I don't really understand that or why it should be supported. If it's because the author doesn't or can't mint a new URL, then I would suggest that using a blank node identifier would solve the problem nicely. If that doesn't actually solve the problem, though, and they do really need to use a graph label that doesn't really denote the graph, I'd like to understand why. I don't think dismissing it as a solved problem by lots of other systems in production is necessarily helpful.

The consequences of the graph label always denoting a graph are quite severe, it rules out some common situations (e.g. naming the graph after the URI that we dereferenced, and making changes to the graph over time). It's also totally unenforceable, so what will happen to systems when they encounter data that doesn't follow the rule? This will inevitably happen given how difficult it is to ensure that it's always the case.

> If we are to "move way beyond the time where RDF is an 'emerging tech' only suitable for early-stage startups and academics", as you say, then I believe that we must embrace more common practices that occur outside the walls of its current use. Saying that developers should simply do something unnatural and/or prohibitive to solve their use cases will only continue to restrict the adoption of the technology by wider audiences.

My point was that RDF has already moved beyond that point, but not enough people in the WG acknowledge that. It's not /widely/ used in financial services, but we're certainly not the only users. We're also using RDF in a much more security sensitive, heavily regulated, and provenance critical product. The WG should respect the fact that there are deployed systems, and not randomly change things without a very good reason. Supporting one company's modelling decisions is not a very good reason, IMHO.

I personally don't believe that any of the other solutions (which don't require changing RDF semantics) that have been proposed are unnatural or prohibitive, though obviously unnatural is in the eye of the beholder.

There are other ways you could have modelled the data you're attempting to express which wouldn't require wholesale changes to RDF.

The RDF community has a poor history of including random features like this (without enough understanding of the consequences) which have far reaching consequences on implementations. e.g. rdf:Bag/Alt/etc., rdf:List, XMLLiterals, reification, plain literals, and some would say bNodes. Those badly thought out features have all cost the community dearly.

- Steve

Steve Harris
+44 20 3042 4132
Registered in England and Wales 653331 VAT # 887 1335 93
80 Victoria Street, London, SW1E 5JL
Received on Tuesday, 26 February 2013 11:35:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:53:21 UTC