Re: Fine-tuning CURIEs

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.

Received on Tuesday, 11 September 2007 15:51:11 UTC