- From: Jonathan Rees <jar@creativecommons.org>
- Date: Mon, 21 Feb 2011 11:56:11 -0500
- To: AWWSW TF <public-awwsw@w3.org>, Harry Halpin <hhalpin@w3.org>
As I reported earlier, I'd like to help bring about a consensus document about the httpRange-14 resolution and its consequences. I have a TAG action open on this, which is to figure out what TAG issue to track this work under. http://www.w3.org/2001/tag/group/track/actions/532 I have two purposes in mind for the document. One is to describe what was decided - why it was done, how it works, and what benefits one gets if it's followed. The other is to document and if possible address recently raised concerns, with Harry's message http://lists.w3.org/Archives/Public/public-awwsw/2011Jan/0021.html as a launching point. This may end up being two or more documents. Here are some tracking options: Closed issue: 14 httpRange (using this was Henry's suggestion) Open issues: 39 rdfURIMeaning http://www.w3.org/2001/tag/group/track/issues/39 57 HttpRedirections (mainly about interaction of 30x and semweb) 62 UniformAccessToMetadata (mainly about Link: and .well-known) 63 metadataArchitecture (mostly about preventing bad interactions and inconsistent practice) Or a new issue. (Tracker doesn't allow you to associate actions and comments with products.) I don't consider any of the open issues to be appropriate. 57 and 62 are too narrow, and the problem cuts across both 39 and 63. I don't consider issue 14 to be appropriate, even though the design space is the same. It was closed to the satisfaction of the TAG at the time, and has way too much baggage associated with it. The new work should be described under the pain point (what problem retracting the resolution would be the solution to), not under the design space. For your reference, here is what I think the question to which the httpRange-14 resolution was the (partial) answer: How to (1) refer to the Web-accessible information resource at a URI, and (2) provide a URI for a thing given a description of it, given that each dereferenceable URI can be used for only one of these two purposes? The resolution was fine given this as the question. My description of Harry's problem is something this: Linked-description-based URI definition is too hard, given hash and 303 URIs as the only agreed ways to do it. (I added the funny adjective 'linked' to rule out non-nose-followable solutions.) Obviously liberating 200s would be one solution, and perhaps the only one, but the issue description shouldn't presuppose any particular solution. I'd be happy with more specific or general versions if Harry or others prefer, such as 'RDF-based' instead of 'description-based', or some word other than 'definition' (I like 'binding' but I know that doesn't do much for most people), or even Hash and 303 don't work for associating descriptions with URIs. or we could phrase it like a question, like most TAG issues What is an easily deployed way to associate a URI with a description of its intended referent? My inclination is to propose a new TAG issue with a general description like the above, and track the new work under it. (We would need a short name too, and a longer description. The longer description would cite Harry's email.) Since the people on this list have been involved in the discussion, I'm asking your advice in defining and describing the new issue in the next couple of days, or in talking me into using an existing issue for tracking. Thanks Jonathan
Received on Monday, 21 February 2011 17:04:31 UTC