Re: WebID 1.0 Definition - Nathan's comments

thanks that's helpful. You should be able to join the WebID CG easily, no?


On 22 Nov 2012, at 19:10, Nathan <nathan@webr3.org> wrote:
> 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

Social Web Architect
http://bblfish.net/

Received on Thursday, 22 November 2012 18:24:57 UTC