WARNING: the new ITSMO ontology home is now https://w3id.org/itsmo . This URL is old and deprecated.

Abstract

IT Service Management Ontology (ITSMO) is a powerful vocabulary for describing all of the detail of IT Services in a way friendly to search engines, inventory applications, and browser extensions.

ITSMO is for everyone that wants to describe or publish an IT Service Catalog according with ITIL best practices, ISO 20000 standards and LinkedData W3C principles.

By adding few extra tags to your service description, you make sure that potential customers realize all the benefits of doing business with you, because their computers can find, explore and present your IT Service Catalog with ease.

ITSMO it is based on open Semantic Web technologies; this enable computers to help you in managing IT service architectures: you can use semantic web tools to show the hidden dependency between services and between their components (processes, documents, software, hardware, people, etc.).

ITSMO is tolerant with incomplete, missing and even wrong data. It helps you to get the best from what you have, helping you to manage risks and allowing to incrementally increase the quality of your data. It works with any mix of structured and unstructured data source, from expensive repository tools (CMDB) to uncontrolled sparse files.

ITSMO is free, easy to extend and works together with other public vocabularies, like Dublin Core, GoodRelations, FOAF and with the forthcoming USDL to provide you a complete semantic framework for IT Service Providing business.

Overview

IT Service Management Ontology (ITSMO) provides a formal vocabulary (also known as "schema", "data dictionary", or "ontology") for describing resources related to IT Service Management best practices.

The goals of ISTMO can be summarized in following points:

1. Supporting IT Service Providers with a formal and shared vocabulary to describe their assets consistently with the ITIL, and ISO 20000 glossaries.
2. Enabling IT service providers to distribute the knowledge about their assets; still maintaining the full control over them.
3. Being methodology agnostic.
4. Being fully compatible with W3C Semantic Web standards.
5. Being tolerant with partial, duplicate and missing information: get the best from what you have.
6. Being independent from tools and vendors: you are free to choose different level of control for your assets, mixing technologies and tools in a pragmatic strategy.
7. To use the power of open semantic web technologies to automatically infer useful things about your IT services infrastructure, just reading the service descriptions.
8. Being a building block for vertical applications supporting automatic impact analysis and risk management in service providing.

Last but not least ...be as simple as it can be, but not simpler. (A.Einstein)

ITSMO define a vocabulary of less than 100 terms. The most important are:

• The classes: Configuration Item, Process and IT Service.
• The predicates: uses, requires and links that depict Dependency relations between items.

The following diagram illustrates the interplay between some of the main ITSMO language elements. Please note that this diagram is VERY partial and shows just few of the terms defined in ITSMO vocabulary.

Usage examples: how it works

Use ITSMO vocabulary to enrich your asset descriptions (i.e. the description of your processes, services, systems, etc) with additional information about your data. Such extra information is called metadata.

The task of adding metadata is called "annotation" and usually consists in tagging a data (i.e. a number, a link, a field, a sentence, etc) with one or more properties. ITSMO provides you terms to annotate data about IT services and related concepts.

ITSMO uses the standard Resource Description Framework (RDF) to represent metadata, this means that you can use lots of existing technologies and tools to annotate your resources with ITSMO terms. Depending form the physical format of the resource you can use: attribute fields (like in Word , Excel, DBMS), RDFa or microformats (in HTML). If a resource does not support embedded metadata annotations, you can add them with external xml files.

Because ITSMO is a formal vocabulary, annotated resources can be understood by a software agent that builds automatically its knowledge navigating your resources and making deductions in order to answer queries and solving problems, exactly like a human reader.

Here are two HTML documents annotated with ITSMO vocabulary:

• The first example is this document (i.e. the web page you are reading now). This document is an important asset and I want to control its evolution. To state this, what I have to do is just to add an attribute to the <body> tag in the html source:

  
  	<body ... typeof='itsmo:Document' >
  

  Because of the ITSMO ontology, a semantic tools is able to infer that this web page represents is a kind of a Configuration Item and so it knows that this document should have a"configuration", a management process, a reference baseline and so on.

  Please have look to the source of this page, using "view source" feature of your favorite browser, and see how to inject ITSMO meta data in a plain HTML file.

  You can extract all annotations from this document using the W3C RDFa Distiller service. Try it providing, as the URI field, the address of this document (http://ontology.it/itsmo/v1/userguide) and selecting "Turtle" as Output Format like in following image:

  

  You can also click on the RDF icon in the footer of this document to download all metadata in XML/RDF format.

• The second example is the E-Artspace eCloud service description (sorry just available in Italian). This is a real Service Catalog entry annotated using ISTMO, ISPO, Goodrelations, Dublin Core and other ontologies.

  You are free to inspect meta data looking at the HTML source or using W3C RDFa Distiller to extract all of them in a text file.

In both examples, all meta data are embedded into HTML using RDFa standard; no other information source is required. These web pages can be understood by a human reader and/or by a machine reader (i.e. software agent). The reader could be able to make deductions (inferences), find relations between elements and start navigating the links to enrich his/her/its knowledge about selected topic.

Configuration Items

Configuration Item is a core concept: it is the base class for many ITSMO important terms.

You can think to a itsmo:ConfigurationItem at least from four points of view:

• From ITIL Point of view: it is any component or other service asset that needs to be managed in order to deliver an IT service. Information about each configuration item is recorded in a configuration record within the configuration management system and is maintained throughout its life cycle by service asset and configuration management. Configuration items are under the control of change management. They typically include IT services, hardware, software, buildings, people and formal documentation such as process documentation and service level agreements.

  ITSMO adopts ITIL definition, relaxing some constrains in order to be tolerant to "real word" service management practice: an ITSMO Configuration Item could be stored in more than a physical configuration and its metadata could be defined everywhere in the web. The configuration could also be controlled without tools in some informal way (i.e. without a CMDB)

  To be fully conformant to ITIL best practices is sufficient to introduce just three restrictions:

  1. A configuration item should have exactly one itsmo:hasConfiguration relation.
  2. The range of ismo:hasConfiguration properties must be restricted to controlled configuration.
  3. All configuration metadata must be defined in only one Controlled Configuration (i.e. without using Linked data and annotation properties like rdfs:seeAlso)

  In ITSMO you are free to choose the grade of control in management of Configuration items.

  You can choose to manage some CI in a central place with an expensive CMDB tool and following rigorous ITIL practices. At the same time, you can manage some other CI with less stringent requirements, tolerating a certain degree of wrong, biased, inconsistent or outdated information and letting the "trust" level of Semantic Web Architecture to help you in giving them a rank. In both cases, you will gain the benefit of having a semantic service knowledge management system able to use all available information, also if brought by poorly controlled items.

• From a physical point of view it is an identifier (i.e. a URI) for a set of related files that are managed as a whole. Files contain data and metadata.

  Such file collection is called Configuration. When a Configuration it is subjected to change management, it is called Controlled Configuration.

  In ITSMO, the Configuration Item meta data are represented with RDF triples that can be stored:

  • as records in the CMDB, providing an RDF extraction tool;
  • embedded into one or more file in the configuration (for example as RDFa in an HTML documents, in Microsoft Office properties or documents, XML, RDF file), providing a RDF extraction tool;
  • in one or more RDF Linked Data files or triple stores, outside configuration;
  • in a mixed combination of all these options.

  Note that only the first two points are ITIL compatible practices but all four are compatible with semantic web architecture.

  In most cases, you can think to a Configuration Item as an indirect reference to a versioned directory.

• According with Semantic Web architecture, a configuration item is a name for a conceptual object defined as a node in a RDF Graph. The concept must be named with a unique URI that should be represented (dereferenced) with a Web Information Resources ( see Cool Uri)

  You should pay attention to not confuse the concept with its web representation.

  For example, this page is a web resource that just represents the Configuration Item ITSMO User's Guide. ITSMO User's Guide is physically as a set of files stored in this subversion record. So this page is not the user's guide, it is just its representation. Do you remember René Magritte "Ceci n'est pas une pipe"?

• From a commercial point of view a CI (and IT services in particular) is something you can sell or buy. This aspect is fully covered by the Goodrelations ontology. Using ITSMO together with Goodrelations (both are OWL-DL) you get a complete lexical framework for describing an IT Service Provider business. See Goodrelations chapter for more details about this topic.

You are free to adopt the most appropriate point of view according your need.

Baseline and Snapshot

Configuration items are changing things. A baseline is a snapshot of a Configuration Item that is used as a reference point. Many snapshots may be taken and recorded over time but only some will be used as baselines. For example:

• A service management baseline can be used as a starting point to measure the effect of a service improvement plan.
• A performance baseline can be used to measure changes in performance over the lifetime of an IT service.
• A configuration management baseline can be used as part of a back-out plan to enable the IT infrastructure to be restored to a known configuration if a change or release fails.

A snapshot can be used to rebuild a Configuration Item.

A Configuration item can declare a specific baseline as a Reference Baseline. This means that the CI has a reference configuration snapshot that can be used as a contractual base.

Normally a Reference Baseline,if assigned, never change. If you need to change the reference baseline you shoud create another version of the whole CI.

If the Reference Baseline is not assigned, the CI is an evolving concept. If you reference an evolving concept you must know that its properties (i.e. its semantic) can change with time.

I need a tool to manage Configuration Items?

Configuration Management needs to store configuration data and meta-data somewhere.

The easy way to do it is to use a Version Control System like subversion or a proprietary CMDB System or one of available on-line repository.

This article shows how easy is to integrate Subversion with ITSMO.

But you are free to use just a file system and store CI configuration as a simple directory (i.e. the file system is your CMDB). In this case you will have to carefully implement change management using snapshots of the configuration directory. Many articles, like this show how to implement fast snapshots of a directory using Hard links and rsync.

File system based CMDB could be useful when your configuration is composed mainly by binary files and for items with a low change rate.

Version? Configuration? Revision? Snapshots? Baselines? Dumps? What a mess!!!

One big source of confusion is related to the common misuse of terms "version" and "revision" applied to Configuration Item, Configuration and Baseline such as: Configuration Item Version, Configuration Version, Configuration Revision, Snapshot Version, Baseline Version.

Configuration Item Version

In ITSMO a Configuration Item Version is a reference to another, newer or older, itsmo:ConfigurationItem. They are two distinct Configuration Items with different URI.

In other words, Configuration Item Version denotes a relation between two Configuration Items that should be expressed with Dublin Core vocabulary as in this example:

	sc:Apache2_hosting_service dcterms:replaces sc:Apache_hosting_service .
	sc:Apache_hosting_service dcterms:isReplacedBy sc:Apache2_hosting_service .
	sc:Apache_hosting_service dcterms:hasVersion sc:Apache2_hosting_service .
	sc:Apache2_hosting_service dcterms:isVersionOf sc:Apache_hosting_service .
	

In plain English this means that Apache2_hosting_service is the new edition of Apache_hosting_service.

Configuration Revision or Configuration version

These locutions are common used to indicate the dump of a Configuration Snapshot: that is a tar/zip file, or a tag that label a set of resources in a CMDB.

In other words: a Configuration Item (i.e. a concept) can be related to a Snapshot (i.e another concept) that represents its frozen configuration in a defined time. The Snapshot has a "configuration dump" that phisically is a tag (i.e. a label) in a Version Control System (or the URL of a dump file) that groups the forzen version of the phisical resources refernced in the configuration.

As a matter of facts, Configuration Revision or Configuration version are often used to indicate such dump.

Configuration dump is not a term defined in ITSMO vocabulary but you can annotate a Snapshot with the itsmo:hasConfigurationDump datatype property.

Unfortunately the locution Configuration version is also frequently used to denote a relation between a configuration and its dump (i.e. a_dump isVersionOf a_configuration). This could be confusing and shoud be avoided.

Version relations between configurations and between dumps should be expressed using Dublin Core vocabulary. Let's see some examples from real world:

	sc:Apache2_hosting_service itsmo:hasConfiguration CMDB:v1 .
	CMDB:trunk dcterm:hasVersion CMDB:v1.
	

Previous statements assert that the current configuration of Apache2_hosting_service is CMDB:v1; that is derived from the CMDB:trunk . In subversion specific terminology we can translate this in: Apache2_hosting_service source tree is archived the repository under v1 branch of the trunk path.

	sc:Apache2_hosting_service itsmo:referenceBaseline _n:;
	_n itsmo:hasConfigurationDump 35.
	

Previous statements assert that Apache2_hosting_service has a baseline (unnamed) derived from a configuration that has a dump tagged as "35" in CMDB. Note that in this case 35 is a literal (not an URI).

CONSTRUCT {
	?A itsmo:hasDependency _:C.
	_:C a itsmo:Dependency;
		itsmo:hasDependencyStrength ?strength;
		itsmo:hasDependencyDistance op:numeric-ad(?distance,1);
		ismo:hasDependentObject ?C.	
} WHERE {
	?A a itsmo:ConfigurationItem;
		itsmo:hasDependency ?depenencyToB.
	?depenencyToB a itsmo:Dependency;
		itsmo:hasDependentObject ?B.

	?B a itsmo:ConfigurationItem;
		itsmo:hasDependency ?depenencyToC.
	?depenencyToC a itsmo:Dependency;
		itsmo:hasDependentObject ?C;
		itsmo:hasDependencyStrength ?strength;
		itsmo:hasDependencyDistance ?distance.
}

@prefix gr: <http://purl.org/goodrelations/v1#> .
@prefix itsmo: <http://ontology.it/itsmo/v1#> .
@prefix example: <http://www.example.com/#> .

example:catalog:SSN10001234 a itsmo:ITService, gr:individual;
	rdfs:label "Service Serial Number ITS10001234";
	rdfs:comment "Specific ERP SaaS for BigCustomer";
	gr:serialNumber "SSN10001234";
	itsmo:hasAgreement  example:SLA:SSN10001234;
	itsmo:hasCustomer 	<http://www.bigcustomer.com/#company>;
	gr:hasMakeAndModel sc:catalog:ERPSaaS:v1;
			   
sc:catalog:ERPSaaS:v1 a itsmo:ITService, gr:ProductOrServiceModel;
    itsmo:hasProvider example:company;
	gr:hasMPN "ERP-v1";
	rdfs:label "ERP service";
	rdfs:comment "Access to a private istance of the ERP application hosted on Amazon EC2";
	itsmo:uses <http://aws.amazon.com/ec2#ITservice>;
	itsmo:hasOperationProcess [
	a itsmo:Process;
	 itsmo:hasAccountable example:department:IT;
	 itsmo:hasResponsable example:department:IT:operations;
	]
	itsmo:hasConfigurationManagement [
	 a itsmo:ConfigurationManagement;
	 itsmo:hasAccountable example:department:IT;
	 itsmo:hasResponsable example:department:IT:cm;
	]