How to relate events to datasets

[saumier]

Modelling question

What property should be used to link an event to the dataset it is a part of?

Competency question: What dataset is this Event part of?

Use Cases:

1. IPAA datafeed for the Indigenous calendar of events on their website. This data feed (iCal or JSON-LD) combines events with indigenous agents (included in Wikidata) across all of the Artdata feeds and Artsdata core. It also includes indigenous events (included in Footlight CMS indigenous calendar). In order to know which events to include and prioritize, it must be possible to check the source dataset of events.
2. Provenance tracking for Artsdata core triples. Each triple in Artsdata core has metadata about its provenance. This is usually linked with prov:wasDerivedFrom or prov:hadPrimiarySource to the most precise entity in the source dataset. For example, an event has a title that was derived from an external event in an external dataset. The derivedFrom links to the external event. The external event needs to be linked to the external dataset that it is part of. The Artsdata core should include the link between the external event and the dataset it was part of. This is critical to be able to follow provenance all the way to the dataset which can be a website, API, Wikidata, DBPedia, etc. In most cases for website sources, the external dataset gets updated with new events and does not maintain past events, so it is not reliable over time to count on the external dataset for dataset provenance of events. The relationship between the external event and its graph should be preserved in Artsdata core.
3. The ability to follow links in Artsdata (Nebula) to discover external (non-authoritative) events in a data feed graph. Currently there is no triple that expresses the relationship between an event and the graph it is in (4th part of a tuple). The work around is to filter triples using SPARQL Graph. Having a triple that assets inclusion in a graph would simplify navigation and queries to data feed graphs.

Background

Artsdata stores many graphs of datasets coming from external data sources (crawling websites/APIs).

The Artsdata core graph is the standardized view of all the datasets. However, sometimes clients that are consuming data from Artsdata want to access data outside the Artsdata core. In the case of the IPAA datafeed, the events included are a combination of Artsdata core events, events not in the core, and all events from the CMS calendar of indigenous events.

Currently the only way to relate events to datasets is to lookup the named graph (4th part of a tuple). This is done by filtering triples using SPARQL GRAPH ?g. However, using this approach does not allow inferencing and can make for complex SPARQL queries. Having a triple that assets inclusion in a graph would simplify navigation and queries. And it would cover cases when an event may have triples in more than one graph (such as an external datasets and the Artsdata core).

Proposals

PROVO

:event1 prov:hadPrimarySource :dataset1 .
:dataset1 a prov:Entity .

Note: There is no notion of derivation. Since prov:hadPrimarySource is a sub-class of prov:wasDerivedFrom then the lack of derivation from another source makes this choice not semantically clear.

DCAT

:event1 dcterms:isPartOf  :dataset1
:dataset1 a dcat:Dataset .

Note: Domain and Range of dcterms:isPartOf is rdfs:Resource. This is quite generic but semantically good.

VOID

:event1 void:inDataset :dataset1 .
:dataset1 a void:Dataset .

Note: Domain of void:inDataset is rdfs:Resource. Range is void:Dataset. This is semantically very precise.

Schema.org

:event1 schema:isPartOf :dataset1  .
:dataset1  a schema:Dataset .

Note: DomainIncludes of schema:isPartOf is schema:CreativeWork. This is not semantically correct because schema:Event is not a sub-type of schema:CreativeWork.

Other Classes

Consider which other classes, such as Person, Place, Organization, should also have a relationship to the graph it is in.

[saumier]

I propose void:inDataset for the following reasons:

1. It is semantically accurate
2. Artsdata already uses the VOID ontology for adding statistics to datafeeds like the number of events, people etc.
3. The datasets are currently all assigned a type schema:Dataset which is defined in schema.org with owl:equivalentClass void:Dataset.

Further more, I propose reviewing additional metadata as recommended in Describing Linked Datasets with the VoID Vocabulary and specifically assigning an additional type to the graph that loads the datasets as in :graph a sd:Graph to further clarify which datasets are graphs loaded into Artsdata.

[fjjulien]

@saumier This sounds generally good and it will work as long as we rank sources at the graph level. But will this solution scale up well when we start ranking individual triples within an Event entity?

[saumier]

@fjjulien The use of void:inDataset will be used to track which external events are part of which graph. It will not be needed for Artsdata core events. In Artsdata core we have a more granular tracking of provenance for each triple (similar to Wikidata). So the core will scale to support ranking individual triples when we add that in future.