Re: Proposal for 'URIs everywhere'

Hi Julian,

Thanks for this.

The changes I'm proposing do actually give us 'URIorCURIEorSafeCURIE'
everywhere.

:)

It's just that since a CURIE is /either/ a [CURIE] or a [safe CURIE],
I figured that using the name 'URIorCURIE' rather than
'URIorCURIEorSafeCURIE', to represent this in the prose, would be
acceptable.

In other words, the functionality is definitely as you describe --
i.e., it is backwards-compatible -- it's just that the short name I've
used collapses the two types of CURIE into one, more general notion,
of a CURIE.

But if there's a feeling that this might confuse people, and that we
should use the longer term, then I don't have a problem with that
either.

Regards,

Mark

On Thu, Nov 26, 2009 at 12:30 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
> 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 13:47:28 UTC