Re: Proposal for allowing URIs in CURIE-only attributes

Toby A Inkster wrote:
> On 10 Jul 2009, at 13:23, Mark Birbeck wrote:
> 
>>  (c) but since ordinary CURIEs may still be used, we should differentiate
>>      by saying that anything appearing before a colon, that is not a
>>      mapped prefix, is a protocol.
> 
> 
> Wouldn't this break existing pre-RDFa uses of CURIE-like tokens?

(apologies if somebody else covered this already, I haven't caught up
with all of my list traffic for the week - only 120 e-mails to go!)

Yes, you're right, it would. However, we could adjust the rules slightly
by doing something like this:

---------------------

= CURIE prefix mappings =

If a prefix mapping is not found for text that is given to the CURIE
processing algorithm, and the text is an Internationalized Resource
Identifier as defined in IRI[1], and the scheme is one of the allowable
scheme values in the section below, then the expanded value of the
potential CURIE should be the IRI.

== Allowable CURIE Scheme values ==

This section is informative.

Each of these listed values are allowable scheme values for CURIE
processing. The values should be used verbatim in CURIE expansion. Each
value is a registered IANA Scheme[2], each with a corresponding RFC:

aaa aaas acap cap cid crid data dav dict dns fax file ftp go gopher h323
http https iax icap im imap info ipp iris iris.beep iris.xpc iris.xpcs
iris.lwz ldap mailto ... and so on

--------------------

> Uses of "dc:blah" with no explicit prefix mapping are not uncommon.
> (Admittedly more in meta@name than @rel.) I'd say they're almost
> certainly more common than the full-URIs-in-rel that this solution is
> designed to work around.

The above would prevent the dc:blah, dcterms:blah and dmci:blah stuff
from generating a triple, wouldn't it?

> eRDF pages will often also contain rel values with colons in. eRDF does
> map prefixes to URIs, but not via xmlns:foo, instead using an
> RFC2731-style <link> element.

Supporting less of the registered IANA schemes would allow for a
wider-range of backwards compatability with eRDF. I believe Shane said
we could just support "http", "https", "urn", "ftp", and perhaps leave
it at that.

Do we know how many eRDF-enabled documents are out in the wild right
now? If the answer is "not much", then some spurious triples on older
content might be okay...

-- manu

[1] http://www.ietf.org/rfc/rfc3987
[2] http://www.iana.org/assignments/uri-schemes.html

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Bitmunk 3.1 Released - Browser-based P2P Commerce
http://blog.digitalbazaar.com/2009/06/29/browser-based-p2p-commerce/

Received on Thursday, 16 July 2009 05:22:20 UTC