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

Re: schema.org Breadcrumb design on top of ItemList

From: Aaron Bradley <aaranged@gmail.com>
Date: Sat, 20 Sep 2014 09:46:24 -0700
Message-ID: <CAMbipBtVciFeFsy+jw-hEcgMDD2sJbMPQSG5sRAweVxosWXWSA@mail.gmail.com>
To: "martin.hepp@ebusiness-unibw.org" <martin.hepp@ebusiness-unibw.org>
Cc: Dan Brickley <danbri@google.com>, Jarno van Driel <jarnovandriel@gmail.com>, W3C Web Schemas Task Force <public-vocabs@w3.org>, Stéphane Corlosquet <scorlosquet@gmail.com>
Re: current page being included in the breadcrumb trail -

While, like Jarno, I've had my share of developers grumble about excluding
the current page from a linked breadcrumb trail, none have failed to figure
out how to do so.

That it's common to see the current page linked in a breadcrumb trail
doesn't mean that it's good practice.  IMO most information architects (and
UI designers) would consider it bad practice, because the link is
self-referential (from a UI perspective it provides users with an
opportunity to initiate a meaningless click , which obviously makes the
breadcrumbs sub-optimal).

FWIW the Wikipedia entry [1] pretty unequivocally considers breadcrumb to
be a list of links *to* to the page.

"[Breadcrumbs] provide links back to each previous page the user navigated
through to get to the current page or—in hierarchical site structures—the
parent pages of the current one."

All of this to say is that linking up the current page - insofar as it
isn't (AFAIK) best practice, isn't something schema.org should encourage -
which it certainly would because webmasters would be eager to generate
in-SERP breadcrumbs by adhering to the protocol.

Also, for the past several years webmasters have been eschewing
schema.org/breadcrumb in favor of data-vocabulary.org/Breadcrumb, both
because the problems with the former are well-known, and because the
Webmaster Tools guidelines for Google [2] (to which
data-vocabulary.org/Breadcrumb/ links) declares that "[each] breadcrumb
item should appear in order, with the first item representing the top-level
page, and the final item representing the parent of the current page."
 This means that probably the vast majority of marked up breadcrumb trails
out there omit the current page.

I acknowledge that this is not a unanimous approach.  Bing's Webmaster
Tools guidelines [3] state that "[the] last breadcrumb in the trail
represents the user’s current location in your site’s hierarchy."  (I
couldn't find any Yandex recommendations, but I'm not able search in
Russian).  However, the Google guidelines are much more frequently cited
and used.

Re syntax -

>> I would prefer to
>> - keep the breadcrumb property and
>> - either use a generic ItemList for the breadcrumbs or a BreadCrumbList
type
>I would actually recommend using the breadcrumb property for all of them.

I definitely think retaining breadcrumb as a property, and I *think* I'd
like to see the breadcrumb property used for the cases Dan references, but
I need so see some sample code. :)

Whatever is the least complicated.  The precision of the position property
for a single breadcrumb trail is redundant, because if breadcrumbs aren't
presented in the order in which they're to be understood (by humans and
parsers) they're not breadcrumbs.  (I like the data-vocabulary.org approach
because it's straightforward and two of its three properties are
universal.  But replicating it isn't sensible because the need to declare a
new scope for each individual breadcrumb is obviously clunky.)

And even for multiple breadcrumb trails, if each trail is a homogeneous
item there's no need to state a "position".  This was necessary for
data-vocabulary.org because there each individual breadcrumb link is a
separate Breadcrumb item, but there'd be so such ambiguity if each
breadcrumb *list* was separately declared (a la BreadCrumbList).

The challenge of indicating the primacy of breadcrumb trails when there's
multiple trails is a manufactured problem.  If you explore the topic of
"multiple breadcrumb trails" even in general, it's predominantly structured
data discussions like this that predominate in search results.  Aside from
actively not recommending the use of multiple breadcrumb trails, UI
designers are silent on the subject of primacy of breadcrumb trails.  I
guess the case could be made that indicating the primary breadcrumb trail
could instruct search engines which breadcrumbs to display in the search
results, but a webmaster is more likely to circumvent that problem by only
marking up the one breadcrumb trail to begin with.  IMO it's an edge case.

[1] http://en.wikipedia.org/wiki/Breadcrumb_(navigation)
[2] https://support.google.com/webmasters/answer/185417
[3] http://www.bing.com/webmaster/help/markup-breadcrumbs-72419f3f


On Sat, Sep 20, 2014 at 1:05 AM, martin.hepp@ebusiness-unibw.org <
martin.hepp@ebusiness-unibw.org> wrote:

>
> On 20 Sep 2014, at 09:53, Dan Brickley <danbri@google.com> wrote:
>
> > On 20 September 2014 08:43, Martin Hepp <martin.hepp@unibw.de> wrote:
> >> I would prefer to
> >>
> >> - keep the breadcrumb property and
> >> - either use a generic ItemList for the breadcrumbs or a BreadCrumbList
> type
> >
> > Some pages have a few breadcrumb chains. Perhaps we might say
> > something about http://schema.org/breadcrumb indicating the primary
> > navigation?
> >
> I would actually recommend using the breadcrumb property for all of them.
>
> If you want to have two or more breadcrumb paths in a page, one could also
> use an ItemList of BreadCrumbLists with a position property. That would be
> conceptually clean and nice.
>
> > There's still the question of whether the most specific end of the
> > chain should contain the current page or not? If not, then linking it
> > also with 'breadcrumb' might be overkill. Jarno's comment suggests
> > that inclusion would be simpler for implementors.
> >
> Jarno will know better, but I think that including it seems more natural,
> because you can use the sample templating patterns for all pages without
> extra handling for the actual page.
>
> > Dan
> >
> >> Martin
> >>
> >>
> >> On 19 Sep 2014, at 22:17, Jarno van Driel <jarnovandriel@gmail.com>
> wrote:
> >>
> >>> "(This would replace/obsolete the existing unused
> >>> http://schema.org/breadcrumb property)"
> >>>
> >>> If I understand you correct you mean this for example:
> >>>
> >>> <body vocab="http://schema.org/" typeof="WebPage">
> >>>  <ol typeof="BreadcrumbList">
> >>>    ...
> >>>  </ol>
> >>> </body>
> >>>
> >>> But with keeping 'breadcrumb' as a property we would actually be able
> to chain the BreadcrumbList to the WebPage:
> >>>
> >>> <body vocab="http://schema.org/" typeof="WebPage">
> >>>  <ol property="breadcrumb" typeof="BreadcrumbList">
> >>>    ...
> >>>  </ol>
> >>> </body>
> >>>
> >>> Or is this too much and is having both WebPage and BreadcrumbList
> being top level entities good enough?
> >>>
> >>> 2014-09-19 21:15 GMT+02:00 Dan Brickley <danbri@google.com>:
> >>> On 19 September 2014 20:05, Aaron Bradley <aaranged@gmail.com> wrote:
> >>>> Glad to see the breadcrumb issue making its way back into the queue.
> >>>>
> >>>> What neither the description nor the example markup addresses is
> whether the
> >>>> declared breadcrumbs do (or should) include the current page.
> >>>
> >>> In general most schema.org definitions only hint at "shoulds" and
> >>> "musts" w.r.t. what a description ought to contain.
> >>>
> >>> Maybe
> >>>
> >>> "A BreadcrumbList is an ItemList
> >>> consisting of a list of Web pages, typically described using at least
> >>> their URL and their name. A common pattern is for the list to
> >>> represent a hierarchy from a top level entry point to the current page
> >>> (or the page above it)."
> >>>
> >>>> Perhaps this is a vocabulary-agnostic matter insofar as individual
> data
> >>>> consumers may have their own guidelines, and/or be able to figure out
> from
> >>>> parsing the content (if one is on the page "../dresses/real" and
> you've
> >>>> declared "../dresses/real" as your highest position breadcrumb one
> would
> >>>> think Google et al. would be able to figure out that this breadcrumb
> and the
> >>>> current page are one and the same).
> >>>>
> >>>> FWIW, though, Google [1] explicitly instructs webmasters to exclude
> the
> >>>> current page when using data-vocabulary.org/Breadcrumb:
> >>>>
> >>>> "Each breadcrumb item should appear in order, with the first item
> >>>> representing the top-level page, and the final item representing the
> parent
> >>>> of the current page."
> >>>
> >>> My personal view (and I'm checking back with colleagues now that
> >>> ItemList has settled down) is that the more explicit the better.
> >>>
> >>>> Also, if the example was actually meant to show the proposed type
> >>>> BreadcrumbList in action, shouldn't it be employed in the example?
> >>>
> >>> Since the ItemList design is finished, I thought it worth working up
> >>> an example that uses it - potentially for inclusion in the site asap.
> >>> Hopefully it could be followed up soon afterwards by a dedicated type
> >>> ("BreadcrumbList"? "BreadcrumbChain"?) if one is agreed.
> >>>
> >>> Dan
> >>>
> >>>
> >>>> I.e. for microdata the shouldn't the type declaration:
> >>>> <ol itemscope itemtype="http://schema.org/ItemList">
> >>>> ... actually be:
> >>>> <ol itemscope itemtype="http://schema.org/BreadcrumbList">
> >>>>>
> >>>>
> >>>> [1] https://support.google.com/webmasters/answer/185417
> >>>>
> >>>>
> >>>> On Fri, Sep 19, 2014 at 11:43 AM, Dan Brickley <danbri@google.com>
> wrote:
> >>>>>
> >>>>> Here's one more pass over the schema.org breadcrumb usecase for
> ItemList.
> >>>>>
> >>>>> As a recap, the challenge was to keep an ordered list of url + label
> >>>>> pairs which survives the transformation into an extracted graph (aka
> >>>>> triples). Thanks for everyone who jumped into this discussion
> already.
> >>>>> I've just been going over the rdfa/microdata options with Stephane
> >>>>> Corlosquet in IM and here's the best we can come up with.
> >>>>>
> >>>>> I won't go into all the boring and fiddly tradeoffs here, just the 3
> >>>>> minimalistic examples showing a 2 item ordered list of link / anchor
> >>>>> text pairs. We considered dropping the @typeof in the RDFa but it
> >>>>> parses differently; while WebPage is quite an uninformative type, it
> >>>>> has a few subtypes (http://schema.org/WebPage) that might be useful.
> >>>>>
> >>>>> As part of this, here's a one liner proposal for a "Breadcrumb" type,
> >>>>> which would be used here in place of the initial ItemList:
> >>>>>
> >>>>> http://schema.org/BreadcrumbList: "A BreadcrumbList is an ItemList
> >>>>> consisting of a list of Web pages, typically described using at least
> >>>>> their URL and their name."
> >>>>>
> >>>>> (This would replace/obsolete the existing unused
> >>>>> http://schema.org/breadcrumb property)
> >>>>>
> >>>>> The examples below work with the ItemList design recently agreed here
> >>>>> directly:
> >>>>>
> >>>>> RDFa 1.1:
> >>>>>
> >>>>> <ol vocab="http://schema.org/" typeof="ItemList">
> >>>>>  <li property="itemListElement" typeof="ListItem">
> >>>>>    <a property="item" typeof="WebPage"
> >>>>> href="https://example.com/dresses"><span
> >>>>> property="name">Dresses</span></a>
> >>>>>      <meta property="position" content="1">
> >>>>>  </li>
> >>>>> › <li property="itemListElement" typeof="ListItem">
> >>>>>    <a property="item" typeof="WebPage"
> >>>>> href="https://example.com/dresses/real"><span property="name">Real
> >>>>> Dresses</span></a>
> >>>>>    <meta property="position" content="2">
> >>>>>  </li>
> >>>>> </ol>
> >>>>>
> >>>>>
> >>>>> Microdata:
> >>>>>
> >>>>> <ol itemscope itemtype="http://schema.org/ItemList">
> >>>>>  <li itemprop="itemListElement" itemscope
> >>>>> itemtype="http://schema.org/ListItem">
> >>>>>    <a itemprop="item" href="https://example.com/dresses"><span
> >>>>> itemprop="name">Dresses</span></a>
> >>>>>    <meta itemprop="position" content="1" />
> >>>>>  </li>
> >>>>> › <li itemprop="itemListElement" itemscope
> >>>>> itemtype="http://schema.org/ListItem">
> >>>>>    <a itemprop="item" href="https://example.com/dresses/real"><span
> >>>>> itemprop="name">Real Dresses</span></a>
> >>>>>    <meta itemprop="position" content="2" />
> >>>>>  </li>
> >>>>> </ol>
> >>>>>
> >>>>> JSON-LD:
> >>>>>
> >>>>> {
> >>>>> "@context": "http://schema.org",
> >>>>> "@type": "ItemList",
> >>>>> "itemListElement":
> >>>>> [
> >>>>>  {
> >>>>>   "@type": "ListItem",
> >>>>>   "position": 1,
> >>>>>   "item":
> >>>>>   {
> >>>>>    "@id": "https://example.com/dresses",
> >>>>>    "name": "Dresses"
> >>>>>    }
> >>>>>  },
> >>>>>  {
> >>>>>   "@type": "ListItem",
> >>>>>  "position": 2,
> >>>>>  "item":
> >>>>>   {
> >>>>>     "@id": "https://example.com/dresses/real",
> >>>>>     "name": "Real Dresses"
> >>>>>   }
> >>>>>  }
> >>>>> ]
> >>>>> }
> >>>>>
> >>>>
> >>>
> >>>
> >>
> >
>
>
>
> Best wishes / Mit freundlichen Grüßen
>
> Martin Hepp
>
> -------------------------------------------------------
> martin hepp
> e-business & web science research group
> universitaet der bundeswehr muenchen
>
> e-mail:  martin.hepp@unibw.de
> phone:   +49-(0)89-6004-4217
> fax:     +49-(0)89-6004-4620
> www:     http://www.unibw.de/ebusiness/ (group)
>          http://www.heppnetz.de/ (personal)
> skype:   mfhepp
> twitter: mfhepp
>
> Check out GoodRelations for E-Commerce on the Web of Linked Data!
> =================================================================
> * Project Main Page: http://purl.org/goodrelations/
>
>
>
>
>
Received on Saturday, 20 September 2014 16:46:52 UTC

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