Re: Uniform access to metadata: XRD use case.

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

>

Hi Pat.

>
> 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? Yes, the symbol "representation" can have other interpretations
in other contexts, 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 ;-)

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

Regards,

Patrick

>
> Pat
>
>

Received on Friday, 27 February 2009 06:40:39 UTC