Re: Uniform access to descriptions

On 2008-04-14 11:57, "ext Patrick Stickler (Nokia-TP-MSW/Tampere)"
<patrick.stickler@nokia.com> wrote:

> 
> 
> 
> 
> 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.

Or any other encoding.

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

Sorry, expressed that using implicit sarcasm. Given the nature of this
thread, let me restate:

Conneg, of course.

Patrick


> 
>> 
>> 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:11:03 UTC