- From: Jason Douglas <jasondouglas@google.com>
- Date: Tue, 05 Aug 2014 17:22:38 +0000
- 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>
- Message-ID: <CAEiKvUATty-BgZcGjzN9=2epDEBYkSD8ovhsGLauCkBCNVgtsA@mail.gmail.com>
>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