W3C home > Mailing lists > Public > public-vocabs@w3.org > September 2014

Re: ItemList proposal

From: Stéphane Corlosquet <scorlosquet@gmail.com>
Date: Wed, 17 Sep 2014 10:59:55 -0400
Message-ID: <CAGR+nnG+DrtvSJ0ZbrLtfNe2mBM+-VVeUaJHTE94yR1T8MefNA@mail.gmail.com>
To: Jarno van Driel <jarnovandriel@gmail.com>
Cc: Dan Brickley <danbri@google.com>, "martin.hepp@ebusiness-unibw.org" <martin.hepp@ebusiness-unibw.org>, Vicki Tardif Holland <vtardif@google.com>, "Jason Johnson (BING)" <jasjoh@microsoft.com>, W3C Web Schemas Task Force <public-vocabs@w3.org>
I think the bottom line is that the sponsors are starting to get the right
tooling in place, it's just taking a bit longer than we all would hope.
Regarding the documentation, anyone can provide this documentation now in
the form of better example via github. But to you point, Jarno, I agree
that before committing time to improve the examples, any contributor would
want to make sure that the features they plan to use in their improved
examples (be it @itemid or @resource) will be supported and understood by
the sponsors. I don't think any sponsor claimed they were against this,
it's just that they have to juggle with products deadlines etc. Even if
some sponsors are lagging behind one day, they will eventually catch up to
keep up with the other sponsors (since at the end of the day, it comes down
to competition of their products).

Steph.

On Wed, Sep 17, 2014 at 10:16 AM, Jarno van Driel <jarnovandriel@gmail.com>
wrote:

> And pardon me if I'm starting to be a bit grumpy about this, so let me say
> this now, to be able to continue in a reasonable manner:
>
> <rant>
> It just annoys the heck out of me that the more I learn about @resource,
> @itemid, @href and (fragment) identifiers, the more I discover every day
> developers (let alone marketers) lack the tools and documentation to learn
> this stuff properly. And even worse, if somebody somehow does come to
> understand how all of this is supposed to work, they only end up
> discovering they do a better job at understanding syntax than the sponsors
> reasoners/algorithms/whatever do. Surely the sponsors plan to correct this
> so us little Elves can perform the magic they want us to do, right?
> </rant>
>
>
>
> 2014-09-17 16:01 GMT+02:00 Jarno van Driel <jarnovandriel@gmail.com>:
>
>> "Please try the RDFa example above in
>>> https://www.google.com/webmasters/markup-tester/events, and you will
>>> see that @href is well understood by Google event markup parser (same
>>> applies to @resource). Google definitely has a sharp in-house RDFa parser,
>>> it's just a matter of using it across the board on all their products,
>>> which I'm sure is only a matter of time before it happens. The sooner the
>>> better, of course. We're all waiting to see this parser deployed on
>>> http://www.google.com/webmasters/tools/richsnippets.
>>> The Microdata markup above will not work, and that's by design because
>>> MD doesn't honor the @href as being used as URI for data items. That said,
>>> @itemid might work.
>>> Steph."
>>
>>
>> Thanks for pointing out the *Events* markup tester does eat the RDFa
>> version. Glad to see Google's making it easy for developers to find out if
>> something works: "SDDT, says one thing, so does WMT and now even the EVT
>> says something different".   :(
>>
>> The microdata version fails by the way. The EVT doesn't merge the two.
>>
>> 2014-09-17 15:58 GMT+02:00 Jarno van Driel <jarnovandriel@gmail.com>:
>>
>>> Please try the RDFa example above in
>>> https://www.google.com/webmasters/markup-tester/events, and you will
>>> see that @href is well understood by Google event markup parser (same
>>> applies to @resource). Google definitely has a sharp in-house RDFa parser,
>>> it's just a matter of using it across the board on all their products,
>>> which I'm sure is only a matter of time before it happens. The sooner the
>>> better, of course. We're all waiting to see this parser deployed on
>>> http://www.google.com/webmasters/tools/richsnippets.
>>>
>>> The Microdata markup above will not work, and that's by design because
>>> MD doesn't honor the @href as being used as URI for data items. That said,
>>> @itemid might work.
>>>
>>> Steph.
>>>
>>> 2014-09-17 15:55 GMT+02:00 Stéphane Corlosquet <scorlosquet@gmail.com>:
>>>
>>>>
>>>>
>>>> On Wed, Sep 17, 2014 at 3:21 AM, Jarno van Driel <
>>>> jarnovandriel@gmail.com> wrote:
>>>>
>>>>> "The trick is to avoid relying on an explicit value for 'url', and
>>>>>> instead use the href value as the URI as the Webpage. This is in fact much
>>>>>> more in line with Linked Data best practices and it avoids blank nodes. A
>>>>>> pet peeve of mine is that Schema.org relies too heavily on an explicit
>>>>>> 'url' property in its examples. If the 'url' property is not provided,
>>>>>> consumers such as Google should simply use the resource URI provided in
>>>>>> @itemid (microdata), @href/@resource (RDFa) or @id in JSON-LD."
>>>>>
>>>>>
>>>>> Kudos for this solution, it's a beauty. But...
>>>>>
>>>>> Unfortunately the current support for @itemid and @resource by the
>>>>> sponsors is unreliable. Let me illustrate by giving an example:
>>>>> (parsing these through rdfa.info/play/, Structured Data Linter,
>>>>> Structured Data Testing Tool (=Google ) and Structured Data Validator
>>>>> (=Yandex) will illustrate the issue). And I know, by testing it, that
>>>>> Google's WMT doesn't handle @itemid @@resource very well either.
>>>>>
>>>>> Microdata:
>>>>> <body>
>>>>>   <a href="http://example.com/article" itemscope itemtype="
>>>>> http://schema.org/Article">
>>>>>     <span itemprop="name">Multiple identical @itemid's don't
>>>>> merge</span>
>>>>>   </a>
>>>>>
>>>>>   <a href="http://example.com/article" itemscope itemtype="
>>>>> http://schema.org/Article">
>>>>>     <span itemprop="description">Google (WMT and SDTT) and Yandex
>>>>> (SDV) fail to merge 2 entities with the same @href/@itemid</span>
>>>>>   </a>
>>>>> </body>
>>>>>
>>>>> RDFa:
>>>>> <body vocab="http://schema.org/">
>>>>>   <a href="http://example.com/article" typeof="Article">
>>>>>     <span property="name">Multiple identical @itemid's don't
>>>>> merge</span>
>>>>>   </a>
>>>>>
>>>>>   <a href="http://example.com/article" typeof="Article">
>>>>>     <span property="description">Google (WMT and SDTT) and Yandex
>>>>> (SDV) fails to merge 2 entities with the same @href, however Yandex
>>>>> succeeds when @resource is specified where Google does not</span>
>>>>>   </a>
>>>>> </body>
>>>>>
>>>>>
>>>> Please try the RDFa example above in
>>>> https://www.google.com/webmasters/markup-tester/events, and you will
>>>> see that @href is well understood by Google event markup parser (same
>>>> applies to @resource). Google definitely has a sharp in-house RDFa parser,
>>>> it's just a matter of using it across the board on all their products,
>>>> which I'm sure is only a matter of time before it happens. The sooner the
>>>> better, of course. We're all waiting to see this parser deployed on
>>>> http://www.google.com/webmasters/tools/richsnippets.
>>>>
>>>> The Microdata markup above will not work, and that's by design because
>>>> MD doesn't honor the @href as being used as URI for data items. That said,
>>>> @itemid might work.
>>>>
>>>> Steph.
>>>>
>>>>
>>>>> Which does lead me to say that something needs to change in the way
>>>>> the sponsors deal with @resource (and @href) before relying on Stéphane's
>>>>> solution (again, which I think is a beauty).
>>>>>
>>>>> I see it as a bit of a disgrace the Structured Data Linter is the only
>>>>> tool that's able to parse both microdata and RDFa examples successfully. It
>>>>> most certainly doesn't help one bit in global identifiers being deployed by
>>>>> web developers. I for one would not expect the sponsors to be behind in
>>>>> supporting this.
>>>>>
>>>>>
>>>>> 2014-09-17 7:12 GMT+02:00 Stéphane Corlosquet <scorlosquet@gmail.com>:
>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 16, 2014 at 5:08 PM, Dan Brickley <danbri@google.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On 16 September 2014 21:50, Jarno van Driel <jarnovandriel@gmail.com>
>>>>>>> wrote:
>>>>>>> > Not much really, it's a custom I picked up because the W3 Validator
>>>>>>> > (http://validator.w3.org/) kept complaining about not providing a
>>>>>>> @title for
>>>>>>> > anchors, which it stopped complaining about if one added an empty
>>>>>>> @title. So
>>>>>>> > I became accustomed to alway specifying a @title, even it it's
>>>>>>> empty.
>>>>>>> >
>>>>>>> > To be honest I don't even know if the workaround is still needed
>>>>>>> or not, I
>>>>>>> > haven't looked into it for ages.  :)
>>>>>>> >
>>>>>>> > I'll remove it from the document though.
>>>>>>>
>>>>>>> Ah thanks, I thought it might be some wiki markup / escaping
>>>>>>> artifact.
>>>>>>>
>>>>>>> It's a big document. Maybe we could settle on one single core example
>>>>>>> that applies new Itemlist to the breadcrumbs usecase?
>>>>>>>
>>>>>>> A lot of people are interested in knowing how
>>>>>>> https://support.google.com/webmasters/answer/185417?hl=en should
>>>>>>> look.
>>>>>>>
>>>>>>> Here's the old markup:
>>>>>>>
>>>>>>> <div itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
>>>>>>>   <a href="http://www.example.com/dresses" itemprop="url">
>>>>>>>     <span itemprop="title">Dresses</span>
>>>>>>>   </a> ›
>>>>>>> </div>
>>>>>>> <div itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
>>>>>>>   <a href="http://www.example.com/dresses/real" itemprop="url">
>>>>>>>     <span itemprop="title">Real Dresses</span>
>>>>>>>   </a> ›
>>>>>>> </div>
>>>>>>> <div itemscope itemtype="http://data-vocabulary.org/Breadcrumb">
>>>>>>>   <a href="http://www.example.com/clothes/dresses/real/green"
>>>>>>> itemprop="url">
>>>>>>>     <span itemprop="title">Real Green Dresses</span>
>>>>>>>   </a>
>>>>>>> </div>
>>>>>>>
>>>>>>> How concisely can we do this with new ItemList? Does this look
>>>>>>> monsterously verbose, or bearable?
>>>>>>>
>>>>>>> <ol itemscope="" itemtype="http://schema.org/ItemList">
>>>>>>>   <li itemprop="itemListElement" itemscope=""
>>>>>>> itemtype="http://schema.org/ListItem">
>>>>>>>     <span itemprop="item" itemscope="" itemtype="
>>>>>>> http://schema.org/WebPage">
>>>>>>>       <a href="http://www.example.com/dresses" itemprop="url">
>>>>>>>         <span itemprop="title">Dresses</span>
>>>>>>>       </a>
>>>>>>>     </span>
>>>>>>>   </li>
>>>>>>> ›  <li itemprop="itemListElement" itemscope=""
>>>>>>> itemtype="http://schema.org/ListItem">
>>>>>>>     <span itemprop="item" itemscope="" itemtype="
>>>>>>> http://schema.org/WebPage">
>>>>>>>       <a href="http://www.example.com/dresses/real" itemprop="url">
>>>>>>>         <span itemprop="title">Real Dresses</span>
>>>>>>>       </a>
>>>>>>>     </span>
>>>>>>>   </li>
>>>>>>> ›  <li itemprop="itemListElement" itemscope=""
>>>>>>> itemtype="http://schema.org/ListItem">
>>>>>>>     <span itemprop="item" itemscope="" itemtype="
>>>>>>> http://schema.org/WebPage">
>>>>>>>       <a href="http://www.example.com/clothes/dresses/real/green"
>>>>>>> itemprop="url">
>>>>>>>         <span itemprop="title">Real Green Dresses</span>
>>>>>>>       </a>
>>>>>>>     </span>
>>>>>>>   </li>
>>>>>>> </ol>
>>>>>>>
>>>>>>
>>>>>> This example can be simplified by removing one level of nesting, as
>>>>>> shown in this example in RDFa, which I tested in Play
>>>>>> <http://rdfa.info/play/>:
>>>>>>
>>>>>> <ol vocab="http://schema.org/" typeof="ItemList">
>>>>>>   <li property="itemListElement" typeof="ListItem">
>>>>>>       <a property="item" typeof="WebPage" href="
>>>>>> http://www.example.com/dresses">
>>>>>>         <span property="title">Dresses</span>
>>>>>>       </a>
>>>>>>       <meta property="position" content="1">
>>>>>>   </li>
>>>>>> ›  <li property="itemListElement" typeof="ListItem">
>>>>>>       <a property="item" typeof="WebPage" href="
>>>>>> http://www.example.com/dresses/real">
>>>>>>         <span property="title">Real Dresses</span>
>>>>>>       </a>
>>>>>>       <meta property="position" content="2">
>>>>>>   </li>
>>>>>> </ol>
>>>>>>
>>>>>> The trick is to avoid relying on an explicit value for 'url', and
>>>>>> instead use the href value as the URI as the Webpage. This is in fact much
>>>>>> more in line with Linked Data best practices and it avoids blank nodes. A
>>>>>> pet peeve of mine is that Schema.org relies too heavily on an explicit
>>>>>> 'url' property in its examples. If the 'url' property is not provided,
>>>>>> consumers such as Google should simply use the resource URI provided in
>>>>>> @itemid (microdata), @href/@resource (RDFa) or @id in JSON-LD.
>>>>>>
>>>>>> Equivalent JSON-LD:
>>>>>>     {
>>>>>>       "@id": "_:g70204145541180",
>>>>>>       "@type": "ItemList",
>>>>>>       "itemListElement": [
>>>>>>         "_:g70204145492480",
>>>>>>         "_:g70204145237140"
>>>>>>       ]
>>>>>>     },
>>>>>>     {
>>>>>>       "@id": "_:g70204145492480",
>>>>>>       "@type": "ListItem",
>>>>>>       "item": "http://www.example.com/dresses",
>>>>>>       "position": "1"
>>>>>>     },
>>>>>>     {
>>>>>>       "@id": "_:g70204145237140",
>>>>>>       "@type": "ListItem",
>>>>>>       "item": "http://www.example.com/dresses/real",
>>>>>>       "position": "2"
>>>>>>     },
>>>>>>     {
>>>>>>       "@id": "http://www.example.com/dresses",
>>>>>>       "@type": "WebPage",
>>>>>>       "title": "Dresses"
>>>>>>     },
>>>>>>     {
>>>>>>       "@id": "http://www.example.com/dresses/real",
>>>>>>       "@type": "WebPage",
>>>>>>       "title": "Real Dresses"
>>>>>>     }
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Steph.
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Steph.
>>>>
>>>
>>>
>>
>


-- 
Steph.
Received on Wednesday, 17 September 2014 15:00:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:29:44 UTC