Re: Fine-tuning CURIEs

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

Received on Tuesday, 11 September 2007 15:24:03 UTC