Fork me on GitHub

Simple Service Status Ontology (SSSO)

Jakob Voß (voss@gbv.de)

2013-11-19 (version 0.3.0)

Table of Contents

1 Introduction

The Simple Service Status Ontology (SSSO) is an event-based RDF ontology for typical status in fulfillment of a service. A service in SSSO is an event that is provided as product. The specification of SSSO was motivated by the design of an ontology of Patrons Account Information API (PAIA) and a redesign of an ontology of Document Availability API (DAIA).

1.1 Status of this document

This specification is managed in a public git repository at http://github.com/gbv/ssso. The master file ssso.md is written in Pandoc’s Markdown. The current version hash is 412fb59.

RDF serializations of the Simple Service Status Ontology exist as ssso.ttl in RDF/Turtle as ssss.owl, both generated from Markdown via makespec.

How to contribute

Revision history

1.2 Terminology

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

1.3 Namespace and prefix

The URI namespace of Simple Service Status Ontology (SSSO) is http://purl.org/ontology/ssso#. The namespace prefix ssso SHOULD be used. The URI of this ontology as a whole is http://purl.org/ontology/ssso.

The ontology is defined in RDF/Turtle as following:

@prefix ssso: <http://purl.org/ontology/ssso#> .
@base         <http://purl.org/ontology/ssso> .

@prefix owl:     <http://www.w3.org/2002/07/owl#> .
@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#> .
@prefix vann:    <http://purl.org/vocab/vann/> .
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#> .
@prefix cc:      <http://creativecommons.org/ns#> .
@prefix dcterms: <http://purl.org/dc/terms/> .

<> a owl:Ontology ;
    dcterms:title "Simple Service Status Ontology"@en ;
    rdfs:label "SSSO" ;
    vann:preferredNamespacePrefix "ssso" ;
    vann:preferredNamespaceUri "http://purl.org/ontology/ssso#" ;
    dcterms:description "An event-based RDF ontology for typical status in fulfillment of a service."@en ;
    dcterms:modified "2013-11-19"^^xsd:date ;
    owl:versionInfo "0.3.0" ;
    cc:license <http://creativecommons.org/licenses/by/3.0/> ;
    dcterms:creator "Jakob Voß" 
.

2 Overview

A ServiceEvent according to SSSO is an event that is provided as product. Examples of ServiceEvent and ServiceFulfillment include a particular purchase of a product in a shop, a specific attendance at a performance, and a certain lending of a book in a library. The event is an activity in time that is typically provided by one or more service:ServiceProvider (e.g. a shop, presenter, or library) and consumed by one or more service:ServiceConsumer (e.g. a customer, attendee, or patron).

The following diagram illustrates the classes and properties defined in this ontology:

    nextService / previousService
               ------
              |      |
              v      v
       +--------------------+
       |    ServiceEvent    |
       |                    |
       |   ReservedService  |
       |   PreparedService  |
       |   ProvidedService  |
       |   ExecutedService  |
       |   RejectedService  |
       |                    |
       | ServiceFulfillment |
       +-----^--------------+
             |      ^
             |      |
              ------
dcterms:hasPart / dcterms:partOf

2.1 Service status

SSSO defines five typical service status as disjoint subclasses of ServiceEvent. Multiple ServiceEvent that belong to one ServiceFulfillment SHOULD be connected in time with properties nextService and previousService. An actual ServiceFulfillment does not need to implement all of these service status.

2.2 Service types

SSSO does not make any assumptions about types of services. To define service types, define a subclass of ServiceEvent. The class TimeTravel is included in SSSO as toy example of an artificial service type. See the Document Service Ontology (DSO) for more practical examples of service types that can be used together with SSSO.

2.3 Service times

SSSO does not define (yet another) set of properties to relate a service event to the time when it started and/or ended. The following properties from related ontologies are RECOMMENDED instead:

Property values of service times SHOULD be modeled as instance of [xsd:dateTime] or [xsd:date]. The starting time of a service event (if given) MUST be equal to or earlier than the ending time of the same service event (unless the service is an instance of TimeTravel and ExecutedService).

To express an estimated and additional time, the Service Ontology defines the property service:delay which can also hold a relative duration. Applications SHOULD NOT use this property to relate a service event to its normal time, unless this time is an additional constraint.

2.4 Service locations

The following properties from related ontologies are RECOMMENDED to relate a ServiceEvent to the location where the service is, will be, or has been provided. SSSO does not include any constraints on the nature of locations — see the specific property for suitable ranges:

property ontology range
schema:location Schema.org Ontology schema:Place or schema:PostalAddress
event:place Event Ontology geo:SpatialThing
crm:P7_took_place_at CIDOC-CRM crm:E53_Place
crm:P8_took_place_on_or_within CIDOC-CRM crm:E19_Physical_Object
prov:atLocation Provenance Ontology prov:Location
tio:takesPlaceAt Tickets Ontology tio:POI (subclass of gr:Location = schema:Place)
ncal:geo NEPOMUK Calendar Ontology geo:Point
ncal:location NEPOMUK Calendar Ontology xsd:string
ncal:locationAltRep NEPOMUK Calendar Ontology rdfs:Resource
lode:atPlace Linking Open Descriptions of Events dul:Place
dul:hasLocation DOLCE+DnS Ultralite Ontology dul:Entity

Service locations are OPTIONAL and a service event MAY have multiple locations.

3 Classes

3.1 ServiceEvent

A service event is a service (defined as service:Service in the Service Ontology and also an activity that takes places during a specific time. Several related ontologies define more general event or activity classes:

Existing product classes include:

SSSO is agnostic to these existing classes, so ServiceEvent is a subclass of all of them to make happy multiple communities. Applications of SSSO, however, SHOULD NOT depend on the explicit expression of a particular event or product class in addition to ServiceEvent.

ssso:ServiceEvent a owl:Class ;
    rdfs:label "ServiceEvent"@en ;
    rdfs:subClassOf 
        service:Service ,
        dctype:Event , 
        event:Event , 
        edm:Event ,
        prov:Activity , 
        lode:Event , 
        dul:Event ,
        crm:E7_Activity ,
        ncal:Event ,
        schema:Event ,
        tio:Event ,
        schema:IndividualProduct ,
        gr:Individual ;
        rdfs:isDefinedBy <> .

3.2 ServiceFulfillment

A service fulfillment is a ServiceEvent that consists of one or more parts. Each of these parts is also a ServiceEvent and connected to the service fulfillment by dcterms:partOf. Vice versa, each instance of ServiceEvent is also instance of ServiceFulfillment if connected to another ServiceEvent by dcterms:hasPart. The parts of a service fulfillment SHOULD be connected to each other by nextService and previousService.

ssso:ServiceFulfillment a owl:Class ;
    rdfs:label "ServiceFulfillment"@en ;
    rdfs:subClassOf ssso:ServiceEvent ;
    rdfs:isDefinedBy <> .

3.3 ReservedService

A reserved service is a ServiceEvent that has been accepted by a service provider for execution but not prepared yet. The reserved service has neither been prepared by a service provider but only queued for further processing. A typical example is a product order that has been placed but not payed yet or a payed ticket to a theater performance.

ssso:ReservedService a owl:Class ;
    rdfs:label "ReservedService"@en ;
    rdfs:subClassOf ssso:ServiceEvent ;
    owl:disjointWith 
      ssso:PreparedService, ssso:ProvidedService, 
      ssso:ExecutedService, ssso:RejectedService ;
    rdfs:isDefinedBy <> .

3.4 PreparedService

A prepared service is being prepared to be provided or executed. A typical example is a product that is being send to its consumer.

ssso:PreparedService a owl:Class ;
    rdfs:label "ReservedService"@en ;
    rdfs:subClassOf ssso:ServiceEvent ;
    owl:disjointWith
      ssso:ReservedService, ssso:ProvidedService, 
      ssso:ExecutedService, ssso:RejectedService ;
    rdfs:isDefinedBy <> .

3.5 ProvidedService

A provided service is being made available for immediate execution. A typical example is a product that is ready for being picked up by its consumer.

ssso:ReservedService a owl:Class ;
    rdfs:label "ReservedService"@en ;
    rdfs:subClassOf ssso:ServiceEvent ;
    owl:disjointWith
      ssso:ReservedService, ssso:PreparedService, 
      ssso:ExecutedService, ssso:RejectedService ;
    rdfs:isDefinedBy <> .

3.6 ExecutedService

An executed service represents the actual execution event of fulfillment of a service. A typical example is a theater performance that is being played.

ssso:ExecutedService a owl:Class ;
    rdfs:label "ExecutedService"@en ;
    rdfs:subClassOf ssso:ServiceEvent ;
    owl:disjointWith
      ssso:ReservedService, ssso:PreparedService, 
      ssso:ProvidedService, ssso:RejectedService ;
    rdfs:isDefinedBy <> .

3.7 RejectedService

A rejected service is a ServiceEvent that has been rejected by its provider or by its consumer. The rejection may be infinite or it may be followed by another service when the reason for rejection has been removed.

ssso:RejectedService a owl:Class ;
    rdfs:label "RejectedService"@en ;
    rdfs:subClassOf ssso:ServiceEvent ;
    owl:disjointWith
      ssso:ReservedService, ssso:PreparedService, 
      ssso:ProvidedService, ssso:ExecutedService ;
    rdfs:isDefinedBy <> .

3.8 TimeTravel

A time travel is an event which ends before it has been started. Details have been implemented in the future.

ssso:TimeTravel a owl:Class ;
    rdfs:label "TimeTravel"@en ;
    rdfs:isDefinedBy <> .

4 Properties

4.1 nextService

Relates a ServiceEvent instances to another service event that is the next service following in time. The starting time of the following service instance MUST be equal or later then the ending time of the previous service (unless one of the services is an instance of TimeTravel and ExecutedService).

ssso:nextService a owl:ObjectProperty ;
    rdfs:label "nextService"@en ;
    rdfs:domain ssso:ServiceEvent ;
    rdfs:range  ssso:ServiceEvent ;
    owl:inverseOf ssso:previousService ;
    rdfs:isDefinedBy <> .

4.2 previousService

Relates a ServiceEvent instances to another service event that is the previous service preceding in time. The ending time of the previousg service instance MUST be equal or earlier then the starting time of the next service (unless one of the services is an instance of TimeTravel and ExecutedService).

ssso:previousService a owl:ObjectProperty ;
    rdfs:label "previousService"@en ;
    rdfs:domain ssso:ServiceEvent ;
    rdfs:range  ssso:ServiceEvent ;
    owl:inverseOf ssso:nextService ;
    rdfs:isDefinedBy <> .

5 Relations to Schema.org and GoodRelations

The relation between SSSO, Schema.org, and GoodRelations can best be described by some examples (taken from GoodRelations, licensed under CC-BY-SA 3.0):

In short, a gr:Offering refers to a potential ServiceEvent (and possibly ServiceFulfillment), which is typically also an instance of gr:Individual, gr:ProductOrService, and schema:Product.

6 References

6.1 Normative References

6.2 Informative References

SSSO was motivated by the design of the following ontologies and specifications

SSSO is loosely connected to the following ontologies: it is compatible with them but their use is optional. Feel free to rely on or ignore additional parts of these ontologies when using SSSO.