- From: Gregg Kellogg <gregg@kellogg-assoc.com>
- Date: Mon, 24 Oct 2011 16:55:29 -0400
- To: Gregg Kellogg <gregg@kellogg-assoc.com>
- CC: Ivan Herman <ivan@w3.org>, Stéphane Corlosquet <scorlosquet@gmail.com>, Ramanathan V Guha <guha@google.com>, Manu Sporny <msporny@digitalbazaar.com>, HTML Data Task Force WG <public-html-data-tf@w3.org>, RDFa WG <public-rdfa-wg@w3.org>
I've created a Wiki entry [1] in the RDFa wiki space that describes using @property in RDFa 1.1 Lite for the HTML+RDFa 1.1 host language. This could presumably be done for other source languages, if specific element tags and atributes were identified. Doing this for XHTML+RDFa 1.1 would create a backwards compatibility issue. By not applying it to that host language, we avoid the compatibility issue, but make the behavior for XHTML 1.1 different than for (X)HTML5. It may be worth considering that option, but this is not necessary to make the standard plain HTML case simpler. Gregg [1] http://www.w3.org/2010/02/rdfa/wiki/RDFaLiteWithProperty On Oct 23, 2011, at 11:19 PM, Gregg Kellogg wrote: > On Oct 23, 2011, at 10:52 PM, Ivan Herman wrote: > >> Gregg, >> >> just for my understanding, because your answer was not fully clear to me (it is still early morning and I have not yet have my breakfast...): do you say that the mechanical transformation I outline is enough, and the fact that leads to the chaining artifact is not a problem in practice? I am happy if we all agree on that... >> >> The good thing of the rule: >> >> "If, on an element, there is an @href/@src, there is a @property, but there is no @rel/@rev, then @property behaves like a @rel with @href in RDFa terms" >> >> is that, conceptually, this could be considered for an RDFa processor as some sort of a preprocessing step. This is the way I would implement it. Which can also be a way to spec it, without upsetting the balance of the current processing step description in the spec. > > I can see why this might lead to a simpler implementation, but I think there are a number of issues with @rel and @typeof that we can't deal with in RDFa 1.1 due to backwards compatibility issues, that we have an opportunity to fix in HTML+RDFa 1.1 (Lite) with specific @property behavior. > > A problem with @rel and @typeof (and one of the common errors I sited in my blog post) is that if they are both used on the same element, a new subject is created before the @rel is applied, so the @rel is applied to the new subject, rather than being a property of the current subject referencing the newly created subject. AFIK, this was necessary so you could say: > > <img src="http://foo" rel="license" resource="http://creativecommons.org/licenses/by/3.0/us/"/> > > Of course, with @src changing to be like @href, this wouldn't work anymore, but we're still left with @rel being processed after creating a new subject, which could happen because of @about or @typeof. > > I'm suggesting that RDFa 1.1 Lite use different semantics for @property along with @about and/or @typeof on the same subject. This allows you to say the following: > > <div vocab="http://schema.org/" about="#me" typeof="Person"> > <div property="address" typeof="PostalAddress> > <span property="streetAddress">...</span> > </div> > </div> > > which requires an extra element using @rel. > > The chaining rule I suggested was the following: > > If an element has an @property attribute and either or both of @about or @typeof, create a new subject _s_. > For each IRI reference _p_ obtained from the values of @property emit the following triple: > *subject*: current subject > *predicate*: _p_ > *object*: _s_ > > This does pretty much the same thing as Microdata does with an element having both @itemprop and @itemscope, and I think is the way that people naturally think @property should work, as evidenced by the problems people have using @rel for chaining. > > The advantage is, we do all this without breaking backwards compatibility (there is no HTML+RDFa 1.0, only XHTML+RDFa 1.0), we're still fully compatible with existing RDFa Core 1.1 processing rules, but allow for a limited subset of the language, with HTML-specific extensions, that has characteristics that are actually closer to what is expected for schema.org than the current Microdata spec does, vis-a-vis property URI generation from non-URI @itemprop values. > > It's certainly worth a but more effort on the part of processor maintainers to support this pattern, if it is actually easier for publishers to get right. > > Gregg > >> Ok, I have go to go now, and I will be on a different workshop for the whole day... Ie, I can react sporadically only! >> >> Cheers >> >> Ivan >> >> >> On Oct 24, 2011, at 07:33 , Gregg Kellogg wrote: >> >>> On Oct 23, 2011, at 10:15 PM, Ivan Herman wrote: >>> >>>> Hey Gregg et al, >>>> >>>> (Guha, there is an explicit question to you...) >>>> >>>> On Oct 23, 2011, at 19:16 , Gregg Kellogg wrote: >>>> >>>>> On Oct 23, 2011, at 12:42 AM, Stéphane Corlosquet wrote: >>>>> >>>>>> (removing public-vocabs) >>>>>> >>>>>> On Sun, Oct 23, 2011 at 12:34 AM, Ivan Herman <ivan@w3.org> wrote: >>>>>> Gregg, >>>>>> >>>>>> >>>>>> just for my understanding and concentrate on the most frequent @href/@src cases (the others are of a secondary importance compared to @href/@src). Can your rules be summarized as: >>>>>> >>>>>> - If, on an element, there is an @href/@src, there is a @property, but there is no @rel/@rev, then @property behaves like a @rel with @href in RDFa terms >>>>>> - In RDFa 1.1 Lite we advise users not to use @rel. Alternatively, @rel is not recognized in RDFa 1.1 Lite though still possible. (I would prefer the former, b.t.w.) >>>>>> >>>>>> I can see the value of this but, to be able to move ahead, we have to analyze the technical issues. Some that come to my mind immediately (I am at a conference now, unfortunately, so I have to divide my attention...): >>>>>> >>>>>> - If this is a general rule, I am not sure how we could use the textual content of a <a> element as a literal property. Well, it can be done by putting it in a separate <span> with all kind of other things. >>>>>> >>>>>> I don't see this as a problem. Microdata has the same caveat, and <span> has to be used inside <a> as well. >>>>> >>>>> Agreed, I think this removes some ambiguity for users; the general advice would be to be as specific as possible when using @property. >>>> >>>> So the problem is chaining, as I realized (again:-(. If I say >>>> >>>> <a href="blah" property="yup"><span property="foo">something</span></a> >>>> >>>> and I mechanically apply the rule I have outlined above then, per chaining, I would get >>>> >>>> <inherited_subject> <yup> <blah> . >>>> <blah> <foo> "Something" . >>>> >>>> Ie, if one wants to reproduce the 'old' behaviour, then we have, I think, two options >>>> >>>> 1. the author is supposed to add an explicit @about on the span. Probably error prone. >>>> 2. the rule I outline above should be expanded with something like @property behaves like the 'proper' property in terms of chaining, ie, it does not set the new subject, but behaves like @rel in terms of the triples generated >>>> >>>> The problem with #2 is how to spec it properly without distorting the current RDFa 1.1 spec too much. Otherwise we really get into some sort of a spaghetti code. Any good ideas there? >>> >>> I think we can over-complicate and over-think this considering all the different behaviors that _might_ happen. If, as Guha said, that chaining isn't recommended, then I really don't think we want to introduce a new subject without some explicit markup. Using @about or @typeof makes this explicit, much in the way @itemscope does for Microdata. In fact, the more like Microdata we can make this behavior, the more Microdata can be considered just a transformation of RDFa 1.1 Lite, which I think would be a good direction (@itemid => @about, @itemtype => @typeof, @itemprop => @property, ...). >>> >>> The one time where chaining is necessary is when the object doesn't have a URI, as is commonly the case for schema.org examples. In this case, chaining is necessary to avoid needing to explicitly use a named blank node. >>> >>> Gregg >>> >>>> Guha, do you have any experience, based on the rich snippets, how frequent is the situation when the content of the <a> element is also used to generate additional triples, or is it so that users usually 'stop' at <a>, so we should not worry about that too much? >>>> >>>>> >>>>>> Steph. >>>>>> >>>>>> A possible, hack-style approach is to put a @rel="" on the element, which would push @property back on its traditional role. >>>>> >>>>> Yes, that can still work, as it is still RDFa 1.1, and if used, an @rel would have it's original intent, but this should be discouraged in the spec/note/primer. >>>>> >>>> >>>> Agreed. >>>> >>>>>> - I know I will sound as a broken record, but I am forced to beat this issue because it is still open. This works in microdata because the microdata spec introduced a special treatment for <link> (and <meta>) insofar as it allows <link> being part of the body if it uses microdata attributes. Until the same happens with RDFa attributes, the model above means that users can encode non-literal links (using RDF terms) only with clickable links (forget about the <head> now). Current HTML5 parser would move <link> to the head, unless I am mistaken (and I hope I am!), ie, it will not work. >>>>> >>>>> As HTML+RDFa is an HTML spec, not an RDFA WG spec, we can make it explicit there that <meta> and <link> are in the body if used with a @property. Or, the HTML WG could just make it simpler and remove restrictions on <meta> and <link> in the body altogether, although they would have no purpose but to express metadata. It would allow it's use for other specs, such as Microformats, though. >>>> >>>> Yes. But how can we convince the HTML5 WG to really _do_ this change? >>>> >>>> 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 >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >> ---- >> 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, 24 October 2011 20:56:15 UTC