Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
ttrapp
Active Contributor
0 Kudos

In the third part of my weblog series I showed how to explore dependencies of development object of AS ABAP using ontologies. Using Semantic Web technologies we can visualize structures and can answer questions using techniques from artificial intelligence.

As a result of an ongoing discussion between Markus and me I decided to published a small ABAP application that gives out usages between XSLT programs and Simple Transformations. Exploring the structure of development objects within AS ABAP lead to the question whether I have complete or uncomplete knowledge about the problem domain. In fact I came to the conclusion that this is a severe problem that affects reasoning.

Dependencies between Objects within AS ABAP

Lets get into detail. I suggest you to download the nugget, create an ontology of all transformations of your ABAP system and use an OWL tool like Protegé. In the following picture you see a small ontology which I use here as example:

Ontologies are concept models and contain concepts as well as instances that represent objects of the "real" world like ABAP packages or transformations. The concept of an XSLT  or ST program corresponds the class of transformations that consists of to disjoint subclasses ST programs and Simple Transformations. In OWL it looks like the following:

<owl:Class rdf:ID="Transformation"/>
  <owl:Class rdf:ID="ST">
    <owl:disjointWith>
      <owl:Class rdf:ID="XSLT"/>
    </owl:disjointWith>
    <rdfs:subClassOf rdf:resource="#Transformation"/>
</owl:Class>

You can use a reasoner like Pellet to ask questions about the ontology: Typical questions are the consistency of a concept model or calculating members of a certain class which is defined using logical terms. The above mentioned ontology contains the dependencies between concrete transformations. An example are the following about XSL transformations foo, bar and baz:

<XSLT rdf:ID="foo">
  <includes>
    <XSLT rdf:about="#bar"/>
  </includes>
</XSLT>
<XSLT rdf:ID="bar">
  <imports>
     <XSLT rdf:about="#baz"/>
  </imports>
</XSLT>

Here the transformation foo includes bar which imports baz. Then you define a property uses as generalization:

<owl:ObjectProperty rdf:ID="imports">
  <rdfs:subPropertyOf>
    <owl:TransitiveProperty rdf:about="#uses"/>
  </rdfs:subPropertyOf>
  <rdfs:range rdf:resource="#XSLT"/>
  <rdfs:domain rdf:resource="#XSLT"/>
</owl:ObjectProperty>

Reasoning in an Open World

A reasoner like Pellet can calculate all transformations which are used indirectly by foo. You can see the result on the following picture:

OWL was designed so that reasoners can answer questions about concept models. But this leads to the question how a reasoner works. In the example above the reasoner is able to conclude the following:

  • foo includes bar and bar imports baz.
  • foo uses bar and bar uses baz
  • foo uses bar
  • foo uses baz

But what happens of we ask the reasoner whether bar uses foo? The reasoner won’t give us an answer. Due to our facts there is no usage but the reasoner assumes that out knowledge about the world is not complete. And in fact this is exactly how we do reasoning in real life: If we do not know a fact then we can’t judge it.

It Ain’t Necessarily So

This is a very interesting aspect. In fact the AS ABAP has aspects of an open world: An XSLT program call a method of an arbitrary object and this object can call other methods as well as transformations dynamically. So an ontology about dependencies is necessarily incomplete.

On the other hand the example above shows that some parts the AS ABAP are not an open world – we have a complete knowledge of all facts. In release 7.01 Simple Transformations can’t call ABAP methods so we have a complete knowledge of all usages. In logical terms this is called closed world assumption.

The closed world assumption is natural in database context which is interpreted that a fact is true if and only if it is stored in a transparent table.

Reasoning in OWL ontologies lead to so called monotone logics that rely an open world and the closed world assumption leads to logical inconsistencies.

Epistemic Logic

But what do we do if our concept model contains facts from an open world as well as closed world? Here we need help from mathematical logics. There is a branch of logics called epistemic logic that deals with reasoning about knowledge.

One possibility is to restrict on fragments of OWL like OWL 1.1: http://korrekt.org/page/Conjunctive_Queries_for_a_Tractable_Fragment_of_OWL1.1  ).

Another possibility is to extend the logics with so called epistemic operators: http://www.mindswap.org/2005/OWLWorkshop/sub12.pdf . With those operators we can handle the fact that a logic contains complete knowledge as well knowledge in an open world context.

Unfortunately it seems hard to integrate such logics in OWL: http://www.mindswap.org/2005/OWLWorkshop/sub7.pdf . But nevertheless open source reasoners like Pellet support epistemic extensions.

Reasoning about Software Architecture

And in fact this is what I’m working on at the moment:

  • How can we model aspects of ABAP software architecture like packages, dependencies, software components and so?
  • What kind of questions concerning architecture can be answered in an open world and what kind of questions in an closed world?
  • Can epistemic logic help us?
3 Comments