Re: Uniform access to descriptions

Patrick Stickler (Nokia-TP-MSW/Tampere) wrote:
>
> 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?
>   
When you request a content type, such as application/rdf+xml, don't you 
know its encoding?  Don't you know what it is for?  If you don't, why do 
you request it? In addition, I have also described in an response to 
Alan that I would like the mime-type be denoted in URI too.
> Will RDF/XML only ever be the single allowed encoding for descriptions. I
> expect not, even if it will and should have primary status.
>   
Who said that? And will that contradict to Conneg?  If someone invented 
a better logic language than RDF, make it a MIME-type, cannot you do the 
same thing as RDF? 
> 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.
>   
Which functionality?  I think this kind of blank statement is not useful. 
> 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.
>   
Who should ask this question? I am reusing your phrase with word 
substitution: "If (MGET) is used to ask for descriptions of resources, 
what will we use to ask for different encodings of those descriptions?"

Do you imply to get M....MGet in the future?

Xiaoshu

Received on Monday, 14 April 2008 16:44:40 UTC