WebID 1.0 Definition - Nathan's comments

Hi All,

I can't edit the wiki, and I can't attend the telecon due to it being 
the only time of the day I can't manage (1500-1600UTC). so here's my 
feedback, broken down in to several sections.

General Architectural Principals:
============================================
1) "Being part of a Modular Design
It is not only necessary to make sure your own system is designed to be 
made of modular parts. It is also necessary to realize that your own 
system, no matter how big and wonderful it seems now, should always be 
designed to be a part of another larger system."
  ~ http://www.w3.org/DesignIssues/Principles.html

In the context of WebID 1.0, we must acknowledge that the larger eco 
system already exists, and has for ages, Linked Data and the Web Of 
Data; which use both #frag and 303 URIs.

2) "Tolerance: Be liberal in what you require but conservative in what 
you do"

In the context of WebID 1.0, we must be liberal in what we require 
(http(s): URIs), and conservative in what we do (publish and encourage 
http(s) #frag URIs)

3) "Test of Independent Invention: If someone else had already invented 
your system, would theirs work with yours?"

In the context of WebID 1.0, if 303 URIs are not allowed, then no, it 
probably would not - this includes systems which have already existed 
for a long time, many 303 URIs which refer to agents and deref to turtle 
already exist, and many more will in the future too.


Implementation Conformance:
============================================

1) Will any implementations throw an error or fail if a WebID URI does 
not include a #fragment? (no, and those that do will be ignored by most).


Specification Structure
============================================

1) If the specification is to be general, oriented at both producers and 
consumers, then anything after a MUST which does not further refine the 
constraint is a waste of time.

2) If the specification is to split in to guidance for consumers, and 
separately for producers, then a "SHOULD use #frags" in the producer 
section may make sense.


Interoperability:
============================================
There exists already a huge amount of data on the web, and a fair subset 
of that is data describing agents, and URIs which refer to agents, both 
#frag and 303.

LDP is in progress and we want to (and should) be interoperable with it, 
but to preclude the many existing systems used in a read and write 
scenario, from ftp through to sparql and via every custom system, and to 
discount the billions of existing triples, makes no sense at all - why 
is interoperability with LDP considered more important than 
interoperability with the rest of the web of data?


Personal:
============================================
I will use and create WebIDs which are http(s) scheme URIs with a 
#fragment, that's my choice, but I will also support your choice to use 
303 URIs.


Sanity Check:
============================================

   Interoperability Table:
   ---------------------------------------------------------
   Systems          |  MUST be #frag  | MUST be HTTP(S) URI
   ---------------------------------------------------------
   use 303 URIs     |       no        |       yes
   use #frag URIs   |       yes       |       yes

By this table it is clear that all "interoperability" arguments FOR a 
#frag URI constraint fail instantly, so should be ignored.


Finally:
============================================
Remember I've argued at length for years against the use of 303 URIs, 
investigated innumerable man hours in to hr14, and in to endless 
conversations around the web and lists about hash vs slash, 303, frags 
and everything related - right up to and including this email.

The issue is not about what I or we prefer, or think is right - the 
issue is about tolerance and modularity.

Using #frag URIs has many benefits, who can dispute that? but adding a 
#frag URI constraint excludes a *huge* section of the web of data, and 
the linked data community. With NO, NONE, ZERO benefit.

Best,

Nathan

Received on Thursday, 22 November 2012 18:11:02 UTC