- From: Niklas Lindström <lindstream@gmail.com>
- Date: Mon, 13 Feb 2012 23:04:29 +0100
- To: Ivan Herman <ivan@w3.org>
- Cc: public-rdfa-wg <public-rdfa-wg@w3.org>
Hi Ivan, 2012/2/13 Ivan Herman <ivan@w3.org>: > 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 Indeed, there are. (They were so related in my mind that I didn't thoroughly divide them. Thanks!) > 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. Yes, we're in total agreement here. > 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. When I look up that page I see a lot of predefined terms? If indeed these are to be removed, at least a lot of potentially bad things have been prevented, which is good (such as 'chapter' being reset in a scenario using BIBO in a @vocab). If they are not, we should address this situation. > 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. Indeed. (Of course, in 1.0 there was no @vocab to interfere with, and the predefined terms we're only in effect in @rel/@rev.) > 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. Since we're are talking about this specifically in the other thread (starting with "ISSUE-129 (Power of @vocab) [...]"), I'll continue there for the rest. Kind regards, Niklas > 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 > > > > >
Received on Monday, 13 February 2012 22:05:29 UTC