Re: Uniform access to metadata: XRD use case.

On Feb 27, 2009, at 12:42 AM, <Patrick.Stickler@nokia.com> <Patrick.Stickler@nokia.com 
 > wrote:

>
>
>
> On 2009-02-26 19:52, "ext Pat Hayes" <phayes@ihmc.us> wrote:
>
>>
>
> Hi Pat.

Hi Patrick.

>
>>
>> On Feb 24, 2009, at 11:38 PM, <Patrick.Stickler@nokia.com>
>> <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.
>>
>> To avoid (even more) confusion, here you mean "representation" in the
>> narrow TAG/awww sense. right? The sense used in the REST architecture
>> description. Its important to get this clear, since when
>> 'representation' is used in its more common, wider, sense, a
>> description _is_ a representation. In fact, descriptions are in very
>> real sense the paradigmatic kind of representation.
>
> Yes. I meant "representation" as used in the narrow TAG/AWWW/REST  
> sense.
>
> Is it still too soon to expect that such would be presumed when  
> talking
> about responses to HTTP GET on a W3C mailing list, unless specified
> otherwise?

The danger of confusion is too great to ever make this assumption, in  
my experience. Even when the entire debate is about the most technical  
matters, the fact that awww:representation is called "representation"  
can give rise to mutual confusion quite rapidly.

> Yes, the symbol "representation" can have other interpretations
> in other contexts

It has an English meaning in the entire language. It is the AWWW sense  
which is peculiar, to the point of being deviant, which is why its  
important to mark that peculiar usage.

> , but in the context of this discussion I think it should
> be fair to expect folks to presume I mean the narrow TAG/AWWW/REST  
> sense.
>
> And when I say "description" as it relates to a URIQA MGET response,  
> I mean
> specifically a representation, per the TAG/AWWW/REST sense, from  
> which one
> may derive an RDF graph having one or more triples in which the URI  
> of the
> resource in question serves as the subject, and where there may be  
> zero or
> more triples in which the URI of the resource in question does not  
> serve as
> the subject. (hopefully that is specific and unambiguous enough for
> effective discussion ;-)

Yes, thanks. But again, believe it or not, that is NOT what I had  
thought you meant for reading the earlier messages. I thought you  
meant something much more general.

>>> If one wants a description of the resource, us MGET.
>>>
>>> There is some potential conceptual overlap between representations  
>>> and
>>> descriptions for certain kinds of resources, but the distinction
>>> should be
>>> reasonably intuitive.
>>
>> Actually no, its not _intuitive_ at all. Intuitively, in fact, it
>> makes absolutely no sense whatsoever. Why is one special kind of
>> representation, one that indeed has never been given a precise
>> definition or any kind of semantics, and appears to have no  
>> precursors
>> or exemplars anywhere in the entire technical literature previous to
>> Roy's doctoral thesis, be elevated to such an exalted status that an
>> entire world-wide transfer protocol be devoted to handling it, while
>> ignoring all other forms of representation?
>
>> And _how_ does this kind
>> of representation make it fundamentally different from a description?
>> Of course Im speaking intuitively here, and I think that both of  
>> these
>> questions have reasonable answers: but AFAIK nobody has actually
>> offered any; and they aren't particularly intuitive.
>
>
> Well, again, I was speaking within the specific focus of the  
> discussion,
> which was the narrow context of HTTP GET and URIQA MGET responses,  
> where the
> definitions of "representation" and "description" should be  
> sufficiently
> clear from the specs in question such that their distinction should be
> reasonably intuitive.
>
> But if it is only intutive to me, fair enough. I won't belabor that  
> point.
>
> (though I think you are taking the particular discussion out of its
> specifically narrow context and putting into a much broader context of
> discourse, and that criticisms about the use of terms arising from  
> expanding
> the specific context of discussion are not fair)

Its already firmly located in this broader context, and there's no way  
to keep it narrowly located any more. Fortunately, I would add. And I  
was only asking for clarification (which you have provided, thanks.)


Pat

>
> Regards,
>
> Patrick
>
>>
>> Pat
>>
>>
>
>
>

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Sunday, 1 March 2009 15:23:25 UTC