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

On Feb 14, 2012, at 24:48 , Gregg Kellogg wrote:

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

Really? My memory is failing. Sorry. (And I must say I am a little bit surprised by this outcome...)

Sigh, then this is o.k. indeed (Shane, forget my previous mail but there is an editorial issue, see below). But then the discrepancy with terms that Niklas raised does indeed bite much more than I thought and those issues with @vocab are more serious than I first anticipated...

Shane, there *is* an editorial issue, though. As far as I can see

- the XML+RDFa language profile refers to rdfa-1.1 file for prefixes and terms
- the XHTML+RDFa language refers to xhtml-rdfa-1.1

but I am not 100% sure it says that the XHTML document must follow the rdfa-1.1 *plus* the additional rules that are in the document. Formally, XHTML+RDFa refers to RDFa Core and *not* to the XML+RDFa profile. Which means that the prefix definitions are not automatically inherited by the current text! Manu, I have not checked for HTML5+RDFa, but that may very well be the case.

One way of handling that in the RDFa Core document is to say that rdfa-1.1 is *always* valid for RDFa 1.1, and then language profiles may add their own. But maybe it is better if each language profile defines it for its own, in which case the XHTML+RDFa 1.1 and the HTML5+RDFa language profiles should all refer to the rdfa-1.1 file, too!

Ivan



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


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