Proposal for 'URIs everywhere'

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 Wednesday, 25 November 2009 22:07:06 UTC