- From: Mark Birbeck <mark.birbeck@webbackplane.com>
- Date: Mon, 26 Jan 2009 14:12:28 +0000
- To: Toby Inkster <tai@g5n.co.uk>
- Cc: Dan Brickley <danbri@danbri.org>, Ben Adida <ben@adida.net>, Manu Sporny <msporny@digitalbazaar.com>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, Ian Hickson <ian@hixie.ch>, Henri Sivonen <hsivonen@iki.fi>, Sam Ruby <rubys@intertwingly.net>
Hi Toby, >> Henri and Dan have noted that by accepting "xmlns:html='html'" and >> limiting oneself to full URIs you get to the point where you have a >> document which can be processed correctly by many RDF parsers. > > To be pedantic, it's xmlns:http="http:" (Note the colon in the attribute > value.) > > As far as I can see, it's a reasonable compromise. RDFa parsers will > probably need some updating for HTML5 anyway (e.g. the proposed @prefix), > so it shouldn't hurt to include this. Just to clarify though, RDFa parsers will already support this. I know this is what you are saying, but I want to make sure it's clear for others -- we're only talking about whether the prefix mapping can be 'omitted'. On the subject of defining @xmlns:http="http:", I should say that this is something that has been touched on, on and off, a few times. I even proposed it myself on a telecon a long time ago, and everyone went "yeuch!". :) Of course the problem is that the designers of QNames made them look like URIs, so any solution is going to evoke a "yeuch!" at some level. Not wishing to rule out the subsequent discussion, another proposal I had was that any prefix that wasn't mapped would simply map to itself plus a colon. This has a number of advantages over the current proposal: * there is no central list to maintain; * it immediately includes common prefixes like "mailto:" and "ftp:", as well as those that feature in URNs, such as "isbn:". However, the disadvantage is that it is not backwards compatible with existing RDFa, in that triples that were previously ignored might now be processed. I don't really see that as a problem, but I'll propose a solution in case others do. One way round this would be to allow 'identity prefixes' to be declared, by simply listing them: @prefix="http isbn" The fuller syntax would still be usable for 'full mappings': @prefix=" dc=http://purl.org/dc/terms/ http isbn " The exact syntax is still being discussed...but you get the picture that you can either declare a mapping, or you can indicate that the prefix maps to itself. Another alternative would be to say that the mere presence of @prefix adds this extra mode of behaviour, which is that any unmapped prefix maps to itself. Either way, the author can now make explicit that they want previously unparsed triples to be parsed, by using @prefix rather than @xmlns. (As I say, I really don't think this is an issue, but I thought I'd mention a few ways to address it in case other people think this could become an issue.) > I'd suggest not specifying it in a way that says that there is a > hard-coded xmlns:http="http:" on the root element though. It should be > hard-coded at an imaginary level "above" the root element, thus allowing > authors to override it if need be (e.g. there is the HTTP-in-RDF > vocabulary that allows for HTTP requests and responses to be described in > RDF). We've been bouncing some ideas around for a while now about how to define a 'collection' of mappings. We left space for this in CURIEs, and the lead candidate at the moment is @profile. We could also then say that HTML/XHTML loads a 'default' profile. (Although as I say above, if we have identity mappings of prefixes then we don't need a default profile, at least not as a way of solving the 'how do you tell if you have a URI or a CURIE' problem.) > In terms of the RDFa syntax document's processing sequence it could be > implemented by making the list of URI mappings non-empty in the initial > evaluation context. <http://www.w3.org/TR/rdfa-syntax/#sec_5.5.> Right, although we consciously left that flexibility to the CURIEs document. In effect the list is already non-empty, due to the tokens provided by XHTML ("next", "prev", etc.), but I'll be publishing a blog post on that shortly. >> What other desirable and undesirable social effects would there be by >> identifying a registry for well-known namespaces? > > When a new prefix was added to the registry, it would presumably take > weeks, months or even years for it to trickle down to RDFa parsers. > (Unless the registry was machine readable and RDFa parsers were obliged to > query it frequently, which would create a central bottleneck of precisely > the type that RDF was designed to avoid.) > > During the trickle-down period, authors would be wary of using the prefix, > as their experience using it would be inconsistent. > > I don't think an evolving list of default prefixes is a good solution, > though a static list of pre-defined prefixes is workable, provided authors > have a mechanism such as @prefix to define their own prefixes and override > the predefined ones. I agree...which is why I think you really need to be looking at letting any unrecognised prefix map to itself. That solves the http/ftp/mailto/isbn problem, but it doesn't predefine dc and foaf (for example). I think that's fair enough, and we should treat these as two separate issues. 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 Monday, 26 January 2009 14:13:05 UTC