# deRSE24 "SPARQL Unicorn"

CfC: https://events.hifis.net/event/994/abstracts/

## Title

The SPARQL Unicorn: A Research Tool for Linked Open Data in QGIS and git-action-based ontology documentation

## Type

* Talk (15min)

## Author(s)

* Timo Homburg (HS Mainz)
* Florian Thiery (LEIZA)

## Text (max. 500 words)

### Introduction

Publishing sustainable research data and providing appropriate access for many research communities challenges many players: Researchers, research software engineers, standardization organizations and data repositories. With [national research data infrastructures (NFDI)](https://www.dfg.de/en/research_funding/funding_initiative/nfdi/index.html) being set up in Germany, the latter could be solved in the mid- to long-term for specific datasets. In the meantime, researchers often produce datasets of various data in research projects which are provided as services, e.g. from a web page, but may, due to a lack of funding, disappear in that form after the research project has ended. To circumvent this, open research data is hosted long-term on public platforms like university libraries, [Zenodo](https://zenodo.org/) or [Github](https://github.com/). However, this hosted data is not necessarily easily discoverable by different research communities. On top of that, research data is rarely published in isolation, but with links to related datasets, leading to the creation of link-preserving, [FAIR](https://www.go-fair.org/fair-principles/) linked open data (LOD) as [RDF](https://www.w3.org/TR/rdf11-concepts/) dumps, modelling data interoperably in common vocabularies. LOD in RDF preserves links, but is not necessarily [Linked Open Usable Data (LOUD)](https://linked.art/loud/), i.e. it does not provide data in ways different research communities expect. We would like to address this problem of missing LOUD data while removing requirements on the backend such as hardware and software to a minimum.

### SPARQLing Unicorn Ontology Documentation

We believe that a solution to this data provision problem is publishing research data as static webpages and using standardized static APIs to serve data in ways different research communities expect.

To that end, we developed a documentation extension to the [SPARQLing Unicorn QGIS Plugin](https://github.com/sparqlunicorn/sparqlunicornGoesGIS), allowing to publish RDF data dumps as one [HTML](https://html.spec.whatwg.org/) page and RDF serialization per data instance, similar to what frontends to triple stores such as [Pubby](https://github.com/cygri/pubby) provide.
It is published as a [QGIS Plugin](10.5281/zenodo.3786814), a [standalone script](https://github.com/sparqlunicorn/sparqlunicornGoesGIS-ontdoc) on Github and a [Github Action](https://github.com/sparqlunicorn/sparqlunicornGoesGIS-ontdoc).

The resulting data dump is hostable on static webspaces e.g. Github pages and allows navigating the contents of the LOD data in HTML including a class tree. It may include:
* Further data formats: Graph Data ([GraphML](http://graphml.graphdrawing.org/), [GEXF](https://gexf.net/)), General Purpose ([CSV](https://www.ietf.org/rfc/rfc4180.txt))
* SPARQL querying in JavaScript using the data dump
* Generation of [static APIs](https://www.seancdavis.com/posts/lets-talk-about-static-apis/), e.g. JSON documents mimicking standardized APIs, for
* [OGC API Features](https://ogcapi.ogc.org/features/): Access to FeatureCollections from e.g. [QGIS](https://qgis.org/)
* [IIIF Presentation API 3.0](https://iiif.io/api/presentation/3.0/): IIIF Manifest Files for images/media in the knowledge graph including typed collections
* [CKAN API](https://ckan.org/features/api): Datasets in the [DCAT vocabulary](https://www.w3.org/TR/vocab-dcat-3/) or data collections

Static APIs further the accessibility of LOD data for different research communities and increase the chances of data reusage and exposure in different research fields, while at the same time not depending on additional infrastructures for data provision.

### Feasibility, Limitations and future work
Our talk shows the feasibility of using three publicly available examples for geodata and CKAN ([SPP Dataset](https://github.com/archaeolink/SPP1630Harbours-RDF), [AncientPorts Dataset](https://github.com/archaeolink/AncientPorts_RDF), [CIGS Datatset](https://github.com/archaeolink/CIGS_RDF)) and the [ARS-LOD](https://github.com/RGZM/ars-lod/) dataset for static IIIF data.
Finally, we discuss requirements and limitations of this kind of publishing in a research data publishing workflow, in relation to NFDI plans and how to extend this approach to only partially open data using a [Solid pod](https://solidproject.org/specification) publishing workflow.

---> Hier würde ich noch Beispiele definieren die man vll im Talk aufgreift. Text ggf. noch kürzen wenn der jetzt schon zu lange ist. Vll noch Bilder einfügen wenn wir dürfen?

---> Ich würde hier vll mehr auf andere APIs als OGC API Features eingehen und vll mehr auf den Publikationsprozess von "Rohdaten" zu LOD und dann zu LOD Publikation

* SPARQLing Unicorn QGIS Plugin (10.5281/zenodo.3786814)
* interdisciplinary Research Software for scientists and Citizen Scientists to integrate Linked Open Data in Open Source GIS Software (QGIS), enrich data with data from the semantic web, transform data into LOD and create documentation.
* SPARQL Unicorn Ontology Documentation (10.5281/zenodo.8190763)
* docu auch als [GitHub action](https://github.com/sparqlunicorn/sparqlunicornGoesGIS-ontdoc), [Beispiel Limes](https://github.com/sparqlunicorn/sparqlunicornGoesGIS_testdata)

## Comment

* keiner

## Length

* other