WebID Definition/hash2
Historical Note: This page has been derived from a precursor hash page, which had set up a space for putting up negative and positive arguments for each option. This page removes the negative arguments sections, and transferred those into positive arguments for a particular case. It also removed arguments that did not have any supporters. For full context, it may be best to review both.
WebID Definition
Given that WebID's must refer to Agents, and that they must have an associated profile document, (that returns a default representation) the question here is which of the following restrictions one should have for WebIDs.
A URI is defined by RFC3986 and is constructed as follows:
foo://example.com:8042/over/there?name=ferret#nose \_/ \______________/\_________/ \_________/ \__/ | | | | | scheme authority path query fragment
- 1. a WebID MUST be a an http(s) hash uri
- that is scheme MUST be http or https and it must have a fragment identifier
- 2. a WebID MUST be an http(s) URI and SHOULD be an http(s) hash uri
- that is scheme MUST be http or https and it SHOULD have a fragment identifier
- 3. a WebID MUST be an http(s) uri
- that is scheme MUST be http or https
This is in the context of the current WebID definition editors draft.
Reasons: "A WebID ..."
1. MUST be an HTTP(S) hash (#) URI
The spec would say:
A WebID is a URI with an `http` or `https` scheme, which MUST contain a URI fragment identifier and which uniquely denotes an Agent (Person, Organization, Group, Device, etc.). The URI without the fragment identifier denotes the WebID Profile page.
- Note: this is a definition of what the class of WebIDs are. It is not imposing a restriction on all URIs to say that only WebIDs can refer to Agents of course.
- Hash URIs make it easy to explain the difference between the Profile document ( a Information Resource from WebArch ) where the description of the agent resides and the user identifier as in the picture in the spec (With 303's the job is more difficult, as one has to teach HTTP redirect codes which are not obvious to most users )
- Necessary relation between URI and definition: The document defines the meaning of the WebID. Definitions are known as analytic truths - they are necessarily true. This is why publishing a public key in that document has completely different significance than publishing it elsewhere. This property follows directly from the URI spec:
WebID Auth relies on the strength of the relation that exists between a WebID and its Profile document, to build up the security reasoning.The fragment identifier component of a URI allows indirect identification of a secondary resource by reference to a primary resource and additional identifying information. The identified secondary resource may be some portion or subset of the primary resource, some view on representations of the primary resource, or some other resource defined or described by those representations.
- Cachability problem of URI redirections. HTTP1.1 states:
As a consequence ( but see the argument on HTTPBis improvements )The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable
- It is not specified for how long the redirection from the URI to the Profile page is valid for. When does the client need to check for it again?
- There is an efficiency problem for all applications, but especially for those built in existing apps such as Web Browsers ( such as the JavaScript Tabulator ) since they must rely on that stack.
Other
- Non #URI are problematic for LDP. What would it mean to:
- to PATCH such a resource?
- to DELETE it?
- how would one create such a resource in an LDP Collection?
But this is something that is evolving, so it is difficult to come to a conclusion on now.
2. MUST be an HTTP(S) URI and SHOULD be an HTTP(s) hash (#) URI
This proposal acknowledges the existence of technical solutions for dealing with 303 redirects, but comes to the conclusion that 303 tends to complicate things for deployment, for consumption and for protocols such as LDP. It recommends therefore the hash URI solution as the cleanest way forward.
WebID definition spec with proposed changes.
The definition is:
A WebID is a URI with an `http` or `https` scheme which uniquely denotes an Agent (Person, Organization, Group, Device, etc.). This URI SHOULD include a fragment identifier. For WebIDs with fragment identifiers the URI without the fragment denotes the Profile Document. For WebIDs without fragment identifiers an HTTP request on the WebID MUST return a 303 with a Location header URI denoting the Profile Document.
Note that SHOULD is defined as meaning, quoting from RFC2119
SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
Arguments in favor:
- It promotes all the goodness of the MUST proposal above, but without excluding existing entity urls described in proposal 3 below.
- It can help simplify the spec, as we don't need to have examples for 303s as well as hash uris
- It fosters interoperability for
- javascript clients like the tabulator, that work from within the browser and need to keep track of where data comes from, and be responsive
- published data that uses non hash-URIs which cannot be avoided see Nathan overview that allows for SHOULD as an option
3. MUST be an HTTP(S) URI
A WebID is a URI with an `http` or `https` scheme which uniquely denotes an Agent (Person, Organization, Group, Device, etc.). For WebIDs with fragment identifiers the URI without the fragment denotes the Profile Document. For WebIDs without fragment identifiers an HTTP request on the WebID MUST return a 303 with a Location header URI denoting the Profile Document.
WebID definition spec with proposed changes (diff).
- be tolerant in what you accept. It is better not to have restriction here since there are technical solutions to get to the profile document for both hash URIs and non hash URIs.
- There is an existing deployed base of URIs that refer to entities descriptions via 303s, e.g., DBpedia URIs like http://dbpedia.org/resource/Gaius_Julius_Caesar_(proconsul)
- Future HTTP protocol improvements will make 303 responses a lot more efficient
- HttpBis's ticket 70 to make caching of 303 responses possible was passed. Mark Nottingham lists this as one of the changes affecting linked data, pointing to 303 status section of HTTPBis.
- The development of SPDY could make a big difference to the efficiency problem of 303s especially if the 303 caching works.
- The Keychain Access.app in Mac OS X takes any SAN that includes a #, and visually presents it correctly ( see picture). But when you click on that URI (the textual string of which you cannot select and copy), your browser loads the URI with %23 in place of the # -- e.g., Keychain Access.app displays http://twitter.com/TallTed#this locally, but when I click it, my browser (observed with both Firefox and Safari; no reason to think any other would behave differently) tries to load http://twitter.com/TallTed%23this -- which correctly 404s - ( it could 303, but this is a requires the server to be setup correctly ). Now, this is clearly a bug in Mac OS X and/or Keychain Access.app -- but this is a very widely deployed tool which demonstrates the folly of forcing a particular URI pattern for WebID.
- Existing guidance (e.g., Interoperability Solutions for European Public Administrations Deliverable D7.1.3 - Study on persistent URIs, with identification of best practices and recommendations on the topic for the MSs and the EC) firmly pushes toward 303 for real world objects:
4.4 Implement 303 redirects for real-world objects When de-referenced, URIs that identify real world objects that cannot be transmitted as a series of bytes (such as buildings, places and people) should redirect using HTTP response code 303 to a document that describes the object. This should be done in a consistent manner that can be written as a URI re-write rule, typically replacing the URI {type} of 'id' with 'doc.' See section 3.2.1.2 for details.