- From: Ivan Herman <ivan@w3.org>
- Date: Tue, 11 Sep 2007 18:01:50 +0200
- To: W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>
- Cc: Ralph Swick <swick@w3.org>
- Message-ID: <46E6BBEE.8000806@w3.org>
This mail actually triggered a procedural issue for me, but maybe I
misunderstood Mark's comment below.
Is it the plan to produce a _separate_ document for CURIE-s? Mark's
formulation below referring to "CURIE-s can be used in any language",
etc, suggests that.
I see a possible problem.
Our goal is to have RDFa as a Rec. Ie, I presume, the RDFa syntax and,
possibly, the RDFa primer will go through the usual channels to become a
Rec, either by the SWD WG or the XHTML2 WG.
If the CURIE becomes a separate document, that means we will have to get
it through the REC channels, too. In view of its more general nature,
that would mean that this document would have to be reviewed by, eg, the
XML Core working group. This would create a significant delay, generate
all kinds of discussions which, frankly, can go out of control.
My proposal is to keep the CURIE issue to its strict minimum, keep it
within the RDFa syntax document and, at least for now, *apply it to the
RDFa case only*. Do _not_ make it more general than that for now. This
could lead to a significant slow down of the RDFa REC which none of us want.
Ivan
-------- Original Message --------
Subject: Re: Fine-tuning CURIEs
Date: Tue, 11 Sep 2007 16:50:48 +0100
From: Mark Birbeck <mark.birbeck@formsPlayer.com>
To: Shane McCarron <shane@aptest.com>
CC: Ivan Herman <ivan@w3.org>, W3C RDFa task force
<public-rdf-in-xhtml-tf@w3.org>
References:
<a707f8300709110540wdf388d6ta2982fab00124295@mail.gmail.com>
<46E6AE6C.2070407@w3.org> <46E6B2FC.9080901@aptest.com>
Ivan/Shane,
Thanks for your comments. You're not actually "disagreeing" with me
though, since I put forward two proposals. :) I didn't think you'd go
for the one I was favouring, but I thought it worth a punt.
However, Shane is right that the side-effect that comes about when
changing the default namespace--that @rel="next" ceases to be an XHTML
predicate--is best avoided, not least because it means that there will
be a difference in interpretation between RDFa and non-RDFa
processors. (But also because it breaks with the notion of trying to
avoid affecting the host language too much.)
However, there is still a clarification that needs to be made, which
is why I raised the issue, although I think I've got sorted now. What
I now have in the syntax document is this:
<blockquote>
CURIEs can be used in any language, including non-XML languages.
Any language
that wishes to make use of CURIEs must provide a context which
consists of:
* a set of mappings from prefixes to URIs (for example,
<code>p:r</code>);
* a mapping to use with the default prefix (for example,
<code>:r</code>);
* a mapping to use when there is no prefix (for example,
<code>r</code>);
* a mapping to use with the '_' prefix, which is used to generate
unique
identifiers (for example, <code>_:r</code>).
When CURIEs are used in RDFa in XHTML, the context is set as follows:
* the prefix mappings are provided by the current in-scope
namespace declarations
of the [current element] during parsing;
* the mapping to use with the default prefix is the current
default namespace;
* the mapping to use when there is no prefix is
<code>http://www.w3.org/1999/xhtml#</code>;
* the mapping to use with the '_' prefix is not explicitly
stated, but should be chosen by
the processor to ensure that there is no possibility of
collision with other documents.
</blockquote>
This fits with most of the uses of QNames that I can find. For
example, XSLT says (for some attributes) that non-prefixed QNames are
*not* expanded relative to the default namespace, whilst in some XML
Schema attributes they are. In our case we've said that a CURIE with
no prefix is expanded, but it will be exanded based on a fixed
mapping, i.e., the XHTML namespace. (I've added '#' but we can discuss
that separately.)
And it also fits with SPARQL/Turtle/N-Triples where ':r' is treated as
a kind of 'prefix with no name'. The closest we can get to that in XML
mark-up is the default namespace prefix.
The final thing about generating unique IDs (aka bnodes) we can look
at a bit more--we might decide to add an algorithm, although my guess
is that it's best not to.
Regards,
Mark
As you can see, ':next' and 'next' can now diverge; the latter will
*always* represent 'xh:next', since we've hard-coded the 'no prefix'
rule. And ':next' may or may not represent 'xh:next', depending on the
current in-scope default namespace.
But note that this still removes the need for any preprocessing to
find XHTML-specific values.
Regards,
Mark
On 11/09/2007, Shane McCarron <shane@aptest.com> 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.
>
> 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.
>
> 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
> >>
> >>
> >
> >
>
> --
> Shane P. McCarron Phone: +1 763 786-8160 x120
> Managing Director Fax: +1 763 786-8180
> ApTest Minnesota Inet: shane@aptest.com
>
>
>
--
Mark Birbeck, formsPlayer
mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
http://www.formsPlayer.com | http://internet-apps.blogspot.com
standards. innovation.
--
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 16:01:59 UTC