Additional properties in RPDE response

[nickevansuk]

From @ldodds "There are now three optional properties for feeds which indicate version number of specifications in use, and the types of entity included in a feed. Details can be found in the table here:
https://www.openactive.io/realtime-paged-data-exchange/EditorsDraft/#response-grammar"

[nickevansuk]

Some thoughts on each property

version

• Note that this is currently present in the metadata of each of the dataset pages as a machine-readable dct:format (see source code http://data.bookwhen.com/). Given that it's in the metadata already, and given that we are not proposing any breaking changes to the spec at this stage, does it need to also appear in the feed, or is sufficient just to update the metadata?
• If we did want to include this in the feed itself, suggest the "version" property should be a URI that links to the version of the RPDE spec that's being used.

opportunityModelVersion

• Should this also be included in the metadata as above, and does that make it redundant in the feed?
• If we did include it in the feed, should we use a simple "model" property as the URI of the model in use, which points to the URI of the spec including version.

feedObjects naming

• We don't use the language of "feed" or "objects" elsewhere in the spec. Following schema.org language should this be type instead?
• So the new property becomes "type" or "itemType" and can include an array or string of the type of item included. I suspect we'll move towards single-type feeds over time, as has been the trend to date.

feedObjects too early?

• Should this be an adaptation of the "kind" property? I.e. the "kind" could be specified at the request level rather than the item level?
• Another thought on this contrary to the above: is schema.org types really what we want to be using here to describe this. The current "kind" property is more open to use to differenitate e.g. "facility", "league", "course" (it's more about "tagging" data rather than specifying exact types we don't yet know what useful classifications will be here). As "http://schema.org/Event" can represent an number of things, perhaps it's too broad to be useful here?

[ldodds]

re: version of spec in dataset metadata, that metadata is not discoverable from the feed itself. The RPDE spec also doesn't indicate that dataset level metadata should be published. So I don't think its redundant to include the version of the spec in the feed itself.

Using URIs versus version numbers seems like a good idea, happy to make that change.

Also happy to use a general model or dataModel property to identify the model of the data.

But I think a consumer might reasonably want to know what type of thing it should be harvesting so something like feedObjects (or similar named property) is necessary.

As I commented in #84 I think kind should be re-thought. A list of types at the feed level, and a requirement to have a type property (of some form) in the data achieves the same goal. Schema.org is serving us well elsewhere, so I'd feel comfortable about recommending it's use here.