- From: Mark Birbeck <mark.birbeck@webbackplane.com>
- Date: Wed, 25 Nov 2009 22:06:20 +0000
- To: W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>
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