On my flight back from the Metadata and Semantics Research conference (MTRS) I thought how to proceed with an RDF encoding of patron information, which I had presented before at the Sematic Web in Libraries conference (SWIB). I have written about the Patrons Account Information API (PAIA) before in this blog and you watch my SWIB slides and a video recording.
As I said in the talk, PAIA is primarily designed as API but it includes a conceptual model, which can be mapped to RDF. The term “conceptual model” needs some clarification: when dealing with some way to express information in data, one should have a conceptual model in her or his head. This model can be made explicit, but most times people prefer to directly use formal languages, such as OWL, or they even neglect the need of conceptual modeling languages at all. People that deal with conceptual modeling languages, on the other hand, often underestimate the importance of implementations – to them RDF is just a technology that is subject to change while models are independent from technology. Examples from the cultural domain include the CIDOC Conceptual Reference Model (CIDOC-CRM) and the Cultural Heritage Abstract Reference Model (CHARM), which I got to know in a talk at MTSR.
So thinking about conceptual models, RDF and patron information I came up with an expression of loan status in a library. In PAIA expressed as API we have defined six (actually five) status:
- 0: no relation
- 1. reserved (the document is not accesible for the patron yet, but it will be)
- 2. ordered (the document is beeing made accesible for the patron)
- 3. held (the document is on loan by the patron)
- 4. provided (the document is ready to be used by the patron)
- 5. rejected (the document is not accesible at all)
This list defines a data type, which one can happily work with without need to think about RDF, models, and all this stuff. But there is a model behind the list, which could also be expressed in different forms in RDF.
The first decision was to express each status as an event that connects patron, library, and document during a specific time. The second decision was to not put this into a PAIA ontology but into a little, specialized ontology that could also be used for other services. It turned out that lending a book in a library is not that different to having your hair cut at a barber or ordering a product from an online shop. So I created the Simple Service Status Ontology (SSSO), which eventually defines five OWL classes:
- A ReservedService has been accepted for fulfillment but no action has taken place.
- A PreparedService is being prepared but fulfillment has not actually started.
- A ProvidedService is ready to be fulfilled immediately on request.
- An ExecutedService is actually being fulfilled.
- A RejectedService has been refused or stopped before normal termination.
Service events can be connected through time, for instance a service can be executed directly after reservation or it could first be prepared. Putting this tiny model into the Semantic Web is not trivial: I found not less than eight (sic!) existing ontologies that define an “Event”, which a SSSO Service is subclass of. Maybe there are even more. As always feedback is very welcome to finalize SSSO.