Re: Uniform access to descriptions

On 2008-04-14 11:43, "ext Xiaoshu Wang" <wangxiao@musc.edu> wrote:

> 
> 
> 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 consider the approach you are suggesting a slippery slope, introducing a
dichotomy of representation encodings, and precluding that a representation
and a description could not both be expressed separately (for possibly good
reason) in 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?

Er. the same software agent that would use conneg.

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

Umm...  conneg?

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

I don't understand this last question. Sorry.

Patrick


> 
> Xiaoshu

Received on Monday, 14 April 2008 17:01:49 UTC