W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > October 2010

Re: Some RDFa 1.1 Core edge cases that we need to clarify

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Tue, 26 Oct 2010 18:24:07 +0100
Message-ID: <AANLkTik=Ch1+_BYgtA9fbNin-TT2yM+O5YEmO57JJ9e=@mail.gmail.com>
To: Shane McCarron <shane@aptest.com>
Cc: nathan@webr3.org, Ivan Herman <ivan@w3.org>, Toby Inkster <tai@g5n.co.uk>, public-rdfa-wg@w3.org, Martin McEvoy <martin@weborganics.co.uk>
Hi Shane,

On Tue, Oct 26, 2010 at 5:18 PM, Shane McCarron <shane@aptest.com> wrote:
> I agree with Mark here.  However, I also feel that we should encourage
> people to NOT do this for the same reasons we encourage people to not use
> relative URIs for prefix mappings.

I think a relative URI for a default vocabulary is actually quite a
legitimate scenario.

Let's say that I want all 'undefined' terms to appear in a triple
store for further processing. If I use an absolute URI then the
undefined term 'foo' in document A will be the same as the undefined
term 'foo' in document B.

However, if I define my default vocabulary as:

  @vocab="/undefined-term/"

then I'll get two different "foo" entries:

  http://example.org/document-A/undefined-term/foo
  http://example.org/document-B/undefined-term/foo

Now I can process them completely independently of each other.


> Also, and correct me if I am wrong, don't we need to fully resolve any
> relative URIs in order to implant them in attributes within an XMLLiteral
> serialization?

I think the /spirit/ of the XML fragment canonicalisation algorithm is
to try to make the fragment fit nicely with the structure of the
document into which it is going to be placed. But I don't think it
tries to do anything clever with the /content/ of the mark-up (i.e.,
the meaning as given to the mark-up by SVG, XHTML, XForms, etc.).

I don't think we should go any further than the canonicalisation algorithm.

Regards,

Mark
Received on Tuesday, 26 October 2010 17:25:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:22 UTC