To achieve inter-enterprise software interoperability, the semantics of interchanged information by using electronic business documents, has to be explicitly modeled. A common approach to model semantics is to use an ontology. However, there is an emerging approach that combines an ontology with its context definition. So, the misunderstanding can be avoided if the context is explicitly defined. The resulting structure is called contextual ontology. To process a contextual ontology at run time, it has to be expressed in a machine procesable language. Recently, some languages have appeared. But, the main disadvantage of these languages is that they are mostly based on logic formalisms to support machine reasoning. Then, for the analysis and design phase of electronic business documents, a more appropriate contextual ontology modelling language is needed. To this aim, this paper presents a language for modelling explicit and formal contextual ontologies that assists business ontology designers in modelling contextual ontologies associated to electronic business documents.
Nowadays, enterprises confronts technological changes, such as Internet and mobile computing, and business changes, such as shorter product life cycles and global market; that makes business decisions complex and difficult. In this scenario, business managers need appropriate tools for conducting collaborative business over Internet. This way of doing business is called e-Collaboration. The e-Collaboration is supported through electronic business documents interchanges.
When information passes between companies, inconsistencies and misunderstandings
occur very often, leading to wasted work efforts. To solve this problem XML-based
specifications were defined to exchange business information between partners. These
specifications propose to use the same vocabulary, that is, the same collection of terms.
However, this is unrealistic since in the same department of different enterprises, people
could use the same term to define different concepts. This problem is known as semantic
interoperability problem. In order to overcome this problem we have to explicitly define
the meaning of the terms, its semantics [
A common approach to represent semantics is to use an ontology. However, it is well
known that a human being does not reason without context. So, if we explicitly define the
context, we improve the semantic interoperability. The resulting structure is called
contextual ontology [
To process a contextual ontology at run time, it has to be expressed in a machine procesable language. Recently, some languages have appeared. However, from business perspective, the main disadvantage of these languages is that they are mostly based on logic formalisms to support machine reasoning. This makes the language syntax unfamiliar to business analysts who model the electronic business documents (EBD).
To overcome the gap between people involved in the definition of EBD and ontology
specification languages, a contextual ontology modeling language is needed. A model
consists of sets of elements that describe some physical, abstract, or hypothetical reality.
Good models serve as means of communications [
The objective of this paper is to present a metamodel for modeling explicit and formal contextual ontologies, for human processing, associated to EBD. Firstly, we discuss some related works. Then, we present the proposed metamodel. Following, we analyze relationships between XML-based specifications and ontologies in order to add formal and explicit semantics to EBD. Finally, we present our conclusions.
The wide acceptance of the Unified Modeling Languages (UML), not only in academia
but also in software development; makes it an ideal language to be used in order to create
a critical mass of people able to build high quality models of information semantics.
Cranefield (2001) proposed an ontology representation formalism based on a subset of the
UML together with its associated Object Constraint Language (OCL) for agent software
communication. However, UML itself does not satisfy needs for representation of
ontology concepts that are borrowed from Descriptive Logic and that are included in
ontology specification languages [
The Ontology Working Group is defining the Ontology Definition Metamodel (ODM)
[
The need for a dedicated contextual ontology modeling language stems from the observation that a contextual ontology cannot be sufficiently modeled in UML or ODM.
In order to define the proposed modeling language, we have imported from the “UML
2.0: Infrastructure” specification [
The main design principles of the metamodel are: (1) easy to use in rapid development of contextual ontologies from electronic business documents, (2) modularity and (3) high independence degree of contextual ontology specification languages.
In order to fill the modularity design principles, the metamodel constructs were grouped into packages. The main package is the Kernel Package which imports the reused elements from Infrastructure::Core Package. All metamodel elements are derived from Kernel elements. Following we define the other packages of the proposed metamodel.
An ontology Oi is defined as a 4-tuple of the form Oi = <Ti, Pi, Ri, Ai> where: i identifies the domain that an ontology is associated with; Ti is a set of terms tj ∈ Oi ;Pi is a set of properties of terms tj ∈ Ti; Ri is a set of relations between tj and tx ∈ Ti and Ai is a set of axioms.
Classes and associations, defined in the proposed modeling language for ontology modeling, are showed in Figure 1. The main component is Ontology class that includes definition of concepts used to describe a domain. This class is associated with the OntologyElements abstract metaclass, which groups the objects of an ontology metamodel. If an ontology is removed, so are the elements owned by it. The imports association represents that an ontology could contain definitions whose meanings are defined in other ontologies. The prior_Version association identifies the referred ontology as a prior version of one ontology. Each ontology element could be described by a comment, represented by the Documentation class. Finally, each ontology could be described by Feature, such as creation date, author, subject, title and so on.
Element (from Kernel)
1 annotatedElem ent NamedElement (from Kernel) na me : Strin g na mesp ace : URIrefe rence imports includes 0..n
Onto logy 0..1prior-Version
Comment (from Kernel) Body : String Documentation Type : String
A term and their relations with other terms represent a concept. A term can be simple or complex. Simple terms have literal of some kind as their values. Complex terms are composed by simple or complex terms.
Properties describe the features of a term. For example, allowed values, the number of the values, and other features of the values that a simple or complex term could take.
The metamodel that represents the relation between Property and Term is showed in Figure 2. In the proposed metamodel, the class Property defines the features of a term so if a term is removed the properties owned by it have to be removed.
0..1 0..1 Property property 0..n characterizedTerm
Term 1 type
Instances
ValueSpecification (from Kernel) DataType (from DataType) 1 type Simple Complex +axioms 0..n non-Relational (from Axioms)
A set of relations Ri represents how terms belonging to Oi are related to. Relations can be divided into hierarchical relations (is-a, part-of), conceptual relations (synonym and antonym), particular relations (defined by the ontology modeler) and the relation that states that a term is an attribute of another term.
Term and Relations classes are associated via the RelationEnd class, as showed in Figure 3. An instance of Relations class has to be associated with two instances of RelationEnd class, the source and target. RelationEnd class is associated with one Term class and contains the information about cardinality and the role of terms. Furthermore, this class has the Navigable attribute to represent the direction of the relation.
The Particular class allows ontology modeler to model user-defined relations between terms. One important requirement for ontologies is the ability to structure the relations into hierarchies, i.e., to define sub-relations of a relation. Furthermore, it is suitable to define equivalent relations and inverse relations. Subrelationof, inverseof and equivalentto relations model these characteristics.
Each relation could be characterized by axioms and this is modeled by the axiom:Relational [0..n] association.
Term (from Terms and Properties) associa tedT erm
1 Attribute
Hierarchical
Conceptual is-a part-of inst-of
Synonym
Antonym
Comp ositeRela tion
SimpleRelation
Axioms are properties of relations and facts about concepts. Axioms help to constrain interpretation of concepts and provide guidelines for automated reasoning.
In the knowledge engineering area, axioms have been represented using logic
languages. In the UML class diagram, axioms could be expressed by Object Constraint
Language (OCL) [
Axioms can be divided into three subsets: the set of axioms for relational algebra, the set of general axioms and the set of axioms that states relations between attributes of a term. These sets of axioms are representing by Relational, AParticular and nonRelational classes, respectively, as showed in Figure 4.
The Relational class is an abstract class that groups the symmetric, transitive, antisymmetric, reflexive and functional axioms. The AParticular class is associated with the Period class indicating that an axiom could be true during a period of time. non-Relational +expression 1..n {ordered}
Axioms
There is no unique definition about what a context is. Different approaches use their own assumptions to define a context and use it for different purposes. In computer science, several context definitions have been defined in different areas, such as artificial intelligence, software development, databases, knowledge representation and semantics Period 0..n Start : Date
1 +expression
ValueSpecification
(fromKernel)
web. However, all of these notions of context are very diverse and suffice for different
purposes [
In the class diagram of Figure 5, we associate the Context class with an Ontology class
and with one or more Assumptions classes. In [
Furthermore, a context could be a simple one or a complex one. That is, a context could be formed by other contexts. For example, the context of an enterprise could be composed by different contexts that represent different decision points, such as Forecasting, Planning, Scheduling, Product Design, and so on.
A context mapping Ms,t allows us to state that a certain property holds between elements defined in the source context s and the target context t.
Mappings are directional, i.e., Ms,t is not the inverse of Mt,s. A mapping Ms,t might be
empty [
A context mapping is defined by bridge rules as linking rules between contexts. A bridge rule from context s to context t is a statement of one of the following forms, NamedElement
(from Kernel) name : String namespace : URIreference +context 0..1 1..n prior-version 0..1
Context +composed-by CompositeContext
SimpleContext
0..n derivedfrom
Ontology (from Ontol ogy) +ownedOntology 1..n 1..n +assumption
Assumptions
ValueSpecification (fromKernel) cs : ei ≡→ct : e j cs : ei ⊥→ct : e j cs : ei *→ct : e j cs : ei ⊆→ct : e j
(1) (2) (3) (4) where ei and ej are elements of context cs and ct respectively.
For example, Forecasting:Item Rule (1) means that ei is similar to ej.
Scheduling:Item.
Rule (2) means that both elements are disjointed. For example, Forecasting:Forecast ⊥→ Scheduling:Employee.
Rule (3) means that ei and ej are compatible elements. For example, Forecasting:Forecast *→ Scheduling:Schedule (an Schedule derives from a Forecast). Rule (4) means that ei is less general than ej and Rule (5) means that ei is more general than ej. For example, Forecasting:Bucket ⊇ → Scheduduling:Date (bucket: valid forecast time period). cs : ei ⊇→ ct : e j (5) ≡→
Finally, we have to define the container of all the above defined elements. This container is the domain space concept. That is, the contexts and the mapping rules that relate the elements between contexts are contained in a domain.
Classes and associations to model context mappings, bridge rules and the domain space are showed in Figure 6. The DomainSpace class is associated with one or more Context and Mapping classes. A Rules class associated with the BrigdeRules class could be one of the five rules previously defined, Equivalence, MoreGeneral, LessGeneral, Compatible and Disjunct.
NamedElement
(fromKernel) + name : String + namespace : URIreference
DomainSpace + Description
Element (fromKernel) Mapping
BridgeRule 0..1
1..n target 1
Context 0..1 1..n (from Context) 0..n 1..n 1
1 source 1
(fromKernel)
Equivalence MoreGeneral LessGeneral Compatible Dis junct
XML (eXtensible Markup Language) has became a standard for business information
interchange in a e-Collaboration domain where the information is interchanged by using
electronic business documents based on XML [
First of all, trading partners have to define the context and the characteristics that make the context unique. Then, they decide about the schemas of business documents that will be interchanged during the e-Collaboration relationship. Finally, they have to model the semantics associated to these business documents.
To model an ontology from a document based on XML, we have defined some rules presented following: 1. The xsd:complexType element has to be modeled by the class Complex. For example, from the document defined in Figure 7, line 1 and line 17, we can model LocalAddress and ReplenishmentOrder terms as complex terms. 2. The xsd:simpleType element has to be modeled by the class Simple. For example, from the document presented in Figure 7, line 26, we can model Description element as a simple term. 3. The xsd:element element could be simple or complex depending on its type definition. That is, if they are defined as a base xsd type, they are simple terms. For example, on line 5 the zip element is defined as xsd:string. So, this element has to be modelled as a simple term. Then, on line 23, the term ItemQuantity element is defined as Quantity. Due to Quantity (line 10) is defined as complexType, ItemQuantity is a complex term. 4. The xsd:restriction element has to be modelled by Properties class. For example, on line 27 the Description element is restricted by using xsd:restriction definition so this characteristic has to be modelled as a property of the Description term.
After identifying the terms, the associations between them have to be defined. These relationships between concepts can be derived from an XML document as follows: 1. The xsd:extension element represents the is-a relationship between terms. For example, in Figure 7 line 18, the <xsd:extension base = "Address"> definition states that the previously defined element (LocalAddress) is-a Address. 2. The combination of complexType and element primitives represents the part-of relationship between terms. For example, all elements defined between the complexType primitives that define the ReplenishmentOrder term are related to it by the part-of relation. That is, Date, Description, Items and LocalAddress are part-of ReplenishmentOrder. 3. The element primitive represents the Inst-of relation between terms. 4. The xs:attribute represents the Atributte relation. For example, in line 13 the definition states that uom term is an attribute of Quantity term.
Figure 8 presents the model of the terms belonging to the XML-based document
represented in Figure 7. On the one hand, at the left of the figure 8, we can see the
syntactic model of the Planning Schedule document represented like a tree. On the other
hand, at the right of the figure, we can see the semantic model. This model was obtained
by applying the rules above defined. The graphical notation is based on [
New information technologies provide new opportunities for allowing e-Collaboration which requires integration of the information and processes needed to conduct business in real time. XML is becoming widely used for defining electronic business documents within an e-Collaboration. However, these specifications need to be enriched using contextual ontologies due to XML does not express semantics by itself.
In order to fill the gap between people involved in the electronic business documents definition and contextual ontology specification languages we have defined a Contextual Ontology Definition Metamodel. This metamodel allows business analysts to explicitly model a contextual ontology. Furthermore, we have defined a set of rules to model the semantics implicit in XML-based business documents. These rules are based on the elements that can be modeled automatically from an XML-based document. Other contextual ontology elements have to be defined by the ontology modeler.
This work has to be partially supported by Banco Rio S.A. and Universidad Tecnológica Nacional.