Differentiate between different types of feeds

[nickevansuk]

Ensure that the feeds are described with enough detail for them to be automatically identified, using the metadata below for example:

https://github.com/openactive/data-models/blob/master/versions/2.x/meta.json#L9

Specifically consider how feeds of "CourseInstanceSubEvent" and "HeadlineEventSubEvent" can be differentiated in the metadata, when they both contain items of type "Event". Perhaps using the "identifier" in the above meta.json as the "kind", and including the "kind" also in the Dataset Site metadata?

Visual description of type hierarchy for current OpenActive Modelling specification:

[thill-odi]

Discussion on the W3C call of 2020-09-09 got into the weeds of the degree of specificity required (just parent/child? Supertypes? Child types?) and how validation would proceed. Agreed to refrain from specifying until more information about use cases was available.

[nickevansuk]

Also noting that the parent/child distinction is currently hard-coded into test suite:

https://github.com/openactive/openactive-test-suite/blob/3a92d5759ff2acb941846a166dc6031d8fc03555/packages/openactive-broker-microservice/app.js#L1171-L1179

  const isParentFeed = {
    'https://openactive.io/SessionSeries': true,
    'https://openactive.io/FacilityUse': true,
    'https://openactive.io/IndividualFacilityUse': true,
    'https://openactive.io/ScheduledSession': false,
    'https://openactive.io/Slot': false,
    'https://schema.org/Event': false,
    'https://schema.org/OnDemandEvent': false,
  };

The logic above does not extend well to Courses if they exist in split feeds.

It would seem like defining a strict set of permissible feed configurations (perhaps based on this page) would be helpful here - potentially as an enum (to which beta values can later be added?)?

This would allow the test suite to validate that the configuration encountered is one of the valid configurations, and that the data within matches the expected model.

Rationalising this would also help data users more generally, as it makes the requirements for a harvesting application well-defined. Additionally a the feed configurations of a particular publisher could then be easily displayed in e.g. status.openactive.io, which allows a data user to understand which feeds they will likely be able to consume given a particular harvesting implementation.

This would also allow for e.g. the auto-generation of swagger documents for RPDE endpoints, that could be included in the dataset site