- From: Ivan Herman <ivan@w3.org>
- Date: Mon, 24 Oct 2011 07:15:29 +0200
- To: Gregg Kellogg <gregg@kellogg-assoc.com>
- Cc: 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>
- Message-Id: <907556A3-7E90-4523-97EB-94FF01CEF997@w3.org>
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? 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
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Monday, 24 October 2011 05:13:55 UTC