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

Mark,

I do not believe our discussion was technical level. The version of the
'unified' document I published a week ago[1] took over the approach you
had in your blog; yes, tokens are prefixes in that document. And yes, it
works. To make the discussion clear(er) (or muddier?), yesterday I
produced an alternative which I have just put up on our site[2] which
separates prefixes and keywords on the definition level. The required
modifications on the processing steps are slightly more elaborate in [2]
than in [1], but nothing dramatic. Ie, technically, both designs are
valid and usable.

I believe the difference between the two is "social". By making a strict
separation between keywords and prefixes (like in [2]) we could argue
that it is conceptually clearer to users and authors and [1] might be a
bit more complicated to understand and follow. Keywords and prefixes are
useful for different communities (as Ben formulated it), so keep them
separated on the specification level, too. (Note that I do not have
facts to prove or disprove all this, all this is just a bunch of
feelings...).

When I made my first implementation, before all this discussion began, I
actually implemented a variant of [2], ie, separation of prefixes and
keywords. Then, while editing [1], I was seduced by your design:-). But
the discussion with Ben, his formulation of different communities, made
me think again, I must admit, and I am more tempted today by a direction
outlined in [2]...

Ivan

P.S. There _is_ an open technical issue that might actually force us to
go for [2], and this is what I described at the end of my mail[3]: do we
want to define restrictions on keyword usage per attributes, the way we
have them now in XHTML+RDFa, or not? If yes, then [2] becomes definitely
the clearer way of doing this...

[1] http://www.w3.org/2010/02/rdfa/drafts/2010/ED-vocab-20100305/
[2] http://www.w3.org/2010/02/rdfa/drafts/2010/ED-vocab-20100311/
[3] http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Mar/0034.html


On 2010-3-10 20:05 , Mark Birbeck wrote:
> Hi Ivan and Ben,
> 
> Sorry for top-posting, but it's a little difficult to intersperse my
> comments amongst both of your comments.
> 
> 
> TOKENS ARE PREFIXES (ARE TOKENS)
> 
> The first thing I would say is that whilst I agree with Ben ("tokens
> are more important than prefix-mappings") I think we'll both have to
> admit that we have nothing to base that on, other than our instinct
> about adoption going forward. :)
> 
> However, I don't think it actually matters whether Ben and I are right
> on tokens, or Ivan is right on prefix-mappings, because the proposal I
> was making about tokens is all about prefixes too.
> 
> To recap, all I said in my original proposal was that since we already
> allow this:
> 
>   @rel="maker:"
> 
> why not just go the extra step and allow this:
> 
>   @rel="maker"
> 
> At this point in the logic we're still talking about 'prefixes' --
> nothing changes in the use of @xmlns, and we don't need @vocab/@token
> or @profile. All we're saying is that removing the colon is a
> convenient shorthand with the important by-product of being easier for
> authors, and much cleaner looking.
> 
> However, a prefix with no suffix is a bit of a contradiction, so if do
> we allow this minor change (that the colon is optional), then my
> further argument was that we should change the name from
> 'prefix-mapping' to 'token'.
> 
> 
> TOKENS AND KEYWORDS
> 
> Note also that this idea of 'tokens' brings our predefined keywords
> into harmony with prefix-mappings; using the new 'optional colon'
> rule, we can see that the predefined token 'next' is no different to
> the following longhand:
> 
>   <div xmlns:next="http://www.w3.org/1999/xhtml/vocab#next">
>     <a rel="next" href="blah">go to next document</a>
>   </div>
> 
> Personally I think this harmonisation is important for the conceptual
> model of RDFa.
> 
> So to summarise -- by making the colon optional we effectively
> harmonise our keywords with prefix-mappings. Since we now have
> something which is more than either I think we need a new term, and I
> suggest we use the term 'token' to describe this new merged concept.
> 
> Anyway, the main point I'm trying to stress is that *both* of the
> 'audiences' that Ben and Ivan are referring to are already catered for
> in the proposal, so we don't need to choose priorities.
> 
> 
> @PROFILE AND @VOCAB
> 
> Now, as I said, none of this touches how tokens are declared -- it
> merely looks at how they are used.
> 
> But on the subject of declaring tokens, I believe that in the past
> we've had two main goals that we wanted to fulfill.
> 
> The first was that we wanted to move away from the @xmlns attribute,
> and the second was that we wanted to have a mechanism for declaring
> bundles of tokens.
> 
> I thought that the first (replace @xmlns) was going to be achieved
> through the use of a new attribute, like @vocab or @token. We've
> discussed various ways to do that, such as comma-separated lists,
> CSS-like syntax, JSON, and so on. I thought we had agreed on one, but
> I might be mistaken. But anyway...it's a simple concept, and really we
> just have to agree on a syntax.
> 
> The second (bundles of tokens) can be easily achieved through the use
> of @profile, and it's possible to define this in such a way that it is
> consistent with the way HTML 4.01 discusses @profile now.
> 
> (Note that my proposals about having a JSON format for the data are
> secondary -- the first question is whether to use @profile at all.)
> 
> 
> BACKWARDS-COMPATIBILITY
> 
> Finally, to the second issue raised in this thread; Ben flags up some
> important points about backwards-compatibility, and one way to come at
> this might be to say that @xmlns and @token/@vocab are not actually
> maintaining the same list of tokens. In other words, whilst @token
> values will override @profile values, neither of them will override
> @xmlns values.
> 
> That would then mean that in Ben's examples, an RDFa 1.0 processor
> will at least produce a subset of what an RDFa 1.1 processor would
> produce. Obviously there will be triples missing, but there won't be
> any triples in the 1.0 graph that aren't in the 1.1 graph.
> 
> You might think this is confusing, but I think it's pretty easy -- all
> we have to do is to point people at the new attributes, and suggest
> that authors avoid using @xmlns if they want the new features
> (bundles, override, etc.). And our tutorials, articles, samples, and
> so on would not even mention @xmlns!
> 
> 
> Sorry to try to tackle so many points at the same time, but I've not
> been able to jump into the debate in real-time to discuss points as
> they arose, hence the build-up.
> 
> Regards,
> 
> Mark
> 
> 
> 
> On Wed, Mar 10, 2010 at 9:46 AM, Ivan Herman <ivan@w3.org> wrote:
>>
>>
>> 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
>>
>>

-- 

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