Data model for 'Collecties' data

[sdevalk]

@wouteraj As discussed during our meeting, last Tuesday:

We are working on a data model for the 'Collecties' data of SolidCBS. We use NDE's Requirements for Datasets for this. These requirements describe the model and the rules to which datasets must adhere (it applies to all datasets in our network, not just to those of SolidCBS). The model uses Schema.org as vocabulary. The model is intended for publishing data (for use by others), not specifically for storing data in a collection management system, such as SolidCBS.

The model consists of four types of resources: an 'Organization' (the heritage institution that uses SolidCBS), a 'Data Catalog' (for grouping the datasets of the institution), a 'Dataset' (a 'Collectie') and a 'Distribution' (to get the actual RDF data of the 'Objecten' in the 'Collectie').

Applied to the 'Heemkundevereniging Het Lage Land' in SolidCBS, with fictional data, the model could look like this (in Turtle):

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix schema: <http://schema.org/> .

# Based upon https://netwerk-digitaal-erfgoed.github.io/requirements-datasets/

<https://data.hetlageland.org/>
    rdf:type schema:Organization ;
    schema:name "Heemkundevereniging Het Lage Land" ;
    schema:alternateName "Het Lage Land" . # Optional

<https://data.hetlageland.org/catalog>
    rdf:type schema:DataCatalog ;
    schema:name "Datacatalogus van Heemkundevereniging Het Lage Land"@nl ;
    schema:description "Datacatalogus met datasets, beschikbaar gesteld door Heemkundevereniging Het Lage Land"@nl ; # Optional
    schema:publisher <https://data.hetlageland.org/> ;
    schema:dataset <https://data.hetlageland.org/datasets/1234> . # 0, 1 or more

<https://data.hetlageland.org/datasets/1234>
    rdf:type schema:Dataset ;
    schema:name "Dataset met topstukken"@nl ;
    schema:description "Dataset met de beschrijvingen van het mooiste beeldmateriaal in onze collectie"@nl ; # Optional
    schema:license <https://creativecommons.org/publicdomain/zero/1.0/deed.nl> ;
    schema:creator <https://data.hetlageland.org/> ;
    schema:publisher <https://data.hetlageland.org/> ;
    schema:dateCreated "2021-04-26" ;
    schema:datePublished "2021-04-26" ; # For now: same as 'schema:dateCreated'
    schema:dateModified "2021-05-07" ;
    schema:includedInDataCatalog <https://data.hetlageland.org/catalog> ;
    schema:distribution <https://data.hetlageland.org/distributions/1234>, <https://data.hetlageland.org/distributions/5678> .  # 0, 1 or more

<https://data.hetlageland.org/distributions/1234>
    rdf:type schema:DataDownload ;
    schema:encodingFormat "text/turtle" ;
    schema:contentUrl <https://data.hetlageland.org/dumps/1234.ttl> ;
    schema:license <https://creativecommons.org/publicdomain/zero/1.0/deed.nl> ; # License of the dataset
    schema:datePublished "2021-04-26" ;
    schema:dateModified "2021-05-07" .

<https://data.hetlageland.org/distributions/5678>
    rdf:type schema:DataDownload ;
    schema:encodingFormat "application/n-triples" ;
    schema:contentUrl <https://data.hetlageland.org/dumps/5678.nt> ;
    schema:license <https://creativecommons.org/publicdomain/zero/1.0/deed.nl> ; # License of the dataset
    schema:datePublished "2021-04-26" ;
    schema:dateModified "2021-05-07" .

What do you think? Can SolidCBS support such a model?

@ddeboer @EnnoMeijers @pietervaneverdingen: feel free to comment!

[ddeboer]

@sdevalk Looks good to me!

    schema:datePublished "2021-04-26" ; # For now: same as 'schema:dateCreated'

Perhaps this could be null to indicate that the dataset has not been published (yet).

@digita-ai/nde Sjors already linked to the Requirements for datasets, see § 5 Tools for a link to the SHACL shapes graph that can be used to validate a dataset’s conformance to the NDE standard.

[lem-onade]

Just checking to see if I understand correctly:

The schema:distribution URIs represent the URIs of 'Objecten' associated with the collection.

In the 'Objecten' example, <https://data.hetlageland.org/heritage-objects/1234> is used as URI. Assuming that object is associated with a certain collection, that collection would include the following triple:

schema:distribution <https://data.hetlageland.org/heritage-objects/1234> ;

Is this correct? @sdevalk @ddeboer

[ddeboer]

Hi @lem-onade! No, that’s incorrect. A distribution is a URL at which the dataset can be accessed, so SPARQL endpoints, TTL downloads etc; see https://netwerk-digitaal-erfgoed.github.io/requirements-datasets/#dataset-distributions.

The link between dataset (collection) and the objects contained in it, which is what you’re asking about, would be schema:hasPart (inversely, schema:isPartOf).

[lem-onade]

Right. schema:hasPart in collections, schema:isPartOf in objects. Could you update the original message to include this triple?

[ddeboer]

@sdevalk #163 already has the relation <object> schema:isPartOf <dataset>. Do you agree we should add an explicit inverse relation <dataset> schema:hasPart <object>?

[sdevalk]

Yes, this makes sense.

One question, though: could SolidCBS use a 'distribution' file to get the objects in a dataset, by fetching the RDF in schema:contentUrl? That file contains all URIs of all objects in the dataset. Or do you need to know the object URIs before querying that file?

Thinking out loud: if we add schema:hasPart to the datasets in the 'datasets' file, the object URIs would have to be maintained in two files: the 'datasets' file and the 'distribution' file of a specific dataset.

[lem-onade]

I thought about it for a while and we might be fine without it. No need to change the model for now.

I'll update if I encounter a specific reason for needing both triples.

[ddeboer]

What is the use case, exactly? A sounds better.

[lem-onade]

An object needs an inbox, for metadata update notifications (borrowing institution made changes to that object).
These inboxes are registered on a resource and I believe it will be easier to create a separate resource per object (with a separate inbox linked to that resource).

[lem-onade]

So keeping track of these objects in a collection will be more complex. Was a single resource, will now be multiple.

[lem-onade]

Hiding this conversation as it is no longer relevant. Objects from the same collection are still stored in a single resource.