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

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
> 
> 
> 
> 
>

Received on Monday, 24 October 2011 05:34:24 UTC