Onder de motorkap: linked open data bieden via SPARQL endpoint

Onder de motorkap: linked open data bieden via SPARQL endpoint

22 december 2022 0

De Gouda Tijdmachine gebruikt Omeka S als collectiebeheersysteem. Alhoewel de data er als RDF (in JSON-LD representatie) uit komt en er ook een search API is, kun je standaard geen SPARQL query loslaten op je in Omeka S beheerde semantische data. In dit artikel wordt er gekeken naar een aantal oplossingsrichtingen om linked open data (LOD) via een SPARQL endpoint beschikbaar te maken.

Harvesten van de RDF

De huidige oplossing die de Gouda Tijdmachine gebruikt is het harvesten van alle RDF. Hiervoor is een eenvoudige crawler gemaakt in PHP die de Omeka S API bevraagt en de ontvangen JSON-LD omzet in N-triples (deze representatie is handiger voor de verdere verwerking). Hierna worden via een simpel Bash script alle N-triples verzameld en ontdubbeld waarna het resultaat een gecomprimeerd bestand van alle N-triples is.

Een datadump is mooi, maar hiermee is er nog geen SPARQL-endpoint. Hiervoor is er binnen de infrastructuur van de Gouda Tijdmachine GraphDB ingezet. Nadat de aangemaakte datadump is ingelezen in de triplestore is de data te bevragen via het door GraphDB gerealiseerde open SPARQL-endpoint. GraphDB van Ontotext is gratis te gebruiken, maar niet open source. Een alternatieve oplossing is de open-source Java applicatie Fuseki van Apache Jena.

Het nadeel van deze harvest-oplossing is dat de harvest enige tijd duurt:

Aantal items (resource) in Omeka S van de Gouda Tijdmachine82.849
Duur crawl (van alle items en sub-resources)4:43:52
Duur ontdubbelen en comprimeren0:02:30
Aantal N-triples2.286.076
Duur import0:01:14

Trigger bij create/update(/delete)

Een alternatief scenario zou zijn om alleen nieuwe en gewijzigde triples naar de triplestore te sturen. In het geval van Omeka S zou bij elke wijziging in een item dan een functie getriggerd moeten worden, die GraphDB (alleen) het gewijzigd item laat importeren. Dit is goed mogelijk omdat Omeka S het item in JSON-LD formaat serveert en GraphDB deze via een URL (bijv. https://www.goudatijdmachine.nl/data/api/items/66280) direct kan importeren! Het resultaat is dat de triplestore near-realtime up-to-date is.

NB: een Omeka S module die de hierboven beschreven functionaliteit biedt is er nog niet.

RDB to RDF Mapping

Een andere manier om, realtime, de data uit je relationele (SQL) database te ontsluiten via een SPARQL-endpoint is door de SPARQL query on-the-fly om te zetten naar SQL queries. R2RML: RDB to RDF Mapping Language is hier de relevante W3C recommendation, maar taai. Dit heeft me lang weerhouden om hiermee te experimenteren.

Ontop is een oplossing die goed is te doorgronden, met goede Guide en Tutorial en de SQL database kan ontsluiten via SPARQL! Ontop is beschikbaar via GithubDocker Hub en in de Protégé plugin repository.

Ontop is a Virtual Knowledge Graph system. It exposes the content of arbitrary relational databases as knowledge graphs. These graphs are virtual, which means that data remains in the data sources instead of being moved to another database.

Ontop translates SPARQL queries expressed over the knowledge graphs into SQL queries executed by the relational data sources. It relies on R2RML mapping and can take advantage of lightweight ontologies.

Met behulp van een met Ontop plugin voorziene versie van Protégé heb ik een mapping gemaakt – voor de klasse Straat – waarbij er op basis van een SQL query (de source) de target triples worden gedefinieerd waarin je de resultaten van de SQL query in verwerkt. Hiervoor is ook een ontologie benodigd en een JDBC koppeling met de database. Hieronder een deel van de mapping in Ontops obda formaat:

mappingId	gtm-Straat-1
target		<https://www.goudatijdmachine.nl/data/api/items/{id}> a :Straat ; dcterms:identifier {ark} ; owl:sameAs <{uri}> . 
source		SELECT resource.id, value.value AS ark, CONCAT('https://n2t.net/',value.value) AS uri FROM resource, value WHERE resource.resource_class_id=909 AND resource.id=value.resource_id AND value.property_id=10;

mappingId	gtm-Straat-2
target		<https://www.goudatijdmachine.nl/data/api/items/{resource_id}> skos:altLabel {value} . 
source		SELECT resource_id,value  FROM value,resource WHERE resource.id=value.resource_id AND property_id=1109

mappingId	gtm-Straat-3
target		<https://www.goudatijdmachine.nl/data/api/items/{resource_id}> skos:prefLabel {value} . 
source		SELECT resource_id,value  FROM value,resource WHERE resource.resource_class_id=909 AND resource.id=value.resource_id AND property_id=1108

mappingId	gtm-Straat-4
target		<https://www.goudatijdmachine.nl/data/api/items/{resource_id}> schema:identifier {value} . 
source		SELECT resource_id,value  FROM value,resource WHERE resource.resource_class_id=909 AND resource.id=value.resource_id AND property_id=1082

mappingId	gtm-Straat-5
target		<https://www.goudatijdmachine.nl/data/api/items/{resource_id}> geo:asWKT {value} . 
source		SELECT resource_id,value  FROM value,resource WHERE resource.resource_class_id=909 AND resource.id=value.resource_id AND property_id=1162

Bovenstaande syntax is redelijk makkelijk, in ieder geval een stuk makkelijker dan R2RML. Maar bovenstaande queries verraden al wel, dat je veel kennis van de SQL database moet hebben… Overigens kun je via Ontop de mapping omzetten naar een R2RML versie van het obda bestand!

Ontop is ook een CLI tool waarmee je een datadump (in mijn Straat experiment 34.470 triples) kunt maken, dit is de materialize optie. Maar er wordt ook een SPARQL-endpoint geboden via de endpoint optie, inclusief Yasgui front-end. Simpel weg te starten via:

./ontop endpoint -m goudatijdmachine-mapping.ttl \
                 -t goudatijdmachine.ttl \
                 -p goudatijdmachine.properties \
                 --cors-allowed-origins=*

De performance van het SPARQL endpoint is goed voor de straten-dataset. Voordeel van deze methode is dat je nu je SQL data realtime via SPARQL kunt bevragen.

NB: in GraphDB kun je ook “Ontop Virtual SPARQL” repository maken op basis van de ontologie, mapping en JDBC-koppeling.

Voor Omeka S voelt de RDB to RDF Mapping niet als de juiste oplossing omdat er al RDF uit Omeka S komt (en dit op een complexe wijze is opgeslagen in een SQL database) en de triplestore niet een realtime kopie hoeft te zijn van het collectiebeheersysteem.

En toch: voor leveranciers van systemen met relationele databases die (klanten hebben die) graag RDF willen publiceren, inclusief SPARQL endpoint, kan RDB to RDF Mapping een goede oplossingsrichting zijn!

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Deze site wordt beschermd door reCAPTCHA en het Google privacybeleid en servicevoorwaarden zijn van toepassing.