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

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

From: Ivan Herman <ivan@w3.org>
Date: Mon, 13 Feb 2012 10:08:15 +0100
Cc: public-rdfa-wg <public-rdfa-wg@w3.org>
Message-Id: <4FC19C6B-91EB-4389-B928-874EA217A837@w3.org>
To: Niklas Lindström <lindstream@gmail.com>
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. 

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






Received on Monday, 13 February 2012 09:06:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:30 UTC