W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > October 2011

Re: More general thoughts on the @property change

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Mon, 31 Oct 2011 13:36:46 -0400
To: Ivan Herman <ivan@w3.org>
CC: W3C RDFWA WG <public-rdfa-wg@w3.org>, Péter Mika <pmika@yahoo-inc.com>
Message-ID: <8D629150-FAAB-41DE-A8B6-1919CF26B00B@greggkellogg.net>
On Oct 31, 2011, at 2:55 AM, Ivan Herman wrote:

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

IIRC, every RDF serialization has chaining. Some only chain BNodes, but that's consistent with most of the schema.org examples I've encountered.

@rel/@rev does have some confusing implications, but really only those that do not involve @about, @typeof, or @resource. What I find confusing about the following:

<a href="loc"><span property="name">Gregg</span></a> is that the name is a property of <loc>, not <>. Using @typeof and @about or @resource makes this explicit and not so confusing.

However, the fact that @rel uses _new subject_ as the subject, rather than _parent subject_ is where I think people have problems. What's confusing about the following:

<div rel="foo" typeof="Bar">
  <a property="name" href="...">Gregg</a>

is that it _doesn't_ create <> :foo [ a :Bar; :name "Gregg ] .

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

IMO, it's the precedence of @rel and confusion about when to use @rel or @property that is at issue. My proposal would do away with the need to use @rel, while not obsoleting it. It would also make the behavior of @property when used for chaining more intuitive (IMO) and consistent with Microdata's chaining rules.

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

My proposal has the advantages of avoiding unexpected chaining, while allowing the use of a single attribute (@property) to do explicit chaining when @typeof and/or @about is present. (I'm not in favor of removing @rel/@rev either, just making them unnecessary).

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

Understood, but respectfully disagree :).


> 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
Received on Monday, 31 October 2011 17:40:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:53 UTC