W3C home > Mailing lists > Public > public-xg-webid@w3.org > November 2011

Re: Normative vs Informative

From: Mo McRoberts <mo.mcroberts@bbc.co.uk>
Date: Mon, 28 Nov 2011 21:12:42 +0000
Cc: public-xg-webid@w3.org
Message-Id: <F3B3CB2A-C10D-4A94-A0F4-B2A10A0FA942@bbc.co.uk>
To: Kingsley Idehen <kidehen@openlinksw.com>

On 28 Nov 2011, at 20:40, Kingsley Idehen wrote:

> On 11/28/11 2:56 PM, Mo McRoberts wrote:
>> On 28 Nov 2011, at 17:17, Kingsley Idehen wrote:
>>> People should be allowed to comprehend what WebID and the WebID protocol are about without any Syntax oriented distractions. That's how to best engage a broad audience of evangelists, developers, and end-users. People can be political about RDF but far less so about the important issue of verifiable identity and privacy at InterWeb scales.
>> Perhaps I’m misunderstanding the intent of this statement, however:—
>> People should be allowed to read a spec and know _exactly_ what they need to implement in order to have a working system. Specs which leave lots of things unspecified, or say “you can use anything kinda like this” aren’t specs at all, they’re just background papers. Sure, expand them over time, provide some narrative indicating future direction (“in principle anything taking the form<x>  will work; at this stage they’re not part of the specification but in future editions may well be”), but you need to start with a concrete basis or nobody will ever implement anything that interoperates with anything else.
> WebID needs the following:
> 1. a document that explains the concept devoid of syntax specificity

Then go and write one. Seriously.

> 2. an implementation guide / spec that outlines how it can be implemented
> #2 can ultimately grow into a collection of crowd sourced guides covering a variety of options as opposed to one gospel. Right now, we have WebID intermingled with RDF. Then we have dangerous reinforcement of Linked Data == RDF. All totally unnecessary if this effort is to truly seek mass adoption. An RDF specific implementation guide can easily be tagged as just that.

#2 as “a collection of crowd source guides covering a variety of options as opposed to one gospel” is an implementor’s nightmare, frankly. Focussing specification efforts on such a beast is pretty much guaranteed to see any adoption of WebID stopped dead in its tracks. There’s a reason that both the W3C and IETF specification processes, with all their informality, result in documents which read like formal specifications: because they are, and that’s how you provide the things people need to produce interoperable implementations.

At some point along the way, *however you do it* you have to stop and say “at this point, these are the syntaxes you need to support”. If I choose syntax X and you choose syntax Y, how the hell are ever going to consume each other’s stuff?

This is not difficult.

Look, I’m participating in this XG because not only do I think WebID is quite a good idea, but because I want to, and intend to, implement it and roll it into other stuff, so when I say “if you don’t specify this, it will make life difficult—possibly fatally—for implementors” I’m saying so because I’m thinking about how on earth I can produce an interoperable implementation without it and drawing a blank. “It will work some of the time if by sheer coincidence both parties decided to support the same particular syntax” simply isn't good enough for the effort to be worthwhile.

You may regard RDF as being inexorably linked to some Semantic Web vision, but to be perfectly honest most people I talk to have no real idea as to what the specifics of “the Semantic Vision” and consider RDF serialisations to be a useful set of tools to perform a job: chiefly, a mechanism for describing values of attributes about entities (yes, EAV) in a fashion which lets anybody come to the party and removes the ambiguity between one person’s definition of "foo" and another’s (because anybody can mint a URI, and so anybody can define any entity, attribute or value they like without risk of clashes with others).

The “when you give those things URIs, make them dereferencable to the data about that thing” isn’t dogma or vision, nor is it the only way to use RDF, but it *is* a very straightforward (technical nuances aside) and sensible way of ensuring that data retrieval is straightforward and hassle-free. Yes, in principle, you could chuck stuff in the middle between 'resolving the URI' and 'retrieving the document from a server', but most people gave up doing that because it's a whole heap of additional complication that _everybody_ needs to support to be useful, and even then it's not clear what actual use beyond assigning HTTP identifiers there is. Again, this isn’t dogmatic, it’s practicality. People tried XRIs, and they failed abysmally for a variety of reasons including because they were more complicated than they needed to be in order to resolve a form of URI to a retrievable resource.

Moreover, in terms of “standard schemes which allow arbitrarily-extensible EAV patterns to be expressed straightforwardly in a well-supported form” we’re left with RDF or, at a push, ASN.1, both of which have several serialisations. Right now, that’s about it. ASN.1 has the distinct disadvantage that it's actually a TLV rather than EAV setup in most serialisations, which has limited its usefulness.

Yes, you _can_ in principle do extensible EAV in any number of a million ways, including EDIFACT if you really wanted to, but people *don’t*, because they all have rather clear downsides. You _could_ spec that a WebID profile document is delivered via two-column CSV consisting of arbitrarily-defined fields like “name”, “homepage”, “keyType”, “modulus” and “exponent”, but all you’d be achieving by this would be making things more—rather than less—ambiguous. Eventually, get as far as giving those fields URIs, and you’ve pretty much reinvented RDF triples the long way around.

So, I’m going to ask this and hope that I’m not going regret it: what things which *aren’t* RDF and aren't trivially deserialised to RDF graphs which you believe WebID applications should support consuming or generating which:—

a) people actually use; and

b) aren’t horrifically ambiguous when used as part of any larger system; and, for bonus points,

c) don’t require massive amounts of prior knowledge in any passive consumer?

Are there any, or is this all just contentious objection on the basis of a perceived hypothetical problem?


Mo McRoberts - Technical Lead - The Space,
0141 422 6036 (Internal: 01-26036) - PGP key CEBCF03E,
Project Office: Room 7083, BBC Television Centre, London W12 7RJ
Received on Monday, 28 November 2011 21:13:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:26 UTC