More general thoughts on the @property change

Dear all,

I have tried to give some more general thoughts on the possible change of @property and why it might be a good idea. I do _not_ want to concentrate on usability issues here, because that has already been discussed (although I do believe that it is an important aspect); instead, let me concentrate on something different.

Let us take a step back. A difficult feature of RDFa is chaining. It represents an implicit, additional semantics. After all, the basic semantics of @rel/@rev is to create a triple with a specific non-literal object. But it doe something else, it does it implicitly, so to say, and it can be difficult to avoid.

Those of use who were on the RDFa 1.0 group may remember that, actually, this feature was the subject of long, nay, VERY long discussion and some of use felt uneasy about it. The fundamental argument that made the group accept it is that there _are_ genuine and useful authoring patterns in RDFa which are greatly helped by those additional features. What we did not know at the time, of course, is how widespread those patterns would become in practice.

Well... my experience _as an author_ is that this feature is the source of many mistakes. And culprits include yours truly; I very frequently screw up the RDFa files I create by forgetting about the effects of chaining. On the other hand, if one looks at a typical foaf file, annotation with DC, or indeed the schema.org examples, chaining is only used in one or two case (if at all). In other words, we defined an implicit, non-trivial feature that is necessary for a strong minority of the authoring patterns only, but is error-prone.

I see the change in the @property behaviour as a way to take care of the confusion for chaining. Indeed, the great advantage of a @property behaviour taking the @resource/@href/@src/ etc values as object is that _it does not define chaining_. It embodies the basic behaviour of @rel, without the implicit one. If one _wants_ chaining, then, well, @rel/@rev is at disposal and can be used as today. As I put it, with this @property behaviour @rel/@rev makes chaining explicit. And I see that as a major improvement. (Let me emphasize, in case that was not clear, that I do _not_ want to remove @rel/@rev; they should stay around with exactly the same behaviour as today.)

(The only authoring pattern that becomes more awkward is when one wants explicitly to avoid using @href with @property on, say, an <a> element and generate a literal instead; this can be achieved using @rel="" or @datatype="", or with an explicit @content. Ain't pretty, but I do not think this is a really important practical case.)

So yes, I think this change does not only answer to the usability issue of end users not making a difference between literals and URI references, but it also improves RDFa overall.

Gregg, as a small aside: this line of thought is also why I am still uneasy adding any kind of additional chaining semantics to @property, something that you propose as an addition. The _only_ change I would propose to do is that @property picks up @resource/@href/@src/... as the object of a triple if there is no @rel/@rev present on the same element. But this is still open.

My 2 cents...

Ivan

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