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

Re: ItemList examples

From: Dan Brickley <danbri@google.com>
Date: Wed, 6 Aug 2014 21:26:43 +0100
Message-ID: <CAK-qy=4nZYkedPqHuYgBAFEgMCDUbS_X429_6rXKWrV3hEzmSw@mail.gmail.com>
To: Jason Douglas <jasondouglas@google.com>
Cc: Vicki Tardif Holland <vtardif@google.com>, Gregg Kellogg <gregg@greggkellogg.net>, Adrian Giurca <giurca@tu-cottbus.de>, W3C Web Schemas Task Force <public-vocabs@w3.org>
On 6 August 2014 18:09, 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, ?

I had a look into this last time you mentioned it. I agree that there
is a need for something that's a pure data structure, and something
else that carries the CreativeWork aspect. Are we OK with changing the
meaning of ItemList out from under the feet of existing publishers? As
far as I could see it was mostly used with Thing-properties, but there
were some sites using 'about', 'author' properties.

I'm quite liking the Role-like idiom. If we're going to use it for
Role, it probably makes sense here too.

Dan

> 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
>>>> >>
>>>> >
>>>> >
>>>>
>>>>
>>
>
Received on Wednesday, 6 August 2014 20:27:11 UTC

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