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

Re: Fine-tuning CURIEs

From: Ivan Herman <ivan@w3.org>
Date: Tue, 11 Sep 2007 17:37:49 +0200
Message-ID: <46E6B64D.5050501@w3.org>
To: Shane McCarron <shane@aptest.com>
Cc: Mark Birbeck <mark.birbeck@formsPlayer.com>, W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>

Shane McCarron wrote:
> I think the XHTML Working Group would disagree with your position,
> Ivan.  We have defined a bunch of reserved terms in the XHTML space, and
> have declared that those map into RDF triples.  I mean, I could be wrong
> here.... but I don't think so.  Further, we the RDFa in XHTML Task Force
> have said time and again that extra triples are ok.  Every instance of
> @rel in a document is going to generate triples.... I can't see this
> working any other way.

I think you misunderstood. Yes, I know, the XHTML working group defines
a number of values for @rel/@rev that would then be used as predicate in
the xhtml namespace. There is a list (that you had in the previous
draft, not in the present one, actually) that contains those definition
(next, copyright, that sort of things).

However: obviously, the user can use other values for @rel, stemming
from different other possible applications and profiles. We cannot
control that, nor should we, I believe. What makes me uneasy is that we
would generate triples for those, too...

> On the other hand, I need to disagree with Mark for a different reason. 
> XHTML says that all non-qualified @rel / @rev values are in the XHTML
> namespace.  So I dont think we can change the CURIE rules to say that
> they are instead in the default namespace - too error prone.  I think it
> would be fine to say a value of ':foo' is in the default namespace.... 
> assuming a grammar has a way to define a default.

Hm. What is the 'default namespace', in fact? Of course, syntactically,
the user can also say

<p xmlns="http://w.q.r">balba</p>


- is this allowed by the current DTD?
- should we allow it for RDFa? Remember that we do not use XML
namespaces but only the syntactic sugar for it. Ie, the attribute @xmlns
(without a local name) would then require extra explanation... In other
words we do not have such animal as default namespace in CURIE, do we?:-)

Ie: I think ":b" means "http://www.w3.org/1999/xhtml/b", and that is the
way we should define it (and keep away from the notion of default


> Ivan Herman wrote:
>> Mark,
>> I have given some thoughts but, after all, I decided to vote against
>> your proposal. Sorry about that:-)
>> The main issue I have is to avoid the generation of 'accidental'
>> triples. The @rel attribute is not proper to RDFa and may and is used in
>> other places in an XHTML file. The intention may _not_ be the generation
>> of a triple but, in the scheme your propose, there is no way to avoid
>> that. Eg, the <link> element use rel for a stylesheet; I am not sure it
>> is relevant to generate a triple for the CSS file (certainly not without
>> the user asking us to do it).
>> Ie: a:b and :b are, in my view, the only two forms that we should
>> accept...
>> Ivan
>> Mark Birbeck wrote:
>>> Hello all,
>>> During the course of finishing off the Syntax document a couple of
>>> issues have popped up. I'll deal with them in separate threads.
>>> This thread relates specifically to the way that we ensure that
>>> mark-up like this yields the kind of triples we'd expect:
>>>   <link rel="next" href="o" />
>>> At the moment we say that some kind of preprocessor runs and that the
>>> mark-up above is 'mapped' to this:
>>>   <link rel="xh:next" href="o" />
>>> This is fine, and if we're happy with that, we can just leave it.
>>> However, there is another way to come at this, which I'll describe.
>>> Myself and Shane changed the CURIE definition recently so that *both*
>>> the prefix and the colon were optional:
>>>   [ [ prefix ] ':' ] reference
>>> This is so that all of the following are valid:
>>>   a:b
>>>   :b
>>>   b
>>> We did this because the second format is needed in N3 and Turtle-based
>>> languages such as SPARQL, whilst the third format is needed if we want
>>> to be able to handle legacy QNames.
>>> I was therefore looking more closely at what exactly these three
>>> different formats should mean since we don't have that defined clearly
>>> in our specification. The most obvious route for the second format is
>>> to say that it should use the current default namespace, making it
>>> consistent with SPARQL, etc.
>>> However, there is no general practice for non-prefixed QNames--in some
>>> situations the default namespace is used (such as in declarations of
>>> type in XML Schema), and in some situations it is explicitly ignored
>>> (such as when defining a template in XSLT). This means that we could
>>> choose to use the default namespace, or define some other rule like
>>> always using the XHTML namespace, or even the current value of [base].
>>> An interesting thing comes about though, if we were to choose to use
>>> the default namespace; returning to the syntax we had earlier:
>>>   <link rel="next" href="o" />
>>> we could obtain a predicate of 'xh:next' without having to do _any_
>>> preprocessing, but *only* if the default namespace was XHTML:
>>> <html xmlns="http://www.w3.org/1999/xhtml">
>>>   <head>
>>>     <title>...</title>
>>>     <link rel="next" href="o" />
>>>   </head>
>>>   ...
>>> </html>
>>> I like this approach since I think it gives future authors a lot of
>>> flexibility. It also, quite by accident, provides a way to remove the
>>> need for a lot of the preprocessing we have been discussing. For
>>> example, one could mark-up OpenID using a layout like this:
>>>    <link rel="openid.server" xmlns="http://openid.net/"
>>>       href="https://api.screenname.aol.com/auth/openidServer" />
>>>    <link rel="openid.delegate" xmlns="http://openid.net/"
>>>        href="http://openid.aol.com/wezfurlong" />
>>> Note that instead of worrying about trying to make "openid." into some
>>> kind of prefix, we simply use the full string as the reference.
>>> Anyway, there you have it. The choices seem to be:
>>>   * have a preprocessing step to get at 'legacy' properties and
>>> short-forms, such
>>>     as xh:next. In this case we'd still need to say what unprefixed
>>> CURIEs mean,
>>>     but wherever we choose would make no difference to the
>>> preprocessing step;
>>>     they could be in the default namespace, the current document, or
>>> some explit
>>>     namespace;
>>>   * or, we say that CURIEs with no prefix--with or without the
>>> colon--use the default
>>>     namespace, and then leverage this to cope with some of the legacy
>>> properties
>>>     like 'xh:next' and 'openid:openid.delegate' _without_ the need for
>>> a preprocesing
>>>     step.
>>> Myself, I can go either way; I'd prefer the second solution, since I
>>> think it would be quite neat if we only used the preprocessing step
>>> when it is really necessary. This is because although the
>>> preprocessing seems pretty benign, we've never really discussed things
>>> like the fact that the preprocessor must operate across all of the
>>> attributes, in a consistent way. For example, the value of 'next'
>>> would need mapping in both @rel and @about, for the following
>>> statements to work:
>>>   <html xmlns:skos="http://www.w3.org/2004/02/skos/core#">
>>>     <head>
>>>       <link rel="next" href="o" />
>>>       .
>>>       .
>>>       .
>>>       <div about="[next]" instanceof="skos:Concept">
>>>         <span property="skos:prefLabel">Next</span>
>>>         <div property="skos:definitionl">
>>>           Refers to the next document in a linear sequence of
>>> documents. User
>>>           agents may choose to preload the "next" document, to reduce
>>> the
>>>           perceived load time.
>>>         </div>
>>>       </div>
>>> However, if the CURIEs were using the default namespace you can see
>>> that this mark-up would 'just work'.
>>> Your thoughts and votes please. :)
>>> Regards,
>>> Mark


Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Tuesday, 11 September 2007 15:37:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:01:52 UTC