Re: the Creative Commons take on @href everywhere

Mark Birbeck wrote:
> In a set of RDF triples that is of course true. But we're dealing with
> links in HTML documents. I think it's reasonable to say that a URI
> that appears in an @href in an <a> in an HTML document is making
> reference to an information resource.

I just don't see the reasoning for this. People use links that redirect
somewhere else all the time. They do content-negotiation. They do all
sorts of things that change what the browser gets depending on all sorts
of parameters. So I don't see why it's a good idea to have the linking
document declare the type of the linked document.

> Note by the way that I'm not proposing stopping people using one or
> the other--as I said before if they get it wrong, so be it. However,
> in my mark-up I certainly don't want to use @href to indicate a
> resource that is *not* a web page, since I don't want to run the risk
> that in the future some browser will allow the user to click on it and
> load...well, nothing.
> 
> (And I also don't want XHTML 2 spec authors to be told in the future
> that we can't allow the appearance of @href on _any_ element to
> represent a navigable link, because unfortunately there are too many
> non-navigable values in use already.)

Again, I don't think you would get nothing. You would get redirected
somewhere that describes the resource in question.

So, specifically, when you link to:

http://acme.com/car

a web browser would be redirected to

http://acme.com/stuff-about-the-car.

If you do it your way, you would have to write:

<a resource="car" href="stuff-about-the-car">car</a>

which is totally wrong, because the stable link is "car", not
"stuff-about-the-car"

> All I'm suggesting is that if an author knows for definite that they
> are referring to something that will never be viewable in a web
> browser

but the point of what we're doing is to make sure that it *is* always
viewable in a web browser! This artificial separation of "viewable" and
"non-viewable" in an HTML browser is not what we want for the future, in
my opinion, so I don't see why we should encourage this separation.

> (like me, or you, or a box of chocolates or a camel) then they
> should be able to make statements about it without worrying that
> someone _might_ try to load the camel or your or me or the chocolates
> into their web browser. (Because currently technology only allows us
> to load _information_ resources into a web browser.)

I'm pretty sure you know that's not what I was arguing :) The semantic
web expects that you would get redirected to something that describes
the resource. Obviously, you're not loading chocolate into your browser
(though that would be nice.)

> But I *do* know. :) I know when I'm making statements about a web
> page, and I know when I'm making statements about an airplane. If I
> didn't, I'd be in a right pickle. And since I know what it is that I'm
> making statements about, then I certainly know that one is an
> information resource, and the other is not.

But that should NOT change how you link to it! That's the whole point.
You link to the URI, and the server decides how to help browsers
dereference it. It's not your job, as the linker, to say "please don't
go there." The URI is *meant* to be dereferenceable, no matter what.

If you really want to not provide a link to it, I'm sure XHTML2 will
provide you with a style that says "non-navigeable", right? But that's a
style decision, not something that should change the RDF statements.

-Ben

Received on Thursday, 12 July 2007 02:56:03 UTC