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

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

From: Gregg Kellogg <gregg@kellogg-assoc.com>
Date: Mon, 24 Oct 2011 13:03:57 -0400
To: Ivan Herman <ivan@w3.org>
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: <C1BB5970-4BF8-4DF1-AA2D-2E9A413091DF@kellogg-assoc.com>
On Oct 24, 2011, at 8:57 AM, "Ivan Herman" <ivan@w3.org> wrote:

> Forgive me Gregg, I really just peek into your email (running around between two meetings:-). But I am not sure I fully understand.
> 
> Looking at
> 
>>    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_
> 
> what would then be the effect of <a href="bla" property="yep"/> ? I thought the idea was that this would/should generate
> 
> <current_subject> <bla> <yep> .
> 
> but your proposal does not seem to address that... Or do you mean that people would have to use @about or @typeof for this?

This is clearly getting to complex
For an email thread, and I'll re-state in an RDFa Wiki.

The behavior with @about and @typeof is to support chaining. Otherwise, it behaves more like @itemprop for generating URI refs and existing @property for literals.

If you look back to my original proposal in this thread describes this behavior.

Gregg

> Ivan
> 
> 
> 
> 
> On Oct 24, 2011, at 08:19 , 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 Monday, 24 October 2011 17:05:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 24 October 2011 17:05:16 GMT