Re: WebID Requirements and SHOULD

On 30 November 2012 12:19, Henry Story <henry.story@bblfish.net> wrote:

> 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
>

Given that a WebID is just a string of characters, what does changing a
WebID mean?



>   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/
>
>