Skip to content

Latest commit

 

History

History
625 lines (492 loc) · 25.6 KB

ssso.md

File metadata and controls

625 lines (492 loc) · 25.6 KB
Raw

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).

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 {GIT_REVISION_HASH}.

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

  • Express data in RDF with SSSO!
  • Map other ontologies to SSSO!
  • Comment on the specification!
  • Correct the current SSSO draft!

Revision history

{GIT_CHANGES}

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.

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 "{GIT_REVISION_DATE}"^^xsd:date ;
    owl:versionInfo "{VERSION}" ;
    cc:license <http://creativecommons.org/licenses/by/3.0/> ;
    dcterms:creator "Jakob Voß" 
.

Related ontologies

The core class ServiceEvent is based on the class service:Service from the Service Ontology.

Several existing ontologies include classes to model events or activities. Interconnections between these related ontologies, however, are rare. The large number of similar classes may result from an inability of ontology engineers to agree on semantics or from the dislike to refer to ontologies that have been designed by someone else. The related ontologies are:

The following namespace prefixes are used to refer to related ontologies:

@prefix service: <http://purl.org/ontology/service#> .
@prefix crm:     <http://purl.org/NET/cidoc-crm/core#> .
@prefix dctype:  <http://purl.org/dc/dcmitype/> .
@prefix dul:     <http://www.loa-cnr.it/ontologies/DUL.owl#> .
@prefix event:   <http://purl.org/ontology/c4dm/event.owl#> .
@prefix edm:     <http://www.europeana.eu/schemas/edm/> .
@prefix foaf:    <http://xmlns.com/foaf/0.1/> .
@prefix geo:     <http://www.w3.org/2003/01/geo/wgs84_pos#> .
@prefix gr:      <http://purl.org/goodrelations/v1#> .
@prefix lode:    <http://linkedevents.org/ontology/> .
@prefix ncal:    <http://www.semanticdesktop.org/ontologies/2007/04/02/ncal#> .
@prefix prov:    <http://www.w3.org/ns/prov#> .
@prefix schema:  <http://schema.org/> .
@prefix tio:     <http://purl.org/tio/ns#> .

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

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.

  • 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.

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.

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.

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.

Classes

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 <> .

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 <> .

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 <> .

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 <> .

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 <> .

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 <> .

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 <> .

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 <> .

Properties

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 <> .

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 <> .

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.

References

Normative References

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.