W3C home > Mailing lists > Public > public-html-data-tf@w3.org > October 2011

Re: RDF 1.1 Lite Issue # 2: property vs rel

From: Guha <guha@google.com>
Date: Tue, 25 Oct 2011 09:02:47 -0700
Message-ID: <CAPAGhv8VWMtmUyY0Bh1s1t4oLeDVyNbRNT=9fBKJ4vRFijuMkg@mail.gmail.com>
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>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 25 October 2011 16:03:31 GMT