Re: A possible design to incorporate collections and containers into RDFa? [ISSUE-16]

Hi Ivan,

2010-08-28 11:05 Ivan Herman <ivan@w3.org>:
> 1. How do you know that the CURIE rdf:Seq is really _that_ rdf:Seq?

I didn't require it to be, because my example was meant to be processed in the course of normal RDFa processing, not in a pre-processing stage.

> 2. 'rdf:li' is _not_ an RDF predicate, ie, not part of the RDF terms. It is an artifact of the RDF/XML syntax; RDF/XML parsers are supposed to transform those into rdf:_1, rdf:_2, etc.

Oh, I see, thanks for pointing out – wasn't aware of that.

> ...
> 
> Of course, we could require the user to use rdf:_1, rdf:_2, ... directly, but then it would make his/her life more complicated: any time a new item is added to a list, all predicates should be renumbered. That is ugly (and that is why the RDF/XML designers introduced the rdf:li trick in the first place!)

You are perfectly right.

> These, plus a symmetry with collections, tells me that we should not use rdf:Seq and rdf:li... (Or, alternatively, we do not care about collections at all, considering them to be soon-to-be-deprecated...)

The general discussion on collections in RDF aside, I think that particularly in the XHTML+RDFa setting many users want to have something that easily fits into the structure of HTML's <li>, without the need to first design an ontology from scratch whenever you have the need to represent something n-ary.

> > 3. On @typeof vs. @resource: I have not checked possible side effects w.r.t. the spec, but I would consider @typeof more intuitive, as both @typeof in normal RDFa and @typeof in your "collection processing" mode generate bnodes.
> > 
> 
> Note that <... resource="::List"> is equivalent to <... resource="_:x"> (plus the preprocessing steps), ie, it is fairly intuitive, too, if you think about it...

I agree.

> But true, they both generate bnodes. The problem is that the rules around @typeof are fairly complicated and, in my experience, lead the user astray sometimes. Because the preprocessing would generate 'real' @typeof with real URI-s, those complex situations would affect containers and collections, too. Consider
> 
> <span rel="dc:author" resource="::Seq"><span....></span>
> 
> this is translated, in my current proposal, to 
> 
> <span rel="dc:author" resource="_:x"><span about="_:x" typeof="rdf:Seq"/><span....></span>
> 
> which behaves pretty much as we think; the subject will be whatever is defined one step above (say, <>).
> 
> If the same rule is used but with typeof, ie,
> 
> <span rel="dc:author" typeof="::Seq"><span....></span>
> 
> was transformed into
> 
> <span rel="dc:author" typeof="rdf:Seq"><span....></span>
> 
> then we have a different behaviour.

Ah, yes, I didn't consider that @typeof in this place denotes the subject, not the object.

> Indeed, according to the processing rules a new bnode will be created for the type and _that will be the subject_ (instead of the inherited one). Ie, to write the same collection, the user would have to write
> 
> <span rel="dc:author"><span typeof="::Seq"><span...></span></span>
> 
> instead of the stuff above or, alternatively, our rules of transforming the DOM tree would become more complicated (Eg, what if the user uses typeof as a _list_ of URIs with the requested behaviour of new blank node generation? How would you combine the two?)
> 
> To be completely open about it: I did use @typeof myself first. Even implemented it, and then tested it and I ran into these examples where the RDFa encoding became unnecessarily complex. Then I thought about it more and realized that, mentally, @resource works just as well and all these complications fall away instantly (eg, the value of @resource can be a single URI only...). Ie, the design become simpler...

Cheers,

Christoph

-- 
Christoph Lange, Jacobs Univ. Bremen, http://kwarc.info/clange, Skype duke4701