Re: hash/303, all use cases, requirements, thoughts, notes, approaches, use cases, user stories..

On 21 Nov 2012, at 19:54, Nathan <nathan@webr3.org> wrote:

> Stéphane Corlosquet wrote:
>> On Wed, Nov 21, 2012 at 12:29 PM, Henry Story <henry.story@bblfish.net>wrote:
>>> On 21 Nov 2012, at 18:25, Nathan <nathan@webr3.org> wrote:
>>> 
>>>> Henry Story wrote:
>>>>> http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition/hash
>>>> I'm unsure that anything could be captured here which hasn't already
>>> been captured by the exhaustive work of Jonathan Rees and others via
>>> www-tag and the awwsw tf, see:
>>>> http://www.w3.org/2001/tag/products/defininguris.html
>>> 
>>> We can define WebIDs to be whatever we want I think.
>> We can. The question is whether we should!
>> option 1: define it the way we want (e.g. hash URIs only), and disregard
>> any on-going work by the TAG, which might resolve the issue with a solution
>> incompatible with the one we define today.
>> option 2: leave it open and generic in our definition of WebID, but
>> strongly encourage the use of hash URI via examples.
> 
> Hi Steph,
> 
> Wise words, I think the TAG have committed to not falling on either side of the debate, but rather fostering interop, so I doubt option 1 would be ever happen.

I hope they do a better job than the "Dereferencing HTTP URIs" document 
  http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14
which leaves the simplest solution to the end with very little in form of explanation, 
whereas all the other solutions are given detailed explanation.

I am interested in the new finding, but I don't think we can wait around for them to be finished.
We can have a provisional solution in the meantime.

> That said, option 2 seems to be the only viable, non exclusive, way forward here - and it's been the approach many of us have adopted in communications and tooling for years.

This does leave "MUST be HTTP uri and SHOULD be an HTTP(s) hash (#) URI" 

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

which I am starting to like quite a bit myself, for reasons explained on the wiki.

Concerning the wiki
-------------------

I have commented on different points people made, btw [bblfish: ...].

I don't think we have all the answers in - I am still waiting for Alexandre Bertails -
who was very vocal at both TPAC and last meeting in favour of the stronger answer 1.
Anyway, the picture is starting to clear.

Could people please consider each point they put down, and see if it really is a point in favor of a position  And also please make the points short and concise with pointers to extra material. (I'd like to remove rambling).

Henry


> 
> ps: thanks for taking this to the TAG, I was glad to see it being raised their.
> 
> Best,
> 
> Nathan

Social Web Architect
http://bblfish.net/