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

[ldodds]

Rather than create new terms, I'd prefer to keep the data model aligned with SKOS (and use skos:Collection) and separately handle any clashes in namespaces using other approaches.

Potential namespace clashes in the design of the Opportunity API is really an issue for that API rather than the core model. One approach is to simply alias the relevant terms in our JSON-LD context. This means we remain aligned with the vocabulary, but don't necessarily have to use the same terms in the API responses. The clashes are only an issue for applications that don't process the context, so aliases is the simplest option there.

For example, we could simple alias Hydra Collections as "SearchResults" in our JSON-LD context for the opportunity API:

E.g. a

{
 "SearchResults": "https://www.w3.org/ns/hydra/core#Collection"
}

We're already partly relying on this type of feature with how concepts is declared in the current context.

[nickevansuk]

Ok great, so just to confirm for the modelling spec (which is the bit we need to sort now), can we alias as follows:

{
 "ConceptCollection": "skos:Collection"
}

instead of:

{
 "Collection": "skos:Collection"
}

That way we avoid having generic aliases ("Collection") in our namespace, and the example in this proposal still holds?

I'd suggest SKOS Collections is something we need to solve for modelling spec (for publishing and referencing Collections) rather than for the Opportunity API specifically

[ldodds]

I wasn't proposing that we change the modelling spec at all. I don't see any current issue with the term "Collection". It's only going to appear in the full activity list anyway.

[nickevansuk]

Won't it have to appear any time a collection is referenced? Which in the future includes all APIs, feeds, etc?

Or do you mean we should have "Collection" always mean "skos:Collection" and any other Collection-ish things will need to be named more specifically?

I guess I was thinking that if ever SKOS terms did make it into schema.org then "skos:Collection" would probably not be called "Collection" as that's too broad, so shouldn't we think the same way when bringing terms into the OpenActive model?

Same reason we've gone with "FemaleOnly" instead of "Female" for genderRestriction