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

Re: ItemList examples

From: Wallis,Richard <Richard.Wallis@oclc.org>
Date: Thu, 7 Aug 2014 14:27:11 +0000
To: Markus Lanthaler <markus.lanthaler@gmx.net>
CC: "<public-vocabs@w3.org>" <public-vocabs@w3.org>
Message-ID: <43BDD7D4-04BE-47F9-B6CA-339D97EBAB67@oclc.org>
Firstly just a bit of background on why the name Collection was chosen in the Collection proposal from SchemaBibExtend.

Collection has specific meaning in the world of libraries museums galleries, and the wider world  - there are many folks sporting the title Collection Manager.  All the books in a library is referred to as the library’s collection, museums, and galleries curate and manage their collections. - There is the Getty Collection, the National Numismatic Collection in the Smithsonian, contains over 450,00 coins and medals - I could go on but i won’t…

Naming is obviously important but secondary in my mind to us being able to satisfy 4 separate but connected needs around this to describe:

  1.  A grouping of things, with no particular ordering implied, the minimum connection between those things being that they members of the group.  Such membership not preventing them being members of other groupings.

  2.  A grouping of things in which some form of ordering is applied, numerical, alphabetical, order of insertion, or even on the whim of the person or application that defines the group.  In my world I would call this a list, but as I say naming is secondary.

  3.  A grouping functionally the same as 1. but a subtype of CreativeWork so that the creative efforts in producing it can be described.

  4.  A grouping functionally the same as 2.. but a subtype of CreativeWork so that the creative efforts in producing it can be described.

Beyond these four basic needs, there needs to be some utilities, mostly for members of the ordered examples, to identify first, last, next previous, and possibly sub-groupings (pages).  This last capability could be achieved by describing an ordered grouping the member of which are themselves ordered groupings for page1, 2, etc. or perhaps ‘A-M’, ’N-Z’.

I have deliberately have avoided using terms such as collection, list, item etc. to separate out the names from the functionality.  However in retrospect ‘Group’ could be a possible name for a collection of unordered things.


On 7 Aug 2014, at 05:37, Markus Lanthaler <markus.lanthaler@gmx.net<mailto:markus.lanthaler@gmx.net>> wrote:

On 7 Aug 2014 at 10:09, Dan Brickley wrote:
On 7 August 2014 04:42, Gregg Kellogg wrote:
On Aug 6, 2014, at 7:49 PM, Jason Douglas wrote:

I suppose the backward-compatible way to do it would be to:

Create a new type (Collection?)
Change the domain of the structural properties of ItemList to Collection
Make ItemList inherit from Collection as well as CreativeWork

That leaves ItemLiist as the editorial thing, so all existing markup would
still be semantically unchanged.

That's where I ended up - but it feels backwards. Note that
"Collection" is being proposed by the bibextend folk for the editorial
thing: http://www.w3.org/community/schemabibex/wiki/Collection#New_Type:_Collection

"This is a collection in the broadest and simplest possible sense. It is
a set of CreativeWorks or Things. The things in a collection may be
thought of as its "parts", even though the membership could be
ephemeral. The defining of a Collection, by bringing, identifying, or
linking together a collection of things, is considered to be a creative
act, hence a Collection is a more specific type of CreativeWork."

I think Collection makes a lot of sense. To me, ItemList sounds like a
curated list, whereas Collection sounds like a basic grouping.

My intuitions run the other way. Collection slightly emphasises the
act of bringing together, ItemList sounds like a made up data
structure word.

What about simply using List?

I'm still a bit on the fence whether it is really a good idea to use the Role design for such a basic data structure. Do we plan to add (Item)List to the range resp. support it as value of just about every property?

In Hydra (which also has to work with vocabularies that might use rdfs:range and would thus break such a design) we solved this by introducing an explicit indirection and describing what relationship the collection manages; similar to hasRole that was discussed a while ago. So, Greggs example

   "@context": "http://schema.org",
   "@type": "SportsEvent",
   "@id": "/world-series/2013",
   "name": "2013 World Series",

   "subEvent": {
     "@id": "/world-series/2013/subEvents",
     "@type"; "ItemList"

would instead be expressed as

   "@context": "http://schema.org",
   "@type": "SportsEvent",
   "@id": "/world-series/2013",
   "name": "2013 World Series",

   "collection": {
     "@id": "/world-series/2013/subEvents",
     "@type"; "Collection",
     "manages": { "subject": "/world-series/2013", "property": "subEvent" }

The list items at /world-series/2013/subEvents then also express their relationship to /world-series/2013 explicitly instead of depending on some sort of inference.

Btw. none of the new Role types have been added to any range so far making them very difficult to discover IMO. Are there plans to change that?

Markus Lanthaler
Received on Thursday, 7 August 2014 14:27:43 UTC

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