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

Return to the regular view of this page.

Examples

use cases for ITSMO

1 - ITSMO reasoning

what an ITSMO reasoner can do

This example show how a complete ITSMO reasoner enrich some facts.

Suppose that https://demo.polisorbis.eu/ is a public web service deployed from the release 1.0.0 of the https://gitlab.com/copernicani/polisorbis/demo.polisorbis.eu gitlab repository maintained by the ecow user.

In ITSMO you know this fact as as:

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

<https://demo.polisorbis.eu/#1.0.0> :versionOf <https://demo.polisorbis.eu/> ;
    :hasResponsible <https://gitlab.com/ecow> ;
    :deployedFrom <https://gitlab.com/copernicani/polisorbis/demo.polisorbis.eu/-/tree/1.0.0#deployment> ;
    :hasScope :BusinessService 
.
<https://gitlab.com/copernicani/polisorbis/demo.polisorbis.eu/-/tree/1.0.0/#deployment> :created "2025-01-12T15:23:35"^^xsd:dateTime .

A compliant ITSMO reasoner will understand:

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


<https://demo.polisorbis.eu/> a itsmo:Asset .

<https://demo.polisorbis.eu/#1.0.0> a itsmo:WebService, itsmo:ConfigurationItem, istmo:Service, istmo:ITService, schema:Service, schema:WebApi, prov:Entity;
    itsmo:versionOf <https://demo.polisorbis.eu/> ;
    itsmo:deployedFrom <https://gitlab.com/copernicani/polisorbis/demo.polisorbis.eu/-/tree/1.0.0/#deployment> ;
    itsmo:dependsOn <https://gitlab.com/copernicani/polisorbis/demo.polisorbis.eu/-/tree/1.0.0/#deployment> ;
	itsmo:created "2025-01-12T15:23:35"^^xsd:dateTime ;
    itsmo:hasScope itsmo:BusinessService ;
    itsmo:hasPriority itsmo:LowPriority ;
    itsmo:hasCriticality itsmo:LowCriticality ;
    schema:availableChannel [ schema:serviceUrl "https://demo.polisorbis.eu/" ] ;
    itsmo:versionTag "1.0.0" ;
    itsmo:hasOwner <https://gitlab.com/copernicani> ;
    itsmo:hasResponsible <https://gitlab.com/ecow> ;
    prov:wasDerivedFrom <https://gitlab.com/copernicani/polisorbis/demo.polisorbis.eu/-/tree/1.0.0/#deployment> ;
    prov:wasGeneratedBy [  a prov:Activity ;
        prov:wasAssociatedWith <https://gitlab.com/ecow> ;
        prov:used <https://gitlab.com/copernicani/polisorbis/demo.polisorbis.eu/-/tree/1.0.0/#deployment> ;
        prov:qualifiedUsage [  a prov:Usage ;
            prov:entity <https://gitlab.com/copernicani/polisorbis/demo.polisorbis.eu/-/tree/1.0.0/#deployment> ;
            prov:hadRole :DeployProcessDescription ;          
        ]
    ];
    prov:wasAttributedTo  <https://gitlab.com/copernicani>, <https://gitlab.com/ecow> ;
    prov:qualifiedAttribution [ a prov:Attribution ;
        prov:agent <https://gitlab.com/copernicani> ;
        prov:hadRole itsmo:Owner ;
    ] , [ a prov:Attribution ;
        prov:agent <https://gitlab.com/ecow> ;
        prov:hadRole itsmo:Responsible 
    ]
.
<https://gitlab.com/copernicani/polisorbis/demo.polisorbis.eu/-/tree/1.0.0/#deployment> 
    a prov:Entity, itsmo:ConfigurationItem, itsmo:ConfigurationBaseline, itsmo:Software, itsmo:Deployment, itsmo:ProcessDescription ;
    itsmo:hasOwner <https://gitlab.com/copernicani> ;
	itsmo:created "2025-01-12T15:23:35"^^xsd:dateTime ;
    itsmo:versionOf <https://gitlab.com/copernicani/polisorbis/demo.polisorbis.eu> ;
    itsmo:versionTag "1.0.0" ;
    itsmo:path "/" :
    prov:wasAttributedTo  <https://gitlab.com/copernicani>;
    prov:qualifiedAttribution [ a prov:Attribution ;
        prov:agent <https://gitlab.com/copernicani> ;
        prov:hadRole itsmo:Owner ;
    ] 
.
<https://gitlab.com/copernicani/polisorbis/demo.polisorbis.eu> 
    a prov:Entity, itsmo:ObjectRepository, itsmo:GitLabProject ;
    itsmo:hasOwner <https://gitlab.com/copernicani> ;
    prov:wasAttributedTo  <https://gitlab.com/copernicani>;
    prov:qualifiedAttribution [ a prov:Attribution ;
        prov:agent <https://gitlab.com/copernicani> ;
        prov:hadRole itsmo:Owner ;
    ] 
.
<https://gitlab.com/ecow> a itsmo:Agent, prov:Agent, prov:Person, schema:Person .
<https://gitlab.com/copernicani> a itsmo:Agent, prov:Agent, prov:Organization, schema:Organization .

[] a prov:Activity, 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:35"^^xsd:dateTime ;
	prov:endedAtTime "2025-01-12T15:23:35"^^xsd:dateTime

Note that:

  • some fact are inferred from rdfs an OWL semantic
  • some facts are inferred by ITSMO axioms
  • some of facts are deducted by recognizing and parsing the GitLab URIs

More sophisticated reasoners, could infer other information. For example:

  • detect semantic inconsistences,
  • accessing GitLab APIs to discover the repository maintainer, the project description and the project name, dependencies, etc., etc.
  • apply euristic (e.g defining a schema:Name)
  • apply company specific rules
  • discovering other information by dereferencing the URLs,
  • etc, etc

2 - ITSMO & GitLab

CMDB automation with GitLab and SPARQL

You are using GitLab (GitHub is similar) as a devop platform.

You want to use a CMDB based on an RDF knowledge graph providing a SPARQL interface and you want to keep it updated when a IT service is deployed.

You could introduce some simple policies, leveraging the ITSMO semantic:

  • each ConfigurationItem in the CMDB is represented with a GRAPH.
  • each Deployment exposes a CI/CD pipeline (.gitlab-ci.yml) that defines some ITService metadata under the variables section, e.g.:
stages:
    - deploy

deploy-ITservice:
    stage: deploy

    variables: 
        ITSERVICE_METADATA: |
            {
                "versionOf": "https://coach-660862.gitlab.io/",
                "dependsOn": "https://gitlab.io/",
                "hasScope": "BusinessService" 
            }            
    
    script:
        - echo "here the deploy script..."

You need to write an integration webhook endpoint that traps the pipeline successful execution. The webhook code updates the CMDB using the data provided by GitLab in the pipeline event payload.

For example, your webhook, using the pipeline event payload, is supposed to be able to update the following graph in the CMDB endpoint using the Graph Store Protocol:

PUT /rdf-graph-store?graph=<https://gitlab.com/linkeddatacenter/coach/-/pipelines/1625977111>  HTTP/1.1
Host: cmdb.example.com
Content-Type: text/turtle

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

<https://coach-660862.gitlab.io/> a :Asset .

<https://gitlab.com/linkeddatacenter/coach/> a :ObjectRepository ;
    schema:name "coach repository" ;
    :owner  <https://gitlab.com/linkeddatacenter> ;
    :responsible <https://gitlab.com/ecows> ;
.

<https://coach-660862.gitlab.io/#1.0.0>a :ITService ;
    schema:name "coach service 1.0.0 in staging" ;
    :hasEndpoint <https://coach-660862.gitlab.io/>  ;
    :deployedFrom <https://gitlab.com/linkeddatacenter/coach/-/tree/1.0.0/#deployment> ; 
	:created "2025-01-12T15:23:35"^^xsd:dateTime ;
    :requires <https://gitlab.io/#service> ;
    :hasScope :BusinessService ;
    prov:wasGeneratedBy <https://gitlab.com/linkeddatacenter/coach/-/pipelines/1625977111#activity> ;
.

<https://gitlab.com/linkeddatacenter/coach/-/tree/1.0.0/#deployment> a :Deployment ;
    schema:name "coach deployment 1.0.0" ;
    :versionOf <https://gitlab.com/linkeddatacenter/coach/> ;
	:created "2025-01-12T15:23:28"^^xsd:dateTime ;
    :versionTag "1.0.0"
.

<https://gitlab.com/linkeddatacenter/coach/-/pipelines/1625977111#activity> a prov:Activity, prov:Publish ;
	prov:generated <https://coach-660862.gitlab.io/> ;
    :uses <https://gitlab.com/linkeddatacenter/coach/-/tree/1.0.0/#deployment> ;
    prov:startedAtTime "2025-01-12T15:23:28"^^xsd:dateTime ;
    prov:endedAtTime "2025-01-12T15:23:35"^^xsd:dateTime 
.

Now a semantic reasoner is free to infer the missing properties according with ITSMO reasoner requirements (see example)

3 - ITSMO & files

CMDB automation with an old plain filesystem.

You are using a filesystem to store some scripts and documentation. You want to manage it using ITIL best practices.

You want to use a CMDB based on an RDF knowledge graph providing a SPARQL interface.

A file system is generally not well-suited to serve as a Configuration Management Database (CMDB) for several reasons. While both store information, they have very different purposes, architectures, and functionalities. Here’s why a file system is difficult to use as a CMDB:

  1. Lack of Structure: File systems store files in a hierarchical directory structure. They are primarily designed for storing and retrieving data such as documents, media files, and executables. While you can organize these files into folders, the file system lacks a specific structure for representing relationships between different items or configurations. A CMDB is designed to store information about IT assets, services, configurations, and their relationships. It requires a much more structured approach, often with predefined schemas, fields, and relationships between objects (e.g., servers, software, networks). The CMDB is intended to provide insights into how assets are interconnected, dependencies, and their current states.
  2. Absence of Metadata and Context: File systems mainly store the name, size, date of creation, and other file attributes, but they don’t store rich metadata that provides context about the contents or relationships of the data. A CMDB tracks complex metadata such as version, ownership, location, status, configurations, dependencies, and even historical changes. This contextual data is crucial for managing IT environments, and it’s often stored in structured formats such as relational databases or specialized tools.
  3. Lack of Relationship Tracking: File systems are good for storing files, but they don’t inherently manage the relationships between files, users, or services. They do not track dependencies between objects (for example, how a specific software depends on a server or network infrastructure). A key function of a CMDB is to map and visualize relationships between configuration items (CIs), such as a server depending on a specific database or a service relying on a particular network configuration. Without this feature, a CMDB is not effective in helping IT teams understand the impact of changes.
  4. No Change History or Versioning: While a file system can store versions of files (through timestamps or using version control tools), it does not automatically track changes to the configuration or state of the files in a meaningful way. CMDB is designed to track changes over time, such as updates to software versions, hardware upgrades, or changes in network configurations. This version history and audit trail are critical for understanding how the configuration has evolved and ensuring compliance.
  5. Limited Access Control for Configuration Management : Access control in file systems is typically limited to file permissions." While this works for protecting access to files, it doesn’t have the depth needed for configuration management, where roles such as “admin,” “approver,” and “auditor” may require different levels of access. CMDB tools have robust access control mechanisms that allow different levels of access based on roles, ensuring that only authorized personnel can make changes to critical configuration information. This feature is necessary to ensure data integrity and compliance in an enterprise setting.

That said, a simple configuration management system can often be implemented using a plain file system with carefully manually applied naming conventions and organizational rules. This approach, while basic, can be surprisingly effective for small-scale or less complex environments.

How ITSMO can help:

While a traditional file system is not designed for the complexities of a Configuration Management Database (CMDB), with ITSMO it’s possible to implement certain organizational strategies to address some of the limitations. Below are a few ways you can organize a file system to simulate or bypass some of the constraints when managing configurations or IT assets, although it still won’t provide the full functionality of a CMDB.

Suggested directory Structure

Create a directory structure that mimics the hierarchical relationships and categorization of configuration items (CIs).

For example:

/
    service1/
        v1.0.0/
            itsmo.ttl
            install-script.sh
            install-data.txt
            ...
        v2.0.0/
            itsmo.ttl
            install-script.sh
            install-data.txt
            ...
    doc1/
        v1.0.0/
            itsmo.ttl
            README.MD
            ...
        v1.0.1/
            itsmo.ttl
            README.MD
            ...

Use ITSMO to inject a meaning to such structure:

dir level role Notes
root directory CMDB could be a relative directory
first level repository Each directory represents a ObjectRepository
second level baseline Each directory represents a ConfigurationBaseline
third level controlled files baseline content, each baseline contains a file named itsmo.ttl that stores CI metadata

The URI file://<fileserver>/rootdirectory/ represent the prefix for all other URIs.

Each folder under the root must contain a metadata.ttl directory to store information like version, owner, and status (active/inactive). This file should be a valid RDF serialized linked data using ITSMO

example of service1/v2.0.0/itsmo.ttl:

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



<service1/v2.0.0#service> a :ITService ;
    :versionOf <https://service1.example.com/> ;
    schema:description "my simple service v1.0.0 deployed in production"@en ;
    :deployedFrom </service1/v1.0.0/install-script#deployment> ;
	:created "2025-01-12T15:23:35"^^xsd:dateTime ; # from dir last modified date
    prov:wasRevisionOf </service1/v1.0.0#service>
.

</service1/v2.0.0/install-script#deployment> a :Deployment ; 
  schema:description "the service 1 install script"@en ;
  :created "2025-01-12T15:23:35"^^xsd:dateTime ; # from file last  modified date
  :versionOf <service1> ;
  :versionTag "2.0.0" ; 
  :path "/install-script"
  :requires  </service1/v2.0.0/install-data.txt#dataset> ;
  :hasOwner <https://example.com/me> ;
  :hasResponsible <https://example.com/me> ;
.
</service1/v2.0.0/install-data.txt#dataset> a :Dataset;
  schema:description "some data required by service 1 install script"@en ;
  :created "2025-01-12T15:23:35"^^xsd:dateTime ; # from file last modified date
  :versionOf <service1> ;
  :versionTag "2.0.0" ;
  :created "2025-01-12T15:23:35"^^xsd:dateTime ; # from file last  modified date
  :path "/install-data.txt"
.

Now You can load all .ttl files in a RDF Data Store to enable all query features required by a CMDB.

While organizing a file system in this manner can help you simulate some of the functions of a CMDB, it requires lot of manual effort to maintain dependencies, relationships, and metadata.

Note that much of the metadata file content can be generated by analyzing the directory structure. Consider writing scripts and aliases to automate part of your work.