- From: Gregg Kellogg <gregg@kellogg-assoc.com>
- Date: Tue, 25 Oct 2011 15:26:10 -0400
- To: Ivan Herman <ivan@w3.org>
- CC: Gregg Kellogg <gregg@kellogg-assoc.com>, 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>
On Oct 25, 2011, at 12:09 AM, Ivan Herman wrote: > Gregg, > > thanks. That makes it much clearer. > > I think that, for the sake of the discussion, we should separate four different issues. This is just to make it easier to follow... > > 1. We referred to <a> and @href in the earlier discussions, you extended it to a number of other elements and attributes. Which is fine by itself, but I wonder whether it is up to the RDFa processing to go into such details for some of those. RDFa already accepts @href and @src, but I do not think it is the job of the RDFa processor to check whether these attributes are used on the right element (ie, on, say, <a> and not on a <span>). So it would simplify our processing if we simply referred to the possible attributes (we do not go into such details in the other areas of the processing either). What this means is that you propose to handle, beyond @href and @src, is also @data the same way. Beyond that, you refer to @content in a <meta>, @datetime and @cite. For simplicity, I was just re-using the Microdata property value term, but this could certainly be less language specific and use the existence of @href, @src and @data without regard to the element tag itself. > - I think that, for symmetry, @data should indeed be adopted > - For @content, we have a generic processing already. Why listing it separately? (The only issue is for RDFa Lite, ie, whether @content is allowed in a <meta> setting; I guess that must be spelled out.) This actually falls out without needing special rules, as RDFa Core currently looks for a value in @content, so using it for <meta> becomes more a matter of if the content model for <meta> allows @content, rather than any specific rules that are required. > - For @datetime, rumour says that the HTML5 WG is looking for an alternative and that will not be used. I'd propose not to consider it for now. I've been keeping this for Microdata to RDF until the HTML WG actually makes a change. > - I am uneasy about the @cite attribute, I am not sure how it is used... This is actually something Jeni complained about too, for Microdata, and I really don't have an opinion. I added for Microdata to RDF because it had been a GRDDL-type rule, which we eliminated, so as to not loose it, I put it in the property value section. I'm fine with either or both of Microdata and RDFa dropping it, if that's the concensus. > 2. The processing step modifications you propose on the usage of @href & co is indeed better than the simple DOM change that I described, insofar as it avoids all questions about chaining. Great. A bit more pain to implementers but, well, we will survive:-) > > 3. You have mixed in the other proposal on the usage of @property, with the @typeof and @about becoming objects. I regard this as a different issue, not really related to original issue about @property and @rel. Although I see the rationale of what you propose, it makes me feel uneasy to add yet another tweak in the way processing is done. I am not convinced we should go there unless we rethink the whole processing, also involving @rel and I am not yet sure where this would lead us. Are there, say, schema.org or similar examples where this would make a radical difference? Is it really necessary to go there? I think there is general dis-satisfaction with @rel in RDFa, and amore radical proposal would be to drop generalized @rel processing altogether, but I don't know how we could continue to call it RDFa 1.1 in that case, better to cleanly break all pretenses of backwards compatibility and call it RDFa 2.0. >From what Guha and Henri have written, we should take this seriously. I'm fine with separating the issues of @property URI ref generation from chaining, but don't see the point in splitting the Wiki entry right now. One thing that my suggested @property chaining rules get is to change the precedence of @property WRT chaining. With @rel on the same element as @about, it places @rel in the new subject, with @property it uses the current subject and creates a relationship to new subject. I think that this is what people are generally confused about, and I don't see any way to fix @rel. > In any case, again for the sake of the technical discussion, I would prefer to separate this issue from the rest > > 4. There is the question on what is Core specific, what is HTML5 specific, and finally what is XHTML specific. @href and @src are only Core specific, and the modification to use @property could be done there, without reference to (X)HTML. Adding @data to the list can be done, in my view, both for (X)HTML and HTML, without a problem on backward compatibility. > > In general, separating XHTML from HTML5 may be a problem. True, by the letter, XHTML and HTML5 are different but we all know that it is a huge controversy what should be considered as XHTML. Some would say the presence of the DTD, others would say the returned media type when HTTP is invoked; we should not get into this religious debate. The fact is that for end users, these differences are invisible and they would see them as the same. If processors switch between HTML5 and XHTML mode based on the media type (this is what I do pyRdfa, fwiw) then the user of the processor will experience a backward compatibility issue. Hence I would try to avoid differentiating between the two languages as far as we can... I agree that it's a problem, and note that you can use XHTML with HTML5, so simple content-type detection isn't really enough. Having different behavior for XHTML and HTML would lead to even more problems, but I suggested that as a way to avoid backwards-compatibility issues. My own feeling is that we through out backwards compatibility a while ago and we should not do things in half measures. Fixing the processing model based on substantial community feedback is something that the RDF WebApps WG should (re-)consider. Gregg > Thanks again! > > Ivan > > > On Oct 24, 2011, at 22:55 , Gregg Kellogg wrote: > >> 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 >>>> >>>> >>>> >>>> >>>> >>> >> >> > > > ---- > 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 Tuesday, 25 October 2011 19:26:59 UTC