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

Re: Uniform access to descriptions

From: Harry Halpin <hhalpin@ibiblio.org>
Date: Mon, 24 Mar 2008 14:54:10 -0400
Message-ID: <47E7F8D2.8010600@ibiblio.org>
To: wangxiao@musc.edu
Cc: Jonathan Rees <jar@creativecommons.org>, "www-tag@w3.org WG" <www-tag@w3.org>

Xiaoshu Wang wrote:
> Harry Halpin wrote:
>> 1) As a typed link header, as in "Link:
>> http://www.example.org/mydescription
>> rel="http://www.w3c.org/example/describedBy"
>>   
> Honestly, I don't think Link header solves anything.  The logic is here,
> What is the content type of the Linked resource? Fixed or anything?
Not just a link header, but more ways of linking in general is the issue
at hand, one of which is a link header. The content type of the Linked
resource would not be fixed, but would be whatever it's normal content
type is, i.e. likely application+rdf/xml, but one could imagine other
ones (n3) or even XML and HTML. The idea of authoritative descriptions
is not even tied to the Semantic Web, for example, think of namespace
documents or RDDL. The extra @rel link relation just makes it clear it's
authoritative, not necessarily RDF.
> (1) If it is fixed, say it is RDF, then, why not just make the RDF the
> content type of the original resource the metadata or link - whatever
> you call it?  Since the users or browsers has to know it anyway.
I have no idea what you're talking about here. They can get the content
type from the linked authoritative description.
> (2) If it is anything, that means, the original resource should have a
> fixed representation?  Otherwise, what will be the  relationship
> between R1, R2, etc. vs. M1, M2, etc.  If R1 has only one
> representation, then, it again make the multiple representation of the
> linked resource redundant because it all can merged back to R1
Sigh. Look, in some cases content negotiation for RDF is not going to
work. Resources can be linked to each other to provide descriptions and
authoritative meta data. Linking is very powerful. Most people know what
links are. Most people have no idea that content negotiation even exists.
>
> What is the purpose of Link then? To make a client to read something
> and then figuring out where the metadata is? Then, putting the Link in
> the content is sufficient.
Yep, and I might add Yahoo! and others are already moving to supporting
this way of adding metadata [1]. I think it's generally a good idea to
standardize things that the majority of the Web is moving to.  And in
some cases the Link cannot be put directly in the content, and in some
cases it can. Please read the GRDDL use-cases [2].
> Or to make a client not to read the content and directly go to the
> metadata (Link), then the client should already know what they don't
> need, say, the HTML content.   Then, make the RDF content type the
> default metadata or whatever is sufficient too.
You might want both HTML and RDF obviously.
> Either way, it makes the use of Link redundant .  Of course, unless we
> want to abandon content-negotiation, which I don't think we should. 
> Otherwise, Link is unnecessary.
Content negotiation is always an option, but it's one many people don't
have access to, because they are in a managed IT environment. How about
giving people *more* options for adding metadata to their page, instead
of *less*?

I don't see how this forms an argument against having a stronger version
of linking or the use of a Link header. What the argument is "Why not
use content negotiation?" The argument against that, which is supported
by empirical evidence, is that most of the Web does not use conneg
because they do not know how and -  more importantly - may not have
access. Therefore, it is the duty of Webarch to provide alternative ways
of doing the same thing, i.e. linking data to metadata.
> Xiaoshu
[1]http://www.yr-bcn.es/dokuwiki/doku.php?id=microsearch
[2]http://www.w3.org/TR/grddl-scenarios/#header_use_case


-- 
		-harry

Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426
Received on Monday, 24 March 2008 19:07:09 GMT

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