To integrate ICONCLASS with services like the Termennetwerk we would like to have a SPARQL query service.
Easy! You might say. Let's just dump all the terms to a file on disk, and then load them into a triplestore, and be done. We tried that. It has some issues. Namely fulltext searches, and secondly, the exploding size of the number of nodes when taking IC "keys" into account.
Firstly, you would like to do some fulltext searches over the data that includes more than just the literals in each triple. For a hierarchical system like ICONCLASS, when you index an item lower down in the tree, you would also like to include the texts and keywords for all "parents" in the tree, to give better recall. There are ways to integrate a search index with the most well known triplestores, but it is not logistically trivial, nor cheap. (if you use commercial triplestore providers)
A first version of the IC sparql service used the Blazegraph store. While blazingly fast, freely available, and widely used, it has very much become "abandoware" after it's authors were hired by AWS. I do not consider it wise to invest more time in a product with no future.
Then the issue of the "exploding numbers" 🤯 when using IC keys. This is explained here in more detail. It boils down to the fact that the core IC system has around 40K terms, but when using keys this count increases to more than 1.2 million. We can't just ignore this feature, it is integral to the system and has been used in databases around the world for more than 40 years to catalog their collections in detail. So we have to support it. And actually, it is very useful from an Art Historians perspective...😉
This repository contains a custom Python RDFlib based sparql query engine, that integrates searching using the most excellent SQLITE FTS5 (the same index that is used in the ICONCLASS web service).
An endpoint is available at https://test.iconclass.org/sparql DISCLAIMER: it may go down, it may be unresponsive, there is no crack super devops team that has made it foolproof. (yet)
Some test can be done with YASGUI
But we are hard at work crossing the t's and dotting the i's, if you encounter bugs, please let me know or you can mail me on info@iconclass.org or file some issues in this repo.
Or ideally, contribute some fixes in a pull request... 🎯
Work on this service has been done with support from FIZ Karlsruhe Information Service Engineering and NFDI4Culture
rdflib-endpoint ✨️ SPARQL endpoint built with RDFLib to serve RDF files, machine learning models, or any other logic implemented in Python
SPARQL endpoint for Translator services A SPARQL endpoint to serve NCATS Translator services as SPARQL custom functions. Built with rdflib-endpoint
Hydra library for Python The primary goal is to provide a lib for easily writing Hydra-enabled clients
Python Linked Data Fragment Server. Python Linked Data Fragment server using asyncio and Redis
ODTMP-TPF Triple pattern matching over non-RDF datasources with inference
A Survey of RDF Stores & SPARQL Engines for Querying Knowledge Graphs
PREFIX skos: http://www.w3.org/2004/02/skos/core#
CONSTRUCT { ?uri a skos:Concept ; skos:prefLabel ?prefLabel ; skos:broader ?broader_uri ; skos:narrower ?narrower_uri ; skos:related ?related_uri .
?broader_uri skos:prefLabel ?broader_prefLabel .
?narrower_uri skos:prefLabel ?narrower_prefLabel .
?related_uri skos:prefLabel ?related_prefLabel .
} WHERE { ?uri a skos:Concept ; skos:prefLabel ?prefLabel .
?uri <http://iconclass.org/search> ?query .
OPTIONAL {
?uri skos:broader ?broader_uri .
?broader_uri skos:prefLabel ?broader_prefLabel .
}
OPTIONAL {
?uri skos:narrower ?narrower_uri .
?narrower_uri skos:prefLabel ?narrower_prefLabel .
}
OPTIONAL {
?uri skos:related ?related_uri .
?narrower_uri skos:prefLabel ?related_prefLabel .
}
} LIMIT 1000