- From: Patrick Stickler (Nokia-TP-MSW/Tampere) <patrick.stickler@nokia.com>
- Date: Mon, 14 Apr 2008 11:19:09 -0500
- To: ext Pat Hayes <phayes@ihmc.us>, Michaeljohn Clement <mj@mjclement.com>
- CC: <wangxiao@musc.edu>, "www-tag@w3.org WG" <www-tag@w3.org>, <noah_mendelsohn@us.ibm.com>, Jonathan Rees <jar@creativecommons.org>, Phil Archer <parcher@icra.org>, "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
On 2008-04-13 15:32, "ext Pat Hayes" <phayes@ihmc.us> wrote: > > It matters that we all agree on expectations, of course. But I really > dislike the tone of pronouncements like "not what conneg is for". Who > has the authority to say what conneg is for? All this means is "not > what conneg has been used for until now". Conneg is just machinery, > and we, as a society, can use for whatever we decide and find > convenient. I agree in spirit, Pat, about maximizing the potential of any existing feature or function and not being too rigid to the point of missing clear and obvious opportunities, but in this particular case, I don't see content negotiation as a suitable solution to this general problem. If conneg is used to ask for descriptions of resources, what will we use to ask for different encodings of those descriptions? Will RDF/XML only ever be the single allowed encoding for descriptions. I expect not, even if it will and should have primary status. I expect that as more and more semantics becomes available and accessible on the web, that there will be need for supporting alternative encodings of that knowledge. And one can certainly expect RDF/XML to improve over time, perhaps in ways that may be not fully backwards compatible. "Stealing" content negotiation as a mechanism to obtain descriptions about resources, rather than requesting variant encodings of the same essential body of information, would I think be a short-sighted error. Yes, it could be made to work in solving the general issue of access to descriptions, but at a loss of functionality that will be needed later. I really wish I had time to jump back into this debate (unfortunately I don't) as I firmly believe that URIQA is still the best solution to this general problem, and allows us to both avoid a lot of philosophical debates such as "awww:representation" vs. "representation" and allows us to fully exploite mechanisms such as conneg for access to variant descriptions in the same manner as it is used to date for access to variant representations. And it works equally well for resources which, for whatever reason, may not have a web-accessible representation yet still be in the domain of discourse by semantic web agents. If you want a representation, use GET. If you want a description, use MGET. Simple. Done. (there's even support for hash URIs ;-) Regards, Patrick
Received on Monday, 14 April 2008 16:29:35 UTC