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).
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
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.
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ß"
.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:partOfSSSO 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.
A ReservedService is in status reserved:
the service has been accepted for execution but no action has taken place. Possible examples include an order of a product that must be paid in advance but has not been paid yet, or the reservation of a book in a library that is not accesible yet.
A PreparedService is in status prepared:
the execution is being prepared but is has not actually started. A possible example is a product being sent to the customer.
A ProvidedService is in status provided:
the service is ready to be executed on request. An example is a product that is ready to be picked up by a customer.
A ExecutedService is in status executed:
the service is actually being executed. For instance this activity can be the event when a bought product is handed over to the customer, the time of a performance, or the time a book is held on loan by a patron.
A RejectedService is in status rejected:
the service has been refused or stopped. A possible example is a canceled contract.
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.
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.
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:
Service locations are OPTIONAL and a service event MAY have multiple locations.
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 <> .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 <> .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 <> .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 <> .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 <> .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 <> .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 <> .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 <> .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 <> .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 <> .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.
[RFC 2119] S. Bradner: Key words for use in RFCs to Indicate Requirement Levels. March 1997 http://tools.ietf.org/html/rfc2119.
[RFC 2396] T. Berners-Lee et al.: Uniform Resource Identifiers (URI): Generic Syntax. August 1998 http://tools.ietf.org/html/rfc2396.
The Service Ontology. (work in progress) http://dini-ag-kim.github.io/service-ontology/.
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.