This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

ITSMO Data model

The conceptual data model that forms a basis for ITSMO

This section we present the ITSMO data model for IT Service Management, which enables the interchange of specific information representations between systems. Thus, heterogeneous systems can export their native IT Service Management data, and applications can import, process, and reason over it.

The data model provides a comprehensive framework for managing IT services and related entities. Its foundation lies in extending well-established standards such as the PROV Data Model and the schema.org vocabulary. By doing so, ITSMO bridges semantic gaps between diverse systems, enabling interoperability and efficient data exchange in IT Service Management contexts.

In order to avoid data duplication, all definitions links to the official ontology documentation.

The conceptual design of the ITSMO data model organizes its elements into thematic groupings, each representing a key aspect of IT Service Management. Configuration items, such as services software, artifacts, and documents, are central to the model. The model also captures complex interdependencies, such as IT services requiring other services, depending on configuration items, or being deployed with specific software.

The following UML diagram shows the main ITSMO classes with their attributes and relationships:

@startuml
' ====================
'  Attributes
' ====================

class ConfigurationItem  {
  +versionTag: string
  +created: dateTime
}
class ConfigurationBaseline  {
  +path: string
}
class Service {
  +hasPriority(): Priority
  +hasCriticality(): Criticality
  +hasScope(): ServiceScope
}
' ====================
'  INHERITANCE
' ====================

Asset <|-- ObjectRepository

ConfigurationItem <|-- ConfigurationBaseline
ConfigurationItem <|-- Service


ConfigurationBaseline <|-- Artifact
ConfigurationBaseline <|--- Documentation
ConfigurationBaseline <|-- Software


Service <|-- ITService

Software  <|-- Deployment
Software  <|-- Packaging

Documentation <|-- ProductSheet
Documentation <|-- FeatureSheet


' ===================
  '  ASSOCIATIONS
' ===================
Asset <- ConfigurationItem : versionOf

ObjectRepository <-- ConfigurationBaseline : versionOf

ConfigurationItem --> ConfigurationItem : dependsOn\npartOf\nlinks
ConfigurationItem --> Agent : hasResponsible\nhasOwner

Artifact --> Packaging : builtFrom

Service --> Service : informedBy
ITService --> Deployment : deployedFrom

ProductSheet -> FeatureSheet : promises

@enduml

Besides the terms depicted in this UML diagram, the ITSMO vocabulary provides many additional classification terms derived from ITIL jargon.

The core element of ITSMO is the ConfigurationItem, which represents a defined state of a managed asset. It is characterized by the created and versionTag properties and is a versionOf an abstract resource.

ITSMO distinguishes between two types of configuration items:

ConfigurationBaseline is a schema:CreativeWork that exposes a versionTag and path, which uniquely identify a particular configuration in an ObjectRepository.
Service is a schema:Service that represents an intangible running process. Its specialization, ITService, is generated from a Deployment process (i.e., a software ConfigurationBaseline).

A Configuration URI should be designed according to the Linked Data best practice.

For example, the PolisOrbis Sandbox is a low-priority, low-criticality public website available at the endpoint https://demo.polisorbis.eu/.
The service is deployed via a Terraform script contained in the https://gitlab.com/copernicani/polisorbis/demo.polisorbis.eu repository.

In ITSMO you describe it as:

@prefix schema: <https://schema.org/> .
@prefix : <https://w3id.org/itsmo#> .

<https://demo.polisorbis.eu/#1.0.0> a :ITService ;
    schema:name "PolisOrbis Sandbox"@en ;
    :versionOf <https://demo.polisorbis.eu/> ;
    :deployedFrom <https://gitlab.com/copernicani/polisorbis/demo.polisorbis.eu/-/tree/1.0.0/#deployment> ;
    :hasScope :BusinessService ;
    :hasPriority :LowPriority ;
    :hasCriticality :LowCriticality 
.

Note that the IT service is uniquely identified by the deployedFrom property.

ITSMO reasoner requirements

The ITSMO reasoner plays a critical role in enhancing the utility and intelligence of the ITSMO data model. By applying a set of predefined rules, the reasoner automates the inference of relationships and attributes across the ontology. These rules ensure consistency, reduce manual effort, and enable dynamic enrichment of the data model. From metadata inheritance to platform-specific integrations, the reasoner facilitates seamless interoperability and supports advanced reasoning capabilities, making IT Service Management processes more efficient and adaptable.

The ITSMO reasoner can infer lot of properties from few source facts, see here an example.

Basic rdfs reasoning support

An ITSMO reasoners should be able to understand at least the semantic for:

rdfs:domain
rdfs:subPropertyOf
rdfs:subClassOf

Metadata inheritance

ITService and Artifact inherits missing versionTag, created [hasResponsible] and hasOwner attributes from the Software who generated them:

PREFIX : <https://w3id.org/itsmo#>
CONSTRUCT { ?subject ?property ?object ; :dependsOn ?software }
WHERE {
    VALUES (?property) {
        :hasResponsible
        :hasOwner
        :versionTag
        :created
    }
    ?subject :builtFrom|:deployedFrom ?software .
    ?software ?property ?object .
    FILTER NOT EXISTS { ?subject ?property [] }
}

Default values for qualitative values.

If a functional property that expects a qualitative value is missing, an ITSMO reasoner should use following defaults:

property	default
hasCritically	LowCritically
hasPriority	LowPriority
hasScope	SupportService

ConfigurationBaseline metadata discovery with GitLab and GitHub

Any ConfigurationBaseline must be managed by a Version Control System (VCS). Git is a well known VCS, and services like GitLab and GitHub provides a web interface to its feature. These services also provide URLs that can be used to deduce some attributes.

An ITSMO reasoner should be able to infer metadata attributes by recognizing and parsing the VCS related URL structure:

itsmo:versionTag: Extracted from versioning information within the URI (e.g., branch or tag names).
itsmo:path:Inferred from the repository’s base URL in the URI. If not specified you can assume /
itsmo:hasOwner: Inferred from the repository’s namespace.

This rule streamlines the process of metadata enrichment by leveraging the standardized formats of Git hosting platforms. For instance, a configuration item with a URI like https://github.com/org/repo/tree/1.1.0 allows the reasoner to identify it as ConfigurationBaseline of the GitLab repository (https://github.com/org/repo), owned by (https://github.com/org), with path (/), and with the versionTag 1.1.0.

By incorporating this antipattern rule, ITSMO reduces the need for manual metadata entry for commonly used platforms, improving efficiency and ensuring that configuration items maintain consistent and accurate metadata across systems. This capability also enhances interoperability and traceability in IT Service Management processes.

An ITSMO reasoner should recognize GitLab and GitHub URLs schemas.

Interoperability Through Integration

ITSMO’s integration with external vocabularies like schema.org and PROV enhances its usability and reach. By mapping ITSMO entities and properties to corresponding classes and attributes in schema.org, the ontology supports broader semantic web standards. This ensures ITSMO’s compatibility with diverse web-based applications and facilitates seamless data interchange. Similarly, its alignment with the PROV model strengthens provenance tracking, making it easier to audit and trace the lifecycle of IT services and related artifacts.

These integrations are further supported by formalized rules for reasoning over the model. For instance, SPARQL rules specify how IT services and artifacts should be attributed to agents or derived from deployments. These reasoning mechanisms enable dynamic inferences and enrich the data with meaningful relationships.

schema.org integration

The schema.org integration in the ITSMO data model establishes mappings between ITSMO entities and the widely used schema.org vocabulary. This integration aligns ITSMO concepts with global web standards, enabling broader interoperability and semantic consistency across systems. By leveraging schema.org, ITSMO enhances its ability to exchange structured data in a way that is easily understood and utilized by diverse applications, from web-based platforms to enterprise systems.

schema.org class mappings

The following relationships exist between ITSMO and schema.org Classes:

@startuml
left to right direction
"schema:Thing" <|-- ConfigurationItem
"schema:Thing" <|-- Asset
"schema:Service" <|-- Service
"schema:CreativeWork" <|-- ConfigurationBaseline
SoftwareSourceCode <|-- Software
"schema:SoftwareApplication" <|-- SoftwarePackage

"schema:Person" --|> Agent
"schema:Organization" --|> Agent

@enduml

schema.org property mappings

The following relationships exist between ITSMO and schema.org properties:

@startuml
left to right direction
"schema:codeRepository" --|> versionOf : rdfs:subPropertyOf
"schema:mainEntityOfPage " --|> versionOf : rdfs:subPropertyOf
"schema:url " --|> versionOf : rdfs:subPropertyOf
@enduml

PROV integration

The PROV integration in the ITSMO data model establishes a formal alignment between ITSMO concepts and the PROV Data Model, a widely used standard for representing provenance information. This integration enhances ITSMO’s capability to trace the origins, history, and accountability of configuration items, supporting transparency and auditability.

The following relationships exist between ITSMO and PROV Classes:

@startuml
left to right direction
class "prov:Role" as Role
class "prov:Entity" as Entity
class "Agent" as Agent
class "prov:Agent" as provAgent

Entity <|-- ConfigurationItem
Entity <|-- ConfigurationBaseline

provAgent  <|-- Agent

Role <|-- Owner
Role <|-- Responsible
Role <|-- BuildProcessDescription
Role <|-- DeployProcessDescription
@enduml

Asset publishing and service catalog

One tricky question is how to link a resource URL to its ConfigurationItem .

To do this, you can create a [prov:Activity] as in this example:

@prefix : <https://w3id.org/itsmo#> .
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .
@prefix prov: <http://www.w3.org/ns/prov#> .

[] a prov:Publish ;
	prov:generated <https://demo.polisorbis.eu/> ;
	prov:used <https://gitlab.com/copernicani/polisorbis/demo.polisorbis.eu/-/tree/1.0.0/#deployment> ;
	prov:startedAtTime "2025-01-12T15:23:30"^^xsd:dateTime ; # OPTIONAL: same date of the creation of the Deployment
	prov:endedAtTime "2025-01-12T15:23:35"^^xsd:dateTime # MANDATORY: same date of the creation of the ITservice
.

Note that the link with the ITService can be inferred from the used Deployment .

The following SPARQL QUERY prints the whole [ServiceCatalog]:

PREFIX : <https://w3id.org/itsmo#>
PREFIX schema: <https://schema.org/> 
PREFIX prov: <http://www.w3.org/ns/prov#>

SELECT DISTINCT ?serviceEndpoint ?version ?onlineStatus ?lastUpdated ?scope ?priority ?criticality ?deploymentRepository ?commit 
WHERE {

	# Discover the last update date
	{
		SELECT DISTINCT ?asset (MAX(?endedAtTime) AS ?lastUpdated) 
		WHERE {
			?activity a prov:Publish ; prov:endedAtTime ?endedAtTime
		} GROUP BY ?asset ?endedAtTime 
	}
	BIND( ?asset AS ?serviceEndpoint)

	
	# Detect the online status
	{
		?activity prov:generated ?serviceEndpoint
		BIND( "ONLINE" as ?onlineStatus )
	} UNION {
		?activity prov:invalidates ?serviceEndpoint
		BIND( "OFFLINE" as ?onlineStatus )
	}

	# Extract some ITservice properties
	?service a :ITService ;
		:versionOf ?serviceEndpoint ;
		:created ?lastDeployed ; # this is the trick that allow to link the Asset with its related ITService version!
		:deployedFrom ?deployment ;
		:versionTag ?version 
	.
	?deployment a :Deployment ;
		:versionOf ?deploymentRepository ;
		:versionTag ?commit
	.
	OPTIONAL {?service :hasScope ?scope }
	OPTIONAL {?service :hasPriority ?priority }
	OPTIONAL {?service :hasCriticality ?criticality }
}

RULE: generated items

This rule formalizes the relationships between a configuration item, the build processes that generate it, and the software involved, providing a clear provenance trail within the ITSMO data model.

The rule is described by this SPARQL construct:

CONSTRUCT {
    ?entity a prov:Entity ;
        prov:wasDerivedFrom ?software ;
        prov:wasGeneratedBy [  a prov:Activity ;
            prov:wasAssociatedWith ?agent ;
            prov:used ?software ;
            prov:qualifiedUsage [  a prov:Usage ;
                prov:entity ?software ;
                prov:hadRole ?role ;          
            ]
        ]
}
WHERE {
    VALUES ( ?generatedFrom ?role) {
        ( itsmo:deployedFrom :DeployProcessDescription)
        ( itsmo:builtFrom :BuildProcessDescription)
    }
    ?entity ?generatedFrom ?software
    OPTIONAL {?entity itsmo:hasResponsible ?agent }
}

RULE: role attribution

This rule formalizes the relationships between a configuration item, and the agent in role:

CONSTRUCT {
    ?entity
      prov:wasAttributedTo ?agent ;
      prov:qualifiedAttribution [ a prov:Attribution ;
        prov:agent ?agent ;
        prov:hadRole ?role ;
    ]
}
WHERE {
    VALUES ( ?attributedTo ?role) {
        ( itsmo:hasOwner :Owner)
        ( itsmo:hasResponsible :Responsible)
    }
    ?entity ?attributedTo ?agent 
}

For example, to say that a service was deployed using a pipeline in deployment https://gitlab.com/example/website/-/tree/1.0.0 baseline at 2025-01-12T15:23:35:

@prefix : <https://w3id.org/itsmo#> .
@prefix xsd:  <http://www.w3.org/2001/XMLSchema#> .
@prefix prov: <http://www.w3.org/ns/prov#> .

[] 
    prov:wasGeneratedBy [
        prov:qualifiedUsage [
            prov:entity  <https://gitlab.com/example/website/-/tree/1.0.0#as-a-deployment> ;
            prov:hadRole :DeployProcessDescription ;          
        ] ;
        prov:startedAtTime "2025-01-12T15:23:28"^^xsd:dateTime ;
        prov:endedAtTime "2025-01-12T15:23:35"^^xsd:dateTime 
    ] 
.

Let a PROV reasoner to complete all inferences.