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

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.

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

Now, here's the technical problem again with prefix mappings:

>> 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.
>>
>> Neither (1) nor (2) seems like a good idea, and I can't think of an
>> alternative route if @profile can define prefixes.
>>
>
> 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.

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.

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

Received on Tuesday, 9 March 2010 18:58:16 UTC