W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > February 2009

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

From: Niklas Lindström <lindstream@gmail.com>
Date: Sun, 1 Feb 2009 21:29:15 +0100
Message-ID: <cf8107640902011229t66afb2b3s1c6cfbc25dc971aa@mail.gmail.com>
To: Mark Birbeck <mark.birbeck@webbackplane.com>
Cc: Toby Inkster <tai@g5n.co.uk>, 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 Mark, all!

I like the general ideas here about @prefix very much. Both for
enabling RDFa in non-XML markup and since the "overloading" of xmlns
is a bit controversial in certain places.

I think Mark's idea of allowing non-declared prefixes to represent
"themselves plus a colon" has strong merits. Albeit there is at least
one bad edge case. If you have markup like:

    <div about="#me" typeof="http://xmlns.com/foaf/0.1/Person">

and http is declared as a prefix higher up (e.g. to the "HTTP in RDF"
stuff as mentioned earlier), this would break quite dramatically. I
think it would make combining RDFa chunks very brittle.

Since this can be very hard to control, the idea of "shortcut
declarations" seems to be the best way:

    prefix="http urn mailto"

would be the same as:

    prefix="http=http: urn=urn: mailto=mailto:"

One far-off idea would be to interpret e.g. @prefix="*" to mean "reset
all prefixes and use self-referencing prefixes". That way one could,
if one wanted to, explicitly skip CURIEs altogether (in a confined
chunk of markup). I'm not at all sure about any merits of this though.
(It may have some, in regard to e.g. @rel in Atom and if the HTML5
community still won't like or would like to limit the power of @prefix
for some reason.)

Finally: In regard to whether to use "=" or ":" for declarations in
the @prefix list, I'd vote for "=". When using multiple declarations
(the common case I believe), I think groups of non-whitespaced
prefix+'='+uri will be easier to read. And if e.g. urn-uri:s are used,
it will be even harder ("acme: urn:x-acme-com:goo:" vs.

Also, albeit N3 and SPARQL use ":", they do it in conjunction with
angle-bracketed uri:s (and multiple prefix keywords).

(As an alternative I thought of @prefix="foaf
[http://xmlns.com/foaf/0.1/]", but that's the opposite of a safe
CURIE, so it might be way too confusing.. Of course, reverse it to
@prefix="[foaf] http://xmlns.com/foaf/0.1/" maybe; but then I'd wonder
where the ":" at the end of the prefix had gone, and so on..)

Just my 2 cents.

Best regards,

On Mon, Jan 26, 2009 at 3:12 PM, Mark Birbeck
<mark.birbeck@webbackplane.com> wrote:
> 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 Sunday, 1 February 2009 20:29:57 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:30 UTC