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

Hi Christoph,

On Aug 28, 2010, at 24:27 , Christoph LANGE wrote:

> Hi Ivan, hi all,
> 
> 2010-08-25 13:40 Ivan Herman <ivan@w3.org>:
>> http://www.w3.org/2010/02/rdfa/wiki/ContainersAndCollections
> 
> good news – I also welcome collection/container support in RDFa!
> 
> I have comments on the "possible questions" 2 and 3:
> 
> 2. On containers:  Why do we need a special syntax involving pseudo resources and container preprocessing at all?  Wouldn't standard RDF already work?  E.g.
> 
> <li about="http://www.worldcatlibraries.org/isbn/9780262912423" typeof="bibo:Book">
>   <em property="dc:title">A Semantic Web Primer</em>, by
>   <span rel="dc:creator" typeof="rdf:Seq">
>     <span property="rdf:li">Grigoris Antoniou</span> and
>     <span property="rdf:li">Frank van Harmelen</span>
>   </span>
> </li>
> 
> – or, instead of rdf:_1, rdf:_2 – as the author prefers –
> 
> would yield the desired result, as @typeof="rdf:Seq" also generates a bnode.
> 

Well... it looks like the same but it isn't... (Set aside the usage of @typeof vs. @resource, see below.) There are two (in my view) significant issues.

1. How do you know that the CURIE rdf:Seq is really _that_ rdf:Seq? There is nothing that _requires_, nor do I think we should require, the user to use the 'rdf' prefix for, well, RDF (other than habits and maybe best practices). But, if so, then the processor has to have access to the full URI represented by rdf:Seq before taking any actions. Ie, this can only take place only after @profiles, @prefix, etc, have all been processed, which contradicts my design principle that handling containers should be done, conceptually, at a preprocessor phase not to make the core processing steps even more complicated. 

You might say that this is an implementer's objection, which is sort of right. But there is another issue:

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. In other words, if we used 'rdf:li' at that place it would not be really different from using '::member', just a syntactic sugar; we would still have to define what that would mean in terms of RDFa processing. Which means we would be back to exactly the same kind of specification as the one I had put forward (with the extra difficulty with the 'rdf' prefix). 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!)

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

> For collections, i.e. linked lists, a special processing mode is, of course, needed – at least I can't come up with any better idea.
> 
> 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...

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

> Just my 2 cents – cheers,

Thanks for your comments!

Ivan

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

(Tracker, this belongs to ISSUE-16)

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