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

Re: ItemList examples

From: Jason Douglas <jasondouglas@google.com>
Date: Tue, 05 Aug 2014 17:22:38 +0000
Message-ID: <CAEiKvUATty-BgZcGjzN9=2epDEBYkSD8ovhsGLauCkBCNVgtsA@mail.gmail.com>
To: Gregg Kellogg <gregg@greggkellogg.net>, Adrian Giurca <giurca@tu-cottbus.de>
Cc: Dan Brickley <danbri@google.com>, W3C Web Schemas Task Force <public-vocabs@w3.org>
>It might be even more useful if the individual items used the same
property as refers to the list,
>rather than "item"; this would make the rules more like the Role class,
where the property referring
>to the Role is also used within the Role.

+1

On Tue Aug 05 2014 at 10:20:17 AM Gregg Kellogg <gregg@greggkellogg.net>
wrote:

> On Aug 4, 2014, at 11:25 PM, Adrian Giurca <giurca@tu-cottbus.de> wrote:
>
> > itemPosition would not be the best solution as  JSON array is an ordered
> collection  and  JSON-LD is a flavour of JSON.  Add "unordered":"true" to
> catch order-irrelevant arrays.
>
> In this case, the JSON-LD could define itemListElement to have a list
> container ("@container": "@list"), and that would explicitly provide an
> order to those elements. Similarly, @inlist could be used with RDFa.
> Microdata has no syntax for describing ordered values, although the
> Microdata Registry could define itemListElement to be ordered (or an alias
> of this property). Unfortunately, I don't believe that such ordering is
> honored in the schema.org model, but I think that would be worth
> exploring.
>
> Another thing absent from this proposal is some way of dealing with
> external enumerations. It might be useful to consider a use case where the
> value of a property was a URL identifying such an external list. For
> example, looking at the Sports Event Series, which could potentially be
> quite large:
>
> {
>   "@context": "http://schema.org",
>   "@type": "SportsEvent",
>   "@id": "/world-series/2013",
>   "name": "2013 World Series",
>   "subEvent": {
>     "@id": "/world-seriece/2013/subEvents",
>     "@type"; "ItemList"
>   }
> }
>
> Then the list could be found through indirection:
>
> {
>   "@context": "http://schema.org",
>   "@type": "ItemList",
>   "@id": "/world-series/2013/subEvents",
>   "itemListElement": [{
>     "@type": "ListItem",
>     "itemPosition": "1",
>     "item": {
>       "@type": "SportsEvent",
>       "@id": "http://mlb.com/ws2013gl",
>       "name": "2013 World Series - Game One"
>     }, {
>       ...
>     }]
> }
>
> It might be even more useful if the individual items used the same
> property as refers to the list, rather than "item"; this would make the
> rules more like the Role class, where the property referring to the Role is
> also used within the Role.
>
> Lastly, very large lists might need to be paginated, but that could be
> left for some follow-on proposal.
>
> Gregg
>
> > All the best,
> > -Adrian
> > On 8/4/2014 6:10 PM, Dan Brickley wrote:
> >> Just a quick note to share an in-progress document towards improving
> >> the ItemList type. Many thanks to Vicki and Jason for taking a lead on
> >> this.
> >>
> >> https://docs.google.com/a/google.com/document/d/
> 1WIQvnaAWCdcPn3AouznLELbLCcHqkGlttYREChVFycc/edit#
> >>
> >> For now it's shared a public google doc. We can export HTML later, but
> >> if anyone has trouble with it in this form please let me know.
> >>
> >> The idea is to collect together and review various ItemList-related
> >> scenarios across schema.org, to get an overview for possible
> >> improvements to ItemList. There are also machine readable schemas in a
> >> github branch (https://github.com/danbri/schemaorg/tree/sdo-itemlist/
> data)
> >> that correspond to recent proposals discussed here.
> >>
> >> cheers,
> >>
> >> Dan
> >>
> >
> >
>
>
>
Received on Tuesday, 5 August 2014 17:23:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:49:34 UTC