Re: PROPOSAL: Extending @rel/@rev reserved value set

Actually.... I have to object to this pretty strongly.  I don't have the 
proxy of the XHTML 2 Working Group here, but let's pretend that I do for 
a moment.  The problem we are trying to solve in XHTML 2 is to define a 
generally useful markup language that is somewhat backward compatible 
with HTML / XHTML 1.x.  At the same time, XHTML 2 is designed to improve 
the integration of XHTML with the "semantic web", whatever that is.  The 
XHTML Working Group and the Semantic Web Deployment Working Group were 
tasked with creating a task force to make this happen.

The core of this issue seems to be the interpretation of Compact URIs 
(CURIEs) with no "prefix".  CURIEs have their roots in QNames, so let's 
think about it from that perspective for a moment.  QNames do not 
require a prefix.  In the absence of a prefix, a QName is interpreted in 
the context of the current "default" prefix.  With CURIEs we don't have 
a "current" default.  We have a "default", and we get to say what that 
is.  In all cases in XHTML+RDFa (and XHTML+RDFa+Role+Access, my next 
project), I believe that default MUST be 
"http://www.w3.org/1999/xhtml/vocab#".  It is 100% consistent, it is 
easy for a processor to deal with, and it makes the common case 
(rel="next") just work.

The objection to this approach seems to be "what do we do with 
non-prefixed rel values that are not defined in the XHTML+RDFa spec?".  
Now, as most of you know, I don't have an RDF hat on.  Maybe I am 
missing something, but... who cares?  If I am writing a document in 
XHTML+RDFa, I know the rules.  If I ignore those rules, that's my 
choice.  If I want my @rel values interpreted in my special vocabulary 
for purposes of RDF extraction, I will go to the trouble of mapping them 
(rel="shane:monster").  If I don't go to that trouble, I must not really 
care (rel="monster").

Now.... extending the example, if I say:

    <link rel="monster" 
href="http://www.example.com/shaneSpace/jubilex.html" />

Do I want a triple like:

    <>
        xh:monster <http://www.example.com/shaneSpace/jubilex.html>

I have no idea!  I don't know what monster means.  But it doesn't hurt 
anything.  It has NO SEMANTICS.  If I happen to use a non-prefixed value 
that is PREDEFINED and therefore HAS PREDEFINED SEMANTICS, I get what I 
deserve:

If I put in my content, for example:

    <link rel="monster appendix" 
href="http://www.example.com/shaneSpace/jubilex.html" />

Renders the triples:

    <>
        xh:monster <http://www.example.com/shaneSpace/jubilex.html>
    <>
        xh:appendix <http://www.example.com/shaneSpace/jubilex.html>


Is that resource ALSO an appendix for my current document?  A document 
about some vestigial human organ?  No idea!  But if I didn't bother to 
qualify my vocabulary reference, it's my mistake.  It is not the job of 
this task force, nor this specification, to protect me from myself.

Remember that Compact URIs have application outside of the scope of 
RDFa, and RDFa will be combined with other XHTML modules that use 
Compact URIs as values, so whatever solution we agree upon here MUST be 
one that can be generally applied.  There cannot be special rules for 
RDFa attributes.  It will just confuse our customers.

So.... My proposal is we declare victory and move on.  Just say 
non-prefixed CURIEs are in the XHTML namespace and leave it at that.  
Simplifies processing rules immensely, doesn't break ANYTHING that I 
know of, and ensures that people who have rel="next" in their documents 
get useful triples right out of the box.

Manu Sporny wrote:
> Mark Birbeck wrote:
>   
>> One possibility would be to define the default prefix mapping to point
>> to the XHTML-vocab, which would allow authors to write:
>>
>>   <link rel=":next" href="..." />
>>   <link rel=":prev" href="..." />
>>
>> This means that we can still make use of the XHTML values--next, prev,
>> license, and so on--but authors wouldn't need to define a URI mapping
>> like "xh:" in order to do so.
>>
>> Before anyone shouts about this, let me explain why I'm suggesting
>> this. Once you have an easy way to make use of the XHTML-vocab values,
>> then you could argue that from an _authoring_ perspective our job is
>> done; we have provided a convenient way to let authors use a list of
>> clearly defined values in their documents.
>>
>> This has the effect of changing the @rel="next" problem into something
>> else--a 'legacy' question. And once it is a legacy question we can
>> apply different criteria to solving that. We could certainly say that
>> at this time we don't know how to deal with legacy values, and for now
>> these values are completely ignored. The good thing is though, that we
>> are not _ignoring_ the XHTML-vocab values; we're merely ignoring one
>> way that those values might be written.
>>     
>
> +1 - I really like this solution, Mark... primarily because it keeps the
> syntax document simpler than the alternatives that have been kicking
> around. It will also be much simpler for publisher's to grasp this
> concept than the concept that there are magic words that only exist in
> @rel and @rev of which they should be aware.
>
> Just to make sure we're talking about the same thing, your proposal
> above would mean that:
>
> 1. There is no section on "legacy values" or pre-processing steps in
>    the current RDFa Syntax document.
> 2. We would create a section in the future that would be about
>    "legacy processing" or "pre-processing". When would this be done?
> 3. The current Syntax document would be corrected to cover the ":foo"
>    short-hand for XHTML-vocab.
>
> -- manu
>
>   

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com