This is an outdated version of the eClassOWL project

Please visit for the current version.



eClassOWL 5.1
Products and Services Ontology for e-Business


User’s Guide


Version 1.0

June 16, 2006


Author: Martin Hepp





eClassOWL is an initatitive of the
Semantics in Business Information Systems (SEBIS) research cluster
 at the Digital Enterprise Research Institute (DERI).



With kind support by eCl@ss e.V., or




Project URI:





This ontology is derived from eCl@ss version 5.1. eCl@ss is a broad initiative for classifying and describing products and services and aims at easing e-business transactions. More information on eCl@ss can be found at




This ontology  is a RESEARCH PROTOTYPE, not an official release and is NOT ENDORSED by eCl@ss e.V. It may be used FOR RESEARCH PURPOSES ONLY, not for commercial applications.


Please download the official version of eCl@ss from  for any official use.


If you want to use this ontology for commercial purposes, an individual legal framework must be negotiated. In this case, please contact Martin Hepp at so that a link to eCl@ss e.V. can be established.


For additional information, please check the project Web site at




The ontology is released as it is. Usage is permitted for research purposes only and at your own risk! Neither the author nor eCl@ss e.V. can be held liable for any damage or loss resulting from the use of this ontology.



Please note that the ontology size exceeds the capabilities of many current ontology tools (e.g. Jena, Protégé, vowlidator,...). and it is thus possible, depending on the configuration of your system, that trying to load the files will crash your system!




This work on eClassOWL was supported in part by the European Commission under the project DIP (FP6 - 507483),  by the Trans IT Entwicklungs- und Transfercenter at the University of Innsbruck, by Florida Gulf Coast University, and eClass e.V. In addition, I would like to thank Jos de Bruijn, Axel Polleres, Doug Foxvog, and Amit Sheth for very valuable feedback during the development of the ontology.


Table of Contents


1 Overview: eClassOWL. 1

1.1 Domain Scope and Content 2

1.2 Quick Start – Using eClassOWL in 5 Minutes. 3

1.2.1 Identifiers of Ontology Elements: Classes. 4

1.2.1 Identifiers of Ontology Elements: Properties and Property Values. 5

1.2.3 Examples: Using eClassOWL in e-Business Scenarios. 6

2 Ontology Structure. 8

2.1 Taxonomic Classes vs. Generic Classes. 8

2.2 Datatyping. 11

3 eClassOWL Ontology Modeling Patterns. 12

4 Frequently Asked Questions. 13

4.1 How can I quickly find the suitable product class and suitable properties?. 13

4.2 What is the difference between the taxonomic concepts and the generic concepts?. 13

4.3 What are the annotation concepts meant for?. 13

4.4 What is the range and domain of properties?. 13

4.5 Why are you using cryptic identifiers like AAA123345?. 14

4.6 The generic classes do not follow a subsumption hierarchy – aren’t they completely useless?. 14

4.7 Why is the ontology so damn big?. 14

References. 14



1 Overview: eClassOWL

eClassOWL is an OWL DLP ontology for products and services and is based on the comprehensive categorization standard eCl@ss 5.1. For more information on eCl@ss, see (in German) or (in English). For the full theoretical background of eClassOWL, please check the following journal paper:

M. Hepp, "Products and Services Ontologies: A Methodology for Deriving OWL Ontologies from Industrial Categorization Standards," Int'l Journal on Semantic Web & Information Systems (IJSWIS), vol. 2, pp. 72-99, 2006.


eCl@ss includes the following main building blocks:

  1. Products and services concepts (e.g. “TV Set”),
  2. product properties (e.g. “screen size”),
  3. values for enumerated data types,
  4. a hierarchy of the product concepts reflecting the perspective of a buying organization (!),
  5. recommendations which properties should be used for which type of products, and
  6. recommendations which values are allowed for which (object) property.


The hierarchy in the original standard is not directly meant to be a subsumption hierarchy, i.e. it is not equivalent to taxonomic relationships in the sense of rdfs:subClassOf. See [1], [2], and [3] for details.


Also, some architectural aspects of eCl@ss are not compatible with OWL, namely with the global scope of properties. The eClassOWL ontology was built to capture as much of the original semantics as possible while being well within the limits of OWL DLP. Thus, in practice, the ontology can be merged with any OWL DL data without making the resulting ontology exceed OWL DL. At the same time, the full semantics of eClassOWL can be handled in OWLIM[1], the most scalable OWL DLP repository/reasoner that we know of.


The ontology comes in three files:


a) eclass_51en.owl

This module contains all class definitions, properties, and values. For reasons explained later, each eCl@ss category is represented in the form of three different OWL ontology classes, one per each generic category, one for the same concept in the original context of the taxonomy, and one annotation category (see below) for ease of use. See section 2 for details.


b) eclassClassesProperties_51en.owl

This module contains the original eCl@ss property recommendations for each class. The recommendations can be used for spotting suitable properties when annotating a product or service or when expressing a query. One important idea of eCl@ss is to standardize the properties used for describing similar items.


c) eclassPropertiesValues_51en.owl

This module contains the original eCl@ss value recommendations for all properties that support enumerative data typing. The recommendations can be used for spotting suitable values for a property or for validating whether existing data is referring to allowed values.


Module a) is the core ontology. Modules b) and c) capture supporting information that can be added to the ontology in use on demand.


The base URI for all ontology elements is


The naming scheme used for generating the identifiers for all ontology elements is defined in section 1.2.1.

1.1 Domain Scope and Content

Table 1 shows the amount of ontology components contained in eClassOWL 5.1.


Table 1. Amount of ontology elements in eCl@ssOWL


Type of Element


Product categories

(each represented by 3 ontology classes, see below)

Properties for describing products and services instances






Value Instances


Product categories that have a property recommendation


Total number of class-property statements


ObjectProperties that have a value recommendation


Total number of property-value statements



The total number of categories is distributed across various branches as shown in Table 2.

Figure 1 visualizes that data.


Table 2.  Breakdown of categories by top-level branches


Top-Level Category

Number of
Product or Service Categories

Organic chemicals


Automation, electrical-engineering, PLT


Office supplies, furniture, equipment, and papeterie


Machines, apparatus


Inorganic chemicals


Laboratory materials and technology


Auxiliary supplies, additives, formulations






Machine elements and fixings


Construction technology


Medicine, medical technology, life science




Packing materials


Installations (complete)






Industrial piping


Equipment for mining, metallurgical plants, rolling mills, and foundries


Home economics, home technology


Energy, basic chemicals, aux. agents


Machines or devices (for special applications)


Occupational safety, accident prevention


Semi-finished products, materials


Automotive technology




Figure 1. Bar chart showing the distribution of elements by top-level branches


Currently not included in the ontology are keywords, but the eCl@ss Web page at can be used to search suitable categories by keyword.

1.2 Quick Start – Using eClassOWL in 5 Minutes

In this section, we explain the usage of eClassOWL by two simple hands-on examples.


The URIs for all ontology components begin with


The ontology contains three types of entries, i.e.

-         classes for categories,

-         properties, and

-         enumerated values.


The URIs for all such elements are built by concatenating

-         the base URI,

-         one character denoting the type of ontology element (C=Class, P=Property, V=Value), and

-         the original primary key in eCl@ss 5.1.

1.2.1 Identifiers of Ontology Elements: Classes

As said, there are three types of ontology classes created for each eCl@ss category, which are further distinguished by adding a trailing sequence like “-gen” or “-tax” to the URI. The exact difference between these three types of ontology classes is explained in section 2. For understanding the scenarios, it is sufficient to assume that there exist three types of classes in the ontology:


Generic concept: The literal meaning of the respective category. “TV Set” in this sense means all actual TV sets.


Taxonomic concept: Everything that can be treated as an element of this category in the context of purchasing management. This includes also all TV-related items that a purchasing manager would buy from the same source.


Annotation concept: This one is a subclass of both and is used when saying that an actual instance is a particular type of product or service. When one wants to annotate a product, one would simply make it an instance of the respective annotation concept and does not need to care about the two others.


When one wants to query for suitable instances, one would search for instances of

  1. the generic concept, if one wants a true instance of this type (e.g. “I want an actual TV set”), and
  2. the taxonomic concept, if one searches also for all related items that are subordinate nodes in eCl@ss; usually the perspective is that of a buying organization.


Generic Products and Services Concepts: These classes represent the literal meaning of the respective class label, e.g. "TV Sets" encompasses all TV sets, but not any TV set-related item that might belong to a descendent of this category in eCl@ss. The reason for this is differentiation is that hierarchical classification standards often treat related categories which are no subclasses as descendents of a given category or this only in a particular context. Examples are "ice cubes" as a subcategory of "beverages" or "docking stations" as a subcategory of "computers".


The ID for generic products and services concepts is


C_<primary key in eCl@ss 5.1>-gen


"C_" denotes that it is a class. A human-readable label and a textual definition are given as rdfs:label and rdfs:comment.


Example: The ID of the generic product category "agricultural machine" (eCl@ss 5.1 category AKK255002) is


If you want to find an instance of agricultural machines, this would be the class to look out for.

Products and Services Concepts in the Taxonomy: These classes represent the respective category in the context of the original taxonomy. The ID is


C_<primary key in eClqss 5.1>-tax


Example: The ID of the category "agricultural machine" in the original taxonomy (eCl@ss 5.1 category AKK255002) is


Suitable instances are all instances of this product category and of all categories that are subcategories of this one in eCl@ss 5.1. Thus, instances of "maintenance for agricultural machines" might also be returned if you search for instances of this class. This would be the typical class to use when a shop manager wants to find all products in the agricultural machines segment, which includes related products from the perspective of a purchasing organization, or when integrating catalog data for human consumption, e.g. for print or Web catalogs that are browsed by humans.


Annotation concepts: In order to ease annotation, i.e. to be able to make a product instance an instance of both the respective generic and the respective taxonomic concept by a single statement, the ontology includes so-called “annotation classes” that are subclasses of both the respective generic and the taxonomic concepts. Such classes are to be used for the annotation of product instances. The respective ID is


C_<primary key in eClass 5.1>


Example: The ID of the Annotation concept for "agricultural machine" (eCl@ss 5.1 category AKK255002) is:

1.2.1 Identifiers of Ontology Elements: Properties and Property Values

eCl@ss contains a wealth of well-defined properties for product characteristics, e.g. "weight" or "screen size". They fall into two categories: (1) Datatype Properties and (2) Object Properties.


The ID for both types is


P_<primary key in eCl@ss 5.1>,


"P" denoting the fact that it is a property.


Example: The ID for the Datatype Property "Net Weight in kg" (primary key BAD875001 in eCl@ss 5.1) is


For some properties, eCl@ss defines enumerative values. The ID for such values is


V_<primary key in eCl@ss 5.1>,


"V" denoting the fact that it is a value.

1.2.3 Examples: Using eClassOWL in e-Business Scenarios

The following examples show how the eClassOWL ontology can be used for various e-Business scenarios.


The prefix "pcs" must be substituted by "".


Product Description in the Semantic Web


We assume that “Fendt Supermower“ is an agricultural machine (eCl@ss category AKK255002), its weight is 125.5 kg, and the manufacturer name is "Fendt". P_BAD875001 is the property “Net Weight in kg”, P_BAA001001 is the property “Manufacturer”, and P_BAA316001 is the property “Product Name” in the original eCl@ss specification. Assumed that the ID for this product instance[1] is “machine1”, the respective product description using the eCl@ss ontology would be as follows:


<pcs:C_AKK255002 rdf:ID="machine1">

 <pcs:P_BAD875001>125.50</pcs: P_BAD875001>  <!-- Net Weight -->

 <pcs:P_BAA001001>Fendt</pcs:P_BAA001001> <!-- Manufacturer -->

 <pcs:P_BAA316001>Fendt Supermower1234</pcs:P_BAA316001> <!-- Name -->



Now, we want to search for all agricultural machines in the ontology that weigh less than 160 kg. The respective RDQL query would be:


SELECT ?x, ?weight, ?productName, ?vendor WHERE

(?x, <rdf:type>, <pcs:C_AKK255002-gen>)

(?x, <pcs:P_BAA001001>, ?vendor)

(?x, <pcs:P_BAA316001>, ?productName)

(?x, <pcs:P_BAD875001>, ?weight)

AND ?weight <160


Because we want to get only instances of the generic product category, the class to be used in the query is C_AKK255002-gen, not C_AKK255002-tax. The latter could be used to determine all products that fall in the respective taxonomy category. For example, a store manager might want to see all products in this product segment, including maintenance and spare parts for agricultural machines. Just using the class ID C_AKK255002-tax  in the query would return exactly that.


Annotation of Incoming Invoices for Spend Analysis


As described, the usage of this ontology is not limited to product description. It can also be employed to tag incoming invoices for spend analysis and cost accounting. For this, we need the additional class „IncomingInvoice“ (a concept for paid invoices), the annotation property „costAccountingCategory“, and the data type property „totalInUSD“ for the total in US dollar.


<owl:Class rdf:ID="IncomingInvoice"/>

<owl:AnnotationProperty rdf:about="&pcs;costAccountingCategory"/>

<owl:DatatypeProperty rdf:ID="totalInUSD">

 <rdfs:domain rdf:resource="&pcs;IncomingInvoice"/>

 <rdfs:range rdf:resource="&xsd;float"/>




Then, we can annotate the incoming invoice “invoice1” over $ 1,200 for the above mentioned mower:


<pcs:IncomingInvoice rdf:ID="invoice1">


<pcs:costAccountingCategory rdf:resource="&pcs;C_AKK255002"/>



In order to find all incoming invoices related to the cost accounting category C_AKJ644002-tax (“Machine, device (for special applications)”, which is a parent node to C_AKK255002-tax) and its subclasses, we can use the following RDQL query:


SELECT ?x, ?total WHERE

(?x, <rdf:type> <pcs:IncomingInvoice>)

(?x, <pcs:costAccountingCategory>, ?y)   

(?y, <rdfs:subClassOf>  <pcs:C_AKJ644002-tax>)

(?x, <pcs:totalInUSD>, ?total)


Especially the fact that we have a sophisticated set of properties in the ontology allows for rich descriptions of the items, which eases rule-based content integration significantly. For example, we can use a combination of (1) taxonomy class information and (2) property ranges to automatically find the proper cost accounting category. A realistic scenario is that we infer the cost accounting ledger from a combination of the supplier name and the products and service category. For example, invoices referring to the category “Services (unclassified)” will be treated as “IT services” if the supplier is “IBM”, and “Building maintenance” if the supplier is “Southwest Carpet Cleaning”.


Accessing Recommended Properties and Property Values


We can also easily determine the recommended properties for a given class or the recommended property value instances for a given property with a simple RDQL query. As an arbitrary choice, the properties are assigned to the annotation class, and not to the generic or taxonomy concept.


Find recommended properties for C_AKK255002:

SELECT ?property WHERE

(<pcs:C_AKK255002>, <pcs:recommendedProperty> ?property)


Find recommended values for ObjectProperty P_XYZ001001:


(<pcs:P_XYZ001001>, <pcs:recommendedValue> ?value)


Note: Due to the size of the ontology, all known DL reasoners break when loading the full ontology. However, OWLIM can load and operate on the ontology.

2 Ontology Structure

In this section, we explain why eClassOWL contains multiple ontology classes for each original eCl@ss category, and document how the rich data typing of eCl@ss is mapped to standard data types in OWL.

2.1 Taxonomic Classes vs. Generic Classes

The hierarchy of eCl@ss was created on the basis of practical aspects of procurement, treating those commodities that “somehow” belong to a specific category, as descendents of this closest category. This makes e.g. “docking stations” a subcategory of “computers”. Now, we still can read the taxonomic relationship as a strict “rdfs:subClassOf” relationship (i.e. each instance of “docking station” is also an instance of “computers”). Then, however, the notion of the class “computers” is no longer that of any computer, but that of the category “computer” from the perspective of purchasing management, cost accounting, or spend analysis, where an incoming invoice for a docking station can be treated as an incoming invoice for a computer. The problem arises because we have to narrow down the semantics of the original informal standard when turning it into an ontology. Basically, informal hierarchical classifications implicitly contain two concepts for each category node: First the generic concept of the respective category (e.g. “computer”) and second the same concept in the context “element in this taxonomy”, the latter reflecting all the implicit assumptions of the creators of the taxonomy and the constraints resulting from the interpretation of the taxonomic relationship.

The most straightforward approach to deal with this is to define a transitive relationship “taxonomySubClassOf” that can be used to represent the original hierarchy in the taxonomy. Then, the original hierarchy would not be falsely used as the subsumption hierarchy, turning instances of “docking stations” into instances of “computers”, but would still be available for queries. However, this is not possible in OWL Lite, OWL DL, or RDF-S. In OWL Lite and OWL DL, it is not possible to define a transitive relation that links classes; such can only be annotation properties that cannot be assigned a formal semantics. In RDF-S, it is not possible to define transitivity of properties.


There are at least the following three approaches of transforming a given hierarchical standard into an OWL Lite or DL ontology:


  1. Create one class for each category and assume that the meaning of the hierarchical relationship is equivalent to rdfs:subClassOf.
  2. Create one class for each taxonomy category and represent the hierarchical relationship using an annotation property taxonomySubClassOf in OWL.
  3. Treat the category concepts as instances instead of classes and connect them using a transitive object property taxonomySubClassOf.


In RDF-S, only the first two alternatives are possible, with taxonomySubClassOf being a regular RDF property for solution 2. Approach 1 is chosen by both available transformations of UNSPSC into products and services ontologies [4] [5]. Solution 2 seems to be the most straightforward alternative, since the specific meaning of the taxonomic relationship is captured using a specific property, and the classes can still represent generic product concepts. The problem with this approach is that, in OWL Lite and OWL DL, a property that links classes with classes can only be an annotation property. Thus, it cannot be made a transitive property, and an OWL Lite or OWL DL reasoner will only see explicit statements. In other words, if class A is a taxonomySubClassOf of class B and class B is a taxonomySubClassOf of C, then the reasoner will not infer that class A is also a taxonomySubClassOf of class C. This limitation can be avoided by making the products and services concepts instances instead of classes, as described in solution 3. Then, the property “taxonomySubClassOf” can be an owl:ObjectProperty and can be made transitive. The downside of this approach is that one absolutely needs OWL Lite or OWL DL reasoning support in order to process the transitive nature of the property. We also think that it is not very intuitive to model categories, which are quite obviously classes, in the form of instances.


For eClassOWL, we use a fourth approach of transforming existing hierarchical standards into domain ontologies. The approach is described in full detail in [2] and [3]. Our approach is based on the idea of deriving two concepts for each original category, one reflecting the generic concept and another reflecting the taxonomy concept. The advantage of this solution is that it works with the “intersection” of RDF-S and OWL Lite, i.e. it does not require reasoning capabilities beyond rdfs:subClassOf. This minimal requirement on the ontology language has also advantageous effects from an implementation perspective.


The basic idea of this “gen/tax” approach is as following:


  1. We create two separate concepts for (1) the generic category and (2) the respective taxonomy category.
  2. We arrange the taxonomy concepts in a rdfs:subClassOf hierarchy that is identical to the original order in the taxonomy, but don’t do this for the generic concepts. The generic concepts are just named classes without any support for subsumption, but can be manually augmented at a later point in time. This split allows for capturing the hierarchy of taxonomy concepts without linking the generic concepts to incorrect superordinate classes.
  3. In order to ease annotation, we create one “annotation” class for each taxonomy node, which becomes an rdfs:subClassOf of both the respective generic and the respective taxonomy concept. With this construct, a single rdf:type statement is sufficient to make a resource an instance of both the generic and the taxonomy concept.


In the following, we illustrate the gen/tax approach using an example. The example is based on the sample products and services taxonomy shown in Figure 2.



Figure 2. Example of a hierarchical products and services classification schema.


Figure 3 illustrates how the two grey-shaded categories in Figure 2 can be represented using the gen/tax approach. The generic concept “TV Set” represents all TV Sets. The taxonomy concept “TV Set” represents “TV Set”-related instances in the context of the original taxonomy (“everything that shall be treated as a TV Set in the context of the ordering purpose of the original taxonomy”). The annotation concept, being a subclass of both, is just for convenience reasons and allows making an instance, e.g. the concrete TV set model “sony:TV-123” an instance of both the generic and the taxonomy concept with one single rdf:type statement.



Figure 3. The gen/tax approach: Separating the generic concept from the taxonomic concept


This approach allows preserving the original order of the taxonomy without narrowing down the semantics of the concepts to one application domain, and puts only minimal requirements on the expressiveness of the ontology language. One might argue that the generic classes are of little value, because they are just named classes. However, there are two counterarguments: First, more semantics cannot be automatically deduced from the input taxonomy. It might be desirable to infer more about these classes, but this means manual ontology engineering work. Keep in mind that the relevant standards for reuse are rather big with more than 20,000 concepts and are also volatile with multiple releases per year. Second, in combination with a library of properties, already a flat set of consensual, named classes can bring a lot for the application domain, e.g. in e-business.


The application of this approach for describing products is shown in Figure 4: The TV maintenance service ex:tv-set-repair is an instance of the annotation class “TV Set Maintenance”. This makes it also an instance of the generic product class “TV Set Maintenance (Generic)” and the taxonomy concept “TV Set Maintenance (Taxonomy)”. The second is a subclass of “TV Set (Taxonomy)”, but the first is not a subclass of “TV Set (Generic)”.


This yields exactly the distinction we want: When searching for a TV maintenance service, we look for instances of the generic class, and when looking for all items that belong to the taxonomy category, we use the taxonomy concept. For example, a store manager might want to find all products in the TV set segment. In this case, he or she also wants to find TV set cabling and maintenance, so the query will be based on the taxonomy concept. The taxonomic concepts on the right side are the narrow interpretations of the taxonomic categories and are arranged in the original hierarchical order. The generic concepts on the left side are the original, broad variants of the taxonomy concepts, not constrained by the implications of reading the taxonomic relationships as rdfs:subClassOf. The convenience classes in the middle ease the annotation task, since an instance can be made an instance of both the generic and the taxonomy concept by just one rdf:type statement.



Figure 4. Usage of the gen/tax ontology for product description

2.2 Datatyping


The data types used in eCl@ss cannot be directly mapped to standard XSD data types. eCl@ss uses over hundred different data type definitions based on ISO 9735 and ISO 6093, which are far more specific than available standard XSD data types. There are basically two options for this transformation:

  1. One can use a rather coarse mapping from the specific ISO 9735 and ISO 6093 data types to standard XSD data types, loosing constraints of the original definition (e.g. field length, number of digits, …).
  2. Alternatively, it seems possible to create specific XSD data types or use constraining facets (see [6], section 4.3) to further constrain the standard XSD data types.


Given the yet limited support of reasoning for data types in Semantic Web tools, the first approach seems currently more appropriate. Thus, eClassOWL represents the rich eCl@ss data types using the three XSD data types currently supported by reasoners, i.e. xsd:integer, xsd:float, and xsd:string. We mapped them as follows:

-        all data types of the kind NR1* to xsd:integer,

-        all data types of the kind NR2* and NR3* to xsd:float, and

-        all others to xsd:string.


Generally spoken are the original data type definitions more restrictive. Thus any legal eCl@ss data can be properly represented in the OWL variant. Precision issues could result when OWL data has to be converted back to fit into the original eCl@ss specification.

3 eClassOWL Ontology Modeling Patterns


Table 3 shows the OWL modeling patterns used in eClassOWL as RDF/XML.


Table 3. Summary of the OWL Modeling Patterns used in eClassOWL


Classes and Hierarchy

<owl:Class rdf:ID="C_AKK255002-gen">
<rdfs:label xml:lang="en">Agricultural machine [generic concept]</rdfs:label>
<rdfs:comment xml:lang="en">Agricultural machine [generic concept]</rdfs:comment>

<owl:Class rdf:ID="C_AKK255002-tax">
<rdfs:label xml:lang="en">Agricultural machine [taxonomy concept]</rdfs:label>
<rdfs:comment xml:lang="en">Agricultural machine [taxonomy concept]</rdfs:comment>
<rdfs:subClassOf rdf:resource="&pcs;C_AKJ644002-tax"/>

<owl:Class rdf:ID="C_AKK255002">
<rdfs:label xml:lang="en">Agricultural machine</rdfs:label>
<rdfs:comment xml:lang="en">Agricultural machine</rdfs:comment>
<rdfs:subClassOf rdf:resource="&pcs;C_AKK255002-tax"/>
<rdfs:subClassOf rdf:resource="&pcs;C_AKK255002-gen"/>


<owl:DatatypeProperty rdf:ID="P_AAA826001">
<rdfs:domain rdf:resource="&owl;Thing"/>
<rdfs:range rdf:resource="&xsd;float"/>
<rdfs:label xml:lang="en">Input signal range max. (Unit: V)</rdfs:label>
<rdfs:comment xml:lang="en">Maximum value of the measured variable
  with a specified accuracy.</rdfs:comment>


<pcs:PropertyValue rdf:ID="V_WPB317003">
<rdfs:label xml:lang="en">Highly explosive (Highly explosive)</rdfs:label>
<rdfs:comment xml:lang="en">Highly explosive</rdfs:comment>


dc:subject for classes and properties (currently not included in the ontology)

Class-Specific Property Lists

<owl:AnnotationProperty rdf:about="&pcs;recommendedProperty"/>
<owl:Class rdf:ID="C_AAA361001">
<pcs:recommendedProperty rdf:resource="&pcs;P_AAA001001"/>
<pcs:recommendedProperty rdf:resource="&pcs;P_AAA252001"/>

Value Recommendations

<owl:AnnotationProperty rdf:about="&pcs;recommendedValue"/>
<owl:ObjectProperty rdf:ID="P_AAA008001">
<pcs:recommendedValue rdf:resource="&pcs;V_WAA012001"/>
<pcs:recommendedValue rdf:resource="&pcs;V_WAA013001"/>


4 Frequently Asked Questions


4.1 How can I quickly find the suitable product class and suitable properties?

The most feasible way is to search the proper category in the online version of eCl@ss 5.1, available in multiple languages at or This way you can easily find the primary keys of the relevant category (e.g. “AAA124001”) and suitable properties (similar form). Refer to section 1.2 for a description of how to derive the proper identifiers (e.g. “C_AAA124001-gen”) from these primary keys.


Make sure that you are searching in the proper version (5.1) of eCl@ss. eCl@ss is updated frequently, and while we try to create updated versions of eClassOWL in a timely manner, there might be a newer version of eCl@ss available before eClassOWL will have been updated.

4.2 What is the difference between the taxonomic concepts and the generic concepts?

In a nutshell, the generic concepts entail all actual products and services when one reads the category label literally. So “computers” means actual computers. The taxonomic concepts are wider in scope and include everything that can be regarded as belonging into the respective category in the context of purchasing management. In particular, related items, maintenance, and spare parts may also be included. For a detailed explanation, see section 2.1 and [3] or [2].

4.3 What are the annotation concepts meant for?

They are just for convenience, because in most cases, we want an actual product instance to be an instance of both the generic and the taxonomy class. Each annotation concept is a subclass of the respective two generic and taxonomic concepts. See section 2.1 for details.

4.4 What is the range and domain of properties?

Since in OWL, the domain and range constructs are used to infer class membership and do not restrict the domain and range, they cannot be used to enforce proper usage. See [7] for an explanation. Thus, the domain of all properties in eClassOWL is owl:Thing.


The range for all Datatype Properties is xsd:integer, xsd:float, or xsd:string, according to the mapping described in section 2.2. The range for all Object Properties is pcs:PropertyValue.


4.5 Why are you using cryptic identifiers like AAA123345?

Mainly for two reasons: First, it cannot be assumed that the human-readable labels of eCl@ss are unique. Second, we want to establish an unambiguous reference to the exact definition of the classes, so that users can look up the description of a concept in the online version of eCl@ss.

Human-readable labels and a textual description are given for each class by adding rdfs:label and rdfs:comment to the classes.

4.6 The generic classes do not follow a subsumption hierarchy – aren’t they completely useless?

It is true that the generic products and services concepts do not support much reasoning, for they are just named classes. However, the semantic richness needed for most business scenarios will come from the usage of the huge collection of properties. An example is a parametric search like “find all TV sets made by Siemens with a screen size between 10 and 15 inches and 12 Volt power-supply”.


Of course, we agree that a consistent subsumption hierarchy and a greater amount of e.g. axioms would be generally desirable. On the other hand, we see no simple way of automatically adding these features, because they cannot be easily derived from the input standard. Additionally, we will have to put the resources necessary for the respective axiomatic enrichment in relation to the gain in automation and the resulting economies. In a domain as dynamic as products and services it should not be taken for granted that the business benefit will always outweigh the cost of the creation of the respective ontologies, nor that we are able to yield axiomatic richness during the lifespan of the concept, i.e. as long as the category is still relevant.

4.7 Why is the ontology so damn big?

This is mainly because eCl@ss contains exactly this much of content. However, we think that the size of eClassOWL is not a serious argument against its usefulness. OWLIM, for example, can load the full ontology in about 33 seconds. For three reasons, we assume that quite the opposite is true, i.e. that the size of eClassOWL is not a bug but a feature: First, we must stress that ontologies of this size will rather be the lower limit of what we will have to expect for real E-business ontologies, since the required conceptual specificity of product description in non-toy scenarios is very high. Using traditional relational databases and COTS application software, even small companies are dealing with such amounts of data. Second, we conclude from the experienced limitations with current tools not that the ontology is too big, but that many prototypes yielded by the Semantic Web community have so far not achieved scalability beyond toy applications. Third, we expect our ontology to become a widely used benchmark among the developers of repositories and tools, and will thus hopefully contribute to a quick gain in scalability of Semantic Web infrastructure.




[1]        M. Hepp, "A Methodology for Deriving OWL Ontologies from Products and Services Categorization Standards," presented at the 13th European Conference on Information Systems (ECIS2005), Regensburg, Germany, 2005. Available at

[2]        M. Hepp, "Representing the Hierarchy of Industrial Taxonomies in OWL: The gen/tax Approach," presented at the ISWC Workshop Semantic Web Case Studies and Best Practices for eBusiness (SWCASE05), Galway, Irland, 2005. Available at

[3]        M. Hepp, "Products and Services Ontologies: A Methodology for Deriving OWL Ontologies from Industrial Categorization Standards," Int'l Journal on Semantic Web & Information Systems (IJSWIS), vol. 2, pp. 72-99, 2006.

[4]        M. Klein, "DAML+OIL and RDF Schema representation of UNSPSC," available at, retrieved April 23, 2004.

[5]        D. L. McGuinness, "UNSPSC Ontology in DAML+OIL," available at, retrieved November 5, 2004.

[6]        W3C, "XML Schema Part 2: Datatypes Second Edition. W3C Recommendation 28 October 2004," available at, retrieved November 15, 2004.

[7]        J. de Bruijn, R. Lara, A. Polleres, and D. Fensel, "OWL DL vs. OWL Flight: Conceptual Modeling and Reasoning for the Semantic Web," presented at 14th International World Wide Web Conference (WWW2005), Chiba, Japan, 2005.




[1] We do not elaborate in here that what is often exposed as URIs are not product instances, but IDs for makes and models. The same class can be used to existentially quantify such an instance.