Re: @itemref functionality wrt itemtype context

Hi,

This is related to ISSUE-105.

On Fri, Sep 2, 2011 at 4:24 PM, Jeni Tennison <jeni@jenitennison.com> 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>
>
> 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.
>

Good point. though under the previous microdata to RDF conversion as spec'ed
out by hixie, this example would have also generated two different URIs
factoring in the itemtype even though they shared the same
scherma.org"namespace". Reading between the lines of the md spec,
property names really
belong to a type in microdata, and not to a namespace which includes a set
of types and properties like it is the case in the RDF world.

Steph.


>
> 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
>
>
>
On Thu, Sep 1, 2011 at 3:04 PM, Stéphane Corlosquet
<scorlosquet@gmail.com>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.
>
> Here is a first snippet describing a movie and an article using different
> vocabularies:
>
> <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://rdfs.org/sioc/ns#Post" 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>
>
> Even though there is no official RDF conversion for microdata yet, I used
> Gregg's RDF distiller [1] to convert to RDF. The following property URIs
> were generated for the @itemprop license token:
> http://rdfs.org/sioc/ns#license
> http://schema.org/license
>
> Another example:
>
> <div>
>   <div itemscope itemtype="http://xmlns.com/foaf/0.1/Person"
> itemref="a"></div>
>   <div itemscope itemtype="http://schema.org/Person" itemref="a"></div>
>   <p id="a">Name: <span itemprop="name">Amanda</span></p>
> </div>
>
> which yields:
> http://xmlns.com/foaf/0.1/name
> http://schema.org/name
>
> Microdata does not care much about full URIs for properties, and uses the
> tokens as is in the JSON output (I guess it's up to the application
> consuming the data to check if a given property name makes sense in the
> context of its type, but I guess most won't check that). This can be
> cumbersome for the conversion to RDF where a namespace is required to build
> a proper URI for the property. Here's another use case which I didn't
> include in the example above: @itemtype is optional in microdata, so if it
> is omitted, there is no source to infer a namespace from during the
> conversion to RDF.
>
> @Ivan, does that illustrate all of your points re @itemref?
>
> Steph.
>