W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > February 2012

Re: Regarding @vocab and terms (ISSUE-129)

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Mon, 13 Feb 2012 18:48:58 -0500
To: Ivan Herman <ivan@w3.org>
CC: Niklas Lindström <lindstream@gmail.com>, public-rdfa-wg <public-rdfa-wg@w3.org>
Message-ID: <B9F26EC9-CB01-4DE0-9CB4-AFAF7B6B40E0@greggkellogg.net>
On Feb 13, 2012, at 1:08 AM, Ivan Herman wrote:

> Hi Niklas,
> 
> You have, actually, three sub-issues here. I definitely agree with first, I do not agree with the second, and I am still undecided with the third and have an alternative proposal to it:-). Here they are, as I see it
> 
> 1. Using @vocab in head may be dangerous, due to the <link> elements.
> 
>  I agree. I think we both agree that there is not much to do about it in the specs, but we should remember adding a warning in the primer and in RDFa 1.1 Lite.
> 
> 
> 2. You claim that there is a difference between XHTML 1 and XHTML5/HTML5 in terms of terms. 
> 
> I think there aren't, at least that was the intention... Section 3 of the XHTML+RDFa document refers to http://www.w3.org/2011/rdfa-context/xhtml-rdfa-1.1 as the definition of terms and prefixes. That file includes only the minimal set of the three: license, role, and describedby. 

It's my recolection that we intended to keep the existing set of terms (1.0 terms) for XHTML+RDFa, but use a minimal set for HTML4/HTML5/XHTML5/SVG+RDFa 1.1. This seems to be bourn out in the notes of ISSUE 108 [1]

[[[
RESOLVED: RDFa 1.1 will have 3 default profiles, RDFa Core 1.1 will contain the terms 'describedby', 'license', and 'role', HTML+RDFa will not have any terms, XHTML+RDFa will have all terms required for backwards compatability.
]]]

It seems to me that the xhtml-rdfa-1.1 document is probably okay.

Gregg

> I think the difference is between RDFa 1.1 and RDFa 1.0; the latter, indeed, contains a large number of predefined terms. Those are all gone.
> 
> 3. The role of @vocab vs. predefined terms.
> 
> I see the issue with license. Indeed, even I made the mistake for the primer.
> 
> On the other hand, one could say that, in some cases, the situation is the reverse. If I use
> 
> <span about="http://bla.bla" rel="describedby" resource="http://yep.yep.yep" />
> 
> I definitely do *not* want any @vocab to override this, because what I refer to is the http://www.w3.org/2007/05/powder-s#describedby attribute. The case of 'role' may even be more problematic, Shane should react on that. In those cases I suggest the current rule, ie, that gives a priority to the default terms, _is_ the right one.
> 
> I actually wonder whether a much smaller change would not be more appropriate: currently, license is mapped against http://www.w3.org/1999/xhtml/vocab#license which, let us face it, leads to a predicate that nobody in the RDF world uses for licensing. What about mapping this term to http://creativecommons.org/ns#license or maybe even more appropriately, http://purl.org/dc/terms/license ? I think the user would be much *less* surprised if that was the generated triple which has a clear definition. By doing that, we can leave the current processing rules intact.
> 
> Ivan
> 
> 
> On Feb 13, 2012, at 02:47 , Niklas Lindström wrote:
> 
>> Hi all!
>> 
>> In applying RDFa 1.1 to various use cases lately (working with legal,
>> educational and library data, and tinkering with examples in the
>> wild), I have made some observations regarding @vocab and terms which
>> I need to address.
>> 
>> 
>> ## The effect of @vocab on undefined terms ##
>> 
>> It should be noted that the following:
>> 
>>   <div vocab="http://schema.org/">
>>       <a rel="nofollow"
>> href="http://www.seo-blog.com/rel-nofollow.php">Nofollow in Google,
>> Yahoo and MSN</a>
>>   </div>
>> 
>> produces:
>> 
>>   <> <http://schema.org/nofollow> <http://www.seo-blog.com/rel-nofollow.php> .
>> 
>> To turn that triple off, you can clear the @vocab with:
>> 
>>   <div vocab="http://schema.org/">
>>       <a vocab="" rel="nofollow"
>>          href="http://www.seo-blog.com/rel-nofollow.php">Nofollow in
>> Google, Yahoo and MSN</a>
>>   </div>
>> 
>> Note also that this happens with e.g. 'stylesheet', which is not a
>> reserved term by default (and not for RDFa 1.1 in HTML5). So in
>> general, one should not use @vocab until in <body>. If you have more
>> demanding requirements, you should use the same pattern as above,
>> e.g.:
>> 
>>   <html vocab="http://example.org/ns#">
>>       <head>
>>           <link vocab="" rel="stylesheet" href="/style.css" />
>>           ... lots of link and meta elements relying on the parent @vocab ...
>>       </head>
>>   </html>
>> 
>> While I believe that we fully accept the above, I want to make it
>> abundantly clear. And we may want to explain this in the primer.
>> 
>> Perhaps some of this should also be noted in RDFa 1.1 Lite. Especially
>> the behaviour of @rel, since it is in effect, but not mentioned.
>> 
>> (By the way, is it fully understood that the terms defined in the
>> XHTML context do *not* apply in XHTML5? We must make it very clear
>> that the XHTML initial context is for 1.0 and 1.1, and *not* XHTML5.
>> That is a different host language, and it has the same limited set of
>> predefined terms as HTML (i.e. only the default rdfa initial
>> context).)
>> 
>> 
>> ## Predefined terms ##
>> 
>> The following is more troubling.
>> 
>> I wonder whether an HTML author in general will understand that this:
>> 
>>   <div vocab="http://purl.org/dc/terms/">
>>       <a rel="license" href="/cc-by">CC-BY</a>
>>   </div>
>> 
>> actually produces:
>> 
>>   <> xhv:license </cc-by> .
>> 
>> and *not*:
>> 
>>   <> dc:license </cc-by> .
>> 
>> To work around that, one *have* to use:
>> 
>>   <a rel="dc:license" href="/cc-by">CC-BY</a>
>> 
>> One very clear indication that this is *not* fully understood can be
>> found in the RDFa 1.1 Primer itself! The last example in section "2.4
>> Setting a Default Vocabulary" reads:
>> 
>>   <p vocab="http://creativecommons.org/ns#">All content on this site
>> is licensed under
>>       <a property="license"
>> href="http://creativecommons.org/licenses/by/3.0/">
>>       a Creative Commons License</a>.</p>
>> 
>> , with the clear intent to produce cc:license, not xhv:license. Either
>> this example must be changed (along with the expectations that caused
>> it), or the Core rules for terms must.
>> 
>>> From a general design perspective, this effect of predefined terms in
>> conjunction with @vocab is problematic. It's more complex for authors
>> to remember that some terms (even three) are *reserved* and are never
>> resolved against the active @vocab.
>> 
>> More crucially, these terms differ between host languages, at least
>> between HTML5 and XHTML 1.1. Note that in XHTML 1.1, one cannot use
>> BIBO exclusively with @vocab, since 'chapter' is a predefined term
>> there and thus must be written as 'bibo:chapter' if that's the intent.
>> 
>> Perhaps most authors and vocabulary publishers, e.g. Schema.org, are
>> well aware of and accept this fact. However, if this makes anybody
>> else but me concerned, please consider the following suggestion.
>> 
>> 
>> ## Changing the power of @vocab ##
>> 
>> The term mechanism can be changed so that terms only provide
>> *defaults*, used if *no* @vocab is active.
>> 
>> It would make @vocab behave predictably, by uniformly capturing any
>> regular terms. It would still ensure that by default, if no @vocab is
>> used, @rel="license" means xhv:license.
>> 
>> In practise, the change would be in section "7.4.3 General Use of
>> Terms in Attributes". The specific rules today are:
>> 
>> [[[
>> * Check if the term matches an item in the list of local term
>> mappings. First compare against the list case-sensitively, and if
>> there is no match then compare case-insensitively. If there is a
>> match, use the associated IRI.
>> * If there is a local default vocabulary the IRI is obtained by
>> concatenating that value and the term.
>> * If there is no local default vocabulary, the term has no associated
>> IRI and must be ignored.
>> ]]]
>> 
>> I propose to change this to:
>> 
>> [[[
>> * If there is a local default vocabulary, the IRI is obtained by
>> concatenating that value and the term.
>> * Otherwise, check if the term matches an item in the list of local
>> term mappings. First compare against the list case-sensitively, and if
>> there is no match then compare case-insensitively. If there is a
>> match, use the associated IRI.
>> * Otherwise, the term has no associated IRI and must be ignored.
>> ]]]
>> 
>> This would not affect any currently deployed RDFa 1.0 of course (since
>> @vocab is new). It would *only* affect any currently used RDFa 1.1
>> where @vocab is used *and* the markup relies on predefined terms
>> within those regions. Considering the examples given above, I would
>> say that all bets are off regarding what people in general would
>> expect from such markup. This suggestion attempts to simplify all
>> these expectations.
>> 
>> 
>> ## Reserved terms left behind ##
>> 
>> Now, this does reduce the power of the term mechanism substantially.
>> It does so for the sake of authors and for simplicity, since it makes
>> @vocab work uniformly.
>> 
>> *If*, in the future, direct mixing of vocabularies were to become
>> desirable, the term definition mechanism can very well be extended
>> without breaking backwards compatibility. This would be done by adding
>> a means for declaring certain terms as "reserved" (say by typing them
>> as rdfa:ReservedTermMapping). Those, and only those, would behave as
>> all terms do right now, i.e. being fully reserved, regardless of
>> @vocab.
>> 
>> But I don't think we should do that now. We backed away from the term
>> mechanism in general, and mostly use it to preserve backwards
>> compatibility. For mixing vocabularies, we rely on the use of CURIEs,
>> @vocab and vocabulary expansion. Which is good.
>> 
>> 
>> What do you think?
>> 
>> Kind regards,
>> Niklas
>> 
> 
> 
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> FOAF: http://www.ivan-herman.net/foaf.rdf

[1] http://www.w3.org/2010/02/rdfa/track/issues/108
Received on Monday, 13 February 2012 23:50:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:55 UTC