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 http://www.eclass.de
(in German) or http://www.eclass-online.com/
(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:
- Products and services concepts (e.g. “TV Set”),
- product properties (e.g. “screen size”),
- values for enumerated data types,
- a hierarchy of the product concepts reflecting the
perspective of a buying organization (!),
- recommendations which properties should be used for which
type of products, and
- 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,
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
http://ontologies.deri.org/eclass/5.1/#
The naming scheme used for generating the identifiers for
all ontology elements is defined in section 1.2.1.
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
|
Number
|
|
Product categories
|
25,658
(each represented by 3
ontology classes, see below)
|
|
Properties for describing products and
services instances
|
5,525
|
|
DatatypeProperties
|
3,232
|
|
ObjectProperties
|
2,293
|
|
Value
Instances
|
4,544
|
|
Product
categories that have a property recommendation
|
21,100
|
|
Total number
of class-property statements
|
403,859
|
|
ObjectProperties
that have a value recommendation
|
2,293
|
|
Total
number of property-value statements
|
10,000
|
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
|
5,312
|
|
Automation, electrical-engineering, PLT
|
2,659
|
|
Office supplies, furniture, equipment, and papeterie
|
1,992
|
|
Machines, apparatus
|
1,793
|
|
Inorganic chemicals
|
1,464
|
|
Laboratory materials and technology
|
1,327
|
|
Auxiliary supplies, additives, formulations
|
1,216
|
|
Services
|
1,064
|
|
Tools
|
1,033
|
|
Machine elements and fixings
|
964
|
|
Construction technology
|
802
|
|
Medicine, medical technology, life science
|
760
|
|
Polymers
|
726
|
|
Packing materials
|
620
|
|
Installations (complete)
|
521
|
|
Marketing
|
504
|
|
IT
|
489
|
|
Industrial piping
|
440
|
|
Equipment for mining, metallurgical plants, rolling mills, and
foundries
|
432
|
|
Home economics, home technology
|
351
|
|
Energy, basic chemicals, aux. agents
|
258
|
|
Machines or devices (for special applications)
|
255
|
|
Occupational safety, accident prevention
|
247
|
|
Semi-finished products, materials
|
226
|
|
Automotive technology
|
203
|
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 http://www.eclass-online.com/
can be used to search suitable categories by keyword.
In this section, we explain the usage of eClassOWL by two
simple hands-on examples.
The URIs for all ontology components begin with
http://ontologies.deri.org/eclass/5.1/#
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.
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
- the generic concept, if one wants a true instance
of this type (e.g. “I want an actual TV set”), and
- 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
http://ontologies.deri.org/eclass/5.1/#C_AKK255002-gen
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
http://ontologies.deri.org/eclass/5.1/#C_AKK255002-tax
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:
http://ontologies.deri.org/eclass/5.1/#C_AKK255002
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
http://ontologies.deri.org/eclass/5.1/#P_BAD875001
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.
The following examples show how the eClassOWL ontology can
be used for various e-Business scenarios.
The prefix "pcs" must be substituted by
"http://ontologies.deri.org/eclass/5.1/#".
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 -->
</pcs:C_AKK255002>
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"/>
</owl:DatatypeProperty>
Then, we can annotate the incoming invoice “invoice1” over $
1,200 for the above mentioned mower:
<pcs:IncomingInvoice
rdf:ID="invoice1">
<pcs:totalInUSD>1200.00</pcs:totalInUSD>
<pcs:costAccountingCategory
rdf:resource="&pcs;C_AKK255002"/>
</pcs:IncomingInvoice>
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:
SELECT
?value WHERE
(<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.
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.
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:
- Create one class for each category and assume that the
meaning of the hierarchical relationship is equivalent to rdfs:subClassOf.
- Create one class for each taxonomy
category and represent the hierarchical relationship
using an annotation property taxonomySubClassOf in OWL.
- 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:
- We create two separate concepts for (1)
the generic category and (2) the respective taxonomy
category.
- 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.
- 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
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:
- 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, …).
- 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.
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>
<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>
<pcs:hierarchyCode>17080000</pcs:hierarchyCode>
<rdfs:subClassOf rdf:resource="&pcs;C_AKJ644002-tax"/>
</owl:Class>
<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:Class>
|
|
Properties
|
|
<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>
</owl:DatatypeProperty>
|
|
Values
|
|
<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>
</pcs:PropertyValue>
|
|
Keywords
|
|
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"/>
</owl:Class>
|
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"/>
</owl:ObjectProperty>
|
The most feasible way is to search the proper category in
the online version of eCl@ss 5.1, available in multiple languages at http://www.eclass.de or http://www.eclass-online.com/. 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.
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].
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.
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.
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.
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.
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 http://www.heppnetz.de
[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 http://www.heppnetz.de
[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 http://www.cs.vu.nl/~mcaklein/unspsc/,
retrieved April 23, 2004.
[5] D. L. McGuinness, "UNSPSC Ontology in
DAML+OIL," available at http://www.ksl.stanford.edu/projects/DAML/UNSPSC.daml,
retrieved November 5, 2004.
[6] W3C, "XML Schema Part 2: Datatypes Second
Edition. W3C Recommendation 28 October 2004," available at http://www.w3.org/TR/xmlschema-2/,
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.
