Research issues in STARLab

This page contains some information on the general research interests of STARLab, as well as details on the DOGMA initiative that is the lab's anchor project. Detailed information on specific research projects and publications can be found elsewhere.



Research interests:
The Semantic Web, Databases and Ontologies Currently, STARLab's research interest is mainly focused on the fairly recent field of the so-called Semantic Web (T. Berners-Lee, 2000; also Scientific American, May 2001) and more specifically in one of its principal enabling technologies, known as "ontologies". One definition of an ontology is the one by N. Guarino and P. Giaretta (1995) (based on an earlier one by T. Gruber, 1993): "an ontology is an explicit, partial account of a conceptualization". Another related definition is the one given by M. Uschold and M. Gruninger: ontologies are agreements about shared conceptualizations. Indeed, since many conceptualizations about a small part of the world are possible, the term "agreement" is a key issue. An ontology thus necessarily includes a specification of the terms used (terminology) and agreements that allow to determine their meaning, along with the possible inter-relationships between these terms, standing for "concepts". To express concepts we need languages, of course. Several ontology languages are at this moment being developed and studied, most notably RDF Schema and OWL . Also, an ontology ---or rather its commitment--- restrains the possible interpretations of terms within the domain it covers. One important way of ontology representation therefore uses principles and methodology of databases, exemplified in the STARLab DOGMA Project. A key general resource of information on the Semantic Web, ontologies and ontology languages is www.w3c.org Also industrial players are interested in the opportunities of the Semantic Web, especially as the technology's claimed assets are improved information retrieval performance and better systems interoperability. STARLab's contribution to the ontology world consists mainly of basic research on standards for ontologies, ontology servers, unification and exchange of metadata, ontology content, reusable ontologies and ontology contexts. STARLab is also a member of the AgentLink Special Interest Group on Intelligent Information Agents, as well as a founding member of OntoWeb , another EU Thematic Network on ontology research, where it participates, along with experts from around the world.

DOGMA project is to set up an ontology server in order to assist the gathering and incremental growth of ontologies. The use of the extremely simple structures should -we conjecture- achieve at least a degree of scalability not possible with more complex representations hitherto used in the literature and practice. This extensional approach will naturally lead to very large sets, thereby moving the issue to matters of ontology organization, rather than of representational power or sophistication. Sources of domain-specific knowledge, as opposed to general-purpose lexicons like Wordnet etc., will be formed e.g. by relational database schemas, yielding an activity best described as ontology mining.

Interesting research issues about contextual layers within ontologies arise here as one e.g. needs to separate local jargon from “common knowledge”. Other important sources are numerous existing thesauri and glossaries.

DOGMA-MESS is an ontology capturing methdology introduced by STARLab in 2006. It achieves its overall objective of supporting collaborative communities in defining a relevant common ontology in an evolutionary process in which (core) domain experts and knowledge engineers interact intensively and in a focused way.

DOGMA Modeler

Short description of DOGMAModeler

DogmaModeler is an implementation of a theoretical DOGMA framework, including its model (the “Lexon” model) for creating, editing and representing ontologies, based on the separation of the ontology base and ontological commitments.

The screenshot of DogmaModeler is shown below where the left pane contains an ontology base represented as tree and the right pane is a graphical ontology editing tool. DogmaModeler can be used in two modes: either a user is editing the ontobase (the constraints toolbar is disabled), either he creates ontological commitments (it is possible to use the content of the ontology base, but impossible to change it).

The following features make DogmaModeler very efficient for knowledge engineering, in particular browsing and/or editing an ontology base and/or ontological commitments.
  1. Ontology base and ontological commitment trees. A user is able to choose what commitment (s)he wants to review and for what application.

  2. Graphical representation of ontology base and/or ontological commitments.

  3. Tree of concepts and rules – another way of browsing part of ontology base and/or ontological commitments.

  4. Natural language – verbalised representation of a conceptual model. The output are the facts and their constraints in pseudo natural language sentences, which allows non-experts to check, validate or build conceptual schema.

  5. ORM-ML window represents conceptual models in ORM Markup Language.

contact: mustafa.jarrar@vub.ac.be

The ontology server in DogmaModeler

DOGMA Studio Server

The DOGMA Studio Server is a robust ontology server, developed in J2EE and deployed in a JBoss Application. It completely supports the DOGMA ontology engineering approach, distributed over the Lexon Base, the Commitment Layer and the Concept Definition Server (CDS).

Through its J2EE deployement, it provides access to all sorts of Java client applications (such as the DOGMA Studio Workbench). These interfaces can also be externalized as web services, thereby enabling interaction with all sorts of different platforms and clients.

DOGMA pipelineDOGMA pipeline


DOGMA-MESS

 

(Fig. 1 - DOGMA MESS overview)

 

DOGMA-MESS achieves its overall objective of supporting collaborative communities in defining a relevant common ontology in an evolutionary process in which (core) domain experts and knowledge engineers interact intensively and in a focused way.

Useful Links:

1. DOGMA-MESS WIKI

2. DOGMA-MESS Manual

3. DOGMA-MESS Tutorial

Tools

This page contains all the tools that are (or being) developed at the STARLab.

Tool Name Summary Availability
 It is a ontology-based wiki (semantic wiki) to support scientific exchange, the development of new technologies and knowledge around virtual representations of human body for interactive medical applications.
It's an open semantic wiki, you can have a free access at: http://3dah.miralab.ch/cms/

DoggyBank

DoggyBank is a social web page tagger based on DOGMABank. DoggyBank firefox extension is compatible with firefox 1.5.x (not yet with 2.x) and requires a Java JVM 1.5 or later to be installed.It was developed in 2005.

Users can download the free trail version of DoggyBank here. This trail version only contains limited concept definitions.

The DOGMA-MESS (Meaning Evolution Support System) is a state-of-the-art system built on the DOGMA framework for scalable ontology engineering. It helps communities of practice consisting of stakeholders from different organizations to define shared ontologies that are relevant to their joint collaboration objectives. The goal of DOGMA-MESS is to provide support to make this complex and fuzzy shared meaning evolution process of a collaborative community as effective and efficient as possible. It was developed in 2006.

http://www.dogma-mess.org/

Users need to contact STARLab (not free) to have the access to DOGMA-MESS.

To learn DOGMA-MESS, visit here.

DOGMA Studio Workbench is a marvelous collection of tools to facilitate the life of the DOGMA ontology engineer (overview) The current version of DOGMA Studio Workbench is able to edit lexons, browse lexons, visualize lexon NORM trees, visualize some ORM constraints that are applied to the lexon NORM tree at the commitment layer.

Not free. Currently we are preparing to make a free trial version.


Ontology based Online Email Fraud Detector V1.0. Online version is free.

STARLab Logo

DOGMA Studio

DOGMA Studio Server is a robust ontology server. It is developed as a JBoss J2EE application, backed by a PostgreSQL relational database. It supports the DOGMA framework for ontology engineering.

Not free. Use of this server through the API is currently restricted to project partners. DOGMA-MESS and the DOGMA Studio Workbench provide access to the content stored in the server.

Feel free to contact us for cooperative opportunities.

DOGMAModeler is an implementation of a theoretical DOGMA framework, including its model (the “Lexon” model) for creating, editing and representing ontologies, based on the separation of the ontology base and ontological commitments. Note that it only uses ORM diagrams to describe the commitment layer. We propose to use the DOGMA studio workbench for avdanced DOGMA ontology engineering.

Users who only use DOGMAModeler for their own researches can contact mustafa.jarrar@vub.ac.be for the free download.

The Profile Compiler is a web based competence profile tool. It allows Small to Medium Sized Enterprises (SMEs) to browse through various jobs and competencies, and to easily compile this information into a competency profile for themselves.

The application gives access to the knowledge repository that was assembled in the PoCeHRMOM project based on various competeny resources (e.g., O*NET, SERV).

The current version of the user interface is Dutch only. The contained competencies and jobs are available in three languages (English, French and Dutch).

Freely accessible on the web. Contact Stijn Christiaens or Yan Tang for more information.

Check out the demo scenario video or (the low quality youtube distribution)!

 
 The ODMF is a set of tools that supports ontology-based data matching tasks. Its preliminary version contains seven matching strategies based on matching algorithms.  

 

DOGTagger

 The DOGTagger is an annotation tool, which supports organization-specific, ontology-based annotation. It was initially designed and implemented by Stijn Christaens in 2006 (CoDrive project) . The current version is implemented by Peter Debaer in 2009 (Prolix project).  The online version is free of charge.
 The SDT tool set is designed and built as an (Eclipse) perspective for the DOGMA studio framework. It is a group decision making system that is embedded with modern ontology engineering technologies. It supports the approaches to semantic decision tables. The SDT perspective is designed, constructed and implemented as a collection of loosely coupled (Eclipse) plug-ins. Contact Dr. Yan Tang for more information
  Secure Process Annotator (SPA) is a tool to supports the annotation of BPMN elements, using an ontology base grounded in natural language. Provides valid annotation recommendations searching for similarity within previous annotations.  

 

(last update: 2010-10-15)

DECOL Rule Writing Language (Syntax)

Qualification | Set Constraint | Logical Connector | Relational Property | Control Operator | Meta SDT

DECOL stands for “Decision Commitment Language”. Note that the SDT commitments are formed according to a semantic path. A semantic path has two directions. For example, the commitment

P1 = [competence level, is of, has, competence]: L (P1 (has), P1 (is of)).

The above commitment is read as "competence level is NECESSARILY of competence".
A semantic path ends with a dot ".". Readers may be careful not to write a dot before the end of a commitment.
A semantic path is often labeled and starts with an alphabetic word. Numbers, underscores may follow this alphabetic word, e.g. P1, path_A, competence1_a etc.
A semantic path is written as a lexon, which has the order of head term, role, co-role and tail term. If an element is omitted, we keep the slot empty. For example, the following examples of semantic paths are accepted:

P1 = [person, work, , ].
P2 = [person, work for, , university].
P3 = [ , , , university].

Any ontological constraints can be put after a declaration of a semantic path (or a set of semantic paths). A colon ":" is used to split a semantic path declaration and its constraint(s).

1. Qualification

1.1. Cardinality

1.1.1. Cardinality of Uniqueness

Consider a lexon that represents the fact "(a) person is born in (a) country". If we apply the Cardinality of Uniqueness to the lexon “EACH person is born in AT MOST ONE country”.
We write this SDT commitment as:

P2 = [person, is born in, is the place of birth, country]: UNIQ (P2).

There also exists spanned uniqueness. Look at the following examples:

P2_1 = [car, is driven by, drives, driver]: UNIQ (P2_1).
P2_2 = [driver, drives, is driven by, car]: UNIQ (P2_2).

They are different from the commitment below:

P2_1 = [car, is driven by, drives, driver], P2_2 = [driver, drives, is driven by, car]): UNIQ (P2_1, P2_2).

The former is verbalized as "EACH car is driven by AT MOST ONE driver, and, EACH driver drives AT MOST ONE car". The latter is verbalized as "the record pair of driver and car is UNIQUE".
The above commitments with the uniqueness constraints are direction sensitive. Seeing that the uniqueness constraint is applied only on roles (not on terms), they can in practice be written in a direction insensitive way.
For example,

p2 = [person, is born in, is the place of birth, country]: UNIQ (p2 (is born in)).

The above statement can as well be written as below.

p2 = [person, is born in, is the place of birth, country]: UNIQ (p2).

The commitment -

p2_1 = [car, is driven by, drives, driver]: UNIQ (p2_1 (is driven by)), UNIQ (p2_1 (drives)).

- is equivalent to

p2_1 = [car, is driven by, drives, driver]: UNIQ (p2_1).
p2_2 = [driver, drives, is driven by, car]: UNIQ (p2_2).

The commitment -

p2_1 = [car, is driven by, drives, driver]: UNIQ(p2_1(is driven by), p2_1(drives)).

- is equivalent to

(p2_1 = [car, is driven by, drives, driver], p2_2 = [driver, drives, is driven by, car]): UNIQ (p2_1, p2_2).

1.1.2. Cardinality of Multiple (Occurrence frequency)

Suppose that we have a lexon and we want to have a commitment as "EACH person has AT MOST 2 legs". The SDT commitment is written as:

P3 = [person, has, is of, leg]: CARD (p3 (has), 2).

If there is a lexon and a company has its own (decision) rules, such as "EACH employee has AT MOST 5 job titles". We can write an SDT commitment as:

p4 = [employee, has, is of, job title]: CARD (p4 (has), <=5).

Note that the cardinality is also called occurrence frequency in ORM (Halpin, 2001, p. 278) and in this thesis (section 4.1.2.1). The occurrence frequency defined in ORM defines the column number in a data table, while we use it as an operator to specify the occurrence of an object that plays a certain role. “CARD” is only applied on the lexon roles.

1.2. Quantification

Quantification is normally used in logic to satisfy an open formula. In predicate logic, they can be used respectively for the existential quantification and universal quantification.

1.2.1. Universal quantification

The SDT commitment:

P5 = [person, has, is of, mother]: FORALL (P5).

It expresses that "EVERY (or FOR ALL) person has mother ".

1.2.2. Existential quantification

The SDT commitment –

P6 = [person, work in, is the working place of, enterprise]: EXIST (P6).

It means that "SOME person(s) work in enterprise" or "there EXISTS (a) person who work(s) in enterprise".
Note that how to use the qualification in SDT is a future work. It is not used within the discussions of this thesis. Therefore, we have only defined it at the syntactical level for the DECOL language.

1.3. Value Constraint

It is rather easy to understand the value constraint. The mathematical operators - <,>,>=, <=, = - are verbalized as "less than", "more than", "more than or equal to", "less than or equal to" and "equal to" respectively.
For instance, we have an SDT commitment as:

P6 = [group, has, is of, member number]: P6 (member number) <=5, P6 (member number)>=2.

The above commitment means, the member number of a group is more than 2 and less than 5. Note that in the earlier version, we use a propositional separator • to separate the path and its path member. For instance,

P6 = [member, has, is of, member number]: P6• (member number) <=5, P6• (member number)>=2.

The value constraints are also used to limit the value candidates. For example, English course has only five levels – EN A, EN B, EN C, EN D and EN E. The commitment is written as follows.

P9 = [English course, has, is of, English course level]: P9 (English course level) = {EN A, EN B, EN C, EN D, EN E}.

Furthermore, if we want to train employees with the English courses level up to B, then we have the commitment written as below.

(P10 = [Employee, learn, is learned by, English course], P11 = [English course, has, is of, English course level]): P11 (English course) = {EN A, EN B}. 

Queries

If we want to get a value that is the minimum value in the value range, then we use the following statement.

(P1= [Weight, has, is of, Value]): MIN(P1 (Value)).

If we want to get a value that is the minimum positive value (>0) in the value range, then we use the following statement.

(P1= [Weight, has, is of, Value]): MIN_POS(P1 (Value)).

If we want to get a value that is the minimum negative value (<0) in the value range, then we use the following statement.

(P1= [Weight, has, is of, Value]): MIN_NEG(P1 (Value)).

If we want to get a value that is the maximum value in the value range, then we use the following statement.

(P1= [Weight, has, is of, Value]): MAX(P1 (Value)).

If we want to get a value that is the maximum positive value (>0) in the value range, then we use the following statement.

(P1= [Weight, has, is of, Value]): MAX_POS(P1 (Value)).

If we want to get a value that is the maximum negative value (<0) in the value range, then we use the following statement.

(P1= [Weight, has, is of, Value]): MAX_Neg(P1 (Value)).

1.4. Modification

Modification is a computer linguistic term. Lexons are represented in (some) language, e.g. English. One task of the commitment layer is to interpret the "meaning" of lexon terms. Understanding adverbial clauses and how they function in discourse is often very useful in interpreting subtle layers of meaning. Therefore, it is necessary to have the modification as a special kind of commitment constraint.
There are two types of modifiers for a lexon - the pre-modifier and the post-modifier. Accordingly, the modification can be pre-modification or post-modification.

1.4.1. PREMODI - pre-modification

P7 = [weather, cause, is caused by, mood]: PREMODI (P7 (weather), rainy), PREMODI (P7 (mood), bad).

The commitment means that 'weather' is pre-modified with 'rainy' and 'mood' is pre-modified with 'bad'.

1.4.2. POSMODI - post-modification

P8 = [weather, cause, is caused by, depression]: POSMODI (P8 (weather), from Belgium).

It means that 'weather' is post-modified with 'from Belgium'.
Note that modification is not discussed in this thesis. It is a future work.

1.5. Time

Time constraints are often seen as 'before', 'after', 'at the same time', 'in parallel' etc. In the current version, we only include the comparison of two facts in the time aspect. For instance, a fact (represented as a lexon) happens later than another fact.

1.5.1. Time sequence (Sequence)

Suppose that we have two facts - 'a user has a login name', 'a user logs in the system'. The former happens earlier than the latter. We model the commitment as -

(P9 = [user, has, is of, login name], P10 = [user, log in, is logged in, system]): TSEQ (P9, P10).

TSEQ can contain more member parameters, i.e.

(P9 = [user, has, is of, login name], P10 = [user, log in, is logged in, system], P11 = [user, request, is requested by, order]): TSEQ (P9, P10, P11).

The commitment above means that P9 (a user has a login name) happens before P10 (the user logs in a system), and P10 happens before P11 (the user requests an order).
The sentences, such as '... happens before (after)...', can be used to express this kind of time sequence constraint
TSEQ is used equivalently to ORDER. For instance, the commitments above can also be written as below.

(P9 = [user, has, is of, login name], P10 = [user, log in, is logged in, system]): ORDER (P9, P10).

And,

(P9 = [user, has, is of, login name], P10 = [user, log in, is logged in, system], P11 = [user, request, is requested by, order]): ORDER (P9, P10, P11).

1.5.2. Parallel events

The sentences, such as the ones that contain the phrase 'happens at the same time as', can be constrained with parallel time constraint.

(P12 = [data, is enriched by, enrich, user], P13 = [data, is enriched by, enrich, system administrator]): PARA (P12, P13).

This commitment means that data is enriched by a user; and at the same time, data is enriched by a system administrator.
Note that only time sequence is used in this thesis. Two parallel events can be described with the time sequence constraint. For instance, the commitment of “The events ‘data is enriched by user’ and ‘data is enriched by system administrator’ happen simultaneously” can be also written as below.

(P12 = [data, is enriched by, enrich, user], P13 = [data, is enriched by, enrich, system administrator]): NOT (ORDER (P12, P13)), NOT (ORDER (P13, P12)).

1.6. Aspect

If we consider a concept (that is, an SDT lexon term) as a class, then an aspect describes an iteration of the interaction between two (or more) concepts. In the field of modern programming languages, the notion of aspect is specified as services. An aspect constraint indeed is the interpretation of a (co-)role of a lexon. For example,

P14 = [data, is enriched by, enrich, user]: INVSERV (P14 (enrich), serviceX).

The aspect constraint keyword "INVSERV" stands for "invoke service". Not that serviceX is a variable, which is application dependent. We may replace serviceX with a specific service of opening a URL that contains a data uploading service.
Note that the aspect constraint is not used in this thesis because further research needs to be studied in the future.

1.7. Identification Schema

The identification schema is another level of modeling view of SDT commitments. The modeling view is NOT equivalent to the graphical view. It will be explored in the future.

2. Set Constraints

2.1. Member

The member commitment describes the members of a set. For example, the commitment -

P15 = [professor, work in, is a working place of, university]: P15 (professor) = {'Robert Meersman', 'Edward Nyssen'}.

It means that 'Robert Meersman' and 'Edward Nyssen' are the members of the set of professors. They are also called instances of the type “professor”.
We can also treat the whole lexon as the set member. For example,

P16 = [Driver's License, is issued to, has, Driver].
P17 = [Driver, has, is of, Name].
Selection 1 = {P16, P17}.

It means that I have selected lexons and into the set Selection 1.

2.2. Intersection

The intersection constraint normally describes an overlapping subset of two sets. For instance, we have two sets of professors - the math professors and the biochemistry professors. The intersection set contains the professor who teaches both math and biochemistry. Accordingly, we have a commitment as below.

(P16 = [math professor, work in, is the working place of, university], P17 = [biochemistry professor, work in, is the working place of, university]): INTERS (P16 (math professor), P17 (biochemistry professor)).

2.3. Union

The set union contains all the members from any involved sets (See Fig. 2). For instance (following the same example), we have two sets of professors - the math professors or the biochemistry professors. The intersection set contains the professors who teach math or biochemistry (or both). Accordingly, we have a commitment as below.

(P16 = [math professor, work in, is the working place of, university], P17 = [biochemistry professor, work in, is the working place of, university]): UNION (P16 (math professor), P17 (biochemistry professor)).

2.4. Equality

The equality constraint is to construct the equivalent relations between two sets. The equivalent sets are sometimes called identity sets. Set A is equivalent to Set B when Set A has exactly the same members as Set B. For example, if consider the set of people who walk in a forest and the set of people who hike in a forest equivalently, we write the commitment as below.

(P18 = [people, walk in, is a leisure place for, wood]), P19 = [people, hike in, is a hiking place for, forest]): EQUAL (P18 (walk in), P19 (hike in)).

The constraint is checked when we update the members for the set of people who walk in a forest. An equality constraint needs to be applied on the lexon terms.
Example 2,

(P10 = [teacher, teach, is taught by, student], P11 = [teacher, has, is of, salary]): EQUAL (P10 (teach), P11 (has)).

The above commitment expresses the constraint that the set of the teachers who teach courses is equivalent to the set of the teachers who get paid.

2.5. Exclusion

We say that two sets are mutually exclusive when they do not share any members. For example, suppose that we don't allow a teacher to be a student at the same time. We shall apply the exclusion constraint as written below.

(P20 = [teacher, teach, is taught by, course], P21 = [student, learn, is learned by, course]): EXCLUSIVE_OR (P20 (teach), P21 (learn)).

Or,

P20 = [person, teach, is taught by, person]: EXCLUSIVE_OR (P20 (teach), P20 (is taught by)).

These two commitments are used equivalently.
Note that the exclusion constraint is equal to the disjunction connector in logics.

2.6. Subset

Set A is a subset of Set B when all the members of A belong to B. The subset constraint is applied on the roles of two lexons that share a lexon term. For instance, in the context of university, the set of the persons who are lecturers is a subset of the set of the persons who are teachers.

(P22_1 = [person, has job title, is of, lecturer], P22_2 = [person, has job title, is of, teacher]): SUBSET (P22_1 (has job title), P22_2 (has job title)).

2.7. Subtype

We use subtyping to classify an object type. For instance, if we specify the object type “bus driver” as a subtype of “driver”, then we write this commitment as below.

P13 = [bus driver, is a, is, driver]: SUBTYPE (P13 (bus driver), P13 (driver)).

The above commitment contains the subtype for one lexon. This constraint can also be applied to two lexon terms that belong to two different lexons, e.g.

(P13_1 = [bus driver, drive, is driven by, car], P13_2 = [driver, has, is of, driver’s license]): SUBTYPE (P13_1 (bus driver), P13_2 (driver)).

Note that the subtype can also be applied to lexon roles when a lexon contains “is-a” taxonomical role pairs. For instance, the first commitment can be written equivalently as below.

P13 = [bus driver, is a, is, driver]: SUBTYPE (P13 (is a)).

2.8. Mandatory

In database theory, a role is mandatory if and only if, for all states of the database, the role must be played by every member of the population of its object type.
There are two ways to write mandatory constrained commitments.
Method 1:

P30 = [driver, has, is issued to, driver's license]: L (P30).

It is equivalent to

P30 = [driver, has, is issued to, driver's license]: L (P30 (has, is issued to)).

And Method 2:

P30 = [driver, has, is issued to, driver's license]: MAND (P30).

It is equivalent to

P30 = [driver, has, is issued to, driver's license]: MAND (P30 (has, is issued to)).

L is used as the necessity operator in modal logic. The reason why we need two different names for the mandatory constraints is for the convenience of different kinds of users.

3. Logical Connectors

There are five basic propositional logic connectives. They are Negation, Conjunction, Disjunction, Implication and Equivalence (bi-conditional).

3.1. Negation

We use NOT to indicate the negation connective in the commitment. For example, the commitment -

P18 = [customer, is listed in, list, customer category]: NOT (P18 (is listed in), P18 (list)).

It can be verbalized as: a customer is NOT listed in a customer category, and can also be written as below.

P18 = [customer, is listed in, list, customer category]: NOT (P18).

3.2. Conjunction

A conjunction connective is read as 'and'. We use AND to formalize the semantics of conjunction constraint for the semantic paths.

(P19 = [STAR member, work for, is a working place of, STAR lab], P20 = [STAR member, work for, is a working place of, VUB]): AND (P19, P20).

The above commitment links two lexons together, which express that "a STAR member works for the STAR lab AND he works for VUB".

3.3. Disjunction

The disjunction operator is to link multiple choices of several lexons with the logical disjunction operator. Such commitments are designed with “OR”. For instance, if we have a commitment as "a person EITHER works for VUB, OR works for ULB". We use exclusive-or constraint for the commitment.

(P21 = [person, work for, is a working place of, VUB], P22 = [person, work for, is as working place of, ULB]): OR (P21, P22).

3.4. Implication

For example, the rule “IF a customer is not listed in the customer catalog THEN the order manager creates a new customer” can be expressed as a commitment:

(p23 = [Customer, is Listed In, list, Customer Catalog], p24 = [Order Manager, create, is Created By, New Customer]): IMPLIES (NOT (p23 (is Listed In), p23 (list)), p24).

3.5. Equivalence

As the equivalence operator is often used to check the equivalence of two formulae, we do not include it here. It should be a function at the application level to check, for instance, the similarity of two SDT commitments.

3.7. Possibility

Let’s look at this situation 1: a cat has skin and the skin color is possibly black. We write this commitment as below.

(P31 = [cat, has, is of, skin], P32 = [skin, has value, indicate, color]): P32 (color) = P {black}.

Note that we use P to indicate the possibility constraint and the set member operator {} to add the possible value. The above commitment is different from the commitment as below.

(P31 = [cat, has, is of, skin], P32 = [skin, has value, indicate, color]): P32 (color) = {black}.

The commitment without "P" is the value constraint. Therefore, the color can only be the set member - 'black'. However, the commitment with "P" means that the color can be 'black' or something else.

4. Relational properties

Halpin (2001) groups the following main relation properties in ORM: reflexive, symmetric, transitive (also called acyclic), antisymmetric, asymmetric, irreflexive and intransitive. We follow the same naming as in ORM ring constraints. ans – antisymmetric, as – asymmetric, ac – acyclic, ir – irreflexive, it – intransitive and sym – symmetric.
For example, if we want to apply the reflexive constraint on lexon . We write it as follows.
P33 = [person, teaches, is taught by, person]: RING_REF (P33 (teaches)).
Similarly, we write the relation properties of symmetric, antisymmetric, asymmetric, irreflexive and intransitive in the commitments as below.

P33 = [person, teaches, is taught by, person]: RING_SYM (P33 (teaches).
P33 = [person, teaches, is taught by, person]: RING_TRA (P33 (teaches)).
P33 = [person, teaches, is taught by, person]: RING_ANS (P33 (teaches)).
P33 = [person, teaches, is taught by, person]: RING_AS (P33 (teaches)).
P33 = [person, teaches, is taught by, person]: RING_IR (P33 (teaches)).
P33 = [person, teaches, is taught by, person]: RING_IT (P33 (teaches)).

Note that these relational properties are not used in this thesis because the application domain goes beyond this thesis. How to use these constraints is the future work.

5. Control Operators

In this thesis, there are two types of control operators: trans-context equality and trans-context subtyping. They are used when lexons are defined in different contexts.

5.1. Trans-Context Equality

The trans-context equality is used to control the population of a set. For example,

(P1 = [Teacher, teach, is taught by, Course], P2 = [Student, learn, is learnt by, Course]): TRANSCONTEXT_EQUAL (P1 (Course), P2 (Course)).

The above commitment means that all the instances in “Course” for P1 are equivalent to the instances in “Course” for P2.
The trans-context equality is very similar to the equality constraint. The difference between them is trans-context equality is applied to two lexons within two different contexts, while the equality constraint is applied to one lexon, or two lexons within the same contexts.
Note that the trans-context equality is always applied to two terms that belong to two lexons in two different contexts. And these two terms need to have the same name.

5.2. Trans-Context Subtyping

The trans-context subtyping is used to control the subtypes of an object type. For instance,

(P1 = [Teacher, teach, is taught by, Course], P2 = [Student, learn, is learnt by, Course]): TRANSCONTEXT_SUBTYPE (P1 (Course), P2 (Course)).

6. Meta SDT

A meta-SDT contains meta decision rules in the form of a decision table. We use the following statement to specify the location of a meta-SDT.

P=[META-SDT, has, is of, LOCATION]: P(LOCATION) = "C:\SDT Files\x.xml".

We use the following statement to specify the title of a meta-SDT (if it's unique).

P=[META-SDT, has, is of, TITLE ]:P(TITLE) = "TABLE X-1023".
 

Invocational SDTs

P6 = [GOTO SDT4, is instance of, has instance, INVOKE_COMMAND].

P7 = [GOTO SDT4, has, is of, FILE_LOCATION]: P7 (FILE_LOCATION) = “C:\\x.xml”.

 

More Examples

Example 1:  set the value range for a value that is annotated with predefined value types

The predefined value types are Float, Integer, Boolean and String (Single) and String (Set).

If we want to define a value that is a Float and it has a value range of [0,1], then the DECOL statement is written as follows.

(P1= [Weight, has, is of, Value], P2 = [Weight, has value type, is value type of, Float]): P1 (Value)>=0, P1 (Value) <=1.

P2 expresses the annotation lexon.

Example 2: set a value that is minimum in the value range

If we want to define a value that should be a minimum value in a value range of [0,1], then we write it as follows.

(P1= [Weight, has, is of, Value], P2 = [Weight, has value type, is value type of, Float]): P1 (Value)>=0, P1 (Value) <=1.

Type of Unit of Measurement

P1 = [Temperature, has, is of, Value]: MEASUREMENT_UNIT(P1 (Value), Celsius Degree). 

References

Yan Tang, Semantic Decision Tables - A New, Promising and Practical Way of Organizing Your Business Semantics with Existing Decision Making Tools , ISBN 978-3-8383-3791-3, LAP LAMBERT Academic Publishing AG & Co. KG, Saarbrücken, Germany, 2010.
http://www.amazon.co.uk/Semantic-Decision-Tables-Promising-Organizing/dp/3838337913

Other Issues

The above commitment contains a constraint that ensures the situation as follows. The subtypes of “course” in the context of P1 are equivalent to the subtypes of “course” in the context of P2.
In this thesis, we have only defined the control operators of trans-context equality and trans-context subtyping. A future work of the control operators will be inspired by the business process models (BPM).

[last update:2012-03-15] 

DoggyBank

Installation Requirements

The DoggyBank firefox extension is compatible with firefox 1.5.x (not yet with 2.x) and requires a Java JVM 1.5 or later to be installed.

Installation

To install DoggyBank download the attached DoggyBank.zip archive. Extract the DoggyBank-x.y.xpi file from the zip archive and double click to install.

On linux (and Mac?) you can execute firefox DoggyBank-x.x.xpi on the command line to install the extension.

Using DoggyBank

All DoggyBank functionality is available in the firefox tools > DogmaBank menu.

All information necessary to start working with DoggyBank can be found in the attached excerpt from Jan Vandenbussches master thesis. Keep in mind that the concept suggestions provided by DoggyBank depends on the information already in DOGMA Server. The system is bootstrapped with a lot of general concepts, but more specialised concepts are not in the system yet.

 

DOGMA Studio Workbench

DOGMA Studio is the tool suite behind the DOGMA ontology engineering approach. It contains both a Workbench and a Server. The Workbench is constructed according to the plug-in architecture in Eclipse. There, plug-ins, being loosely coupled ontology viewing, querying or editing modules support the different ontology engineering activities and new plug-ins continuously emerge. This loose coupling allows any arbitrary knowledge engineering community to support its own ontology engineering method in DOGMA Studio by combining these plug-ins arbitrarily. Such a meaningful combination of view/edit/query plug-ins is called a “perspective” in Eclipse. The DOGMA Server is an advanced J2EE application running in a JBoss server which efficiently stores Lexons and Commitments in a PostgreSQL Database. DOGMA Studio is complemented by a community layer in which the DOGMA collaborative ontology engineering processes are grounded in communities of use. This layer is implemented by the DOGMA-MESS methodology and system.

In the DOGMA ontology engineering approach ontology construction starts from a (possibly very large) uninterpreted base of elementary fact types called lexons that are mined from linguistic descriptions (be it from existing schemas, a text corpus or formulated by domain experts). An ontological commitment to such a ''lexon base'' means selecting/reusing from it a meaningful set of facts that approximates well the intended conceptualization, followed by the addition of a set of constraints, or rules, to this subset. The commitment process is inspired by the fact-based database modeling method NIAM/ORM2, which features a recently updated, extensive graphical support.

For encouraging lexon reuse by ontology engineers a more scalable way of visually browsing a large lexon base is important. Existing techniques for similar semantic networks rather focus on graphical distance between concepts and not always consider the possibility that concepts might be (fact-) related to a large number of other concepts. TLex in DOGMA studio Workbench introduce an alternative approach to browsing large fact-based diagrams in general, which is applied to lexon base browsing and selecting for building ontological commitments in particular. Specific characteristics of DOGMA such as grouping by contexts and its ''double articulation principle'', viz. explicit separation between lexons and an application's commitment to them can increase the scalability of this approach.

CDS (Concept Definition Server) is to provide the annotation information of a lexon term, that is, the linguistic definition of a concept. The current CDS is linked to WordNet and annotate lexon terms with their WordNet definition based on Synset.

The current version of DOGMA Studio Workbench is able to edit lexons, edit lexon term definition, link lexon term to WordNet, browse lexons, visualize lexon NORM trees, visualize some ORM constraints that are applied to the lexon NORM tree at the commitment layer. There is also full versioning and change log storage at Server side.

Overview of the visible tools in the suite

This section will give you a brief summary of the tools. The numbers correspond to the areas in the figure below.

 

 

  1. The Ontology Viewer is responsible for retrieving a list of ontologies, templates and specializations of the organization the user is in. It is a tree view sorting the ontologies in a directory structure.
  2. The Ontology Editor is used to browse and edit a selected ontology or template. Its a multi-page editor with four views for viewing/editing the taxonomy, viewing/editing the relations, viewing/editing the whole ontology and finally a small log for displaying information about the process to the user.
  3. The Ticket Viewer is responsible for displaying tickets to an organization. A ticket notifies an organization that a template needs to be specialized.
  4. The Ontology Operations is a tool displaying what actions can be performed on an item selected in the editor. It displays additional information or
  5. The Concept Viewer tries to look for the concept definition in the Concept Definition Server when a user clicks on a concept in the editor. A concept has a gloss and possibly a set of synonyms. Both are displayed in the concept viewer.

Other tools of the suite

There are a few other tools that are not immediately visible in the perspective. To open them you need to follow the steps from section ‘Finding the views’. The tools are:

  1. The Template Maker, which is used to make a template from an ontology after several non-taxonomical relations have been introduced.
  2. The Ticket Maker, which sends a ticket containing a reference to a template as well as additional information to several organizations. Those organizations are then able to open those tickets.

Videos of the tools (+/- 45 MB each so downloading might take a while)

Instead of just some screenshots, you will find some videos of the DOGMA MESS TOOLS used in a real case, an experiment with the Dutch Bakery Centre (NBC). The videos are:

  • Making a template: this video contains the making of a template starting from a type hierarchy, I demonstrate the adding of 1 relationship of the 'deelhandeling'-template. (The other relationships have been put in advance for the sake of winning time). Click here to watch the video.
  • Making and sending a ticket: In the ticket maker, a template can be chosen and sent to several organizations. Tickets contain information such as: who created the ticket, title, priority, additional information, etc. Click here to watch the video.
  • Opening and specializing a template 1: this organization (ROC Amsterdam) introduces two terms they haven’t found in the type hierarchy and place them in their appropriate place in that hierarchy (two introduce-term followed by change-type operations). Then it specializes several relations for the task ‘kruimelen’ (Specialize relation operations). Click here to watch the video.
  • Opening and specializing a template 2: this organization (ROC Friesland College) specialized the relations with concepts found in the type hierarchy. Click here to watch the video.
  • Opening and specializing a template 3: ROC Eindhoven added five concepts (one tool, one product and three raw materials) and some specializations. Click here to watch the video.

The other videos are not relevant to the case, but show other features of the suite that were not used in the case.

  • Video 1 contains:
    1. Trying to drop root-concept T, which doesn’t work. The log shows why.
    2. Dropping another concept.
    3. Introducing concepts and changing the type of these concepts.
    4. Defining a relation between two concepts, then generalizing it and eventually dropping that relation.
    5. Showing some constraint operations

Click here to watch the video.

  • Video 2 shows how you can articulate a term and what the concept viewer shows once that articulation is stored. Click here to watchthe video.

 

ODMF framework

The Ontology-based Data Matching Framework (ODMF) tool set is used to

  1. demonstrate the usage of domain ontologies
  2. illustrate how to apply ontology-based data matching in the field of human resource management, and
  3. test different ontology-based data matching algorithms and strategies.

The ODMF contains the following components: (1) application ontology, (2) domain ontology, (3) matching module, (4) interpreter module, and (5) comparison module. 

1. Application ontology

The application ontology contains the ontological constraints that map information in the application database to the domain ontology. The application database contains the organization’s specific information that will be used for competency management.

2. Domain ontology

The domain ontology contains the concepts, concept properties, and concept relations relevant for the domain of competency management.

3. Matching module

The matching module provides an interface for the matching of two data sets. Different matching implementations (e.g. string, lexical, and graph) will be included in this module. The interface allows choosing between the different implementations.

4. Interpreter module

The interpreter module makes use of the application ontology (1), the domain ontology (2), and the matching module (3) to interpret application data.

 

(Fig. 1. a screenshot of ODMatcher)

 

 The ODMF tool set contains tools as below.

  • ODMF Multilingual WordNet Editor (De Baer et al., 2006), which is used to manage the knowledge base of the ODMF. In particular, we use it for managing the upper common ontology and terminology. It is not restricted to HRM domain. It currently contains over 120,000 concepts.
  • ODMF Competence Ontology Client Application (COCA, De Baer et al., 2008), which is also used to manage the knowledge base of the ODMF. In particular, it allows different organizations to manage the lower common ontology in the HRM domain. It is the implementation of three methodologies. They are DOGMA methodology (Meersman, 2001; Jarrar and Meersman, 2002; Spyns et al., 2008), DOGMA-MESS methodology (de moor et al., 2006) and PAD-ON methodology (Tang et al., 2009').
  • ODMatcher (Ontology-based Data Matching Tool) for Prolix, which is a tool to evaluate different matching strategies and algorithms in the ODMF within the scope of Prolix project. The end users of ODMatcher are knowledge engineers, e.g. ontology engineers.
(Fig. 2. screenshot of MWN)

References:

  1. De Baer, P., Kerremans, K., and Temmerman, R. (2008): Constructing Ontology-underpinned Terminological Resources, A Categorization Framework API, Proceedings of the 8th International Conference on Terminology and Knowledge Engineering, Copenhagen
  2. De Baer, P., Kerremans, K., and Temmerman, R. (2006): Facilitating Ontology (Re)use by Means of a Categorization Framework. In: Meersman, R., Tari, Z. (eds.) On the Move to Meaningful Internet Systems 2006. Proceedings of the AWeSOMe workshop, pp. 126-135.
  3. De Moor, A., De Leenheer, P., and Meersman (2006), DOGMA-MESS: A Meaning Evolution Support System for Interorganizational Ontology Engineering, in proc. Of 14th International Conference on Conceptual Structures (ICCS 2006), Volume 4068, Aalborg, Denmark, p.189-203
  4. Jarrar, M., Meersman, R. (2002): Formal Ontology Engineering in the DOGMA Approach. In: On the Move to Meaningful Internet Systems: CoopIS, DOA, and ODBASE, LNCS, Springer Verlag, pp. 1238-1254.
  5. Meersman, R. (2001): Ontologies and Databases: More than a Fleeting Resemblance, in Proceedings of OES/SEO 2001 Rome Workshop, In, d’Atri, A. & Missikoff, M.,(eds.), Luiss Publications
  6. Spyns, P., Tang, Y. & Meersman, R. (2008), An ontology engineering methodology for DOGMA, Journal of Applied Ontology, Volume 3, Issue 1-2, p.13-39
  7. Tang, Y., De Baer, P., Zhao, G., Meersman, R., and Pudney, K. (2009’): Towards a Pattern-Driven Topical Ontology Modeling Methodology in Elderly Care Homes, international OntoContent’09 workshop, On the Move to Meaningful Internet Systems: OTM 2009 Workshops, Springer, Heidelberg, LNCS 5872, ISBN 978-3-642-05289-7, pp. 514—523, Vilamoura, Portugal, Nov. 1 ~ Nov. 6, 2009

Ontology Based Email Fraud Detector V1.0

Here is the screenshot:

The free online version will come to your browser very soon.

 

R-RIDL - The GOSPL Database Atomizer and Fact-oriented Query Engine

Content is following ... 

SDRule-ML XSD




<!--SDRule-L-->

<xs:element name="SDRule">

                <xs:complexType>

                                <xs:sequence>

                                                <xs:element ref="Object" maxOccurs="unbounded"/>

                                                <xs:element ref="Predicate" maxOccurs="unbounded"/>

                                                <xs:element ref="Constraint" minOccurs="0" maxOccurs="unbounded"/>

                                                <xs:choice maxOccurs="unbounded">

                                                                <xs:element ref="Rule"/>

                                                                <xs:element ref="Set"/>

                                                </xs:choice>

                                </xs:sequence>

                                <xs:attribute name="name" use="required"/>

                </xs:complexType>

</xs:element>

<xs:element name="Constraint">

                <xs:complexType>

                                <xs:choice>

                                                <xs:element ref="Value" maxOccurs="unbounded"/>

                                                <xs:element ref="Object_Role" maxOccurs="unbounded"/>

                                </xs:choice>

                                <xs:attribute name="Object" type="xs:NCName"/>

                                <xs:attribute name="type" type="xs:NCName" use="required"/>

                </xs:complexType>

</xs:element>

<xs:element name="Object">

                <xs:complexType mixed="true">

                                <xs:attribute name="Name" type="xs:NCName" use="optional"/>

                                <xs:attribute name="type" type="xs:NCName" use="optional"/>

                                <xs:attribute name="CI" type="xs:anyURI" use="optional"/>

                </xs:complexType>

</xs:element>

<xs:element name="Predicate">

                <xs:complexType mixed="true">

                                <xs:sequence>

                                                <xs:element ref="Object_Role" minOccurs="0" maxOccurs="unbounded"/>

                                </xs:sequence>

                                <xs:attribute name="id" type="xs:NCName"/>

                </xs:complexType>

</xs:element>

<xs:element name="Value" type="xs:NCName"/>

<xs:element name="Object_Role">

                <xs:complexType mixed="true">

                                <xs:choice minOccurs="0">

                                                <xs:element ref="Object"/>

                                </xs:choice>

                                <xs:attribute name="ID" type="xs:NCName"/>

                                <xs:attribute name="Object" type="xs:NCName"/>

                                <xs:attribute name="Role" type="xs:NCName"/>

                </xs:complexType>

</xs:element>

<xs:element name="Rule">

                <xs:complexType mixed="true">

                                <xs:choice minOccurs="0" maxOccurs="unbounded">

                                                <xs:element ref="Atom" maxOccurs="unbounded"/>

                                                <xs:element ref="head" minOccurs="0"/>

                                                <xs:element ref="body" minOccurs="0"/>

                                </xs:choice>

                                <xs:attribute name="Maximum" type="xs:NCName"/>

                                <xs:attribute name="Minimum" type="xs:integer"/>

                                <xs:attribute name="direction" type="xs:NCName"/>

                                <xs:attribute name="id" type="xs:NCName"/>

                                <xs:attribute name="type" type="xs:string"/>

                </xs:complexType>

</xs:element>

<xs:element name="body">

                <xs:complexType>

                                <xs:choice>

                                                <xs:element ref="Union"/>

                                                <xs:element ref="And"/>

                                                <xs:element ref="Equivalent"/>

                                                <xs:element ref="Neg"/>

                                                <xs:element ref="Or"/>

                                                <xs:element ref="Atom"/>

                                                <xs:element ref="Rule"/>

                                </xs:choice>

                </xs:complexType>

</xs:element>

<xs:element name="Or">

                <xs:complexType>

                                <xs:sequence>

                                                <xs:element ref="Atom" minOccurs="2" maxOccurs="unbounded"/>

                                </xs:sequence>

                </xs:complexType>

</xs:element>

<xs:element name="And">

                <xs:complexType>

                                <xs:sequence>

                                                <xs:element ref="Atom" minOccurs="2" maxOccurs="unbounded"/>

                                </xs:sequence>

                </xs:complexType>

</xs:element>

<xs:element name="Equivalent">

                <xs:complexType>

                                <xs:sequence>

                                                <xs:element ref="Atom" maxOccurs="unbounded"/>

                                </xs:sequence>

                </xs:complexType>

</xs:element>

<xs:element name="Neg">

                <xs:complexType>

                                <xs:sequence maxOccurs="unbounded">

                                                <xs:element ref="Atom"/>

                                </xs:sequence>

                </xs:complexType>

</xs:element>

<xs:element name="head">

                <xs:complexType>

                                <xs:choice>

                                                <xs:element ref="Atom"/>

                                                <xs:element ref="And"/>

                                                <xs:element ref="Or"/>

                                                <xs:element ref="Neg"/>

                                                <xs:element ref="Rule"/>

                                </xs:choice>

                </xs:complexType>

</xs:element>

                <xs:element name="Set">

                <xs:complexType mixed="true">

                                <xs:sequence>

                                                <xs:element ref="Predicate" minOccurs="0" maxOccurs="unbounded"/>

                                </xs:sequence>

                                <xs:attribute name="id" type="xs:NCName"/>

                                <xs:attribute name="name"/>

                </xs:complexType>

</xs:element>

<xs:element name="Atom">

                <xs:complexType mixed="true">

                                <xs:choice minOccurs="0" maxOccurs="unbounded">

                                                <xs:element ref="Object" minOccurs="0"/>

                                                <xs:element ref="Predicate" minOccurs="0"/>

                                                <xs:element ref="Rule"/>

                                                <xs:element ref="Set" minOccurs="0"/>

                                                <xs:element ref="Value" minOccurs="0"/>

                                </xs:choice>

                </xs:complexType>

</xs:element>

<xs:element name="Union">

                <xs:complexType>

                                <xs:choice minOccurs="0" maxOccurs="unbounded">

                                                <xs:element ref="Atom"/>

                                                <xs:element ref="Union"/>

                                </xs:choice>

                </xs:complexType>

</xs:element>

SDT tool

[last update:  2011-04-07]

The SDT tool set is designed and built as an (Eclipse) perspective for the DOGMA studio framework. It is a group decision making system that is embedded with modern ontology engineering technologies. It supports the approaches to semantic decision tables. The SDT perspective is designed, constructed and implemented as a collection of loosely coupled (Eclipse) plug-ins.

The SDT tool set communicates with the DOGMA Server, which is an advanced J2EE application running in a JBoss server and which efficiently stores Lexons and Commitments in a PostgreSQL Database, in order to get full engineering supports concerning community-based ontology creation. ontology versioning, visualization, querying, reasoning and publishing.

The SDT perspective supports reasoning the decision rules in semantic decision tables, constructing semantic decision tables, managing domain ontologies, annotating decision tables, validate decision tables using domain ontologies.

 

 

   

SDT Perspective

The current SDT perspective contains the following plug-ins:

Basic plug-ins

  • decision table constructor (the first version was released before Oct. 2009). It guides a non-technical end user to create decision tables in an easy and step-wise way.
  • decision table annotator (the first version was released before Oct. 2009). It supports the ontological annotation of decision tables. It includes a viewer for formal ontological relations in order to facilitate the annotation.
  • domain ontology manager (the first version was released before 2008). It support the communication between the local SDT perspective and remote DOGMA server.
  • DECOL editor (the first version was released before Oct. 2009, the second in September 2010). Users write SDT commitments (meta-rules of a decision table) in the form of DECOL. In the second version, users can use it for the natural language verbalization and model commitments based on examples.The verbalization in this version is for the constraints of mandatory, uniqueness and frequency. And so do the examples.
  • SDRule-L editor (the first version was released in 2008. It was disabled since early 2009). It supports the graphical visualization of SDRule-L (Semantic Decision Rule Language).
  • decision item bag/context manager (the first version was released in September 2010; the second version was released in April, 2011). It is used to collect and group condition and action candidates in a domain, and supports necessary functions for different types of decision makers in a hierarchical organization.
  • Concept definition visualizer (the first version was released in 2008, replaced by WordNet+Domain dictionary viewer since December, 2010). It provides definitions in natural language for decision conditions, actions and the concepts in the domain ontologies. The textual definitions are retrieved from domain dictionary (glossary and thesaurus) and WordNet.
  • Domain Dictionary + WordNet viewer (the first version was released in December 2010). It is used to show the definitions of atomic concepts in an SDT (or decision table), or in an ontology. The definitions are stored in WordNet and domain dictionaries. It also supports users with the searching function. 

Advanced Plug-ins (SDT applications)

  • GRASIM (the first version was released in 2009). It uses SDTs for ontology-based data matching.
  • Transaction tester (the first version was released in July 2010). It uses SDTs to test transaction rules with parameters in the conditions.
  • Rule auditor (the first version was released in September 2010). It uses SDTs to audit decision rules in a tabular format.

Ongoing work

  • SDT Analyzer
  • SDT dependency visualizer
  • SDT Mapper

Background of Semantic Decision Tables

Researchers have been investigating the study of decision tables for more than fifty years. As an important tool to support Information System Management, decision tables have many outstanding advantages, i.e. they are easily learned, readable and understandable by non-technical people. Seeing the advantages, the interest of decision tables has been rising steadily. However, often the definition of concepts, variables and hidden (or meta-) decision rules that underlie remain implicit. When decision tables get larger, ambiguities, content inconsistencies and conceptual reasoning difficulties arise. The situation gets naturally worse when a group of decision makers need to build decision tables in a collaborative environment. Thus, the concept of Semantic Decision Table (SDT) is proposed.

SDT provides a means to capture and examine decision makers’ concepts, as well as a tool for refining their knowledge and facilitating knowledge sharing in a scalable manner. An SDT is the result of annotating a (set of) decision table(s) (or any well structured decision resources) with (domain) ontologies. It is modeled based on the framework of Developing Ontology-Grounded Methods and Applications (DOGMA). We have designed a methodology to assist a decision group to create SDTs. With regard to the technical issues of SDT, Semantic Decision Rule Language (SDRule-L/SDRule-ML) and Decision Commitment Language (DECOL) are designed and implemented to model, store, reason and publish SDT rules.

In order to justify the theoretical part of SDT, we have applied SDT in several interesting applications. One application is to use it as self-organizing and automatically reorganizing decision tables when users’ requirements are updated. An algorithm called SOAR (adaptive self-organization and automatic reorganization algorithm) has been developed and evaluated. The other applications show the possibilities of using SDT to monitor processes and present semantically rich decision rules to non-technical persons.

Support Readings

  1. Yan Tang, Semantic Decision Tables - A New, Promising and Practical Way of Organizing Your Business Semantics with Existing Decision Making Tools , ISBN 978-3-8383-3791-3, LAP LAMBERT Academic Publishing AG & Co. KG, Saarbrücken, Germany, 2010 
  2. http://en.wikipedia.org/wiki/Semantic_decision_table

SDT XSD




<?xml version="1.0" encoding="UTF-8"?>

<!--version 0.8, Sept.10, 2009, By Yan Tang, VUB STARLab-->

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">

                <xs:element name="SDT">

                                <xs:annotation>

                                                <xs:documentation>the root element </xs:documentation>

                                </xs:annotation>

                                <xs:complexType>

                                                <xs:sequence>

                                                                <xs:element ref="purpose"/>

                                                                <xs:element ref="MetaSDT" minOccurs="0"/>

                                                                <xs:element ref="condition"/>

                                                                <xs:element ref="action"/>

                                                                <xs:element ref="content"/>

                                                                <xs:element ref="annotation"/>

                                                                <xs:element ref="SDTRules"/>

                                                </xs:sequence>

                                                <xs:attribute name="title" type="xs:string" use="optional"/>

                                                <xs:attribute name="date" type="xs:date" use="required"/>

                                                <xs:attribute name="author" type="xs:string" use="optional"/>

                                                <xs:attribute name="conditionNbr" type="xs:unsignedInt" use="required"/>

                                                <xs:attribute name="actionNbr" type="xs:unsignedInt" use="required"/>

                                                <xs:attribute name="columnNbr" type="xs:unsignedInt" use="required"/>

                                </xs:complexType>

                </xs:element>

                <xs:element name="purpose">

                                <xs:annotation>

                                                <xs:documentation>purpose of the semantic decision table</xs:documentation>

                                </xs:annotation>

                </xs:element>

                <xs:element name="MetaSDT">

                                <xs:annotation>

                                                <xs:documentation>the SDTs that contain the meta rules of this SDT</xs:documentation>

                                </xs:annotation>

                                <xs:complexType>

                                                <xs:sequence>

                                                                <xs:element ref="MetaSDTFile" maxOccurs="unbounded"/>

                                                </xs:sequence>

                                </xs:complexType>

                </xs:element>

                <xs:element name="MetaSDTFile">

                                <xs:annotation>

                                                <xs:documentation>file locations of meta SDTs</xs:documentation>

                                </xs:annotation>

                </xs:element>

                <xs:element name="condition">

                                <xs:annotation>

                                                <xs:documentation>conditions of the decision table</xs:documentation>

                                </xs:annotation>

                                <xs:complexType>

                                                <xs:sequence>

                                                                <xs:element ref="label" maxOccurs="unbounded"/>

                                                </xs:sequence>

                                </xs:complexType>

                </xs:element>

                <xs:element name="action">

                                <xs:annotation>

                                                <xs:documentation>actions of the decision table</xs:documentation>

                                </xs:annotation>

                                <xs:complexType>

                                                <xs:sequence>

                                                                <xs:element ref="label" maxOccurs="unbounded"/>

                                                </xs:sequence>

                                </xs:complexType>

                </xs:element>

                <xs:element name="label">

                                <xs:annotation>

                                                <xs:documentation>the label of the decision item - condition or action</xs:documentation>

                                </xs:annotation>

                </xs:element>

                <xs:element name="content">

                                <xs:annotation>

                                                <xs:documentation>the table content</xs:documentation>

                                </xs:annotation>

                                <xs:complexType>

                                                <xs:sequence>

                                                                <xs:element ref="cell" maxOccurs="unbounded">

                                                                                <xs:annotation>

                                                                                                <xs:documentation>a table cell</xs:documentation>

                                                                                </xs:annotation>

                                                                </xs:element>

                                                </xs:sequence>

                                </xs:complexType>

                </xs:element>

                <xs:element name="cell">

                                <xs:annotation>

                                                <xs:documentation>a table row</xs:documentation>

                                </xs:annotation>

                                <xs:complexType>

                                                <xs:attribute name="xposition" type="xs:int" use="required"/>

                                                <xs:attribute name="yposition" type="xs:int" use="required"/>

                                                <xs:attribute name="item" type="xs:string" use="optional"/>

                                </xs:complexType>

                </xs:element>

                <xs:element name="annotation">

                                <xs:annotation>

                                                <xs:documentation>annotation result</xs:documentation>

                                </xs:annotation>

                                <xs:complexType>

                                                <xs:sequence>

                                                                <xs:element ref="annotated" maxOccurs="unbounded"/>

                                                </xs:sequence>

                                </xs:complexType>

                </xs:element>

                <xs:element name="annotated">

                                <xs:annotation>

                                                <xs:documentation>an annotated item</xs:documentation>

                                </xs:annotation>

                                <xs:complexType>

                                                <xs:sequence>

                                                                <xs:element ref="DecisionItem"/>

                                                                <xs:element ref="Target"/>

                                                </xs:sequence>

                                                <xs:attribute name="time" type="xs:dateTime" use="optional"/>

                                                <xs:attribute name="relation" type="xs:string" use="required"/>

                                </xs:complexType>

                </xs:element>

                <xs:element name="DecisionItem">

                                <xs:annotation>

                                <xs:documentation>decision item that is mapped to a concept in an ontology</xs:documentation>

                                </xs:annotation>

                </xs:element>

                <xs:element name="Target">

                                <xs:annotation>

                                                <xs:documentation>the mapped concept in the ontology</xs:documentation>

                                </xs:annotation>

                                <xs:complexType>

                                                <xs:attribute name="context" type="xs:string" use="required"/>

                                                <xs:attribute name="URI" type="xs:anyURI" use="optional" default="http://starlab.vub.ac.be/DOGMA"/>

                                                <xs:attribute name="conceptName" type="xs:string" use="required"/>

                                </xs:complexType>

                </xs:element>

                <xs:element name="SDTRules">

                                <xs:annotation>

                                                <xs:documentation>sdt rules include commitment in ORM ML and ORM+</xs:documentation>

                                </xs:annotation>

                                <xs:complexType>

                                                <xs:choice minOccurs="0">

                                                                <xs:element ref="SDRule" maxOccurs="unbounded"/>

                                                </xs:choice>

                                                <xs:attribute name="FileName" type="xs:string" use="optional"/>

                                </xs:complexType>

                </xs:element>

                <!--SDRule-L-->

                <xs:element name="SDRule">

                                <xs:complexType>

                                                <xs:sequence>

                                                                <xs:element ref="Object" maxOccurs="unbounded"/>

                                                                <xs:element ref="Predicate" maxOccurs="unbounded"/>

                                                                <xs:element ref="Constraint" minOccurs="0" maxOccurs="unbounded"/>

                                                                <xs:choice maxOccurs="unbounded">

                                                                                <xs:element ref="Rule"/>

                                                                                <xs:element ref="Set"/>

                                                                </xs:choice>

                                                </xs:sequence>

                                                <xs:attribute name="name" use="required"/>

                                </xs:complexType>

                </xs:element>

                <xs:element name="Constraint">

                                <xs:complexType>

                                                <xs:choice>

                                                                <xs:element ref="Value" maxOccurs="unbounded"/>

                                                                <xs:element ref="Object_Role" maxOccurs="unbounded"/>

                                                </xs:choice>

                                                <xs:attribute name="Object" type="xs:string"/>

                                                <xs:attribute name="type" type="xs:string" use="required"/>

                                </xs:complexType>

                </xs:element>

                <xs:element name="Object">

                                <xs:complexType mixed="true">

                                                <xs:attribute name="Name" type="xs:string" use="optional"/>

                                                <xs:attribute name="type" type="xs:string" use="optional"/>

                                                <xs:attribute name="CI" type="xs:anyURI" use="optional"/>

                                </xs:complexType>

                </xs:element>

                <xs:element name="Predicate">

                                <xs:complexType mixed="true">

                                                <xs:sequence>

                                                                <xs:element ref="Object_Role" minOccurs="0" maxOccurs="unbounded"/>

                                                </xs:sequence>

                                                <xs:attribute name="id" type="xs:string"/>

                                </xs:complexType>

                </xs:element>

                <xs:element name="Value" type="xs:NCName"/>

                <xs:element name="Object_Role">

                                <xs:complexType mixed="true">

                                                <xs:choice minOccurs="0">

                                                                <xs:element ref="Object"/>

                                                </xs:choice>

                                                <xs:attribute name="ID" type="xs:string"/>

                                                <xs:attribute name="Object" type="xs:string"/>

                                                <xs:attribute name="Role" type="xs:string"/>

                                </xs:complexType>

                </xs:element>

                <xs:element name="Rule">

                                <xs:complexType mixed="true">

                                                <xs:choice minOccurs="0" maxOccurs="unbounded">

                                                                <xs:element ref="Atom" maxOccurs="unbounded"/>

                                                                <xs:element ref="head" minOccurs="0"/>

                                                                <xs:element ref="body" minOccurs="0"/>

                                                </xs:choice>

                                                <xs:attribute name="Maximum" type="xs:integer" use="optional"/>

                                                <xs:attribute name="Minimum" type="xs:integer" use="optional"/>

                                                <xs:attribute name="direction" type="xs:string" use="required"/>

                                                <xs:attribute name="id" type="xs:string" use="required"/>

                                                <xs:attribute name="type" type="xs:string" use="required"/>

                                </xs:complexType>

                </xs:element>

                <xs:element name="body">

                                <xs:complexType>

                                                <xs:choice>

                                                                <xs:element ref="Union"/>

                                                                <xs:element ref="And"/>

                                                                <xs:element ref="Equivalent"/>

                                                                <xs:element ref="Neg"/>

                                                                <xs:element ref="Or"/>

                                                                <xs:element ref="Atom"/>

                                                                <xs:element ref="Rule"/>

                                                </xs:choice>

                                </xs:complexType>

                </xs:element>

                <xs:element name="Or">

                                <xs:complexType>

                                                <xs:sequence>

                                                                <xs:element ref="Atom" minOccurs="2" maxOccurs="unbounded"/>

                                                </xs:sequence>

                                </xs:complexType>

                </xs:element>

                <xs:element name="And">

                                <xs:complexType>

                                                <xs:sequence>

                                                                <xs:element ref="Atom" minOccurs="2" maxOccurs="unbounded"/>

                                                </xs:sequence>

                                </xs:complexType>

                </xs:element>

                <xs:element name="Equivalent">

                                <xs:complexType>

                                                <xs:sequence>

                                                                <xs:element ref="Atom" maxOccurs="unbounded"/>

                                                </xs:sequence>

                                </xs:complexType>

                </xs:element>

                <xs:element name="Neg">

                                <xs:complexType>

                                                <xs:sequence maxOccurs="unbounded">

                                                                <xs:element ref="Atom"/>

                                                </xs:sequence>

                                </xs:complexType>

                </xs:element>

                <xs:element name="head">

                                <xs:complexType>

                                                <xs:choice>

                                                                <xs:element ref="Atom"/>

                                                                <xs:element ref="And"/>

                                                                <xs:element ref="Or"/>

                                                                <xs:element ref="Neg"/>

                                                                <xs:element ref="Rule"/>

                                                </xs:choice>

                                </xs:complexType>

                </xs:element>

                <xs:element name="Set">

                                <xs:complexType mixed="true">

                                                <xs:sequence>

                                                                <xs:element ref="Predicate" minOccurs="0" maxOccurs="unbounded"/>

                                                </xs:sequence>

                                                <xs:attribute name="id" type="xs:string" use="required"/>

                                                <xs:attribute name="name" type="xs:string" use="required"/>

                                </xs:complexType>

                </xs:element>

                <xs:element name="Atom">

                                <xs:complexType mixed="true">

                                                <xs:choice minOccurs="0" maxOccurs="unbounded">

                                                                <xs:element ref="Object" minOccurs="0"/>

                                                                <xs:element ref="Predicate" minOccurs="0"/>

                                                                <xs:element ref="Rule"/>

                                                                <xs:element ref="Set" minOccurs="0"/>

                                                                <xs:element ref="Value" minOccurs="0"/>

                                                </xs:choice>

                                </xs:complexType>

                </xs:element>

                <xs:element name="Union">

                                <xs:complexType>

                                                <xs:choice minOccurs="0" maxOccurs="unbounded">

                                                                <xs:element ref="Atom"/>

                                                                <xs:element ref="Union"/>

                                                </xs:choice>

                                </xs:complexType>

                </xs:element>

</xs:schema>

Why A Data Model Does Not An Ontology Make

On 2007-08-02, Robert Meersman gave a lecture at SUNY in Buffalo, at the Center of Excellence for BioInformatics and Life Sciences, led by directors Barry Smith, Lew Goldberg and Werner Ceusters. He addressed an active audience of philosophers, computer and AI scientists, biologists, and bio-engineers. The talk was scheduled for 1 hour but developed into a lively discussion lasting 2 1/4 hours. The presentation slides are available online.

Abstract

Almost all examples of so-called ontologies in today's research literature on the Semantic Web are in fact just their author's (extended) data model for a particular, a priori known, application that author has in mind. Ontologies as computer-based repositories of a domain's semantics however should not be bound to the context of a single "application". Indeed they must express a form of agreement, in an "application-independent" language, on the concepts, relationships, events, rules, and processes present in that domain. Agreements in turn imply (virtual) communities of users and/or developers collaborating towards such a shared, formal, understanding.

In the DOGMA Framework (Developing Ontology-Grounded Methodology and Applications) of VUB STARLab we study the theoretical foundations of ontologies and of collaborative ontology engineering, and are building an experimental tool suite to illustrate the principles that we claim are involved. This seminar reported on some results and applications as well as difficulties.