Re: Fine-tuning CURIEs (reply #2 :-)

Mark,

I thought about this again but, I must admit, I did not change my
opinion, even reading through the thread again...

I was actually a bit surprised to read, in Shane's reply[1] that

[[[
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.
]]]

Is this an XHTML1 or and XHTML2 feature? As far as XHTML1 is concerned,
I looked up in [2] and it says:

[[[
Authors may use the following recognized link types, listed here with
their conventional interpretations. A LinkTypes value refers to a
space-separated list of link types. White space characters are not
permitted within link types.
]]]

I am not sure how to interpret the word 'may' in this respect, but my
impression is that this means the author can have his/her own, or use
these predefined ones.

However... regardless of what the spec says, the reality out there is
that authos _do_ use @rel/@rev with values that are _not_ defined by
XHTML. The example of openid or DC are the obvious ones. What this also
means that the _second_ scheme you propose:-) would actually lead to new
and somewhat unexpected triples. (By the way, one of the
questions/comments asked by the DCMI guys in Singapore was exactly that:
they _hope_ that RDFa will not generate extra triples if they are
encoded using the dc.title trick...)

Regardless of how it is described in the CURIE document, my feeling is that:

- 1. We should obviously interpret 'a:b'
- 2. We should interpret 'b' as 'http://www.w3.org/1999/xhtml/b'
_provided_ that 'b' is one of the entries listed by the relevant XHTML
document (I fully agree with Shane on that one for the reasons above)
- 3. For ':b' we can either say that it behaves exactly like 'b' above,
or we introduce the usage of a default namespace. I am mildly in favour
_not_ to use the concept of default namespace at all. Yes, that would
invalidate your openid example, but I do not think that is so important
(and the DCMI use case is, as I said before, moot)



Ivan



[1] http://www.w3.org/mid/46E6BB62.9070204@aptest.com


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
> 

-- 

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