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

Re: ItemList proposal

From: Jarno van Driel <jarnovandriel@gmail.com>
Date: Fri, 12 Sep 2014 21:27:52 +0200
Message-ID: <CADK2AU185mH3M39Sb=4uxj9G3-y2DCFr_0ZZ-s3_eB54r_2Jeg@mail.gmail.com>
To: Dan Brickley <danbri@google.com>
Cc: Vicki Tardif Holland <vtardif@google.com>, Martin Hepp <martin.hepp@unibw.de>, Peter Mika <pmika@yahoo-inc.com>, "Jason Johnson (BING)" <jasjoh@microsoft.com>, PublicVocabs <public-vocabs@w3.org>
"There are situations (e.g. pagination) where you might want to distinguish
between a partial description of the list and the full thing as spread over
several concrete documents."

Well, it's this I'm doubting actually. Search engines don't rely on there
being a 'start/last/end' being specified for HTML. The start is implied
because there's no 'prev' and the end is implied when there's no 'next'.
And they seem to be quite able to understand where the pagination starts
and ends.

Why would this have to be more specific for schema.org?

2014-09-12 20:58 GMT+02:00 Dan Brickley <danbri@google.com>:

> On 12 September 2014 19:52, Jarno van Driel <jarnovandriel@gmail.com>
> wrote:
> > "I think it's useful to have a way to explicitly indicate the end of the
> > list. Information on the Web may be lost or corrupted in all kinds of
> ways,
> > so we can't always rely on the fact that missing information is
> > significative."
> >
> > Although it may seem nice to be able to express there is no previousItem
> > (start) or nextItem (end) I wonder if it actually will be used. Both
> HTML4
> > and 5 have those attributes as well but in all honesty I never encounter
> > them. Rel="next/prev" sure but only because Google recommends it for
> > pagination but there's no mention for using rel="start/last/end", and yet
> > they do seem to be able to understand a series of documents.
> >
> > Now imagine the majority of webmasters don't use 'False' does that then
> mean
> > parsers/reasoners don't understand where a list starts or ends? Somehow I
> > doubt that. So personally I'm not convinced there's much to be gained by
> > adding specifying a False, simply because I don't see webmasters/devs
> > deploying it.
>
> There are situations (e.g. pagination) where you might want to
> distinguish between a partial description of the list and the full
> thing as spread over several concrete documents.
>
> But I agree that in many cases this will be overkill. We should
> probably say something like "In situations where it is important to
> indicate that there is no 'next' item in the list, 'next: False' can
> be used".
>
> Dan
> >
> >
> >
> > 2014-09-12 19:17 GMT+02:00 Vicki Tardif Holland <vtardif@google.com>:
> >>
> >> schema:False works for me.
> >>
> >> - Vicki
> >>
> >> Vicki Tardif Holland | Ontologist | vtardif@google.com
> >>
> >>
> >> On Fri, Sep 12, 2014 at 1:12 PM, Martin Hepp <martin.hepp@unibw.de>
> wrote:
> >>>
> >>> What about simply using schema:False, which exists? Otherwise I
> suggest a
> >>> new, generic element schema:Null, which we will need in future
> DB-related
> >>> use-cases anyway.
> >>> Martin
> >>>
> >>> ---------------------------------------
> >>> martin hepp
> >>> www:  http://www.heppnetz.de/
> >>> email: mhepp@computer.org
> >>>
> >>>
> >>> On 12.09.2014, at 18:58, Vicki Tardif Holland <vtardif@google.com>
> wrote:
> >>>
> >>>
> >>> On Fri, Sep 12, 2014 at 10:07 AM, Peter Mika <pmika@yahoo-inc.com>
> wrote:
> >>>>
> >>>> think it's useful to have a way to explicitly indicate the end of the
> >>>> list. Information on the Web may be lost or corrupted in all kinds of
> ways,
> >>>> so we can't always rely on the fact that missing information is
> >>>> significative
> >>>
> >>>
> >>> In that case, I would suggest a special value like
> >>> http://schema.org/ItemListEnd so authors don't have to create a Thing
> just
> >>> to say it is NULL.
> >>>
> >>> - Vicki
> >>>
> >>>
> >>> Vicki Tardif Holland | Ontologist | vtardif@google.com
> >>>
> >>
> >>
> >
>
Received on Friday, 12 September 2014 19:28:20 UTC

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