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:56:12 +0200
Message-ID: <46E6BA9C.7040803@w3.org>
To: Mark Birbeck <mark.birbeck@formsPlayer.com>
Cc: Shane McCarron <shane@aptest.com>, W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>


Mark Birbeck wrote:
> Ivan/Shane,
> [snip]
> 
> <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>;

I am sorry Mark, but that is the one I was objecting to. In my view this
should not be a valid predicate for RDFa or, put it another way, such
predicates should be ignored by RDFa


>       * 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>
> 

As you say below, let us keep away from that...

Ivan


> 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
>>
>>
>>
> 
> 

-- 

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:56:19 UTC

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