Re: Fine-tuning CURIEs

Ivan Herman wrote:
> Shane,
>
> Shane McCarron 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.
>>
>>     
>
> I think you misunderstood. Yes, I know, the XHTML working group defines
> a number of values for @rel/@rev that would then be used as predicate in
> the xhtml namespace. There is a list (that you had in the previous
> draft, not in the present one, actually) that contains those definition
> (next, copyright, that sort of things).
>   
Those are defined in xhtml-rdfa - a separate document that defines the 
XHTML M12N-compatible module.  See http://www.w3.org/MarkUp/Drafts for 
the latest draft of that.
> However: obviously, the user can use other values for @rel, stemming
> from different other possible applications and profiles. We cannot
> control that, nor should we, I believe. What makes me uneasy is that we
> would generate triples for those, too...
>   
XHTML prohibits the introduction of other values that are not namespace 
qualified into @rel / @rev (and @role).  That whole space is reserved.  
The DTD does not enforce this because it is not possible to do so, but 
conforming RDFa processors should  ignore any incorrect values IMHO.

>> 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.
>>
>>     
>
> Hm. What is the 'default namespace', in fact? Of course, syntactically,
> the user can also say
>
> <p xmlns="http://w.q.r">balba</p>
>
> but
>
> - is this allowed by the current DTD?
> - should we allow it for RDFa? Remember that we do not use XML
> namespaces but only the syntactic sugar for it. Ie, the attribute @xmlns
> (without a local name) would then require extra explanation... In other
> words we do not have such animal as default namespace in CURIE, do we?:-)
>
> Ie: I think ":b" means "http://www.w3.org/1999/xhtml/b", and that is the
> way we should define it (and keep away from the notion of default
> namespace...)
>   
I think the default namespace aspects is the core of the issue Mark was 
raising, to be honest.  CURIEs permit that languages using CURIEs can 
enable some default prefix mechanism (see 
http://www.w3.org/MarkUp/2007/ED-curie-20070905/#s_syntax).  I think in 
the case of XHTML+RDFa that mechanism is by definition the xmlns thing 
above.

You ask if the DTD permits what you did above.  It *does*, but what you 
did above would have a really strange effect since it would put the "p" 
element into that namespace too.  A more common case is where you are 
using XHTML in a qualified way and have some other namespace as your 
default... e.g.:

<x:html xmlns="http://www.example.com/myml" xmlns:x="...xhtml namespace">
  <x:head>...</x:head>
  <x:body>
      <x:p rel=":my_relation">some specialized content</x:p>
      <x:div rel="contents">table of contents</x:div>
  </x:body>
</x:html>

In this case, the triple for the x:div should use the x:contents 
predicate, and the triple for the x:p should use the "myml" 
"my_relation" predicate.  At least, that is how I think we should deal 
with Mark's proposal.
> Ivan
>
>   
>> 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:59:49 UTC