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

Shane,

It is now my turn to disagree with you pretty strongly :)

We're working with the realities of XHTML1.1 and current ad-hoc uses, as
well as the expectations of the RDF community, and the one area where we
have received significant pushback in the past is when we've generated
spurious triples. People do care about those.

Now, in the past, I have also been tempted to say "I don't care if
people care about spurious triples" and I've made arguments very close
to what you're saying. But we've recently received word from the Dublin
Core folks that they would be *really* upset if we started generating
bogus triples for

<a rel="DC.creator">

which is their current ad-hoc approach for DC markup, along with
@profile for GRDDL processing. Their approach is not wrong, and they
*do* care about RDF, so if RDFa parsers start spewing meaningless
triples, we're going to upset a major customer.

So, in fact, the one item that we all seemed to agree on last time was
that rel="DC.creator" should *not* generate a spurious triple in the
default RDFa parser. What we were discussing was the "how".

Regarding your point on special-casing RDFa in XHTML1.1... I think we've
already had to do that. No LINK and META in the body, for example. So
what's wrong with adding one extra constraint, which is no unprefixed
CURIEs? The CURIE spec can certainly define them and explain how to
process them, but the RDFa parser for XHTML1.1 can easily discard
non-prefixed values.

Regarding "declaring victory and moving on," I think that's exactly what
Mark's proposal allows us to do: declare victory by saying we don't
handle legacy but we leave it open to other components, *and* we point
out that these will likely generate triples in XHTML2.

I don't think this approach presents any issues for XHTML2.

-Ben

Shane McCarron wrote:
>  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 <mailto:shane@aptest.com>
>

Received on Thursday, 25 October 2007 22:02:30 UTC