Re: attempting to merge the 'vocab' and 'profile' documents

On 2010-3-9 19:57 , Ben Adida wrote:
> On 3/9/10 10:06 AM, Ivan Herman wrote:
>> I am actually not sure what we are arguing about.... If you think that
>> you have to convince me about the necessity of keyword mapping and
>> definitions, then don't:-) I know it is important...
> 
> Right, sorry for not being clear: what I'm saying is that, of the two
> features, I think the much greater benefit is from keyword mapping.
> 

Ok. I actually realized, after having sent the mail, that you probably
did _not_ mean that, so this was an unnecessary remark on my side. Sorry:-)

>> But a very important one for many. Let us not forget that many authors
>> of RDFa come
>> from the RDF world, for them using different namespaces is the most
>> natural thing of the world, but they are still pissed by the many
>> prefixes they have to declare (and I am one of them!:-).
> 
> Right, so the key point is that we're targeting very different
> communities. The keyword mapping targets microformat/microdata/HTML
> folks who want to simplify their markup, while the prefix mapping
> targets the RDF community members who want to use 'a zillion prefixes'.
> 
> I hope we agree that these are *very* different goals.
> 

Yes. These are different communities and goals. And, to repeat myself:
maybe it is a good reason to separate the two issues technically, too,
and not the smudge them together as it stands in the current proposal.

I also hope that we can agree that both communities/goals are important
and we have to serve them both...

[skip]
>>
>> But... the only obligation we have is that RDFa1.1 processors generate
>> the same triples for current RDFa (ie, RDFa1.0 files). In your example
>> the usage of @profile is incorrect: it is not a recognized RDFa
>> attribute in that place. Ie, I do not really see the problem.
> 
> Are you saying that you envision @profile *only* on the head of the
> document? I guess that would be option #3, but I don't like that case
> because it means no copy-and-paste of HTML chunks.
> 

Certainly not, sorry if I was not clear. I definitely would like to have
the @profile mechanism be available on every element.

For a better reference, here is what you said:

[[[
And as I was writing this out, I just realized that, if we *do* let the
vocab/profile define prefixes, then we have a big backwards
compatibility problem:

=========
  <div xmlns:cc="FOO">
    <div profile="BAR">
       <span property="cc:attributionName">...</span>
    </div>
  </div>
=========
How does one resolve the 'cc' prefix here?

If we want to allow @profile to define prefixes, then we have to go one
of the following routes:

(1) RDFa 1.0 and RDFa 1.1 parsers may generate *different* triples for
the same @property, since RDFa 1.0 will ignore @profile.

(2) RDFa 1.1 must let @xmlns override @profile, even if @xmlns is higher
up in the DOM tree. Significantly hurts cut-and-paste compatibility when
@profile is used.
]]]

And I think I have a better understanding to your issue now. I agree
that (2) is really muddy and awful, so we should try not to have that.
Which leads to (1).

And yes, this is true, RDFa 1.1 parsers may generate different triples
than RDFa 1.0 because the author was really careless and BAR redefines
'cc'. The question is whether we should really optimize on that, ie,
whether we consider that as a theoretical issue or a real one. I tend to
think this is a theoretical issue that we can disregard; yes, there is
rope that the author can use to hang himself/herself but, hopefully, the
RDFa community does not have suicidal tendencies:-) Indeed, that example
is really a careless authoring!

Note that similar problems may arise with the keyword mechanism! Say BAR
defines a keyword URI to the term 'next', then

 <div about="blabla">
    <div profile="BAR">
       <span rel="next" resource="blablabla>...</span>
    </div>
  </div>

will have the same issue; RDFa1.0 will interpret the 'next' as being in
the xhtml namespace and RDFa1.1 will interpret whatever BAR has assigned
to the term 'next'. It is just as careless as before (granted, maybe
even more so). Do we want to disallow people to redefine the keywords
defined by XHTML? I do not think so... The word 'next' may be very
common and useful in many contexts, possibly more useful than those
predefined values in XHTML...

I think that our obligation is to secure that _valid_ RDFa1.0 content
would produce the same triples under RDFa1.0 and RDFa1.1. And the code
in the examples above is _not_ valid RDFa1.0, because @profile is not a
valid attribute in XHTML+RDFa1.0 (that is what I was referring to in my
original response...)

> I'm pretty sure we want the keyword-mapping mechanism to appear on any
> element in the DOM tree, otherwise Google and Yahoo can't provide easy
> examples you can drop into your HTML for enhanced search.
> 

Absolutely.

Cheers

Ivan

> The technical limitation above, though, means that the prefix-mapping
> mechanism can *only* appear in <head> (and there may be some odd edge
> cases when <html> has some @xmlns declarations).
> 
> This means, I think, that we really need to separate the two mechanisms,
> as you suggest. Can I live with a "bundle of prefixes" defined in
> <head>? Yes, but I'm not very enthusiastic about it.
> 
> -Ben

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF   : http://www.ivan-herman.net/foaf.rdf
vCard  : http://www.ivan-herman.net/HermanIvan.vcf