Re: Discussion with Ian and Henri about HTML5+RDFa (part 2/2)

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