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

Re: Fine-tuning CURIEs (reply #2 :-)

From: Ivan Herman <ivan@w3.org>
Date: Wed, 12 Sep 2007 10:40:34 +0200
Message-ID: <46E7A602.2010002@w3.org>
To: Mark Birbeck <mark.birbeck@formsPlayer.com>
Cc: W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>

I thought about this again but, I must admit, I did not change my
opinion, even reading through the thread again...

I was actually a bit surprised to read, in Shane's reply[1] that

XHTML prohibits the introduction of other values that are not namespace
qualified into @rel / @rev (and @role).  That whole space is reserved.
The DTD does not enforce this because it is not possible to do so, but
conforming RDFa processors should  ignore any incorrect values IMHO.

Is this an XHTML1 or and XHTML2 feature? As far as XHTML1 is concerned,
I looked up in [2] and it says:

Authors may use the following recognized link types, listed here with
their conventional interpretations. A LinkTypes value refers to a
space-separated list of link types. White space characters are not
permitted within link types.

I am not sure how to interpret the word 'may' in this respect, but my
impression is that this means the author can have his/her own, or use
these predefined ones.

However... regardless of what the spec says, the reality out there is
that authos _do_ use @rel/@rev with values that are _not_ defined by
XHTML. The example of openid or DC are the obvious ones. What this also
means that the _second_ scheme you propose:-) would actually lead to new
and somewhat unexpected triples. (By the way, one of the
questions/comments asked by the DCMI guys in Singapore was exactly that:
they _hope_ that RDFa will not generate extra triples if they are
encoded using the dc.title trick...)

Regardless of how it is described in the CURIE document, my feeling is that:

- 1. We should obviously interpret 'a:b'
- 2. We should interpret 'b' as 'http://www.w3.org/1999/xhtml/b'
_provided_ that 'b' is one of the entries listed by the relevant XHTML
document (I fully agree with Shane on that one for the reasons above)
- 3. For ':b' we can either say that it behaves exactly like 'b' above,
or we introduce the usage of a default namespace. I am mildly in favour
_not_ to use the concept of default namespace at all. Yes, that would
invalidate your openid example, but I do not think that is so important
(and the DCMI use case is, as I said before, moot)


[1] http://www.w3.org/mid/46E6BB62.9070204@aptest.com

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 Wednesday, 12 September 2007 08:40:32 UTC

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