RE: How to avoid that collections "break" relationships

On Monday, March 31, 2014 8:35 PM, Sam Goto wrote:
> On Mar 28, 2014, at 5:02 PM, Jason Douglas wrote:
> > [Aside] I appreciate re-using an existing Class, but I think ItemList
> > was intended for a different use case than collections (I've given the
> > same feedback to Sam).  It's a subclass of CreativeWork because it's
> > for "editorialized" lists (top 10 list, playlists, etc.). I think we
> > need something new like an actual Collection class in schema.org
> > 
> > I think a Collection class would be great; it should also allow for
> > pagination. This could be done in the scope of this proposal where
> > specific guidance is given on how to separate entity definitions into
> > collections, so that large numbers of relationships can be effectively
> > managed.
> 
> Just on the record, I understand how ItemList is a hack (because it
> extends CreativeWork), I don't personally mind a brand new Collection
> class.

Yeah, it is a hack, and probably a pretty bad one as it doesn't even preserve the order of the things in that list, at least not in RDFa and JSON-LD.

Anyway, the question is still how such an indirection is intended to be used in schema.org. That was the reason why I cc'ed public-vocabs in the first place but I still haven't got any answer to that question. Will all properties that allow multiple values be changed to include Collection or ItemList in their rangeIncludes? Should this just implicitly be assumed to be the case? Or are they not intended to be used in such a way at all?

It would be really helpful if answers to these questions could be given by the schema.org sponsors.


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 31 March 2014 18:49:10 UTC