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

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

Received on Wednesday, 10 March 2010 19:06:00 UTC