Re: Proposal for 'URIs everywhere'

Hi,

here's a high-level comment without looking at the details.

I appreciate the attempt to make progress. As far as I can tell, the 
change being proposed actually will not be backwards-compatible in all 
cases (for instance, when changing from URIorSafeCURIE to URIorCURIE). 
In which case you really should consider making a change that at least 
avoids confusion and potential ambiguity, by making everything 
URIorSafeCURIE. That would also align (as far as I recall) with the TAG 
advice not to use CURIEs where they might be confused with URIs.

Best regards, Julian


Mark Birbeck wrote:
> Hello all,
> 
> I'd hoped to get the following proposal to the group at the beginning
> of the week, but it wasn't possible.
> 
> Anyway, below you'll find a series of minor changes that I feel would
> need to be made to various parts of the syntax document, in order to
> support URIs and CURIEs in all RDFa-related attributes (except @src
> and @href).
> 
> To recap, whilst most of our attributes support URIs and CURIEs
> already, @property, @rel and @rev only supported URIs. This means that
> authors must declare prefix mappings for all predicates, even though
> they are not required to use prefix mappings for subjects or objects.
> We've agreed to try to address this, and I had an action item to come
> up with some proposed text.
> 
> 
> APPROACH
> 
> The first step in sorting this out, is to remove the separation where
> in some places we allow a CURIE, and in others we allow a
> URIorSafeCURIE.
> 
> Both situations will now use the same type, which I've called
> 'URIorCURIE'. (This type did used to exist in previous drafts, but I
> think that's ok. Of course, if anyone can spot a reason why we should
> use a different name, then please mention it.)
> 
> After making the data type consistent throughout, we then need to
> clarify the processing rules.
> 
> And finally, we need to add one or more examples of using a full URI
> for a predicate.
> 
> 
> DATATYPE
> 
> The datatype changes affect section 2.1, as follows:
> 
> 1. On @rel, @rev, @property, @datatype, and @typeof, replace 'CURIE'
> with 'URIorCURIE'.
> 2. On @about and @resource, replace 'URIorSafeCURIE' with 'URIorCURIE'.
> 
> Also, in section 5.4.4, the bullet-points listing the attributes
> should change to this:
> 
>   * @about, @datatype, @property, @resource and @typeof support either a URI or
>     a CURIE.
>   * @href and @src support only a URI.
>   * @rel and @rev support XHTML link types, URIs and CURIEs.
> 
> 
> PROCESSING
> 
> In section 5.4.2, after the three steps, but before the note, we should add:
> 
>   Note that this algorithm assumes that its input is a CURIE, but in practice it
>   won't be possible to definitively establish this until step 2; if
> there is no in-scope
>   mapping that matches the prefix, then the algorithm should terminate, and the
>   input regarded as a URI.
> 
> In section 5.4.3, the first point should be removed, and in the second
> point, the sentence:
> 
>   In this case any value that is not surrounded by square brackets, as defined
>   by 'safe_curie' in the section CURIE Syntax Definition, will be
> processed as if
>   it was a URI.
> 
> should be changed to:
> 
>   In this case any value that is not a CURIE, as outlined in section 5.4.2, will
>   be processed as a URI.
> 
> Note that I've left the prose about square brackets intact, because
> there are probably use-cases where people want to say 'safe CURIE or
> nothing'. (I.e., don't fall back to a URI if there is no prefix
> mapping.)
> 
> In the sentence after the two (now one) sentences, we should change this:
> 
>   An example of an attribute that can contain CURIE and non-CURIE values is
>   @about. As described, any CURIEs expressed in the attribute must follow the
>   format of a [safe CURIE]. So to express a URI directly, an author
> might do this:
> 
> to this:
> 
>   An example of an attribute that can contain a URIorCURIE is @about. To
>   express a URI directly, an author might do this:
> 
> After the example, the next sentence/example combination can be
> duplicated, to give us an extra example, like this:
> 
>   whilst to express a CURIE they could do this:
> 
>     <div about="dbr:Albert_Einstein">
>       ...
>     </div>
> 
>   The author could also use a safe CURIE, as follows:
> 
>     <div about="[dbr:Albert_Einstein]">
>       ...
>     </div>
> 
> In the next example, we just need to clarify that we're now only
> referring to safe CURIEs; this:
> 
>   Since non-CURIE values MUST be ignored, ...
> 
> becomes this:
> 
>   Since non-CURIE values MUST be ignored when they appear in safe CURIEs, ...
> 
> In section 5.4.4, after the bullet-points, the entire sentence reading:
> 
>   Note that unlike @about and @resource, @rel and @rev do not
> differentiate their two
>   types of data by using [safe CURIE]s.
> 
> should be removed. The next sentence, which reads:
> 
>   Instead, any value that matches an entry in the list of link types
> in the section
>   The rel attribute, MUST be treated as if it was a URI within the
> XHTML vocabulary,
>   and all other values must be CURIEs.
> 
> should be changed to:
> 
>   Any value that matches an entry in the list of link types in the
> section The rel
>   attribute, MUST be treated as if it was a URI within the XHTML vocabulary. All
>   other values will be processed as URIorCURIEs.
> 
> The next paragraph and its associated example, beginning:
> 
>   Note that only values in the link type list have this special behaviour, ...
> 
> can be deleted.
> 
> In the section 5.4.5, the example can have its square brackets removed.
> 
> In section 7, the sentence:
> 
>   Since it is difficult to distinguish between CURIEs and URIs, the CURIE
>   syntax adds the notion of a [safe CURIE].
> 
> should be changed to:
> 
>   A URI that uses a scheme that is not an in-scope mapping cannot be
>   confused with a CURIE. However, since there may be situations where
>   authors would like to make it explicit that they are using a CURIE, the
>   CURIE syntax adds the notion of a [safe CURIE].
> 
> 
> EXAMPLES
> 
> At the end of section 2.2, we can add:
> 
>   When dealing with small amounts of mark-up, it is sometimes easier
> to use full URIs,
>   rather than CURIEs. The previous example can also be written as follows:
> 
>   <html xmlns="http://www.w3.org/1999/xhtml">
>     <head>
>       <title>Books by Marco Pierre White</title>
>     </head>
>     <body>
>       I think White's book
>       '<span
>        about="urn:ISBN:0091808189"
>        typeof="http://example.org/book"
>        property="http://purl.org/dc/elements/1.1/title"
>        >Canteen Cuisine</span>'
>       is well worth getting since although it's quite advanced stuff, he
>       makes it pretty easy to follow. You might also like
>       <span
>        about="urn:ISBN:1596913614"
>        typeof="http://example.org/book"
>        property="http://purl.org/dc/elements/1.1/description"
>        >White's autobiography</span>.
>     </body>
>   </html>
> 
> Regards,
> 
> Mark
> 
> --
> Mark Birbeck, webBackplane
> 
> mark.birbeck@webBackplane.com
> 
> http://webBackplane.com/mark-birbeck
> 
> webBackplane is a trading name of Backplane Ltd. (company number
> 05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
> London, EC2A 4RR)
>

Received on Thursday, 26 November 2009 12:31:29 UTC