Re: @itemref functionality wrt itemtype context

On Sep 2, 2011, at 1:24 PM, Jeni Tennison wrote:

> 
> On 1 Sep 2011, at 20:04, Stéphane Corlosquet wrote:
>> Today during the call Ivan raised a concern about @itemref when it is used to associate several items to the same set of properties. His concern was that these properties would possibly inherit different @itemtype contexts.
> 
> This is of course all true, but it's also worth having a motivating example where the inheritance is not a problem. For example:
> 
> <div itemscope itemtype="http://schema.org/Movie" itemref="license">
> <p itemprop="name">Pirates of the Carribean: On Stranger Tides (2011)</p>
> </div>
> <div itemscope itemtype="http://schema.org/Book" itemref="license">
>  <span itemprop="name">How to Tie a Reef Knot</span>
>  by <span itemprop="author">John Doe</span>
> </div>
> <footer>
> <p id="license">All content licensed under the <a itemprop="license"
> href="http://www.opensource.org/licenses/mit-license.php">MIT
> license</a>.</p>
> </footer>

As @itemref is not universally appreciated, and causes a many issues for SAX-based implementations, we discussed possible alternatives. For example, if @about where to take a list of IRIs, rather than just a single IRI, you might have the following:

<body vocab="http://schema.org/">
  <div about="_:m" typeof="schema:Movie">
    <p property="schema:name">Pirates of the Carribean: On Stranger Tides (2011)</p>
  </div>
  <div about="_:b typeof="schema:Book">
    <span property="schema:name">How to Tie a Reef Knot</span>
    by <span property="author">John Doe</span>
  </div>
  <footer about="_:m _:b">
    <p>All content licensed under the
      <a rel="license" href="http://www.opensource.org/licenses/mit-license.php">
        MIT license
      </a>.
    </p>
  </footer>
</body>

Another way to do it with the current syntax, is with @rev. In this case, @ref sort of acts like @itemref in reverse:

<body vocab="http://schema.org/">
  <div about="_:m" typeof="schema:Movie">
    <p property="schema:name">Pirates of the Carribean: On Stranger Tides (2011)</p>
  </div>
  <div about="_:b" typeof="schema:Book">
    <span property="schema:name">How to Tie a Reef Knot</span>
    by <span property="author">John Doe</span>
  </div>
  <footer>
    <p>All content licensed under the
      <a href="http://www.opensource.org/licenses/mit-license.php">
       <span rev="license" resource="_:m"/><span rev="license" resource="_:b"/>MIT license
      </a>.
    </p>
  </footer>
</body>


> Here, the classes are different but the URL for the license property (under an assumed mapping where the property URL is based on the type URL) is the same.
> 
> It might be that a mapping from microdata to RDF should somehow detect when the types of the items that reference a shared property are from different namespaces, and in that case place the property in a 'global' namespace (either world-global or site-global, it's not clear what the intention is in microdata), as it would if the type was missing altogether.
> 
> Thinking about introducing a similar functionality in RDFa, I think there are two distinct kinds of context that are currently merged in the RDFa processing algorithm:
> 
>  * things like xmlns:*, lang/xml:lang and base URIs which are defined as inheriting down the DOM tree
>  * things like the parent subject, lists of incomplete triples and so on, which are dependent on processing context
> 
> So, if you were to introduce something like itemref, I would suggest splitting out these two stages of the algorithm:
> 
>  1. a DOM annotation stage that provided information that should be based on the DOM tree (eg namespaces, languages)
>  2. an RDFa processing stage that could skip around the tree, following links per itemref where necessary.
> 
> (Note that if you're just thinking about xmlns:*, xml:lang and xml:base, the first stage isn't really necessary with XML; with HTML, you can use the lang and base URI present in the DOM but would have to provide additional prefix mappings as already defined in the RDFa+HTML spec.)
> 
> The big question would then be which stage attributes whose semantics aren't defined by other specifications but are of the same ilk, such as vocab, profile or prefix, should be processed under. My inclination would be that prefix at least (and almost certainly vocab and profile too) should be resolved during DOM annotation: that stage would expand any terms or CURIEs in relevant attributes, so that all they contain are URIs. Then the actual processing of the RDFa attributes becomes fairly straightforward, and could include hopping around the DOM to get extra properties.
> 
> There is a problem with this approach, in that it makes the mapping from microdata to RDFa harder in the cases that Stéphane outlined where under microdata you would create properties with different URIs because of the use of types from different vocabularies, so perhaps that argues for having vocab being interpreted as part of the second step, or perhaps it's something that people wouldn't do deliberately in any case. I'm not sure. 
> 
> Jeni
> -- 
> Jeni Tennison
> http://www.jenitennison.com
> 
>

Received on Friday, 2 September 2011 23:13:54 UTC