- From: Niklas Lindström <lindstream@gmail.com>
- Date: Mon, 16 Nov 2009 13:46:58 +0100
- To: Ivan Herman <ivan@w3.org>
- Cc: Ben Adida <ben@adida.net>, RDFa <public-rdf-in-xhtml-tf@w3.org>
Hi!
On Mon, Nov 16, 2009 at 1:03 PM, Ivan Herman <ivan@w3.org> wrote:
> Still following up on this...
>
[...]
> - I actually did an implementation on my machine, reasonably tested. The
> algorithm is fairly simple (unless I miss an elephant in the room):
>
> 1. check whether the value is of the 'a:b' form and 'a' is defined CURIE
> prefix
> 2. if yes, return the URI as defined by the CURIE
> 3. if not, do a urljoin of the base URI and the value. Per definition of
> that join, if the value is an absolute URI, that will prevail, otherwise
> the urljoin rules will dictate the behaviour. (eg, Python has just
> method as part of its standard library...)
>
> The only difference between the old and new version is entries #1 and
> #2, #3 was the behaviour as of RDFa 1.0.
>
> Actually, the same steps could also be used for @rel/@rev/@typeof, ie,
> allowing relative URIs for those attributes as well! Which might
> simplify everything: all RDFa attributes would behave similarly. (Again,
> we should not touch @href and @src.)
>
> So is there an elephant?:-)
I haven't followed this discussion to closely, so I want to check if
this the following is considered:
This usage will "muddle the waters" in cases when the relative URI:s
contain colon, and there is a prefix with the same name as the leading
part before that, right? Concrete (but contrieved) example:
Given:
- base URI: <http://en.wikipedia.org/wiki/>
- prefix Talk: <http://example.org/schema/talk#>
When:
@resource="Talk:Linked_Data"
Then:
- URI becomes < http://example.org/schema/talk#Linked_Data>,
instead of <http://en.wikipedia.org/wiki/Talk:Linked_Data>, which is
might be expected?
(Don't mind the malpractise of using a "Title-cased" prefix here, I
just picked the first real-word relative URL with colon in it I
found..)
Best regards,
Niklas
Received on Monday, 16 November 2009 12:57:57 UTC