XML Clearinghouse Report

14
Semantic Web Technologies
in the Automotive Industry

Herausgeber:

Prof. Dr.-Ing. Robert Tolksdorf

Freie Universität Berlin
Institut für Informatik
Netzbasierte Informationssysteme

Dr. Rainer Eckstein

Humboldt-Universität zu Berlin
Institut für Informatik
Datenbanken und Informationssysteme

ISSN (Print): 1861-1222

ISSN (Internet):1861-1230

team@xml-clearinghouse.de
www.xml-clearinghouse.de

© XML Clearinghouse
Semantic Web Technologies
in the Automotive Industry
Duc Minh Nguyen, Anja Jentzsch
May 12, 2005

1
Contents
1 Introduction 3

2 Data Interchange standards 3

2.1 EDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 ODETTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 X12 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 UN/EDIFACT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 XML/EDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.6 ebXML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.7 XML::EDIFACT . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.8 Verband der Automobilindustrie (VDA) . . . . . . . . . . . . . . 12
2.9 STAR (Standards for Technology in Automotive Retail) . . . . . 13

3 Bringing Together different Formats 13

3.1 Covisint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Redix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Process and Data Management 15

4.1 Product Data Management (PDM) . . . . . . . . . . . . . . . . . 15
4.2 PDTnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Comparison EDI and XML e-commerce 18

6 Semantic Web Technologies 18

6.1 SIMI-Pro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.2 Corporate Ontology Grid (COG) . . . . . . . . . . . . . . . . . . 19
6.3 Solutions by Ontoprise GmbH at AUDI AG . . . . . . . . . . . . 20
6.4 Systems Analysis of Modelling and Validation of Renault Auto-
mobiles(SAMOVAR) . . . . . . . . . . . . . . . . . . . . . . . . . 20

7 Summary 20

List of Figures
1 Transformation Odette UML Sample Model to XML Schema [29] 7
2 The X12 protocol [33] . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Covisint as a Hub [6] . . . . . . . . . . . . . . . . . . . . . . . . . 13
4 Covisint Features [6] . . . . . . . . . . . . . . . . . . . . . . . . . 14
5 PDTnet Concept [32] . . . . . . . . . . . . . . . . . . . . . . . . . 16
6 Semantic search mechanism as proposed in [10] . . . . . . . . . . 19

2
 Abstract
This report presents protocols which are currently used in the automo-
tive industry and their successors, which are based on Semantic Web tech-
nologies. An overview of electronic data interchange standards is given,
including formats for describing processes. Some solutions that aim at
unifying the communication between companies with different protocols
are introduced. After looking at the business to business communica-
tion the internal process and data management protocols of a company
is presented. With the multitude of protocols in mind, the advantages
of XML-enabled e-commerce is compared e-commerce without XML. Fi-
nally research projects are presented, which make use of Semantic Web
technologies to improve the existing technologies and develop new views
on existing data.

1 Introduction
This article tries to carry together current standards that are used in the auto-
motive industry and emerging applications of Semantic Web Technologies. In
the 1970’s the first efforts were already made towards an Electronic Data Inter-
change standard (EDI) which would simplify the business to business commu-
nication. The slow and error-prone paper communication was to be substituted
by EDI. This compilation is not complete, as some protocols are not publicly
available.
The structure of this article is as follows. First the standards for business to
business (B2B) communication summarized. Two examples serve to describe the
unification approach for the incompatible protocols. Then a short description
of Process Data Management (PDM) follows with details on PDTnet (Product
Data Technology Network). A short comparison of XML and EDI concludes the
standards part. The following section examines current research on application
of Semantic Web Technologies in the automotive industry. The last section
summarizes all preceding sections.

2 Data Interchange standards

Electronic Data Interchange (EDI) was introduced and designed to meet the
business needs of the 1970’s, using the technology available at that time. With
the advent of personal computers and the Internet, technology has made signifi-
cant improvements. Additionally, business processes have changed dramatically
and the traditional EDI methodology is being asked to do more than it is capa-
ble.
Over the years EDI has morphed into many different forms. Trying to fit a
single solution into many different situations has necessitated the management
of redundant standards such as X-12 (an ANSI standard that supplies structure
of business data exchanged between companies), EDIFACT (Electronic Data
Interchange For Administration, Commerce and Transport), and others. As a
result, companies supporting EDI are often forced to adopt multiple systems
in order to comply with each of their customers. In effect, every company has
had to create multiple, customer specific infrastructures to maintain trading
activities. Along with that, many companies are forced to manage processes

3
 ISA ˜03˜T5ZXM54W23˜01˜CA67MFFILE˜ 3 2 ˜ 9 8 7 6 5 4 3 2 1 ˜ 0 1 ˜ 6 1 7 8 5 6 9 4 3
˜ 0 2 0 6 3 0 ˜ 0 9 3 1 ˜ | ˜ 0 0 4 0 3 ˜ 0 0 0 0 0 1 0 0 6 ˜ 0 ˜T˜ˆ\
GS˜TF˜COMPANYROUTING˜ 6 1 7 8 5 6 9 4 3 0 5 0 ˜ 2 0 0 2 0 6 2 7 ˜ 0 9 3 1 ˜ 1 0 0 0 6 ˜X˜ 0 0 40 3 0 \
ST˜ 8 1 3 ˜ 1 0 0 0 0 6 \
BTI˜T6 ˜ 0 5 0 ˜ 4 7 ˜ 6 1 7 8 5 6 9 4 3 0 5 0 ˜ 2 0 0 2 0 6 2 7 ˜ ˜ 2 4 ˜ 9 8 7 6 5 4 3 2 1 ˜ 4 9 ˜ 0 5 0 5 2 9 6 6 ˜ ˜ ˜ 0 0 \
DTM˜ 6 8 3 ˜ ˜ ˜ ˜RD8˜20020501 −20020531\
TIA ˜ 5 0 0 0 ˜ ˜ 1 . 0 \
TIA ˜ 5 0 0 1 ˜ ˜ ˜ 2 0 8 3 7 6 9 4 ˜GA\
N1˜L9˜ P i p e l i n e A Company\
N3˜123 O i l Lane \
N4˜Any Town˜CA˜25704˜US\
PER˜CN˜ Timothy C . Doe˜TE˜ 2 2 2 5 5 5 0 1 0 1 ˜FX˜ 2 2 2 5 5 5 0 1 0 2 ˜EM˜ TimDoe@pipelineA . com\
PER˜EA˜Bobby G. Doe˜TE˜ 2 2 2 5 5 5 0 3 0 3 ˜FX˜ 2 2 2 5 5 5 0 3 0 4 ˜EM˜ BobbyDoe@pipelineA . com\

Listing 1: EDI Vessel/Pipeline Operator Report Data for Pipeline A Company

[5]

for which they are ill equipped, such as registration, partner management, and
infrastructure up-keep.
The problem is getting larger. The automotive industry has been increasing
its use of EDI by 20% per year and this is projected to continue into the future
(source: AMR, 2003) [6].
According to these sources the performance and bandwidth was critical at
the time (1970’s) EDI was developed. Therefore the protocol consists mainly of
codes which can be efficiently transferred over a network:
Another example can be found at [8]. The problems resulting from that
approach is that the protocols are difficult to implement and applications that
make use of these protocols are hard to maintain. The EDI, X12, EDIFACT
and other protocols are covered in more detail in the following text.

2.1 EDI
(Electronic Data Interchange)
EDI is the computer-to-computer interchange of strictly formatted messages
that represent documents other than monetary instruments. EDI implies a
sequence of messages between two parties, either of whom may serve as orig-
inator or recipient. The formatted data representing the documents may be
transmitted from originator to recipient via telecommunications or physically
transported on electronic storage media.
In EDI, the usual processing of received messages is by computer only. Hu-
man intervention in the processing of a received message is typically intended
only for error conditions, for quality review, and for special situations. For ex-
ample, the transmission of binary or textual data is not EDI as defined here
unless the data are treated as one or more data elements of an EDI message
and are not normally intended for human interpretation as part of on-line data
processing.
An example of EDI is a set of interchanges between a buyer and a seller.
Messages from buyer to seller could include, for example, request for quotation
(RFQ), purchase order, receiving advice and payment advice; messages from
seller to buyer could include, simi- larly, bid in response to RFQ, purchase or-
der acknowledgment, shipping notice and invoice. These messages may simply
provide information, e.g., receiving advice or shipping notice, or they may in-
clude data that may be interpreted as a legally binding obligation, e.g., bid in

4
response to RFQ or purchase order.
EDI is being used also for an increasingly diverse set of concerns, for exam-
ple, for interchanges between healthcare providers and insurers, for travel and
hotel bookings, for education administration, and for government regulatory,
statistical and tax reporting [23].
From the point of view of the standards needed, EDI may be defined as an
interchange between computers of a sequence of standardized messages taken
from a predetermined set of message types. Each message is composed, ac-
cording to a standardized syntax, of a sequence of standardized data elements.
It is the standardization of message formats using a standard syntax, and the
standardization of data elements within the messages, that makes possible the
assembling, disassembling, and processing of the messages by computer.
Implementation of EDI requires the use of a family of interrelated standards.
Standards are required for, at minimum: (a) the syntax used to compose the
messages and separate the various parts of a message, (b) types and definitions of
application data elements, most of variable length, (c) the message types, defined
by the identification and sequence of data elements forming each message, and
(d) the definitions and sequence of control data elements in message headers
and trailers.
Additional standards may define: (e) a set of short sequences of data ele-
ments called data segments, (f) the manner in which more than one message
may be included in a single transmission, and (g) the manner of adding protec-
tive measures for integrity, confidentiality, and authentication into transmitted
messages [23].
There are several different EDI standards in use today, but the achievement
of a single universally-used family of EDI standards is a long-range goal. A single
universally-used family of standards would make use of EDI more efficient and
minimize aggregate costs of use. Specifically, it would (a) minimize needs for
training of personnel in use and maintenance of EDI standards, (b) eliminate
duplication of functionality and the costs of achieving that duplication now
existing in different systems of standards, (c) minimize requirements for different
kinds of translation software, and (d) allow for a universal set of data elements
that would ease the flow of data among different but interconnected applications,
and thereby maximize useful information interchange.
FIPS PUB (Federal Information Processing Standards Publications) recog-
nizes the reality that some families of EDI standards were developed to provide
solutions to immediate needs, and that inclusion of the goal of universality in
their development would have unacceptably delayed their availability. How-
ever, a future is envisioned in which the benefits of universality outweigh the
sunk costs in specialized solutions, leading first to cooperation among standards
developers, then to harmonization of standards, and eventually to a single uni-
versally accepted family of EDI standards [23].
About 50,000 private sector companies in the United States, like Federal
Express, Eastman Kodak, American Airlines, Nike, Staples, Nationsbank, JC
Penney, and others currently use EDI. EDI is widely used in these industries:
manufacturing, shipping, warehousing, utilities, pharmaceuticals, construction,
petroleum, food processing, and health care. A recent study projects that the
number of companies using EDI will quadruple in the next six years [37].

5
 UNB+UNOA:1+ O00150ER99+O0031130300261091 +961115:1840+00016 ’
UNH+1+DELINS : 3 : : OD’
MID+ARD’
SDT+109930 ’
BDT+COMPANY NAME’
CSG+12+20130 ’
ARD+ 2E0 289 203 A 01C+:PCE+000001 ’
PDI+000000014+961028 ’
SAD+1+121H: JONES, TONY: ( 1 5 1 4 ) 1243 −46498+03 ’
FTX+ZUR NULLSTELLUNG ERR . : FORTSCHR. ZAHL AB 1 1 . 1 1 . ’
SID+2+M: 2 ’
DEL+ 9 6 1 1 1 8 + 0 : : 6 ’
ADI+000000015+961118 ’
UNT+13+1’
UNZ+1+00016 ’

Listing 2: Example ODETTE Message (OFTP) [4]:

2.2 ODETTE
(Organisation for Data Exchange by Teletransmission in Europe) ODETTE In-
ternational is an organisation, formed by the automotive industry for the au-
tomotive industry. It sets the standards for e-business communications, engi-
neering data exchange and logistics management, which link the 4000 plus busi-
nesses in the European motor industry and their global trading partners [26].
ODETTE has proposed some standards to unify the communication and busi-
ness processes of automotive companies. Among those standards the OFTP
(ODETTE File Transfer Protocol) [27] is related to EDI. Other protocols cover
Process Data Management and other B2B processes (an example in [28]). Ow-
ing to the industrial character of the protocols access to most documents is
restricted and password-protected.
The XML Recommendation [29] provides a UML (Unified Modelling Lan-
guage) modelling set and an XML wrapper for ODETTE models. The UML
modelling set is used to modell EDI scenarios. The XMI (XML Metadata In-
terchange) representation of that UML modell can then be transformed (using
XSLT) into an XML representation of OFTP which then can be transformed
into other protocols. Figure 1 shows the modelling process.
Automobile companies and large ”tier 1” suppliers already make use of the
ODETTE XML Standard, which is used in the ”ZF PortalManager”. European
automotive companies like BMW, VW, DaimlerChrysler, Renault and suppliers
as ZF, Bosch, Faurecia have agreed upon using the ODETTE XML Standard
in the ZF PortalManager (since Version 1.3). Thus, all participating companies
implement interfaces conforming to the ODETTE XML Standard in their own
portals, making an easy data interchange possible.

2.3 X12
X12 is the North American variant of an EDI protocol [42]. The general struc-
ture is shown in Figure 2.
X12 is not compatible to the OFTP protocol. In order to perform Data
Interchange between those protocols the messages have to be mapped to the
other protocol. It is a difficult task as it demands knowledge of both protocols.
In 2002 the ASC X12 Reference Model for XML Design [2] was released,
which proposes a granularity model, an architecture, meta data for storing ar-

6
 Figure 1: Transformation Odette UML Sample Model to XML Schema [29]

chitecture components and XML Syntax design with approaches to implement-

ing XML syntax. High level design rules are given which lead to consistent XML
format for different branches of industry.

2.4 UN/EDIFACT
(United Nations/Electronic Data Interchange for Administration, Commerce
and Transport)
Trade facilitation deals with the requirements and procedures related to the flow
of information needed for the international movement of goods. Traditionally,
these requirements have been substantiated in the form of paper documents and
procedures carried out through handling such documents; it was therefore only
natural that initial facilitation efforts should focus on the simplification and
standardization of external trade documents.
Technological developments, however, have made alternative information
handling and transmission methods feasible; in addition, the scope of interna-
tional co-operation has been extended from document harmonization to more
profound research on the identification of basic information requirements and
the development of an entirely new methodology to satisfy them. It is significant
that the UN/ECE Working Party on the Simplification and Standardization of
External Trade Documents, set up in l960, became in l972 the Working Party
on Facilitation of International Trade Procedures, with terms of reference ex-
tended to cover, inter alia, the development of a standard international trade
data terminology and a uniform system for use in automatic processing and

7
 Figure 2: The X12 protocol [33]

transmission of trade data [39].

The handling of trade data includes two major types of activity, processing
and transmission. As to the processing of information, the development of auto-
matic data processing equipment which can be used for commercial applications
has introduced a powerful rationalization tool for those involved in international
trade. Although data processed automatically can, without difficulty, be pre-
sented in normal paper documents, subsequently to be forwarded and handled
in the traditional way, the obvious and very desirable alternative is to make
the information directly available to exchange partners having data processing
equipment at their disposal.
This introduces–quite apart from the method used for processing data prior
to transmission–a need to rationalize the physical transmittal of data, from the
slow and cumbersome mailing of documents to more direct and rapid informa-
tion exchange. It is evident that, when using automatic data interchange, a
much more rigid discipline needs to be exercised regarding data presentation
and exchange rules than in the case of paper documents.
Even though the required technology and services are available, this does

8
 ISA ∗ 0 0 ∗ ∗ 0 0 ∗ ∗ 2 7 ∗ 0 0 8 8 3 ∗ZZ∗ I 0 8 5 8 7 ∗ 0 2 0 8 0 2 ∗ 0 0 4 6 ∗U∗ 0 0 4 0 1 ∗ 0 0 0 0 0 0 0 0 2 ∗ 0 ∗T∗ : ˜
GS∗HP∗00883∗ I 0 8 5 8 7 ∗ 2 0 0 2 0 8 0 2 ∗ 0 0 4 6 5 3 ∗ 1 3 ∗X∗004010 X091˜
ST∗ 8 3 5 ∗ 0 0 0 0 0 0 0 0 1 ˜
BPR∗H∗0∗C∗NON∗∗ ∗∗∗ ∗∗ ∗∗∗ ∗∗ 2 0 0 2 0 7 3 1 ˜
TRN∗ 1 ∗ 5 0 7 3 7 0 2 6 7 ∗ 1 5 7 1 0 6 2 3 2 6 ˜
REF∗EV∗ I 0 8 5 8 7 ˜
DTM∗ 4 0 5 ∗ 2 0 0 2 0 7 3 1 ˜
N1∗PR∗PALMETTO GBA˜
N3∗PO BOX 182957˜
N4∗COLUMBUS∗OH∗ 4 3 2 1 8 2 9 5 7 ˜
REF∗2U∗00883˜
PER∗CX∗ATTN; PROGRAM INTEGRITY∗TE∗ 8 7 7 5 6 7 9 2 3 2 ˜
N1∗PE∗ROHOLT VISION INSTITUTE∗ FI ∗ 3 4 1 9 5 8 3 8 0 ˜
N3∗4425 METRO CIRCLE NW˜
N4∗NORTH CANTON∗OH∗ 4 4 7 2 0 7 7 5 5 ˜
REF∗1C∗ 9 3 1 6 3 4 1 ˜
LX∗1˜
CLP∗ 3 6 0 8 ∗ 4 ∗ 9 5 ∗ 0 ∗ 0 ∗MB∗ 0 2 0 2 2 1 2 2 5 3 4 9 0 ˜
NM1∗QC∗1∗ROLLINS∗CAROL∗A∗∗∗HN∗ 2 7 4 3 0 0 3 8 0A˜
NM1∗82∗1∗∗∗∗∗∗UP∗ U86692 ˜
MOA∗∗∗MA130˜
DTM∗ 0 5 0 ∗ 2 0 0 2 0 7 3 1 ˜
SVC∗HC: 9 2 0 1 4 ∗ 9 5 ∗ 0 ∗ ∗ 0 ∗ ∗ 1 ˜
DTM∗ 4 7 2 ∗ 2 0 0 2 0 2 2 0 ˜
CAS∗CO∗11∗95˜
REF∗6R∗13508˜
REF∗LU∗11˜
REF∗1C∗ 4 0 5 8 9 9 1 ˜
LQ∗HE∗M81˜
SE∗ 2 8 ∗ 0 0 0 0 0 0 0 0 1 ˜
GE∗1∗13˜
IEA ∗ 1 ∗ 0 0 0 0 0 0 0 0 2 ˜

Listing 3: Example X12 Message [15]

not suffice to make data interchange of this type an operational reality. There
is an equally important requirement to develop and agree on standards, proce-
dures, and other essential elements of data handling methodologies to ensure
intelligible communications between different systems used by trade and trans-
port operators.
The first steps in rationalization aiming at the use of automatic data process-
ing and transmission were the development of agreed standards for the repre-
sentation of data used to service international trade movements and of methods
whereby the exchange of data between data processing systems would be made
possible without the need for costly and error-prone re-transcription [39].
The principles for the establishment of any trade data interchange method
or system may be summarized as follows:
1. The basis for any trade data interchange is the United Nations Trade
Data Elements Directory (UNTDED), where data elements are uniquely
named, tagged and defined, and where the representation of data entries
is specified both as regards expression and syntax. From this directory,
data elements required to fulfill specific documentary functions are selected
both for UNLK based forms and to form messages for transmission. Data
elements from UNTDED used in UN Standard Message types are also part
of a separate directory (EDED) in UNTDID.
2. Data elements can be grouped in various sets, systematically arranged
according to agreed rules. These groups (or ”segments”), which are desig-
nated by a common denominator (a segment tag), can be arranged as spec-

9
 ified in United Nations Standard Message types (UNSM’s) or by agreement
between interchange partners. Each data elements is implicitly identified
by its position in the segment [39].
Definition of UN/EDIFACT
At its meeting 1990-03, Working Party 4 agreed on the following definition of
UN/EDIFACT:
United Nations rules for Electronic Data Interchange For Administration,
Commerce and Transport. They comprise a set of internationally agreed stan-
dards, directories and guidelines for the electronic interchange of structured
data, and in particular that related to trade in goods and services between
independent, computerized information systems.
Recommended within the framework of the United Nations, the rules are
approved and published by UN/ECE in the (this) United Nations Trade Data
Interchange Directory (UNTDID) and are maintained under agreed procedures
[39].
While companies may use the EDI standards to communicate. Banks, how-
ever, have agreed upon a standard to perform international transactions which
is called SWIFT (see [25] for a short description). EDIFACT was created in or-
der to reduce the number of interfaces between companies. Business processes
which involve money transactions can be formulated in EDIFACT.[21]

2.5 XML/EDI
In 1998 an effort was made to develop a uniform protocol that could be used
for platform independent data interchange that makes use of XML [22].
XML/EDI is the fusion of five technologies.
• XML
• EDI
• Templates
• Agents, and
• Repository.
This combination of capabilities makes XML/EDI so powerful. Each component
adds unique tools that leverage the other pieces. In the past EDI was very static,
today the XML/EDI framework provides is an exciting dynamic process that
can be infinitely extended.
The European counterpart is ISIS, European XML/EDI Pilot Project [16].
The Extensible Markup Language (XML) has been designed to provide a generic
way of transferring data across the Internet without having to be constrained
to the presentation rules built into the HyperText Markup Language (HTML)
that currently forms the basis of data interchange over the World Wide Web
(WWW).
XML does not contain any predefined set of ’markup tags’ but allows users
to define their own sets, based on the types of data they wish to interchange.
There is an associated XML Stylesheet Language (XSL) that can be used, where
appropriate, to exchange information on how each ’element’ of the transmitted
data should be presented to users of the data.

10
 For business communications there is a need for a globally understood set of
business markup tags. The EDI standardization work for business-to-business
messaging, notably UN/EDIFACT, has already identified a large set of ex-
changeable information objects, which provide a good starter set for defining
business-related information objects for use within XML applications.
XML/EDI is, however, wider in scope than just the use of existing semantic
sets for business-to-business communications. There are many industries that
are only just beginning to use electronic data interchange (EDI) or who are doing
EDI but not using the UN/EDIFACT standards. It is anticipated that many
of these will also adopt XML for interchange of data over the Internet. One of
the roles of the XML/EDI work is, therefore, concerned with the integration of
existing and emerging work with that done under the UN/EDIFACT procedures.

2.6 ebXML
UN/CEFACT and OASIS have developed ebXML [24] which provides a frame-
work that aims at reducing interoperability issues and supports individual com-
pany processes.
For over 25 years Electronic Data Interchange (EDI) has given companies the
prospect of eliminating paper documents, reducing costs, and improving effi-
ciency by exchanging business information in electronic form. Ideally, companies
of all sizes could conduct eBusiness in a completely ad hoc fashion, without prior
agreement of any kind. But this vision has not been realized with EDI; only
large companies are able to afford to ebXML Technical Architecture Team Feb-
ruary 2001 implement it, and much EDI-enabled eBusiness is centered around
a dominant enterprise 188 that imposes proprietary integration approaches on
its Trading Partners [11].
In the last few years, the Extensible Markup Language (XML) has rapidly
become the first choice for defining data interchange formats in new eBusi-
ness applications on the Internet. Many people have interpreted the XML
groundswell as evidence that ’EDI is dead’ made completely obsolete by the
XML upstart – but this view is nave from both business and technical stand-
points.
EDI implementations encode substantial experience in Business Processes,
and companies with large investments in EDI integration will not abandon them
without good reason. XML enables more open, more flexible business transac-
tions than EDI. XML might enable more flexible and innovative ’eMarketplace’
business models than EDI. But the challenges of designing Messages that meet
Business Process requirements and standardizing their semantics are indepen-
dent of the syntax in which the Messages are encoded.
The ebXML specifications provide a framework in which EDI’s substantial
investments in Business Processes can be preserved in an architecture that ex-
ploits XML’s new technical capabilities.
A critical view of ebXML is offered in [34]. The author analyses ebXML
and concludes from his personal point of view that ebXML offers some avdan-
tages and disadvantages. He points out that ebXML may suffer the same fate
as EDI, i.e. to be accessible only to big companies that can invest into the
implementation, and therefore being a standard only to the elite.

11
 <anxs : i n t e r c h a n g e . h e a d er>
<anxc : s y n t a x . i d e n t i f i e r >
<anxe : s y n t a x . i d e n t i f i e r u n s l : c o d e=” 0 0 0 1 :UNOC”>
UN/ECE l e v e l C
</anxe : s y n t a x . i d e n t i f i e r >
<anxe : s y n t a x . v e r s i o n . number>
2
</anxe : s y n t a x . v e r s i o n . number>
</anxc : s y n t a x . i d e n t i f i e r >
<anxc : i n t e r c h a n g e . s e n d e r >
<anxe : s e n d e r . i d e n t i f i c a t i o n >
S p r i n g e r −ILN
</anxe : s e n d e r . i d e n t i f i c a t i o n >
<anxe : r e c i p i e n t s . i d e n t i f i c a t i o n . q u a l i f e r u n s l : c o d e=” 0 0 0 7 : 9 1 ”>
A s s i g n e d by s e l l e r or s e l l e r ’ s a g e n t
</anxe : r e c i p i e n t s . i d e n t i f i c a t i o n . q u a l i f e r >
</anxc : i n t e r c h a n g e . s e n d e r >
<anxc : i n t e r c h a n g e . r e c i p i e n t >
<anxe : r e c i p i e n t . i d e n t i f i c a t i o n >
M i s s i n g Link
</anxe : r e c i p i e n t . i d e n t i f i c a t i o n >
<anxe : r e c i p i e n t s . i d e n t i f i c a t i o n . q u a l i f e r u n s l : c o d e=” 0 0 0 7 : 9 1 ”>
A s s i g n e d by s e l l e r or s e l l e r ’ s a g e n t
</anxe : r e c i p i e n t s . i d e n t i f i c a t i o n . q u a l i f e r >
</anxc : i n t e r c h a n g e . r e c i p i e n t >
<anxc : d a t e . t i m e . o f . p r e p a r a t i o n >
<anxe : date>
980508
</anxe : date>
<anxe : time>
1336
</anxe : time>
</anxc : d a t e . t i m e . o f . p r e p a r a t i o n >
<anxe : i n t e r c h a n g e . c o n t r o l . r e f e r e n c e >
4
</anxe : i n t e r c h a n g e . c o n t r o l . r e f e r e n c e >
<anxe : t e s t . i n d i c a t o r u n s l : c o d e=” 0 0 3 5 : 1 ”>
Interchange i s a test
</anxe : t e s t . i n d i c a t o r >
</anxs : i n t e r c h a n g e . h ea de r>

Listing 4: XML::EDIFACT Example

2.7 XML::EDIFACT
XML::Edifact is a perl module free available under GNU general public license,
able to translate any well-formed UN/EDIFACT message into human readable
and valid XML and vice versa, by using the original words from the UN/EDI-
FACT batch directories as markup and the defining document as namespace [20].
Even an approach to using RDF was undertaken within the same project [19].
However, the project seems to be incomplete or abandoned.

2.8 Verband der Automobilindustrie (VDA)

The German Verband der Automobilindustrie has defined some recommenda-
tions which unfortunately are not publicly available. However, it seems that
the VDA has defined some message protocols as Figure 3 suggests. The annual
report and the link to ordering applications can be found here [9].

12
2.9 STAR (Standards for Technology in Automotive Re-
tail)
The STAR Group proposes voluntary standards, which are directed towards
easy B2B communication. The STAR format is based upon Business Object
Documents (BODs), special XML documents, which are described in detail
in the reference implementation [36]. BODs prescribe a generic document
structure which is capable of representing all messages that are necessary for
B2B communication.

3 Bringing Together different Formats

This section presents two different solutions that address the problems that arise
from the many proprietary EDI standards. Originally intended to be a standard
for easy B2B data interchange EDI has evolved into many different formats as
the sections above have shown. Some companies have realized this problem and
offer a solution for companies that interchange data with different companies
which use different EDI formats. Instead of developing a mapping between
EDI formats themselves companies may use services, which are specialized in
mapping between formats.

3.1 Covisint
Covisint provides services, which can be regarded as a ’hub’ [6]. Companies may
submit their messages to a Covisint server which then transforms the message
into the required destination format (see Figure 3).

Figure 3: Covisint as a Hub [6]

Covisint claims to especially address the needs of the automotive industry.

However, Figure 4 shows that OFTP is not yet implemented. Thus Covisint

13
 Figure 4: Covisint Features [6]

lacks the interface to an important European protocol (ODETTE FTP).

3.2 Redix
The Redix International company [35] offers a converter, which is capable of
transforming different standards. The standards used in the automotive indus-
try are included in the list of supported standards.
Redix ”specializes in the development, marketing, and support of B2B, XML,
DTD, Schema, X12, EDIFACT, EDI, HIPAA, NCPDP, HL7, and Electronic
Commerce software” [35]. Redix offers Any-to-Any format conversion solutions
to developers and companies for the implementation of profitable Electronic
Commerce programs.
The Redix Format Converter combines data security, translation, mapping,
and database access into one process as opposed to the traditional four-step
approach to eliminate unnecessary file I/O. Since the one-pass approach is much
faster than other approaches, Redix Format Converter is ideal for real-time
XML/EDI or Electronic Commerce applications.
The newest version of the Redix AnyToAny XML Format Converter supports
features like NCPDP, HL7, HIPAA pre-defined maps, and automatic database
maps.

Standards supported are:

• X12: 3051, 4010, 4020, 4030, etc
• EDIFACT: 93A, 93B, 94A, 94B, 95A, 95B, 96A, 96B, 97A, 97B, 98A, 98B,
99A, 99B, etc.
• NCPDP: 5.1
• HL7: 2.3, 2.4, and XML versions
• HIPAA: 4010, Addendum (A1)
• UB92, NSF
• HCFA 1500 and 1450 paper formats
XML Standards supported are :

14
 • RosettaNet Version 2.0
• OAG: Open Applications Group
• FIXML: Financial Information eXchange
• FPML: Financial Products Markup Language
• MISMO: Mortgage Industry Standards Maintenance Organization
• OTA: Open Travel Alliance
• HL7: Version 2.3.1
• CIDX: Version 2.0.1
• PIDX: Petroleum Institute Petroleum Industry Data Exchange Version
1.0
• xCBL: Version 2.0, 3.5
• cXML: Version 1.1.008, 1.1.009, 1.1.010
Obviously Redix has put much effort into integrating many protocols. HL7
(Health Level 7 [41]), for example, is a standard in the health care arena. OFTP
is not supported but neither does Redix claim to especially support the auto-
motive industry.

4 Process and Data Management

4.1 Product Data Management (PDM)
Product Data Management is a framework that recommends the management
of data and processes. The aim is to reduce the loss of information within a
company an make best use of a company’s potential (synergy effects). [12, 40]

4.2 PDTnet
Increased challenges for suppliers and manufacturers in the automotive indus-
try require the implementation of process-oriented and technical standards for
product data communication. Today, companies in the manufacturing industry
are forced to cooperate flexible with various partners in changing customer-
/supplier-roles in an international scope.
Each relationship between development partners demands harmonization of
organization-spanning processes, data formats and implementation methods.
This emphasizes the relevance of standards in networked collaboration.
New working techniques and workflows within the product development
processes require increasing support of engineering tasks through CAx tools.
The thereby generated product-describing data, has to be used continuously.
Traditional modes of operation and business processes within the product
development process are subject to a revolutionary change through novel com-
munication technologies, especially in connection with the Internet. Within the
scope of the PDTnet project particularly the following, commonly met problems
were addressed:

15
• Scarcely harmonized processes hinder cross-organizational cooperation.
• The implementation of customer-specific requirements (so-called bilateral
optimization) leads to further segmentation and thus a loss of synergy,
especially at the supplier.
• Aged data and systems constrain the enforcement of new technologies.
• Competing standards decelerate decisions and increase their price.

• Organizational insecurities hamper the consequent use of technology, e.g.

questions on data reliability, security aspects regarding the Internet, mea-
sures for data quality. A relocation of business processes to a network
infrastructure poses great demands on the continuity of data and on data
quality.

• A relocation of business processes to a network infrastructure poses great

demands on the continuity of data and on data quality.
• The availability of know-how to master digital business processes is not
distributed very well: well-informed experts in major enterprises meet con-
tact persons from small- and medium-sized companies, whose core com-
petence is not focussed on the area of information technology.

Figure 5: PDTnet Concept [32]

16
<?xml v e r s i o n=” 1 . 0 ” e n c o d i n g=”UTF−8”?>
<P d t n e t s c h e m a xmlns : x s i=” h t t p : / /www. w3 . o r g /2001/XMLSchema−i n s t a n c e ”
x s i : noNamespaceSchemaLocation=” p d t n e t s c h e m a v 1 1 . xsd ”
id=” p d t n e t 1 ” v e r s i o n i d=” 1 . 1 ”>
<Item id=” i 1 ”>
<Id> 1 8 1 1 0 0 2 8 </Id>
<Name> A i r b a g Modul L i n k s l e n k e r </Name>
<I t e m v e r s i o n id=” i v 1 1 ”>
<Id>V e r s i o n 1 </Id>
< D e s i g n d i s c i p l i n e i t e m d e f i n i t i o n id=” d111 ”
x s i : type=” A s s e m b l y d e f i n i t i o n ”>
<Name> a s s e m b l y d e f i n i t i o n 1 </Name>
<Id> ad111 </Id>
< I n i t i a l c o n t e x t > a p p l i c a t i o n c o n t e x t 1 </ I n i t i a l c o n t e x t >
<Document assignment id=” da1 ”>
<A s s i g n e d d o c u m e n t> dv11 </A s s i g n e d d o c u m e n t>
<Role>i n f o r m a t i v e </Role>
</Document assignment>
<A s s e m b l y c o m p o n e n t r e l a t i o n s h i p id=” nha1111 ”
x s i : type=” N e x t h i g h e r a s s e m b l y ”>
<R e l a t e d > s i 2 1 1 1 </R e l a t e d >
</ A s s e m b l y c o m p o n e n t r e l a t i o n s h i p >
<A s s e m b l y c o m p o n e n t r e l a t i o n s h i p id=” nha1112 ”
x s i : type=” N e x t h i g h e r a s s e m b l y ”>
<R e l a t e d > s i 3 1 1 1 </R e l a t e d >
</ A s s e m b l y c o m p o n e n t r e l a t i o n s h i p >
<A s s e m b l y c o m p o n e n t r e l a t i o n s h i p id=” nha1113 ”
x s i : type=” N e x t h i g h e r a s s e m b l y ”>
<R e l a t e d > s i 4 1 1 1 </R e l a t e d >
</ A s s e m b l y c o m p o n e n t r e l a t i o n s h i p >
</ D e s i g n d i s c i p l i n e i t e m d e f i n i t i o n >
</ I t e m v e r s i o n >
< A l i a s i d e n t i f i c a t i o n id=” a i 1 1 ”>
<A l i a s i d > 6Q3 880 241 </ A l i a s i d >
<A l i a s s c o p e > o1 </ A l i a s s c o p e >
</ A l i a s i d e n t i f i c a t i o n >
...
<A p p l i c a t i o n c o n t e x t id=” a p p l i c a t i o n c o n t e x t ”>
<A p p l i c a t i o n d o m a i n > m e c h a n i c a l d e s i g n </A p p l i c a t i o n d o m a i n >
< L i f e c y c l e s t a g e > d e s i g n </ L i f e c y c l e s t a g e >
</ A p p l i c a t i o n c o n t e x t >
</Pdtnet schema>

Listing 5: Example XML Document [31]

17
5 Comparison EDI and XML e-commerce
Electronic Data Interchange (EDI) is used by large companies for nearly twenty
years now. For small companies it has proven itself to be too complicated and
expensive. As a result, EDI has not been widely adopted.
The Internet and XML have lowered the entry barriers to e-commerce, in
both cost and complexity. Therefore business can be conducted in more afford-
able ways and so XML brings e-commerce to small and midsize companies.
XML complements EDI and should not be interpreted as the end of EDI.

XML e-commerce solution EDI e-commerce solution

Optimized for easy programming Optimized for compressed
messages
Requires web server costing $0 to $5000 Requires dedicated EDI
server costing $10,000 to $100,000
Uses your existing Internet connection Uses value-added network (VAN)
charging $1 to $20 per
message or more
XML message format learned in hours EDI message format takes
months to master
Only requires JavaScript, Visual Basic, Requires highly trained
Python or Perl script writers C++ programmers

Table 1: XML and EDI e-commerce compared [17]

An important advantage with regard to future development is that XML

can be directly transmitted using Http, thus enabling the use by Web Services.

6 Semantic Web Technologies

So far XML is the only Semantic Web Technology that has been integrated
into the automotive standards. XML::EDIFACT (see 2.7) is the only project
that tries to integrate RDF. This section presents research projects that are
concerned with using Semantic Web technologies in the automotive industry.
Billig [3] describes the construction of a domain repository for automotive
production using Semantic Web Technologies. RDF is used to model ontologies
and defines TRIPLE as a language to query the repository. TRIPLE allows
expressions in predicate logic but requires the RDF modell to be extended (RDF
quadruple) and several extensions (e.g. modlets and actlets, text retrieval) to
be added.

6.1 SIMI-Pro
Ucelli et al [10] describe their SIMI-Pro system which they claim allows easy,
fast and centralized access to collections of data from multiple sources and in
supporting the retrieval and re-use of a wide range of data that will help stylists
and engineers shorten the production cycle. The idea is to describe processes
as ontologies, thus augmenting the data with knowledge of the processes. This
idea is depicted in Figure 6.

18
 Figure 6: Semantic search mechanism as proposed in [10]

6.2 Corporate Ontology Grid (COG)

De Bruijn [7] points out that today’s Enterprise Application Integration (EAI)
efforts are mostly made towards syntactic integration, totally ignoring semantic
issues. His masters thesis is not directly concerned about problems of the auto-
motive industry, but proposes a general approach to EAI using Semantic Web
Technologies.
The Corporate Ontology Grid (COG) [?] project makes use of an ontology-
based central information model to provide explicit semantics and a unified view
of all the company information.
The Semantic Information Management (SIM) aims at overcoming the prob-
lems derived from the heterogeneity of the information stored in a given organi-
zation. The SIM uses a central ontology (the Information Model) and maps the
individual sources to this central model. The SIM approach consists of three
stages:

• Collecting the metadata of the existing data sources

• Creating a central ontology based on the metadata, capturing the seman-
tics of the data stored in the different sources
• Defining mappings between the original data schemas and the central on-
tology
The Unicorn Workbench [38] by Unicorn supports all phases in the SIM. It is
used for storage, management of the repository and performing all modeling and

19
semantic mapping tasks. Furthermore it helps validating and testing a model
with test instances.

6.3 Solutions by Ontoprise GmbH at AUDI AG

Maier et al [1] introduce a method to map existing data, e.g. from relational
data bases, to ontologies. For this purpose solutions by Ontoprise GmbH [13]
where used to build a prototype at AUDI AG. This is supposed to be beneficial
as all data sources are being mapped (using OntoMap by Ontoprise GmbH [13])
to one common ontology storage, where all knowledge is accumulated, allow-
ing inferencing across data sources. In order to take advantage of inferencing
relations have to be carefully modeled and rules defined for attributes and re-
lations. During the prototype phase at AUDI, a part of an exhaust-gas system
was modeled with all its dependencies. F-logic (frame logic) is used to create
and query the ontologies, as it can be applied to the model and instance level of
ontologies. OntoBroker by Ontoprise is used for inferencing from the predefined
rules. OntoBroker consists of an inference engine which supports ontologies in
common formats like RDF and OWL, as well as F-Logic. Furthermore On-
toBroker contains an open framework for the connection of data sources like
databases, document management systems, etc.. This approach is now under
further development after been successfully tested at AUDI, especially regard-
ing the aspect of storage, i.e. where and how to store the created ontologies
efficiently.

6.4 Systems Analysis of Modelling and Validation of Re-

nault Automobiles(SAMOVAR)
SAMOVAR (Systems Analysis of Modelling and Validation of Renault Automo-
biles) [18] is an interesting approach, using textual information as its knowledge
base. A language tool (NOMINO [30])is used to populate predefined core
ontology instances with information extracted from texts. Thus knowledge ac-
cumulated in past projects can be reused and consulted without having to have
been already created as ontologies. Knowledge gained in past projects can be
used as a ”project memory”. The tool CORESE (Conceptual Resource Search
Engine) [14] is then used to find solutions in the knowledge base.

7 Summary
The automotive industry makes heavy use of EDI and its specializations. As
EDI has its root in the 1970’s it is optimized for little bandwidth use and fast
processing. Its complexity, however, makes it hard to deploy and the develop-
ment of applications expensive. To make things even worse, industry branches
or branches of different countries have developed their own protocols making
it even harder for companies to implement full compatibility to global business
partners.
Apart from the approaches in section 3, the advantages of XML have been
realized and efforts have been made to embrace those advantages. Many auto-
motive organizations recognize that moving to an XML content infrastructure

20
improves the process of preparing, managing, and delivering customized con-
tent. Using XML to automate publishing processes and improve information
quality reduces costs and publishing times. The usefulness of Semantic Web
technologies is still being researched.
Some of the presented projects already show the power of Semantic Web
technologies in transforming different data sources and integrating them. The
most interesting prospect in using Semantic Web technologies is the easy access
to accumulated knowledge, which is one of the most important resources of a
company.

References
[1] Andreas Maier, Hans-Peter Schnurr, York Sure. Ontology-based informa-
tion integration in the automotive industry.
[2] ASC X12C Communications and Controls Subcommittee. ASC
X12 REFERENCE MODEL FOR XML DESIGN. WWW, 2002.
http://www.x12.org/x12org/xmldesign/X12Reference Model For XML Design.pdf.
[3] Andreas Billig. ODIS - Ein Domaenenrepository auf der Basis von Semantic
Web Technologien.
[4] Blueprint Electronic Commerce Ltd. Introduction to ODETTE. WWW.
http://www.blueprint-ec.co.uk/odette.htm.
[5] California State Board of Equalization. Example 1: Edi
vessel/pipeline operator report data for pipeline a company.
http://www.boe.ca.gov/elecsrv/efiling/pdf/exedi1-3.pdf.
[6] Covisint. Covisint. WWW. http://www.covisint.com/.
[7] Jos de Bruijn. Semantic Information Integration Inside and Across Organi-
zational Boundaries. Master’s thesis, Digital Enterprise Research Institute
(DERI), 2003.
[8] Defense Reutilization and Marketing Service (DRMS). EDI EX-
AMPLE OF A HAZARDOUS WASTE MATERIAL RECEIPT.
https://www.drms.dla.mil/drmsp/edi/861ex1drms.pdf.
[9] Verband der Automobilindustrie. Verffentlichungen. WWW.
http://www.vda.de/en/service/sonstige veroeffentlichungen/index.html.
[10] Dr. Giuliana Ucelli, Dr. Raffaele De Amicis, Dr. Giuseppe Conti, Prof.
Fausto Giunchiglia and Dr. Stefan Noll. A SEMANTIC-BASED IN-
FORMATION MANAGEMENT SYSTEM TO SUPPORT INNOVATIVE
PRODUCT DESIGN.
[11] ebXML. ebxml technical architecture specification v1.0.4, 2001.
http://www.ebxml.org/specs/ebTA.pdf.
[12] Hewlett Packard. Introduction to Product Data Management (PDM).
WWW. http://www.pdmic.com/undrstnd.html#brief.
[13] http://www.ontoprise.de. Ontoprise gmbh. http://www.ontoprise.de.

21
[14] INRIA. Corese. WWW. http://www-sop.inria.fr/acacia/soft/corese/.
[15] Interfaceware. Example X12 Message. WWW.
http://www.interfaceware.com/manual/ch-3-2.html.
[16] ISIS, European XML/EDI Pilot Project. XML/EDI, 2000.
http://palvelut.tieke.fi/edi/isis-xmledi/.
[17] Jeffrey Ricker, Drew Munro, and Doug Hopeman. XML
AND EDI - PEACEFUL CO-EXISTENCE. WWW.
http://www.tdan.com/i011hy01.htm.
[18] Joanna Golebiowska, Rose Dieng-Kuntz, Olivier Corby, Didier Mousseau.
Building and exploiting ontologies for an automobile project memory.
[19] Michael Koehne. RDF/EDIFACT. WWW. http://www.xml-
edifact.org/TR/RDF-Edifact-2.html.
[20] Michael Koehne. Xml::edifact. WWW. http://www.xml-edifact.org/.
[21] Stefan Krieg. Was ist edifact? WWW, 1999.
http://www.zahlungsverkehrsfragen.de/edifact.html.
[22] Martin Bryan, Centre Benot, Marcha Norbert H Mikula, Bruce Peat, David
RR Webber. Guidelines for using xml for electronic data interchange, 1998.
http://www.eccnet.com/xmledi/guidelines-styled.xml.
[23] National Institute of Standards and Technology. EDI Standard, 1993.
http://www.itl.nist.gov/fipspubs/fip161-2.htm.
[24] OASIS. ebXML. http://www.ebxml.org/.
[25] ObjectEdge. The S.W.I.F.T. Framework. WWW, 1999.
http://www.objectedge.com/archive-swift.qxd.pdf.
[26] ODETTE. ODETTE. WWW. http://www.odette.org/.
[27] ODETTE. ODETTE File Transfer Protocol OFTP (RFC 2204).
http://www.faqs.org/rfcs/rfc2204.html.
[28] Odette Espana. User & Access Managementin B2B Portals. WWW, 2004.
http://www.odette.es/documentacion/normas/UAM Presentation July04.pdf.
[29] ODETTE XML Project Group. ODETTE XML Recommendation, 2003.
http://www.odette.org/html/xmlrecommendation.htm.
[30] Pierre Plante, Lucie Dumas, Andr Plante. Nomino. WWW.
http://www.ling.uqam.ca/nomino/.
[31] ProStep. PDTnet Implementation Guide. WWW, 2001.
http://www.xml.org/xml/schema/cf38bfbb/PDTnetImplementationGuide v11.pdf.
[32] ProSTEP iViP. http://www.prostep.org/de/stepportal/pdtnet/. WWW.
http://www.prostep.org/de/stepportal/doku/.
[33] Michael C. Rawlins. X12 tutorial. WWW.
http://www.rawlinsecconsulting.com/x12tutorial/x12syn.html.

22
[34] Michael C. Rawlins. ebXML - A Critical Analysis. WWW, 2002.
http://www.rawlinsecconsulting.com/ebXML/index.html.

[35] Redix. Redix Company. WWW. http://www.redix.com/.

[36] STAR. XML Reference / Implementation Version 3.0. WWW.
http://www.starstandard.org/sigs/tracking.cfm?track=/sigs/xml
/current XML/STARXMLReferenceImplementation v3 0.pdf.
[37] Tradanet. EDI Basics. WWW. http://www.tradanet.intnet.mu/EDIintro.htm.

[38] Unicorn. Unicorn Workbench. http://www.unicorn.com/products/architecture.htm.

[39] United Nations Economic Commission for Europe. UN/EDIFACT DRAFT
DIRECTORY. http://www.unece.org/trade/untdid/texts/unrci.htm.
[40] WAMware. Introduction to PDM. WWW.
http://www.wamware.com/products/metakon/intro-to-pdm.htm.
[41] www.hl7.org. Health level 7 (hl7). http://www.hl7.org/.
[42] X12. ANSI ASC X 12. WWW. http://www.x12.org/.

23
 Werkzeuge zur Visualisierung von Ontologien

team@xml-clearinghouse.de
www.xml-clearinghouse.de

Was ist das XML Clearinghouse?

Das XML Clearinghouse für Berlin und Brandenburg ermöglicht Wissenstransfer zu
XML-Technologien durch öffentlich zugängliche Dienstleistungen. Es beobachtet,
bereitet auf und vermittelt die Entwicklung von XML-Technologien und deren
Anwendungen. Als Teilprojekt des regionalen Wachstumskerns <xmlcity:berlin> sorgt
es für einen Wissenstransfer von der Forschung zur Anwendung in der Region Berlin
und Brandenburg.

Ein Forum zum Wissenstransfer

Das XML Clearinghouse bietet Foren für Akteure aus Forschung, Wirtschaft und
Intermediären zu gemeinsamen Aktivitäten. Ein Webportal ist Anlaufpunkt für XML-
Informationen und regionalen Angeboten dazu. Fokussierte wissenschaftliche
Workshops beleuchten aktuelle Themen, einzelne Entwicklungen werden in
Schulungen didaktisch aufbereitet dargestellt. Die Vorträge im regelmäßigen XML-
Kolloquium berichten von neuen Entwicklungen und Anwendungen.

Workshops
In wissenschaftlichen Workshops werden in begutachteten Beiträgen neue Arbeiten
mit XML-Bezug dargestellt. Diese Veranstaltungen finden mit Unterstützung
unterschiedlicher Informatikgesellschaften, wie zum Beispiel der Fachgruppe
Multimedia der Gesellschaft für Informatik, statt und haben dadurch einen hohen
Stellenwert.

Schulungen
Eine Schulungsreihe dient dem Wissenstransfer zu XML-Technologien. Das XML
Clearinghouse vermittelt ausgewählte XML-Themen in Tiefe und entwickelt dafür
Schulungsmaterial.

Kolloquium
Das XML Clearinghouse bietet eine frei zugängliche Kolloquiumsreihe an, die
abwechselnd an der FU Berlin und HU zu Berlin durchgeführt wird. Im Rahmen dieses
Kolloquiums finden Vorträge und Diskussionen statt.

Web-Portal
Ergänzend zu den Veranstaltungen bietet das XML Clearinghouse eine öffentlich
zugängliche Informationssammlung an. Gegenstand der Sammlung ist XML-
Technologie und deren Standardisierung und Anwendung. Das Webportal enthält
insbesondere Informationen zu XML mit Bezug zu Berlin und Brandenburg.
team@xml-clearinghouse.de
www.xml-clearinghouse.de

Reportreihe XML Clearinghouse:

Im Rahmen des Projektes XML Clearinghouse für Berlin und Brandenburg
sind die folgenden Reports bereits veröffentlicht worden:

Report 1 : XML-Standards in der Medizin

Autor: Russell Watson

Report 2 : XML-Security Standards

Autor: Anja Jentzsch

Report 3 : XML in Berlin und Brandenburg

Autor: Richard Cyganiak

Report 4 : VoiceXML Markt und Möglichkeiten

Autor: Silvan Heintze

Report 5 : Software zum Ontologiemanagement mit OWL

Autor: Sebastian Tietz

Report 6 : Speicherverfahren und Werkzeuge für RDF/S

Autor: Jan Große

Report 7 : Technologien des Semantic Web

Autor: Alexander Hölßig

Report 8 : Recruitment
Autor: Christian Bizer, Malgorzata Mochol, Daniel Westphal

Report 9 : Semantisches Matching

Autor: Maren Lenk

Report 10 : RFID and the Semantic Web

Autor: Franziska Liebsch

Report 11 : Visualisierung von Ontologien

Autor: Maren Lenk

Report 12 : Tourism Standards

Autor: Anja Jentzsch

Report 13 : Product classification and descriptions in the range of food

Autor: Susanne Richter