Re: Comments on draft "baseline" httprange-14 replacement

On 2/19/12 7:29 PM, ashok malhotra wrote:
> Hi Kingsley:
> I raised the the MGET issue several months ago, early in this discussion,
> and received a flurry of responses that said, in effect, FUGGEDABOUTIT,
> no one wants to implement another HTTP verb.  Some response were much
> less polite :-)

Yes! Nobody wants to implement a new HTTP verb. This why many Linked 
Data implementers (like ourselves) have resorted to using sparql 
protocol urls (describe or construct) as a less obtrusive route for 
delivering the critical "describe" verb :-)

Kingsley
> All the best, Ashok
>
> On 2/19/2012 1:33 PM, Kingsley Idehen wrote:
>> On 2/18/12 9:04 AM, Jonathan A Rees wrote:
>>>> A descriptor resource is a kind of information resource.
>>>> >
>>>> >  We are looking for words that clearly explain the following 
>>>> indirection:
>>>> >
>>>> >  
>>>> SubjectName->SubjectDescriptorResourceAddress->SubjectDescriptionRepresentation
>>>> >  (an eav/spo graph pictorial) .
>>> With some methods, such as MGET,
>>
>> MGET is how URIQA retrieves the description of a Subject identified 
>> by a URI. Basically, it delivers the missing DESCRIBE operation which 
>> is a natural fit for Linked Data. That said, a SPARQL DESCRIBE 
>> delivers the same thing to HTTP GET via Query parameters.
>>
>> You still end up dealing with indirection even if its:
>>
>> SubjectName (URI) ->SubjectDescriptorResourceAddress (SPARQL DESCRIBE 
>> URL) ->SubjectDescriptionRepresentation
>>
>> or
>> MGET:
>>
>> SubjectName (URI) -->SubjectDescriptionRepresentation (with a 
>> bookmarking problem since you don't have a 
>> SubjectDescriptorResourceAddress).
>>
>> BTW -- I know of no URIQA implementation bar ours re. Linked Data. 
>> We've long assumed MGET isn't used by anyone.
>>
>>
>>
>>> 209, LSID, and conneg, there is no
>>> "SubjectDescriptorResourceAddress", only a representation, so making
>>> indirection through a URI-named resource a necessary part of the
>>> problem statement would be preemptive.
>>
>> You make a proxy/wrapper HTTP resolver for that, and we've 
>> implemented that re. Linked Data. The end result is the same as I've 
>> outlined re. HTTP.
>>
>>
>>>   The overall relation
>>> "representation Z is a NUDC for URI U" needs to be the operative
>>> primitive here (regardless of what you call it), or else these
>>> solutions get locked out.
>>
>> They don't if HTTP is the data access mechanism in question. You make 
>> a bridge and once made you still end up with:
>>
>> SubjectName (URI) ->SubjectDescriptorResourceAddress (URL - which can 
>> be a proxy/wrapper) ->SubjectDescriptionRepresentation
>>
>>
>>
>
>


-- 

Regards,

Kingsley Idehen	
Founder&  CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen