Re: Uniform access to metadata: XRD use case.

Patrick.Stickler@nokia.com wrote:
>
> On 2009-02-25 02:00, "ext Xiaoshu Wang" <wangxiao@musc.edu> wrote:
>
>   
>> The critical flaw of all the proposed approach is that the definition of
>> "metadata/descriptor" is ambiguous and hence useless in practice.  Take
>> the "describedBy" relations for example.  Here I quote from Eran's link.
>>
>>       The relationship A "describedby" B asserts that resource B
>>       provides a description of resource A. There are no constraints on
>>       the format or representation of either A or B, neither are there
>>       any further constraints on either resource.
>>
>> As a URI owner, I don't know what kind of stuff that I should put in A
>> or B.  As a URI client, how should I know when should I get A and when
>> B?  Since I don't know what I might be missing from either A or B, it
>> seems to suggest that I must always get both A and B. Thus, I cannot
>> help but wondering why they are not put together at A at the first place.
>>
>> The same goes for MGET, how a user knows when to GET and when to MGET?
>>     
>
> If one wants a representation of the resource, use GET.
> If one wants a description of the resource, us MGET.
>   
This doesn't answer the question at all.  For me, a representation must 
be describing something. Hence, I cannot say if something is a 
Representation but not Description.
> There is some potential conceptual overlap between representations and
> descriptions for certain kinds of resources, but the distinction should be
> reasonably intuitive.
>   
 I don't think any protocol based on intuition is practical.  The 
concept of IR seems intuitive, but it doesn't work (at least not for me).
>   
>> PROFOUND is different because when people use it, they have already
>> known that the resources is defined by WebDAV.   Hence, these kind of
>> ideas only works when the client already have some knowledge about A.
>> But, to propose it as a general framework for the Web, it won't work.
>> At the most fundamental level, we only know three things about the Web
>> -- URI, Representation, Resource.  The concept of metadata is
>> ill-conceived at this level because as data about data, to say metadata
>> implies that we already know something about the resource we tries to
>> access, a piece of knowledge that we don't have.
>>     
>
> For URIQA, all that is needed is the URI. After all, you have to be able to
> name something to communicate effectively about it.
>
> URIQA does not presume that any representation exists. It neither posits nor
> requires an "Information Resource".
>
> It is perfectly complimentary to the web.
>
> GET/PUT/etc. deal with representations.
> MGET/MPUT/etc. deal with descriptions.
>
> If you have a URI, you can use it to either get representations or
> descriptions, and if you don't know anything about what resource the URI
> denotes, you might first want to get the description.
>
>   
>> There are a lot of implicit assumptions under the so-called "uniform
>> access to metadata/descriptor" approach.  It either requires the
>> definition of IR or a one-on-one relationship between Resource and
>> Representation.  As the former implies that non-IR cannot have a
>> representation, it makes the "descriptor/metadata" necessary.  The knock
>> on this assumption is that the definition of IR is impossible to work with.
>>     
>
> URIQA makes none of those assumptions.
>   
Really? Try to define the distinction between your terms "description" 
and "representation", see what you must come out.
>> The 1-on-1 relationship gives rise to the so-called "legacy resource".
>> But the word "legacy resource" is wrongly named too.  In the Web, there
>> might be something as "legacy representation" but there should NOT be
>> such thing as "legacy resource" because the latter implies that the
>> Resource is closed and no more semantics will be added.
>>
>> But the so-called "metadata/descriptor" problems can be solved by using
>> HTTP Content Negotiation, making any other proposal a redundant one.
>>     
>
> Actually, it can't. As noted on http://sw.nokia.com/uriqa/URIQA.html:
>   
The link returns a 404, so I don't know if it suppose to return 
something meaningful or it is a metaphor.
> --
> Why not use a MIME type and content negotiation to request a description?
>
> Content negotiation is designed to allow agents to select from among a set
> of alternate encodings. The distinction between a resource description and
> (other kind of) resource representations is not based on any distinction in
> encoding. 
Nope.  That is perhaps the intention that conneg is designed.  But I 
don't think that is the way it should be understood.  Content-type might 
be signal a special encoding, but language, for instance, is also part 
of Conneg.
> In fact, a given description (which is itself a resource) may have
> several available encodings (RDF/XML, XTM, N3, etc.). Thus, if you use
> content negotiation to indicate that you want a description, you can't use
> it to indicate the preferred encoding of the description (if/when other
> encodings than RDF/XML are available).
> --
>   
What is the implication of your statement. That RDF (or its sort) is 
description but others are not?  An HTML or XML doc definitely describes 
somethings.  If you URIDL  them to an RDF, it doesn't change the nature 
of its content. 
> Content negotiation can be used as intended in conjunction with URIQA to
> request particular variant encodings of a description.
>   
Again, the definition of "description"?
>> The
>> actual issue, as I have discussed in [1], is about the incomplete syntax
>> of the URI specs, which  currently does not have a syntactic notation
>> the other two foundation objects in the Web, i.e., URI and
>> Representation.  Once we supplement URI spec with those syntactic sugar,
>> such as the one I proposed in [2], then, we can have a uniform approach
>> to (1) describe URI along with standard resources and (2) to
>> systematically discover the possible representation types, i.e.,
>> Content-Type/MIME types, associated with a Resource (either URI or
>> standard Resource). As a particular content-type is equivalent of a
>> particular *service*, hence, the approach in effect establishes a
>> uniformed approach to service discovery.
>>
>> What is required is to define Content-Type in URI.  Once we have these,
>> not only Data/Resource are linked but DataType/Service.  The best of
>> all, it works within the conceptualizations defined in AWWW, and does
>> not require any other ambiguous conceptualization, such as, IR,
>> metadata, and description, etc.
>>     
>
> I consider on of the strengths of the semantic web layer is that it is
> agnostic about the syntactic structure of URIs. I also think that
> syntactically binding the URI of a resource and the URI(s) of its
> representation(s) or description(s) is necessary, and would be overly
> cumbersome in practice.
>   
Of course.  But anyone who words with the Web should know that the Web 
is consisted of these three kinds of things.  Hence, giving these three 
concept some syntactic sugar doesn't violate the URI's opacity 
principle.  When I say syntactic sugar, I mean that it is not absolutely 
necessary.  But the benefit of defining it is for convenience in practice.

Xiaoshu 
> Patrick
>
>   
>> 1. http://dfdf.inesc-id.pt/misc/man/http.html
>> 2. http://dfdf.inesc-id.pt/tr/uri-issues
>>
>> Xiaoshu
>>
>> Eran Hammer-Lahav wrote:
>>     
>>> Both of which are included in my analysis [1] for the discovery proposal.
>>>
>>> EHL
>>>
>>> [1] http://tools.ietf.org/html/draft-hammer-discovery-02#appendix-B.2
>>>
>>>
>>>       
>>>> -----Original Message-----
>>>> From: Julian Reschke [mailto:julian.reschke@gmx.de]
>>>> Sent: Tuesday, February 24, 2009 1:45 AM
>>>> To: Patrick.Stickler@nokia.com
>>>> Cc: Eran Hammer-Lahav; jar@creativecommons.org; connolly@w3.org; www-
>>>> tag@w3.org
>>>> Subject: Re: Uniform access to metadata: XRD use case.
>>>>
>>>> Patrick.Stickler@nokia.com wrote:
>>>>
>>>>         
>>>>> ...
>>>>> Agents which want to deal with authoritative metadata use
>>>>>
>>>>>           
>>>> MGET/MPUT/etc.
>>>>
>>>>         
>>>>> ...
>>>>>
>>>>>           
>>>> Same with PROPFIND and PROPPATCH, btw.
>>>>
>>>> BR, Julian
>>>>
>>>>         
>>>       
>
>
>

Received on Wednesday, 25 February 2009 09:41:32 UTC