W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > July 2008

Re: RDFa test suite addition

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Mon, 28 Jul 2008 18:59:58 +0100
Message-ID: <ed77aa9f0807281059y4d84501maffd39b65f5d623b@mail.gmail.com>
To: "Manu Sporny" <msporny@digitalbazaar.com>
Cc: "RDFa mailing list" <public-rdf-in-xhtml-tf@w3.org>

Hi Manu,

> For example, if someone were to specify a URI like so:
>    <a rel="next" href="/pages/15">next page</a>
> The correct behavior is to append the "/pages/15" part to the URL
> host-part, not the document part. librdfa was wrongfully appending the
> URL to the document part. Easy to fix, but I was surprised that none of
> the unit tests checked that common behavior.

I guess that's true, although the error is in not using the correct
relative-to-absolute path processing algorithm, i.e., you can't simply
'append'. To illustrate...

In your example, you have this:

  <div about="#sneaking-sally">
    <a rel="media:download" href="/live/sneaking_sally.mp3">Live Recording</a>

and as you say, you want it to generate this:

      <http://rdfa.digitalbazaar.com/live/sneaking_sally.mp3> .

That's fine, and simply 'appending' will work in this situation,
provided -- as you say -- that you append to the correct part of the
base URL.

But we also need to ensure that the same triples are generated by this:

  <div about="#sneaking-sally">
    <a rel="media:download" href="../../live/sneaking_sally.mp3">Live

The sample document you gave is in the directory "/fuzzbot/demo", so
"../../live" should be the same as "/live". However, even if you
'append to the right part', the resulting URL is wrong:


If your triple-store normalises URIs on the way in then you might get
away with this, but if it doesn't then you'll have trouble retrieving
that URI, since you'll almost certainly be searching for:


I may be telling granny to suck eggs here. :) But to get this right
you need to correctly make the path into an absolute path, rather than
just concatenating.

Retrieving the MP3 via a URL that contains ".." will probably work, so
this problem often doesn't show itself. But it becomes more
significant when you get to @about processing; the following *should*
give the same triples as before:

  <div about="/fuzzbot/demo/audio.html#sneaking-sally">
    <a rel="media:download" href="../../live/sneaking_sally.mp3">Live

But it will only do so if relative-to-absolute conversion is correct.
Concatenation won't work.

Same goes for this, which should use the scheme of the base URL:

  <div about="audio.html#sneaking-sally">
    <a rel="media:download"



Mark Birbeck, webBackplane



webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)
Received on Monday, 28 July 2008 18:00:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:28 UTC