ConceptCollection to allow publishing of skos:Collection

[nickevansuk]

Proposer

ODI

Use Case

Representing SKOS collections in JSON-LD, without conflicting with Hydra Collections (which will likely be used in the future for the Opportunity API).

Why is this not covered by existing properties?

The modelling spec does not currently include any provision for describing SKOS collections.

Please provide a link to example data

See example: https://data.emduk.org/collections/strength-and-conditioning.jsonld

Proposal

Include type ConceptCollection in the JSON-LD context as a subclass of both skos:Collection (for SKOS properties) and schema:CreativeWork (for metadata properties).

Based on the Concept Groups (isothes:ConceptGroup) recommendation in this discussion, suggest use of:

• inScheme (skos:inScheme) within ConceptCollection to link a collection to the ConceptScheme it is related to
• prefLabel (skos:prefLabel) to label them (as per discussion about above), which has the advantage of allowing for multiple languages via the same mechanism.
• member (skos:member) to reference the array of IDs of Concept.
• definition (skos:definition) to describe them, instead of schema:description, to be consistent with our current approach to Concept
• publisher (schema:publisher, from schema:CreativeWork) to include the source of the collection
• license (schema:license, from schema:CreativeWork) to include the license under which the collection is published.

Although we could draw from DCAT for metadata elements, as we are already using SKOS for prefLabel instead of dcat:title, it seems a better fit (and more extensible later) to use schema:CreativeWork. Also where a ConceptScheme is a dataset, a ConceptCollection is part of a dataset e.g. it is feasible that a list of ConceptCollections would be returned from an API in the same way as a list of Concepts are - this is less likely to be true of ConceptSchemes which are generally used in their entirety for one implementation (even if multiple ConceptSchemes are in use, they will likely be mapped to a primary ConceptScheme for use in a particular application).

It is also possible for ConceptCollection to simply alias skos:Collection in the JSON-LD, but this does not seem as clean in terms of metadata properties.

Conformance criteria

• If inScheme is provided, all member IDs must be found in the ConceptScheme referenced by inScheme.

Example

{
  "@context": "https://openactive.io/",
  "type": "ConceptCollection",
  "id": "https://data.emduk.org/collections/strength-and-conditioning.jsonld",
  "prefLabel": "Strength and Conditioning",
  "definition": "Group Exercise and Dance classes considered good for Strength and Conditioning.",
  "publisher": {
    "type": "Organization",
    "name": "Better",
    "description": "A charitable social enterprise for all the community",
    "url": "https://www.better.org.uk"
  },
  "inScheme": "https://openactive.io/activity-list",
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "member": [
    "https://openactive.io/activity-list#a71d477f-7263-43d7-8d17-3d69bda8991b"
  ]
}

Beta property

Class	subClass	Description
beta:ConceptCollection	skos:Collection, schema:CreativeWork	A SKOS Collection for use with SKOS ConceptScheme