Skosprovider Documentation Release 0.7.0 Koen Van Daele Feb 19, 2020 Contents 1 Introduction 1 1.1 Other providers..............................................1 1.2 Deviations from SKOS..........................................2 1.3 Support..................................................2 2 Usage 3 3 Development 7 4 API Documentation 9 4.1 Skos module...............................................9 4.2 Providers module............................................. 14 4.3 Registry module............................................. 24 4.4 Uri module................................................ 27 4.5 JsonLd module.............................................. 28 4.6 Exceptions module............................................ 29 4.7 Utils module............................................... 29 5 History 31 5.1 0.7.0 (2020-01-19)............................................ 31 5.2 0.6.1 (2017-07-16)............................................ 31 5.3 0.6.0 (2016-08-09)............................................ 32 5.4 0.5.3 (2015-06-24)............................................ 32 5.5 0.5.2 (2015-03-02)............................................ 32 5.6 0.5.1 (2015-03-02)............................................ 32 5.7 0.5.0 (2014-12-18)............................................ 33 5.8 0.4.2 (2014-10-16)............................................ 33 5.9 0.4.1 (2014-10-15)............................................ 33 5.10 0.4.0 (2014-10-02)............................................ 33 5.11 0.3.0 (2014-05-14)............................................ 34 5.12 0.2.1 (2013-12-06)............................................ 34 5.13 0.2.0 (2013-05-16)............................................ 34 5.14 0.1.3 (2013-03-22)............................................ 34 5.15 0.1.2 (2013-02-07)............................................ 35 5.16 0.1.1 (2012-12-11)............................................ 35 5.17 0.1.0................................................... 35 i 6 Glossary 37 7 Indices and tables 39 Python Module Index 41 Index 43 ii CHAPTER 1 Introduction Skosprovider provides an interface that can be included in an application to allow it to talk to different SKOS vocabu- laries. These vocabularies could be defined locally or accessed remotely through webservices. Adhering to this interface in you application decouples your application and the actual thesaurus. This makes unit testing easy because it allows you to swap a remote and a local implementation. It also makes it easy to switch from a simple, static implementation based on a csv file to a more complete implementation using your relation database of choice. One of the main goals of this project is to be able to build an application that can use thesauri or vocabularies without knowing upfront what these might be or where they might come from. This could be for an application that allows cataloguing things, but where it can be expected that different instances will require different thesauri or would need to be able to talk to existing vocabulary systems. Some sample providers are present in this package. The skosprovider.providers.DictionaryProvider uses a simple python dict as the datastore. It can be considered the reference implementation for the skosprovider.providers.VocabularyProvider interface. Most likely you will want to implement a provider for your own SKOS, vocabulary or thesaurus system. 1.1 Other providers Currently the following other providers exist: • Skosprovider_sqlalchemy: An implementation of the VocabularyProvider interface with a SQLAlchemy backend. This allows using a RDBMS for reading, but also writing, SKOS concepts. • Skosprovider_rdf: An implementation of the VocabularyProvider interface with a RDFLib backend. This allows using a SKOS RDF file as the source for a provider, but also dumping a skosprovider to a SKOS RDF file. • Skosprovider_atramhasis: The AtramhasisProvider lets you interact with an Atramhasis instance. • Skosprovider_getty: An implemenation of the VocabularyProvider against the Linked Open Data vo- cabularies published by the Getty Research Institute at http://vocab.getty.edu such as the Art and Architecture Thesaurus (AAT) and the Thesaurus of Geographic Names (TGN). 1 Skosprovider Documentation, Release 0.7.0 • Skosprovider_heritagedata: An implementation of the VocabularyProvider against the vocabularies pub- lished by EH, RCAHMS and RCAHMW at heritagedata.org. There also exists a library to integrate Skosprovider with Pyramid at pyramid_skosprovider. This allows you to embed a set of REST services in a Pyramid application that expose SKOSproviders as JSON services that can be consumed by eg. Javascript clients or other clients. For those who are looking to build a vocabulary, there’s also Atramhasis, an online SKOS vocabulary editor that builds upon this library and others. Atramhasis can function as the central SKOS registry for an organisation looking to manage its own thesauri and other controlled vocabularies. It provides a public website that allows people to browse you vocabularies and a private interface that allows vocabulary editors to create, edit and delete concepts and collections. By using other Skosproviders Atramhasis can import concepts and collections from other thesauri, saving you the trouble of having to write your own controlled vocabulary from scratch. 1.2 Deviations from SKOS In a few places we’ve deviated a bit from the SKOS standard: • While SKOS technically allows for things like a broader/narrower relation between concepts in different con- ceptschemes, Skosprovider assumes that all hierarchical or associative relations should be between concepts in the same conceptscheme. For relations between concepts in different schemes, the SKOS mapping proper- ties (skos:mappingRelation, skos:closeMatch, skos:exactmatch, . ) should be used. These are supported by Skosprovider since version 0.4.0. • The SKOS standard allows a concept that is marked as a topConcept to have a broader concept. Skosprovider expects that the concepts returned by the skosprovider.providers.VocabularyProvider. get_top_concepts() do not have any broader concepts. • The SKOS ontology ony describes a SKOS:member predicate to indicate that a collection has certain mem- bers. There’s an implicit reverse side to this relation (eg. a concept is a member of a collection). We’ve standardised this on the member_of property that’s available on a skosprovider.skos.Concept and a skosprovider.skos.Collection. • SKOS provides no way for specifying where in a hierarchy a skosprovider.skos.Collection should be placed. Since this is a fairly standard requirement for most thesauri, we have implemented this by looking at the SKOS-THES specification. We have borrowed the skosprovider.skos.Concept. subordinate_arrays and skosprovider.skos.Collection.superordinates properties from this specification. In effect, it turns a SKOS Collection that has one or more superordinates into a The- saurusArray. Since 0.7.0 it’s possible to explicitly state if the member of a collection that has a superordinate concept should be seen as narrower concepts of that superordinate concept with the skosprovider.skos. Collection.infer_concept_relations. By default this is set to True. If you want to model a col- lection that does not contain narrower concepts of it’s superordinate, set it to False. This will mainly stop search expansion using the skosprovider.providers.VocabularyProvider.expand() method. 1.3 Support If you have questions regarding Skosprovider, feel free to contact us. Any bugs you find or feature requests you have, you can add to our issue tracker. If you’re unsure if something is a bug or intentional, or you just want to have a chat about this library or SKOS in general, feel free to join the Atramhasis discussion forum. While these are separate software projects, they are being run by the same people and they integrate rather tightly. 2 Chapter 1. Introduction CHAPTER 2 Usage The basic idea of Skosprovider is very much about the idea of loose coupling, allowing two pieces of software to talk to each other while having as little knowledge of each other as possible. In this case, software A (eg. a webapp) can make use of 1 or more thesauri, controlled vocabularies, authority files and other vocabularies without have to no the details of the vocabularies. This has been achieved by defining an interface of the most common operations needed to integrate an vocabulary in an application. It’s complex and rich enough to allow for most operations that an application might need. And of course, in special cases you might consider expanding the interface. If you do so, please let us know. Your needs might be similar to someone else’s needs and might warrant an extension to the interface. While the interface is very clear on the operations supported and the data it shoudl receive from the provider, it makes not statement whatsoever about the format the data should be in when the provider receives it. So, while a client knows that each provider has a method to find a concept by an id and what this method will return, the client does not need to know where the provider goes to find this concept. One provider might look this up in a CSV file, another one in a database and yet another one through a webservice. In a way, the provider transforms the data from the source format to a common view of the SKOS data model. Because of this, the only part where the different providers are different is when instantiating the provider, since they need to be configured