W3C home > Mailing lists > Public > www-tag@w3.org > April 2008

RE: Uniform access to descriptions

From: Williams, Stuart (HP Labs, Bristol) <skw@hp.com>
Date: Fri, 11 Apr 2008 13:24:11 +0000
To: "wangxiao@musc.edu" <wangxiao@musc.edu>
CC: Jonathan Rees <jar@creativecommons.org>, "Michael K. Bergman" <mike@mkbergman.com>, "www-tag@w3.org WG" <www-tag@w3.org>, Phil Archer <parcher@icra.org>
Message-ID: <9674EA156DA93A4F855379AABDA4A5C611CE6D8DE1@G5W0277.americas.hpqcorp.net>

Hello Xiaoshou,

<snip/>
> >>>
> >>>
> >> I am opposing HTTP LINK not any internal link such as HTML <link>.  So,
> >> HTTP is necessary for my argument.
> >>
> >
> > You are clearly opposed to something, but my comprehension
> of quite what that something is erodes with each exchange of messages :-(.
> >
> >
> >>>> unless we want to drop RDF or human
> >>>> language?  I guess the answer to this question is obvious no.
> >>>>
> >
> > The question you ask "unless we want to drop RDF or human
> language?" seems incomplete. I have failed to make anything of it.
> >
> I am opposing unnecessarily put an HTTP-LINK header because I couldn't
> imagine a use case for HTTP LINK, which cannot be solved with putting
> link in content, i.e., using RDF or human language, or using Conneg.  In
> other words, I think the functionality of the potential HTTP LINK would
> be redundant to some other part of functionalities of the web, which
> eventually will make the web difficult to operate on.

Because you don't see the utility is no reason to stand in the way of a queue of people that do.

In terms of use cases: how would you address use cases from Jonathan for content formats that don't have a means to carry links or inline metadata: the simplest being plain-text resources; zipped resources; extending through signed resources (changing their content will disturb signatures); and just the mass of legacy stuff out there that approximately no-one is going to update to fit in with your world view.

<snip/>

> >> My question to Jonathan is that *description* must be falling into the
> >> argument of /representation/.  I didn't assume /representation/ is a
> >> given, but using /description/ to replace /representation/ doesn't avoid
> >> to answer the relationship between /representation(description)/ to
> >> /resource/.  It is the same problem, nothing new.
> >>
> >
> > Ok... so the bit that I can work with....
> >
> > You posed that Jonathan was "inventing a synonymy" wrt
> > "description" (and variants: describes; descriptionOf...) and
> > "representation" (and variants: represents;
> > reprentationOf...) and that "Inventing a synonymy won't solve
> > any problem."
> >
> > Whilst I agree that "Inventing a synonymy won't solve any
> > problem." I also argued in [2](coherently I thought) that
> > "description"+variants and "representation"+variants are not
> > being used synonmously ie. (at least IMO) Jonathan is not
> >"inventing a synonymy".
> >
> > [2] http://lists.w3.org/Archives/Public/www-tag/2008Apr/0100
> >
> I was trying to say  "description"+variants, should be described in RDF
> or in natural languages.  Isn't description the content of another
> resource in this sense?  So, if description is neither "resource" nor
> "representation"? What can it be?

Are we agreed that Jonathan is *not* "inventing a synonymy"?

Please... that is the point/claim I was addressing. I have no idea whether we have agreed on it or not.

To answer your other question here: "What can it[description] be?". I gave my answer that way before, with all the "awww:"'ing and you agreed:

It is a relation between (in this context) "awww:resource" where on resource is descriptive of another.

And... I am now going to try very hard not to respond with answers that merely repeat something that has already been said...

> Xiaoshu

Thank you,

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
Received on Friday, 11 April 2008 13:28:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:47:55 GMT