- From: Steven Pemberton <Steven.Pemberton@cwi.nl>
- Date: Mon, 30 Nov 2009 15:02:37 +0100
- To: "Ivan Herman" <ivan@w3.org>, "Mark Birbeck" <mark.birbeck@webbackplane.com>
- Cc: "W3C RDFa task force" <public-rdf-in-xhtml-tf@w3.org>
> Looking at this list, the remaining asymmetry is the usage of keywords > for @rel/@rev/@property. I begin to wonder: if we do such a grand > unification, does it make sense to keep this asymmetry? I do not claim > that statements like > > <span about="next" ... /> > > would have a widespread usage but it does make sense in the RDF sense, > ie, it means > > xhtml:next some:property some:value . > > ie, I make a statement on an existing predicate. Perfectly kosher for > RDF. > > Ie: what about removing that asymmetry altogether, and say that > predefined keywords are also valid for @about and @resource? It would > make the URI management simpler and cleaner and I do not really see a > major drawback... No, please not. As far as I am concerned about="next" must always mean the same as about="./next". It must always be a URI. Steven > > Ivan > > P.S. So here is what I run now. > > 1. Get the possible safe curie signs out of the way at the start, ie, if > the value is of the form '[...]' then remove the [ and ] signs and set a > 'safe_curie' flag to True. > > 2. Get the possible blank node management out of the way, ie return the > right blank node for things like '_:a'. Note that if this is called for > a @rel/@property/@ref, then return None (with possible error message) > because you cannot have a blank node for a predicate > > 3. If it is called on @rel/@rev and the value is a keyword then return > the corresponding URI > > 4. Try to match the value against a CURIE definition (ie, see if it is > of the form a:b and 'a' is defined as a namespace, oops, local name). If > yes, return the corresponding URI > > 5. If we get here, this should become a real URI. However, if the > safe_curie flag was set to True, stop at this point and (possibly) issue > an error message and return with None > > 6. If we get here, this is a real URI (absolute or relative), and fall > back to the usual URI management to get the final URI. >
Received on Monday, 30 November 2009 14:03:17 UTC