- From: Guha <guha@google.com>
- Date: Tue, 25 Oct 2011 09:02:47 -0700
- To: Ivan Herman <ivan@w3.org>, John Giannandrea <jgiann@google.com>, Jason Douglas <jasondouglas@google.com>, Kavi Goel <kavi@google.com>
- Cc: Gregg Kellogg <gregg@kellogg-assoc.com>, Stéphane Corlosquet <scorlosquet@gmail.com>, Manu Sporny <msporny@digitalbazaar.com>, HTML Data Task Force WG <public-html-data-tf@w3.org>
- Message-ID: <CAPAGhv8VWMtmUyY0Bh1s1t4oLeDVyNbRNT=9fBKJ4vRFijuMkg@mail.gmail.com>
I don't have the exact number handy. One of us will go compute it. guha On Sun, Oct 23, 2011 at 10:15 PM, Ivan Herman <ivan@w3.org> 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? > > 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 > > > > > >
Received on Tuesday, 25 October 2011 16:03:30 UTC