Re: @itemref functionality wrt itemtype context (related to ISSUE-105)

Jeni,

I have a slightly more general concern which is valid for both this case and also for the separate discussion on lists. Maybe this is a concern we should have in mind when discussing the issues...

One of the remarks we have heard from opponents of RDFa is the the processing steps, at the core of RDFa, are fairly complicated. And I have to acknowledge that to be true: I have implemented RDFa, I have a microdata->RDF converter (though modified v.a.v. the rules of Hixie) and I even have a rudimentary JSON-LD->RDF converter, too. And it is true that the RDFa converter is the most complex one. Not really good.

Of course, some of the complexity comes with the nature of the beast. RDFa has more general concerns than, eg, microdata (datatypes, emphasis on a graph and not on what is more of a tree, general management of URI-s, etc), and that has a price. Some of the reasons for the complexity might be our own stupidity and we may look at cutting back. However, I am afraid of adding new complexities to the processing steps right now and both the @itemref features as well as the more complete list management feature do just that. It honestly bothers me...

As for the issue at hand, namely ISSUE-105: I must admit I find Gregg's solution, namely allowing @about to take a list of subjects, as the most compelling. It is, conceptually, fairly obvious, and it seems to solve this specific issue in an elegant way... (yes, @rev also solves the problem, but it does have a feeling of hack to it:-)

My 2 cents...

Ivan

On Sep 2, 2011, at 22:24 , 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>
> 
> 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
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf

Received on Saturday, 3 September 2011 07:27:24 UTC