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

Re: Procedural question on [Fwd: Re: Fine-tuning CURIEs]

From: Ivan Herman <ivan@w3.org>
Date: Tue, 11 Sep 2007 18:10:21 +0200
Message-ID: <46E6BDED.7040208@w3.org>
To: Shane McCarron <shane@aptest.com>
Cc: W3C RDFa task force <public-rdf-in-xhtml-tf@w3.org>, Ralph Swick <swick@w3.org>
Shane,

thanks. It was indeed not clear.

Shane McCarron wrote:
> The XHTML Working Group is absolutely producing a separate document for
> CURIEs.  The reason we have incorporated the basic rules that apply to
> XHTML+RDFa into the syntax document is so there is no dependency on this
> separate document.  When the separate REC is ready, we can editorially
> update the syntax document.
> 

Hm. My prediction is that the RDFa syntax document will become a REC
_before_ the CURIE document will become a REC. In which case you cannot
update the syntax document any more (unless issuing a new release...)

I know, I am very 'selfish' here, and my primary goal is to have the
current RDFa work done. Anything that smells a delay makes me feel itchy:-)

Ivan


> This has been discussed to death in the task force.  I am sorry if it
> was not clear.
> 
> Ivan Herman wrote:
>> 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
>>>
>>>
>>>
>>>     
>>
>>
>>   
> 

-- 

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:10:20 UTC

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