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

Re: ItemList proposal

From: Jarno van Driel <jarnovandriel@gmail.com>
Date: Wed, 17 Sep 2014 11:53:18 +0200
Message-ID: <CADK2AU1F3eY-oOwbdBcT-NaYNWshT89rvAGGzdhudSiWnguHsQ@mail.gmail.com>
To: Dan Brickley <danbri@google.com>
Cc: Stéphane Corlosquet <scorlosquet@gmail.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>
>
> "Although there might be work to do at the search engines (per examples below
> esp. around @itemid, @resource), I believe Stephane's example ought to be
> fine at least in Google's RDFa parser. It doesn't use @resource, although
> it does use the same modeling style, which is to label the graph node
> directly with the URL rather than represent it as the value of an 'url'
> property."


It would be very nice indeed if the sponsors could do some work in regards
to this. But for now I'm be happy to see it's noted.

Be aware though the examples below only seem to succeed according to the
Structured Data Linter (RDFa Play doesn't digest microdata), Google's SDTT
and Yandex's SDV show different results, and not all have a proper outcome.

RDFa 1:
<body vocab="http://schema.org/">
  <a typeof="Article" href="http://example.com/article">
    <span property="name">Multiple identical @itemid's don't merge</span>
  </a>

  <a typeof="Article" href="http://example.com/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>

RDFa 2:
<body vocab="http://schema.org/">
  <span resource="http://example.com/article" typeof="
http://schema.org/Article">
    <a property="url" href="http://example.com/article">
      <span property="name">Multiple identical @itemid's don't merge</span>
    </a>
  </span>

  <span resource="http://example.com/article" typeof="
http://schema.org/Article">
    <a property="url" href="http://example.com/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>
  </span>
</body>

Microdata:
<body>
  <span itemid="http://example.com/article" itemscope itemtype="
http://schema.org/Article">
    <a itemprop="url" href="http://example.com/article">
      <span itemprop="name">Multiple identical @itemid's don't merge</span>
    </a>
  </span>

  <span itemid="http://example.com/article" itemscope itemtype="
http://schema.org/Article">
    <a itemprop="url" href="http://example.com/article">
      <span itemprop="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>
  </span>
</body>

2014-09-17 11:11 GMT+02:00 Dan Brickley <danbri@google.com>:

> On 17 September 2014 08:21, 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...
>
> Yes, it compressed well in RDFa 1.1.
>
> Although there might be work to do at the search engines (per examples
> below esp. around @itemid, @resource), I believe Stephane's example
> ought to be fine at least in Google's RDFa parser. It doesn't use
> @resource, although it does use the same modeling style, which is to
> label the graph node directly with the URL rather than represent it as
> the value of an 'url' property.
>
> Dan
>
> > 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>
> >
> > 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:
> >>
> >> <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.
> >
> >
>
Received on Wednesday, 17 September 2014 09:53:46 UTC

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