Re: Series

On Fri, Jun 13, 2014 at 9:57 AM, Dan Scott <> wrote:

> On Fri, Jun 13, 2014 at 01:31:51PM +0000, Wallis,Richard wrote:
>> We could create Series as an Intangible base Type that could be used in
>> combination with CreativeWork, Event etc. to produce the relevant series
>> Type we are suggesting.
> Perhaps a more generic Series would use something like "seriesMember" (new
> property) and "partOfSeries" (with a genericized, non-media-specific
> definition) or "isPartOf" (with a range made even broader than
> CreativeWork)?

This discussion and the ItemList related work seem to be growing together,
or at least to be pointing their way towards some common abstraction.

*Aggregations: *

There is a need to represent some kinds of Things that have other Things as

   - Class (schema:Class <> , Cyc #$Collection
   <>) :
    Aggregations whose members are defined by description (inten*s*ionally).
    Two Classes that have the same members are not necessarily the same thing.
   For example, the class Unicorn is not the same as the class Pegasus, even
   though they have the same (0) members.
   - Group:  (Cyc #$Group
   <>) :
   Aggregations whose members are stated explicitly.  There need be no
   ordering between group members, and the membership need not be constant
   over time.
   - Series (Cyc #$Series
   <>) :  A group
   whose members are ordered by some total ordering.   A series of
   <> is a


All of these aggregations are Things, which means that they can have an
identity; they can have names, descriptions ,etc.

Groups need a property to specify members.

Some Groups may only admit certain types of things as members;  this
 expectation could be stated by  a member type property to group
definition. This could simplify the schema:member confusion, and maps
neatly to microdata, OWL, and Cyc. It could also be used to simplify the
generated documentation (cf.

Series whose members do not carry the information needed to calculate the
desired ordering may require a property to carry this ordering. This
property could be domain Thing; however, since the same individual might
have different orderings in different Series, it is better to use something
similar to ListItem.

Note that ListItem has some possibly overly strong semantics; itemPosition
*is* sufficient to specify the ordering, but it may not be *necessary.*
For example one might want to mark up the results of an event where many
people achieved the same score and rank;  if three people tied for first
place, one might want to give each of them the same rank;  itemPosition
does not appear to allow for this situation - it appears to impose a
*strict* total order.

ListItem also lacks any direct way to specify the series of which it is a

It may be possible to create some simple abstractions that simplify several
existing issues.


Received on Friday, 13 June 2014 17:03:30 UTC