Re: ItemList examples

+1 for the Role-like idiom also.  (I'm looking forward to the pure data
structure myself and less so for the CreativeWork aspect, but it's cool
also)

and I'm OK with change the meaning of ItemList, not that big a deal I would
say for most publishers.



On Wed, Aug 6, 2014 at 3:26 PM, Dan Brickley <danbri@google.com> wrote:

> 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
> >>>> >>
> >>>> >
> >>>> >
> >>>>
> >>>>
> >>
> >
>
>


-- 
-Thad
+ThadGuidry <https://www.google.com/+ThadGuidry>
Thad on LinkedIn <http://www.linkedin.com/in/thadguidry/>