WebID Requirements and SHOULD

Alexandre,

  a couple of weeks ago you put forward the following requirements you had for WebID 

[[
  1. one MUST be able to change one's WebID
  2. one MUST distinguish a WebID (a simple URI for a Web Resource) from a WebID Profile (the Web Information Resource). This SHOULD not rely on dereferencing.
  3. the system MUST take efficiency into account
  4. the system MUST not introduce any incompatibility with LDP, especially for Write operations
  5. the Web Profile MUST define a default representation format
  6. the system SHOULD considerer legacy WebIDs (or FOAF/SSL) whenever possible
]]

  As a first step to coming to a consensus on ISSUE-70 [1] I would like to know why these are not compatible with be with the SHOULD position [2]

Let me go through this for the SHOULD position.

  (1) one must be able to change one's WebID 

it seems to me that all solutions allow one to change one's WebID. If someone has a 303 redirect,
then they can change the 303 to a 301 moved permanently. Same follows if it is a document, right?

 (2) one MUST distinguish a WebID ( a simple URI for a Web Resource ) from a WebID profile. 

  I think both 303 solutions and 200 solutions can make that distinction. They just go about it differently.
The 303 URL just points to a document, which is the profile.

 (2a) This SHOULD not  rely on dereferencing.

   The SHOULD position [2] says that WebIDs are http URIs that SHOULD have a #fragment . If it SHOULD have a #fragment, then applications that don't have hash fragments are ones that are not doing what they SHOULD. When we are looking at those that do what they SHOULD we see that the distinction between the WebID and the Profile does not rely on dereferencing.

  (3) The system MUST take efficiency into account

  The solution [2] takes it into account by specifying how things SHOULD be done.

  (4) the system MUST not introduce any incompatibility with LDP, especially for Write operations

  The solution [2] does not introduce any incompatibilities with LDP. LDP I suppose states that if you
write to a WebID profile ( and of course if you are allowed to) then you can write there.

  (5) the Web Profile MUST define a default representation format

  I think we have done that, by syncing with Turtle and the LDP decision.

  (6) the system SHOULD considerer legacy WebIDs (or FOAF/SSL) whenever possible

  The SHOULD position does that, by allowing that WebIDs that don't do what they SHOULD are not excluded by the MUST language. Clearly implementations will need to be flexible to deal with the WebIDs that exist out there already.

    So if you can live with solution [2], then perhaps that brings us closer to some consensus.

	Henry

[1] now opened
    https://www.w3.org/2005/Incubator/webid/track/issues/70
[2] http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition/hash#2._MUST_be_HTTP_uri_and_SHOULD_be_an_HTTP.28s.29_hash_.28.23.29_URI
  


Social Web Architect
http://bblfish.net/