eClassOWL - The Web Ontology for Products and Services

OWL Representation of the eCl@ss Classification Standard

This version: http://www.heppnetz.de/projects/eclassowl/20100418/

Latest version: http://www.heppnetz.de/projects/eclassowl/

Previous version: http://www.heppnetz.de/projects/eclassowl/20060616/

Author: Martin Hepp and Andreas Radinger

Version: 5.1.4

Resources

Project Web Site: http://www.heppnetz.de/projects/eclassowl/

Downloads: eClassOWL 5.1.4 Products and Services Ontology

• http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/ (RDF/XML or HTML via content negotiation - Warning: The files are very large - 38.3...71.8 MB)
• RDF/XML (Warning: The file is very large - 38.3 MB)
• HTML (Warning: The file is very large - 71.8 MB)
• ZIP: RDF/XML+HTML (eClassOWL 5.1.4 ontology and documentation, compressed - RDF/XML + HTML, zip, 4.7 MB)

Note: The current naming schema of eClassOWL requires any client to retrieve the full RDF/XML or HTML representation, even if just a single conceptual element is of interest. We are preparing for the release of a new version eClassOWL 6.x, which will be a major upgrade based on eCl@ss 6.x. Among other changes, it will use slash URIs (http://www.example.de/ID) instead of hash URIs (http://www.example.de/#ID) and thus allow serving smaller chunks of code for individual elements.

Mailing Lists:

• eClassOWL: http://ebusiness-unibw.org/cgi-bin/mailman/listinfo/eclassowl
• GoodRelations: http://ebusiness-unibw.org/cgi-bin/mailman/listinfo/goodrelations

TABLE OF CONTENTS

1. Overview

eClassOWL is an OWL ontology for describing the types and properties of products and services on the Semantic Web (also known as the "Web of Linked Data"). eClassOWL is meant to be used in combination with the GoodRelations ontology for e-commerce, which covers the commercial aspects of offers and demand, e.g. prices, payment, or delivery options.

eClassOWL is a project that has been initiated by Martin Hepp in 2003 and is now being hosted and maintained by the E-Business and Web Science Research Group at the Universität der Bundeswehr München.

1.1 Background

For describing the nature and features of products, there are many established standards from traditional EDI environments, e.g. UNSPSC, eCl@ss, or RNTD.
Among those, eCl@ss is the most sophisticated one, because it covers a wide range of products and services (more than 30,000 types) and defines a huge number of properties for products features (more than 5,000 properties). However, when we want to use such categorization standards for the Semantic Web, we have to make sure that we properly understand the meaning and structure of the existing standard and create a consistent and correct transformation. Fortunately for you, this work has already been done in the case of eCl@ss. For the full background on the underlying research, see the references section at the end of this page.

1.2 eClassOWL and GoodRelations

When you want to publish rich meta-data about the products or services that your business is offering, you need a machine-readable language for describing at least two aspects: First, the type and features of your products or services (e.g. "a TV set with a screen size of 20 inches"), and second the commercial details of your offer (e.g. price and payment options). For the latter problem, the GoodRelations ontology is readily available and widely in use, e.g. by BestBuy, Yahoo, O'Reilly, and others.

eClassOWL is fully compliant with the GoodRelations ontology and follows all guidelines given here. More information about GoodRelations-compliant ontologies for product types and product features is available here.

1.3 Minimal Example

The following is a simple example of describing a pencil using eClassOWL 5.1.4.

• The eClass 5.1.4 ID for the class "Pencil" is AKF303003
• The eClass 5.1.4 ID for the property "Length" is BAF559001
• The eClass 5.1.4 ID for the property "Design of tip state" is BAG073001
• The eClass 5.1.4 ID for the value "pointed" is BAC386001

1.3.1 Turtle Syntax

@prefix eco: <http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#> .
@prefix gr: <http://purl.org/goodrelations/v1#> .
@prefix foo: <http://www.mystore.com/semanticweb/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

# myPencil is a pencil with a pointed tip and a length of 150 mm

foo:myPencil
    # Class "Pencil": 24-24-01-01 [ AKF303003 ]
    a eco:C_AKF303003-gen ;
    # Length [BAF559001] 150 mm
    eco:P_BAF559001 foo:QuantitativeValueFloat_1;
    # Design of tip state [BAG073001] = "pointed" [BAC386001]
    eco:P_BAG073001 eco:V_BAC386001.

foo:QuantitativeValueFloat_1
    a gr:QuantitativeValueFloat ;
    gr:hasUnitOfMeasurement "MMT"^^xsd:string ;
    gr:hasValueFloat "150.0"^^xsd:float .

1.3.2 RDFa Syntax

...
</html>
<body>
<div xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
     xmlns="http://www.w3.org/1999/xhtml"
     xmlns:eco="http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#"
     xmlns:foo="http://www.mystore.com/semanticweb/"
     xmlns:gr="http://purl.org/goodrelations/v1#"
     xmlns:xsd="http://www.w3.org/2001/XMLSchema#">
   <div about="http://www.mystore.com/semanticweb/myPencil" typeof="eco:C_AKF303003-gen">
      <div rel="eco:P_BAF559001">
         <div about="http://www.mystore.com/semanticweb/QuantitativeValueFloat_1" typeof="gr:QuantitativeValueFloat">
            <div property="gr:hasUnitOfMeasurement" content="MMT" datatype="xsd:string"></div>
            <div property="gr:hasValueFloat" content="150.0" datatype="xsd:float"></div>
         </div>
      </div>
      <div rel="eco:P_BAG073001" resource="http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#V_BAC386001"></div>
   </div>
</div>
</body>
</html>

1.3.3 RDF/XML Syntax

<?xml version="1.0"?>
<rdf:RDF xmlns:gr="http://purl.org/goodrelations/v1#"
         xmlns:foo="http://www.mystore.com/semanticweb/"
         xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
         xmlns:eco="http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#"
         xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
	<eco:C_AKF303003-gen rdf:about="http://www.mystore.com/semanticweb/myPencil">
		<eco:P_BAF559001>
			<gr:QuantitativeValueFloat rdf:about="http://www.mystore.com/semanticweb/QuantitativeValueFloat_1">
				<gr:hasUnitOfMeasurement rdf:datatype="http://www.w3.org/2001/XMLSchema#string">MMT</gr:hasUnitOfMeasurement>
				<gr:hasValueFloat rdf:datatype="http://www.w3.org/2001/XMLSchema#float">150.0</gr:hasValueFloat>
			</gr:QuantitativeValueFloat>
		</eco:P_BAF559001>
		<eco:P_BAG073001 rdf:resource="http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#V_BAC386001" />
	</eco:C_AKF303003-gen>
</rdf:RDF>

2. GenTax Modeling Pattern and Differences to eCl@ss

eClassOWL tries to preserve as much of the original semantics of eCl@ss as possible. However, due to the differences in origin and focus, creating a useful OWL variant from eCl@ss is not as straightforward as it may appear. For a discussion of the full background, please see the papers in the references section at the end of this page.

2.1 Classes

A major difference is that eClassOWL defines two OWL classes per each eCl@ss product or service category:

• A "generic" class, representing actual products or services of the respective type, and
• A "taxonomic" class, representing a wider set of objects that may be related to that category.

This is because the hierarchy in eCl@ss is not a proper subsumption hierarchy; sometimes, related types are subcategories of a main category (e.g. "maintenance" as a subcategory of "machine"):

Figure 1. The hierachy in eCl@ss is no consistent subsumption hierarchy.

Also, the same categories can be used to describe different types of objects. For example, some companies want to use eCl@ss and eClassOWL for annotating products, while others use it for annotating invoices or representing staff expertise. But quite clearly, a sales manager with expertise in TV sets is not a TV set, and neither is an invoice related to a TV set a TV set ☺. Within closed EDI settings, such misunderstandings are highly theoretical problems, because you will have a shared context between the provider and the consumer of the data. On a Web scale, however, such ambiguity would be problematic.

Figure 2. The Semantic Web requires unambiguous class definitions.

Accordingly, eClassOWL represents the four classes from eCl@ss as shown in Figure 1 using the following eight classes:

Figure 3. Representation of the classes from Figure 1 in eClassOWL.

The theoretical background is given in the following paper:

Hepp, Martin; de Bruijn, Jos: GenTax: A Generic Methodology for Deriving OWL and RDF-S Ontologies from Hierarchical Classifications, Thesauri, and Inconsistent Taxonomies, Proceedings of the 4th European Semantic Web Conference (ESWC 2007), June 3-7, 2007, Innsbruck, Austria, Springer LNCS, Vol. 4519, pp. 129-144, 2007.

You may also find the SKOS2OWL documentation useful in this regard.

Now, from a practical perspective, there are simple rules of thumb:

1. When describing an object, use the generic concept for actual products or product models and the taxonomic concept for anything that is neither a product nor a product model.
2. When querying RDF data, search for instances of
   • the generic concept if what you need is an instance of exactly this class of products, and
   • the taxonomic concept, if you want to expand your query to include all related categories that are subordinate nodes in eCl@ss.

As said, eClassOWL is fully compliant with the GoodRelations ontology and follows all guidelines given here. Thus, all "gen" classes are rdfs:subClassOf of the GoodRelations class gr:ProductOrService.

2.2 Properties

eCl@ss supports two basic types of properties:

• datatype properties that can be used with any literal value of the respective datatype and
• properties with values predefined in eCl@ss.

The GoodRelations meta-model, which is the conceptual foundation for eClassOWL, supports three types of product properties, i.e.

• quantitative properties, for typical product features with a numeric range;
• qualitative properties, for product features with predefined value instances, and
• datatype properties, used only for a few features with the datatypes string, date, time, datetime, or boolean.

Another difference is that eCl@ss supports only one unit of measurement for each property, while GoodRelations and eClassOWL both separate the unit from the property, which improves data interoperability.

The exact mapping rules applied during the conversion are described in the GoodRelations Technical Report on pages 43 and 44. The basic approach is as follows:

• If there are predefined values in eCl@ss, the property will be a qualitative property and all values will be defined as value instances in eClassOWL.
• If there are no predefined values given, we look at the "Field format" of the original eCl@ss property ("?" and "*" are wildcards in the following):
  • The type "V?" means the eCl@ss property is a GoodRelations datatype property and the range is xsd:boolean.
  • The types "NR2*" or "NE3*" mean that it is a GoodRelations quantitative property and the range is an instance of the GoodRelations value class gr:QuantitativeValueFloat.
  • If the type is "NR1*", then the check is a bit more difficult, because we have to find out whether we are dealing with a numerical token (e.g. an identifier) or with an integer number. In those cases, itÕs best to check the eClassOWL documentation in HTML to see whether it is defined as a GoodRelations quantitative or a datatype property.

The domain of all properties in eClassOWL is gr:ProductOrService.

2.3 Values

All predefined values in eCl@ss are represented as instances of the class gr:QualitativeValue in eClassOWL.

3. URI Schema

All eClassOWL URIs are derived by combining

• the base URI of eClassOWL 5.1.4 ("http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#")
• a prefix for classes ("C_"), properties (P_), or values (V_),
• the original eCl@ss identifier (e.g. "AKF303003"), and
• the suffix "-gen" or "-tax" for distinguishing "generic" from "taxonomic" classes.

As said, there are two classes defined in eClassOWL for each original eCl@ss category, one "generic" class, representing actual products or services or product models of the respective type, and another "taxonomic" class, representing a wider set of objects that may be related to that category.

Their URIs are derived from the eCl@ss identifier (not the eCl@ss hierarchy code) as follows:

http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#C_<ID>-gen

http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#C_<ID>-tax

http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#P_<ID>

http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#V_<ID>

4. Usage

Since eCl@ss is very large, it is often more convenient to use the eCl@ss Web site to find the proper classes and properties instead of searching the ontology file directly.

Make sure to select "eCl@ss 5.1.4", other wise the identifiers won't work.

Assume we want to describe a pencil with 150 mm length and a pointed tip. We would then follow three steps:

4.1 Step 1: Find Class URI

First, we have to find the proper class ID. If you search for "pencil" in eCl@ss, you will get several candidate classes. The following class seems to be the best match:

Classification: 24-24-01-01 [ AKF303003 ]

The eight-digit code "24-24-01-01" reflects the position of the class in the eCl@ss hierarchy, while the code "AKF303003" is a stable identifier for that class. For eClassOWL, always use the alphanumeric class identifier, i.e. AKF303003 in this case.

Now, we have to decide whether we want to use the "generic" class or the "taxonomic" class. There is simple rule:

• If we want to describe an actual product or a product model ("datasheet") of that type, use the "generic" class.
• If it is something else, e.g. an invoice or a picture related to that type of product, use the "taxonomic" class.

Next, you derive the URI for the product class by combining

• the base URI of eClassOWL 5.1.4 ("http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#")
• the prefix for classes ("C_")
• the original eCl@ss class identifier ("AKF303003"), and
• the suffix "-gen" for actual products or "-tax" for anything else.

In our example, the resulting URI is

http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#C_ AKF303003-gen or
eco:C_AKF303003-gen

if we defined the prefix "eco" for "http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#".

4.2 Step 2: Find Property URIs

Next, we have to find the eCl@ss IDs for all properties that we want to use. In our example, we may want to use the following two (you find them as part of the Web search results from the previous step):

• The property "Length", for which the eCl@ss ID is BAF559001.
• The property "Design of tip state", for which the eCl@ss ID is BAG073001.

We derive the URIs for the two properties in a similar fashion as for the class, i.e. by combining

• the base URI of eClassOWL 5.1.4 ("http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#"),
• the prefix for properties ("P_"), and
• the original eCl@ss class identifiers ("BAF559001" and "BAG073001").

The resulting URIs are

or

The domain of all eClassOWL properties is gr:ProductOrService.

4.3 Step 3: Encoding Values

As a last step, we have to encode the property values for our two properties. In order to do so, we first have to find out the proper ranges for each property. The most straightforward way to determine the range is to search the eClassOWL HTML file.

Alternatively, you can also use the following heuristics: First, click on the ID of your property in the eCl@ss search results on the Web. If it lists "Values", then you are dealing with a qualitative property. In our example, this holds for the property "BAG073001", with the following value instances defined in eCl@ss:

BAC386001 - pointed
BAD004001 - unsharpened

Write down the IDs of the matching value, e.g. BAC386001 for "pointed".

In that case, you can directly derive the URI for that value by combining

• the base URI of eClassOWL 5.1.4 ("http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#"),
• the prefix for values ("V_"), and
• the original eCl@ss class identifiers ("BAC386001").

The resulting URI is

or

Then you link from the product URI with the property eco:P_BAG073001 ("Design of tip state") to the value URI eco:V_BAC386001.

For quantitative properties, you have to create instances of the GoodRelations class gr:QuantitativeValueFloat (for float values) or gr:QuantitativeValueInteger (for integer values).

Those collate the point value and the unit of measurement. For encoding the unit of measurement, the UN/CEFACT Common Code standard is used.

In our example, the value "150 mm" is encoded as follows ("MMT" is the UN/CEFACT Common Code for millimeters; for a list, see here):

foo:QuantitativeValueFloat_1
    a gr:QuantitativeValueFloat ;
    gr:hasUnitOfMeasurement "MMT"^^xsd:string ;
    gr:hasValueFloat "150.0"^^xsd:float .

Then you link from the product URI with the property eco:P_BAF559001 ("Length") to foo:QuantitativeValueFloat_1.

For datatype properties, simple attach the lexical representation of the value as an RDF literal.

4.4 Examples

The complete example in Turtle notation would look as follows:

@prefix eco: <http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#> .
@prefix gr: <http://purl.org/goodrelations/v1#> .

# myPencil is a pencil with a pointed tip and a length of 150 mm
# The eClass 5.1.4 ID for the class "Pencil" is AKF303003
# The eClass 5.1.4 ID for the property "Length" is BAF559001
# The eClass 5.1.4 ID for the property "Design of tip state" is BAG073001
# The eClass 5.1.4 ID for the value "pointed" is BAC386001

foo:myPencil
    # Class "Pencil": 24-24-01-01 [ AKF303003 ]
    a eco:C_AKF303003-gen ;
    # Length [BAF559001] 150 mm
    eco:P_BAF559001 foo:QuantitativeValueFloat_1 ;
    # Design of tip state [BAG073001] = "pointed" [BAC386001]
    eco:P_BAG073001 eco:V_BAC386001 .

foo:QuantitativeValueFloat_1
    a gr:QuantitativeValueFloat ;
    gr:hasUnitOfMeasurement "MMT"^^xsd:string ;
    gr:hasValueFloat "150.0"^^xsd:float .

Here are a few more examples:

foo:Pencil_150
    # Class "Pencil": 24-24-01-01 [ AKF303003 ]
    a eco:C_AKF303003-gen, gr:ProductOrServiceModel ;
    rdfs:label "Heavy-duty pencil, 150 mm long, pointed tip"@en ;
    # Length [BAF559001] 150 mm
    eco:P_BAF559001 foo:QuantitativeValueFloat_1 ;
    # Design of tip state [BAG073001] = "pointed" [BAC386001]
    eco:P_BAG073001 eco:V_BAC386001 .

foo:QuantitativeValueFloat_1
    a gr:QuantitativeValueFloat ;
    gr:hasUnitOfMeasurement "MMT"^^xsd:string ;
    gr:hasValueFloat "150.0"^^xsd:float .

foo:somePencils 
    a eco:C_AKF303003-gen, gr:ProductOrServicesSomeInstancesPlaceholder ;
    gr:hasMakeAndModel foo:Pencil_150 .

foo:myPencil 
    a eco:C_AKF303003-gen, gr:ActualProductOrServiceInstance ;
    gr:hasMakeAndModel foo:Pencil_150 .

foo:Seller 
    a gr:BusinessEntity ;
    gr:legalName "Miller Stationery LLC"@en ;
    gr:offers foo:myOffering1 .

foo:myOffering1
    a gr:Offering ;
    rdfs:comment "We sell one pencil for 1 EURO"@en ;
    gr:includes foo:somePencils ;
    gr:hasBusinessFunction gr:Sell ;
    gr:validFrom "2010-01-01T00:00:00+01:00"^^xsd:dateTime ;
    gr:validThrough "2012-12-31T00:00:00+01:00"^^xsd:dateTime ;
    gr:hasPriceSpecification foo:Price_1 .

foo:Price_1
    a gr:UnitPriceSpecification ;
    gr:hasCurrency "EUR"^^xsd:string ;
    gr:hasCurrencyValue "1"^^xsd:float ;
    gr:hasUnitOfMeasurement "C62"^^xsd:string .

foo:Seller 
    gr:offers foo:myOffering2 .

foo:myOffering2
    a gr:Offering ;
    rdfs:comment "We sell five pencils for 2 EURO"@en ;
    gr:includesObject foo:TypeAndQttySpec ;
    gr:hasBusinessFunction gr:Sell ;
    gr:validFrom "2010-01-01T00:00:00+01:00"^^xsd:dateTime ;
    gr:validThrough "2012-12-31T00:00:00+01:00"^^xsd:dateTime ;
    gr:hasPriceSpecification foo:Price_2 .

foo:TypeAndQttySpec 
    a gr:TypeAndQuantityNode ;
    gr:amountOfThisGood "5.0"^^xsd:float ;
    gr:hasUnitOfMeasurement "C62"^^xsd:string ;
    gr:typeOfGood foo:somePencils .

foo:Price_2
    a gr:UnitPriceSpecification ;
    gr:hasCurrency "EUR"^^xsd:string ;
    gr:hasCurrencyValue "2"^^xsd:float ;
    gr:hasUnitOfMeasurement "C62"^^xsd:string .

4.5 SPARQL Queries

In this section, we give examples of using eClassOWL for querying the Web of Linked Data. Note that GoodRelations and eClassOWL are usually employed in combination, so the respective part of the GoodRelations documentation is also relevant in here.

You can try all queries against the demo file at

Some of the queries require RDFS inferencing , i.e. the RDF triplestore (database) must compute at least part of the implicit statements resulting from rdfs:subClassOf and rdfs:subPropertyOf relations. The example file available from the URI above contains all implicit triples explicitly, so it will also work without inferencing (except those for example 4).

All queries require the following prefix declarations:

PREFIX eco: <http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/#>
PREFIX gr: <http://purl.org/goodrelations/v1#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

SELECT ?pencil, ?length WHERE
{
    ?pencil a eco:C_AKF303003-gen.
    {
        {?pencil a gr:ActualProductOrServiceInstance.}
    UNION
        {?pencil a gr:ProductOrServicesSomeInstancesPlaceholder.}
    }
    ?pencil eco:P_BAF559001 ?value.
    ?value gr:hasMaxValue ?length.
    ?value gr:hasUnitOfMeasurement "MMT"^^xsd:string.
    # The following alternative is more tolerant:
    # ?value gr:hasUnitOfMeasurement ?unit.
    # FILTER (regex(?unit, "^MMT")
    FILTER (?length >=100)
}
LIMIT 10

SELECT ?model WHERE
{
    ?model a eco:C_AKF303003-gen.
    ?model a gr:ProductOrServiceModel.
    ?model eco:P_BAG073001 eco:V_BAC386001.
    # Design of tip state [BAG073001] = "pointed" [BAC386001]
}
LIMIT 10

SELECT ?company, ?offer, ?currency, ?amount, (?amount/?qtty) as ?amount_per_piece WHERE
{
    ?company gr:offers ?offer.
    ?offer a gr:Offering.
    ?offer gr:hasBusinessFunction gr:Sell.
    ?offer gr:hasPriceSpecification ?price.
    ?price a gr:UnitPriceSpecification.
    ?price gr:hasCurrency ?currency.
    ?price gr:hasCurrencyValue ?amount.
    ?offer gr:includesObject ?o.
    ?o a gr:TypeAndQuantityNode.
    ?o gr:amountOfThisGood ?qtty.
    ?o gr:hasUnitOfMeasurement "C62"^^xsd:string.
    ?o gr:typeOfGood ?type.
    ?type a eco:C_AKF303003-gen.
    {
        {?type a gr:ActualProductOrServiceInstance.}
    UNION
        {?type a gr:ProductOrServicesSomeInstancesPlaceholder.}
    }
    ?type eco:P_BAG073001 eco:V_BAC386001.
    FILTER (?qtty >=1)
}

First, we have to find the suitable super-category in eCl@ss. In our case, this is the class "Writing instrument, eraser, correction pen" with the eCl@ss 5.1.4 hierarchy code 24-24-00-00 and the identifier AKF301003. Second, we must keep in mind how the original hierarchy of eCl@ss is represented in eClassOWL: There are two classes for this category, i.e.

and

The "gen" class represents actual writing instruments, the "tax" class writing instruments and many other things that may be related to that term, e.g. maintenance of writing instruments or pictures of such. Each "gen" class is a rdfs:subClassOf of its direct "tax" correspondent. However, only the "tax" classes are rdfs:subClassOf of their super-category in eCl@ss. (If this is confusing, which I fear it can be, see Figure 3 for an illustration.)
Thus, we must use the "gen" class whenever we want to exploit the original hierarchy of eCl@ss. The "gen" classes are subclasses only of their direct "tax" counterparts, but not of other "tax" classes from the original eCl@ss hierarchy. Directly searching for instances of eco:AKF301003-tax, however, will also return objects that are related to writing instruments, but are no writing instruments, e.g. pictures depicting writing instruments, invoices related to writing instruments, etc. This means that we have to narrow down the search to objects that are instances of both eco:AKF301003-tax and gr:ProductOrServiceModel.
Keep in mind that this may still include product models that are only close to writing instruments, but no actual writing instruments.

SELECT ?model, ?length
FROM <http://www.heppnetz.de/files/eclassdemo.rdf>
FROM <http://www.ebusiness-unibw.org/ontologies/eclass/5.1.4/>
WHERE
{
    ?model a eco:C_AKF301003-tax.
    ?model a gr:ProductOrServiceModel.
    ?model eco:P_BAF559001 ?value.
    ?value gr:hasMaxValue ?length.
    ?value gr:hasUnitOfMeasurement "MMT"^^xsd:string.
    # The following alternative is more tolerant:
    # ?value gr:hasUnitOfMeasurement ?unit.
    # FILTER (regex(?unit, "^MMT")
    FILTER (?length >=100)
}
LIMIT 10

5. Domain Coverage

In the following, we show the distribution of subclasses along the 25 main branches of the eClassOWL 5.1.4 ontology.

6. License

The eClassOWL ontology is derived from eCl@ss version 5.1.4. 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

or

The eClassOWL 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 http://www.eclass.de/ 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 mheppATcomputerDOTorg 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.

7. Acknowledgements

We would like to thank eClass e.V. in particular Friedhelm Hausmann and Thomas Einsporn, Jos de Bruijn, doug foxvog, Axel Polleres, and Amit Sheth for their kind support and feedback. The work presented in this paper was partly funded by Florida Gulf Cost University, by the European Commission under the project DIP (FP6 - 507483), and by the Trans IT Entwicklungs- und Transfercenter at the University of Innsbruck.

8. References

1. Hepp, Martin: 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, No. 1, pp. 72-99, January-March 2006.
2. Hepp, Martin; de Bruijn, Jos: GenTax: A Generic Methodology for Deriving OWL and RDF-S Ontologies from Hierarchical Classifications, Thesauri, and Inconsistent Taxonomies, Proceedings of the 4th European Semantic Web Conference (ESWC 2007), June 3-7, 2007, Innsbruck, Austria, Springer LNCS, Vol. 4519, pp. 129-144, 2007.
3. Hepp, Martin; Leukel, Joerg; Schmitz, Volker: A Quantitative Analysis of Product Categorization Standards: eCl@ss, UNSPSC, eOTD, and RNTD, in: Knowledge and Information Systems (KAIS), Springer, Vol. 13, No. 1 (September 2007), pp. 77-114.
   DOI: 10.1007/s10115-006-0054-2
4. Hepp, Martin: GoodRelations: An Ontology for Describing Products and Services Offers on the Web, Proceedings of the 16th International Conference on Knowledge Engineering and Knowledge Management (EKAW2008), September 29 - October 3, 2008, Acitrezza, Italy, Springer LNCS, Vol. 5268, pp. 332-347.
5. Hepp, Martin: GoodRelations: An Ontology for Describing Web Offerings, SEBIS Technical Report, December 15, 2007.