Re: the Creative Commons take on @href everywhere

Hi Ben,

[I apologise that I forgot to send this last week. I see that you have
sent another email on this topic, so I'll try to continue the
discussion there, too. But I thought I might as well send this anyway,
since I'd written it!]

> In other words: is this really RDFa's problem?

I definitely agree...it's a really tricky one. I said the same thing
at the start of my email:

> > Ok...that's good news...I think. But we have some problems, and they
> > are not of our own making.

But although it's not of our own making, I don't think we can ignore it.

So...to the issue:

> I'm open to changing my opinion *back* to no @href everywhere, but I'm
> not sure that this convinces me... because I think this can be resolved
> with an existing TAG decision:
>
> http://www.w3.org/2001/tag/issues.html#httpRange-14
>
> Basically, if you get a 303 when you de-reference the URI, then the URI
> can be a non-information resource. In other words, say you have the markup:
>
> <a rel="foaf:knows" href="http://www.ivan-herman.net/ivan">Ivan</a>
>
> but you want http://www.ivan-herman.net/ivan to be "Ivan", then you have
> ivan-herman.net issue a 303 redirect to
> http://www.ivan-herman.net/ivan-foaf.rdf, which describes the URI /ivan.
>
> Clicking through still works, and the URI is a non-information resource.

But clicking through would take you to the RDF file, right? In other
words there is no document at the first URL, just a redirect. That
seems to me to be the wrong way round.

My understanding of that particular TAG finding is that it is not
actually about documents but about URLs; it's simply saying that
although the usual recommended practice is to say that an HTTP-based
URI with no fragment identifier is an information resource, there is a
compromise 'get out of jail' card of using a 303, where you are
entitled to make your HTTP server redirect the request for an HTML
file to a request for an RDF one. In other words, 'if you really must'
:) it is legitimate to use an HTTP-based URI with no fragment
identifier to signify a non-information resource, but you'd need to
use this technique to 'bounce' on to a non-information resource.

But as I say, there will be no document (information resource) at the
first URL since the HTTP server is going to do nothing but redirect to
some other document (invariably a non-information resource).

Also, the problem with the 303 approach is that you don't know what's
behind the first URI until you dereference it, which doesn't work very
well for a parser. If we parse the mark-up and store the first URI
(http://www.ivan-herman.net/ivan in your example) we now have a set of
statements that seem to be about a document (information resource),
and not a person. To work out whether those statements are really
about a person (in your example, that would be
http://www.ivan-herman.net/ivan-foaf.rdf) we'd have to de-reference
every single URI we've obtained, retrieve any URIs in 303 returns, and
then update our triples. That's very flakey (if the request fails you
don't know whether it's because you have a non-information resource
anyway, or if it's because the server is down) and of course it's very
resource intensive.

My suggestion as a way out of this--which is independent of @resource
v. @href--would be to try to encourage some kind of best practice. So,
to follow through the approach, the first step is that we really do
have a document (information resource) at this location:

  <http://www.w3.org/People/Ivan>

It's an HTML document, so we can talk about its creation date, language, etc.

If we look at this document we see that Ivan's personal information
actually starts under:

  <http://www.w3.org/People/Ivan#me>

I think we should consider promoting this as some kind of best
practice, and use this as the reference point for our @href, rather
than the main document. That's not actually a bad thing, I don't
think, since Ivan's document might contain all sorts of other stuff:

  <http://www.w3.org/People/Ivan#me>
  <http://www.w3.org/People/Ivan#www2007>
  <http://www.w3.org/People/Ivan#office>
  <http://www.w3.org/People/Ivan#home>

We would essentially be saying that any link in a document that you
want to make statements about should have a fragment identifier.


> Sure, people will make "mistakes" and point directly to information
> resources they intend to be "Ivan". But that's going to happen no matter
> what we do.

As you say, people will make mistakes, and obviously they'll often
link directly to the main document. It's of course not terrible if
authors do that, but it does mean that their triples might not match
up, since in our example, all of Ivan's triples about himself are
about the subject  "http://www.w3.org/People/Ivan#me". However, by
emphasising best practice in our documents and tutorials, we can
hopefully make the moment when an author adds the @rel attribute to an
<a> into the point where they think, 'Hang on...I'm now saying
something _about_ the link that I already had, so I may need to be
more precise about what I'm saying'.


Anyway, back to the main issue; all I'm saying is that for those
authors who *know* what they are linking to, having the ability to use
the @resource attribute is very useful in *addition* to @href. I.e.,
it's a way of saying 'I _know_ that the resource that I'm referring to
is not an information resource'.

Regards,

Mark

-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Monday, 9 July 2007 22:10:25 UTC