< Back | Home | Edit page | 🙋 Check for open issues |
Architecture Overview
How data flows in and out of Artsdata.ca.
Detailed sections
- Artsdata.ca Website
- Data Consumers
- Artsdata Data Model & Ontology
- Google Spreadsheets & Data-to-RDF
- Footlight Console
- Databus API
- Minting API
- Query API
- Reconciliation API
- SPARQL Endpoint & Federation
- Artsdata Triplestore
Summary
The Artsdata linked open data ecosystem is divided into 3 areas:
- Data providers
- Artsdata knowledge graph
- Data consumers
Data providers
For data providers, such as arts organizations (producers, presenters, agents, venues) and artists, a range of Extract-Transform-Load (ETL) processes and tools are available:
- JSON-LD scraping;
- Front-end ETL combining JSON-LD scraping and natural language processing;
- ETL via endpoints (APIs, JSON-LD endpoint);
- Google Sheet to Artsdata (a tool to convert spreadsheet information into linked open data);
- Footlight Console (event information management software for a single site);
- Footlight CMS (event information management software for multiple sites);
- Artsdata Load API (Graph-store API) that accepts RDF data meeting all Artsdata data modelling requirements and constraints (SHACL defined in Artsdata.ca or ShEx when coming from Wikidata).
All data submitted to Artsdata.ca requires a user account registered with artsdata.ca.
All data submitted to artsdata.ca is agreed upon by the registered account to be CC0.
Data from each source is loaded into its own graph within Artsdata.ca with provenance metadata including a contact point, contributor names and data related license agreements.
Third-party developers are welcome and can use the Artsdata Databus API to load data.
Artsdata data providers include associations, unions, industry platforms, ticketing services, and individual arts organizations (see the list).
Artsdata knowledge graph (kg.artsdata.ca)
Artsdata aggregates and shares descriptive metadata related to cultural events (and related entities) from/with multiple websites and external databases. Data is published as Linked Open Data with persistent identifiers (i.e. URIs) that can be used to link events to artists, venues and arts organizations.
The Artsdata data model is implemented using classic RDF ontologies. It is a sub-set of Schema.org and maps data to a multitude of other classic (i.e. LRMoo, DBpedia) and non-classic (i.e. Wikidata) ontologies.
Artsdata mints its own Artsdata persistent identifiers (URIs) for named entities when they meet minimal requirements for minting. Registered users can mint an Artsdata URI from a Wikidata URI. Artsdata also uses external URIs (Wikidata, VIAF) for named entities and concepts.
The Artsdata triplestore is a standard (compliant with W3C Standards) RDF triplestore using the “GraphDB Free” product by OntoText.
Data consumers
Data consumers wanting to use the data can access it in a number of ways:
- Browse the knowledge graph interface at kg.artsdata.ca;
- Call the Artsdata Reconciliation API to retrieve persistent identifiers;
- Crawl persistent identifiers to access the associated metadata in JSON-LD format;
- Call the RESTfull Artsdata Query API;
- Subscribe to a custom iCalendar subscription feed;
- Call the Artsdata SPARQL endpoint.;
- Download a data dump of triples serialized in a variety of formats such as JSON-LD or N-Quads.
The data from Artsdata.ca is CC0 and can be used in other applications without any restrictions.
Artsdata data consumers include listing sites, industry platforms, arts service organizations, destination marketing organizations, government bodies and search engines (see the list). For an overview of use cases, check our user stories<–! HYPERLINK TO CORPORATE WEBISTE–>.