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

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. A possible, hack-style approach is to put a @rel="" on the element, which would push @property back on its traditional role.

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

I am sure there are some others.

B.t.w., admin issue: I wonder whether this discussion should continue on the vocabulary mailing list. It really becomes a syntax issue, ie, should move to the html task force (thanks for doing this) or the RDFa WG, or both. I would propose to remove the vocabulary task force cc in the future, unless others object...

Thanks

Ivan





On Oct 23, 2011, at 02:28 , Gregg Kellogg wrote:

> I'm CCing the HTML Data TF, as that's really the appropriate location for syntax discussions.
> 
> I'm wondering if we could consider an HTML-specific approach to unifying @property and @rel in HTML+RDFa 1.1 Lite. Within that spec, we could define some additional processing rules for @property to create URIs, much (exactly) as MicroData does. This would not replace @rel, but the eventual RDFa 1.1 Lite specification/note would recommend that @rel NOT be used for markup for these use cases. Of course, if it were, the normal RDFa Core 1.1 rules would apply.
> 
> Microdata describes how to retrieve a property value [1]. The Microdata to RDF draft uses essentially the same, but with some additional detail for creating RDF [2]. Basically, elements that have an attribute with a URI content model use that value to create a URI Reference, and otherwise a literal is generated.
> 
> * audio, embed, iframe, img, source, track, and video use the value of a @src attribute as a URI ref.
> * a, area and link use the value of an @href attribute as a URI ref.
> * object uses the value of a @data attribute as a URI ref.
> * I also added rules for blockquote and q to use the value of a @cite attribute as a URI reference, but this is not in the HTML Microdata spec.
> * Otherwise, @property acts as now defined in RDFa Core 1.1.
> 
> Alternatively, we could say that @href, @src, @object and @cite take higher precedence and result in a URI ref from any element.
> 
> Additionally, to allow for chaining, if @property were used in an element that also had either or both @about or @typeof, it would become a reference (URI or BNode) to a new object defined at that element scope, identically to @itemprop in the same element as @itemscope.
> 
> HTML+RDFa 1.1 Lite could then adopt these same rules, so for example, a schema:Event might be marked up as follows:
> 
> <div vocab="http://schema.org/" typeof="Event"> 
>   <a property="url" href="nba-miami-philidelphia-game3.html"> 
>   NBA Eastern Conference First Round Playoff Tickets: 
>   Miami Heat at Philadelphia 76ers - Game 3 (Home Game 1) 
>   </a> 
>  
>   <span property="startDate">2011-04-21T20:00</span>
>  
>   <div property="Location" typeof="Place"> 
>     <a property="url" href="wells-fargo-center.html"> 
>     Wells Fargo Center 
>     </a> 
>     <div property="address" typeof="PostalAddress"> 
>       <span property="addressLocality">Philadelphia</span>, 
>       <span property="addressRegion">PA</span> 
>     </div> 
>   </div> 
>  
>   <div property="offers" typeof="AggregateOffer"> 
>     Priced from: <span property="lowPrice">$35</span> 
>     <span property="offerCount">1,938</span> tickets left 
>   </div> 
> </div> 
> 
> (Note, we miss some formatting with startDate, but if we were also to adopt @datetime processing rules, or whatever the HTML WG replaces it with, this could be handled better as well).
> 
> There are probably some corner cases that would need to be worked out, but by limiting this to the HTML+RDFa definition, we avoid backwards compatibility issues with RDFa 1.0 and get that much closer
> 
> Gregg
> 
> [1] http://www.w3.org/TR/2011/WD-microdata-20110525/#values
> [2] https://dvcs.w3.org/hg/htmldata/raw-file/24af1cde0da1/microdata-rdf/index.html#algorithm-terms
> 
> On Oct 22, 2011, at 2:36 PM, Guha wrote:
> 
>> 
>> 
>> On Sat, Oct 22, 2011 at 1:49 PM, Manu Sporny <msporny@digitalbazaar.com> wrote:
>> On 10/22/2011 01:38 PM, Guha wrote:
>> Google announced supported RDFa in 2009. One of the startling
>> discoveries we made was that the error rate (i.e., webmasters marking
>> up their pages to say X when the really meant to say Y) was about 3
>> times as much as it was for other formats (which include
>> microformats, sitemaps, Google shopping feeds, etc.). The error rate
>>  is/was so bad that we had resort to highly non-scalable techniques
>> like having humans look at the markup on each site to make sure it
>> said what the page said. More than 40% of the errors had to do with
>> the confusion between rel and property.
>> 
>> That is startling. Could you please publish the data and analysis
>> publicly so that those on this list may look at it and analyze it? We have a couple of approaches that we've discussed over the past 6+ years that could be applied if we knew exactly /how/ people were getting the markup wrong.
>> 
>> We will look into sharing what we can. We have on a number of occasions shared aggregate data. It is not clear we are in a position to share detailed information about other people's websites. You are of course welcome to do the analysis yourself.
>>  
>> 
>> I will also note that this particular data was never brought to the
>> attention of the RDFa Working Group. When did you know about these
>> errors? Why did you not share the data when you came across it? I ask
>> because it would've impacted the design of RDFa 1.1 if you had shared
>> this data with us at the time.
>> 
>> Manu, I think you are missing something here. We have communicated this information, many times, in one-one meetings with Ben Adida and others as we were working on developing microdata. At the end of the day, it was negligence on the part of the folks designing RDFa 1.1 to not actively seek input from some biggest consumers of RDFa. 
>> 
>> 
>> It is important to note that this data is from a very large sample
>> (10s of millions of pages) taken from Schema.org's target audience:
>> webmasters of sites that are by and large not about technical stuff.
>> 
>> A list of URLs would be great along with a technical analysis of all of
>> those URLs. Specifically, the following data would be very helpful:
>> 
>> Google DOES NOT provide lists of URLs to anyone. You are welcome to go crawl the web.
>>  
>> 
>> * How frequent was the use of @rel vs. the use of @property?
>>  
>> * When @rel was used, was it used in chaining or was it used to
>>  simply refer to an external resource?
>> 
>> We don't recommend chaining. Almost no one producing markup with rich snippets uses external resources.
>>  
>> * In the Microformats and Creative Commons cases
>>  (rel="license", rel="tag", etc.) did people get @rel wrong?
>> 
>> You should ask them.
>>  
>> * How frequently does @rel and @property exist on the same element?
>> 
>> In the vocabulary we specified, never.
>>  
>> * How frequently is @property used when @rel should have been used
>>  instead?
>> 
>> Don't have the numbers, but it was pretty random. You have to understand that at anything more than a few percent error rate, the data becomes largely unusable in scale.
>>  
>> * How frequently is @rel used when @property should have been used
>>  instead?
>> 
>> I will look into doing this analysis, but am not sure when we will be able to get around to this.
>>  
>> 
>> Answering these questions will help us understand how the spec should change.
>> 
>> 
>> We really don't want to get into whether there is a distinction
>> between rel and property at a theoretical level.
>> 
>> Who is "we" in this case? The RDFa WG does not want to get into a theoretical debate either. We care about authors easily generating good, valid data.
>> 
>> We = Google, Schema.org. 
>> 
>> 
>> But the bottom line remains that as long as
>> the error rate in RDFa usage does not go down dramatically, it is not
>> a viable option for us.
>> 
>> Who is "us" in this case?
>> 
>> Us = Google, Schema.org 
>> 
>> 
>> The current proposal takes a step in the
>> right direction, but several big issues, like the removal of the
>> distinction between rel and property still need to be addressed.
>> 
>> Could you please detail every one of those "big issues"?
>> 
>> We are doing it. Jason brought up the other issue.
>>  
>> -- manu
>> 
>> -- 
>> Manu Sporny (skype: msporny, twitter: manusporny)
>> Founder/CEO - Digital Bazaar, Inc.
>> blog: Standardizing Payment Links - Why Online Tipping has Failed
>> http://manu.sporny.org/2011/payment-links/
>> 
>> 
> 


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

Received on Sunday, 23 October 2011 07:33:26 UTC