Re: ItemList examples

Would this work?

1. Introduce ListItemRole as a subtype of Role. It would add the extra
metadata we want (position, next, previous, positionBasis) and be usable on
any attribute following our usual role conventions. No need for a
containing ItemList, for use cases like an album's tracks or a
competition's winners, where the list isn't a standalone entity.

2. For types of lists that are standalone top-level entities, like a Top 10
Sushi Restaurants list, use ItemList with an 'item' property that expects a
Thing or ListItemRole. (The 'item' property would then be repeated within
the ListItemRole, per our usual role convention; itemListElement would be
deprecated.)

Justin

On Wed Aug 06 2014 at 1:11:34 PM Jason Douglas <jasondouglas@google.com>
wrote:

> My complaint about using ItemList for collections has always been that it
> is a sublcass of CreativeWork.  (check the archives! ;-)
>
> Perhaps we can kill two birds with one stone and break that inheritance
> and come up with a new type that is a subclass of both ItemList and
> CreativeWork and has a property called "listEntry" or some such.
>  EditorialList, ContentList, ?
>
> On Wed Aug 06 2014 at 9:08:08 AM Vicki Tardif Holland <vtardif@google.com>
> wrote:
>
>> To forward this discussion, I have updated the original document. (Link
>> again below.) Please forgive the length, as showing the differences doubled
>> the length.
>>
>> I like the role-like syntax. The only issue I have is how to model a list
>> that is an entity in its own right. In the example document, the "Billboard
>> Top 200" is the clearest example. The list is not hanging off of a
>> property. It is a creative work in its own right.
>>
>> In the examples, I used the "about" property from CreativeWork. I don't
>> particularly like that, but could not come up with a better property off
>> the top of my head.
>>
>> As always, comments are welcome here or on that document.
>>
>>
>> https://docs.google.com/document/d/1WIQvnaAWCdcPn3AouznLELbLCcHqkGlttYREChVFycc/edit?usp=sharing
>>
>> - Vicki
>>
>>
>>
>> Vicki Tardif Holland | Ontologist | vtardif@google.com
>>
>>
>>
>> On Tue, Aug 5, 2014 at 1:22 PM, Jason Douglas <jasondouglas@google.com>
>> wrote:
>>
>>> >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
>>>> >>
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>