During my research I got confronted with a lot of different approaches how Semantic Business Process Management (SBPM) can be done. This means in the first step, that the process models need a semantic annotation. But what does that mean?
If you model something (and here it doesn't matter whether this is a business process via BPMN, a UML class diagram or a flow chart) you make use of a standard that defines what kind of model elements exist: in BPMN you have Activities, Events, Gateways, etc. In UML class diagrams you have classes, attributes, methods and assoziations.
So these define what the metamodel element is about. There is often no clear defined semantics in a machine-readable way how a Gateway in BPMN or a method in UML shall be used. The semantics of these elements is mostly captured in a textual way.
So for every human who has a little bit of knowledge about BPMN or UML it is mostly clear what these diagrams mean. But what does a computer do with that? Can it "understand" what we model? Sure, you could say, I tell him that each Activity in BPMN shall be executed. Okay, that's fair. But what does it need to execute? What does the label in these Activities mean? And are there e.g. any relations between an Activity in BPMN and e.g. an Action in UML activity diagrams? The PC simply can't say.
That's where the semantic annotation comes into play. Annotation is contemporary English and has two meanings:
(1) a note added by way of comment or explanation
(2) the act of annotating.
As outlined in this session the annotation can be about a whole document (document-level annotation) or refer to just a specifi part of a text (character-level annotations). Additionally, it can be about the constructs defined in a metamodel (metamodel-level annotations) and on elements in the model itself (model-level annotations).
So, with semantic annotation we aim to capture the semantics of the metamodel elements when different representations are used as well as the terms that describe the model elements.
Now you may ask: what for?
Business process models and workflow models have despite their growing usage still some obstacles to cope with:
- they are used for documentation purposes only
- they are often not up-to-date
- they are not executable
- not all processes /workflows in a company are modeled
- there are different (somehow incompatible) representations used in different companies or departments
- several constructs for one real-world entity exist
- and (the other way round) one construct can be used for different purposes
Now I'd like to come to the initial question: how to semantically annotate a process model?
There are several research projects in the world and many of those need a semantic annotation of the process model (for the rest of this blog post I'll only speak about process models and workflows, however, semantic annotation is definitely something used also for other modeling areas such as software or systems engineering).
Yun Lin describes in her dissertation "Semantic Annotation for Process Models" an approach where an additional tool is used that can read an existing process model and one or more ontologies and can then annotate the model elements with concepts of the ontology and store that in an additional file. This approach (also called "Use metadata to bridge models and ontologies" makes it easy to leave the proprietary process model independent so it can be changed in the modeling tool, but once changes are performed the semantic annotation might not be actual any more.
Michael Fellmann and Oliver Thomas describe in their paper "Semantic Business Process Management: Ontology based Process Modeling Using Event-Driven Process Chains" and in a newer version in German I just got to read how semantic process modeling (a synonym for the semantic annotation of process models) can be done. In their approach they also use metadata to describe what each process action in a business process model means. This metadata connects the process model to an ontology that builds on the Suggested Upper Merged Ontology (SUMO) and where not only domain knowledge but also knowledge about the process language is stored (e.g. they have Activities as well as Offer). But in my opinion this approach makes it quite difficult to use existing ontologies: a domain ontology probably won't have concepts such as Process, but will only talk about the domain at hand.
Additionally, it remains somehow unclear how the semantic annotation is done in practice. They say that they use Protégé for ontology creation and in another paper they speak about semantic wikis for storing the relationsships in a process model. But neither of those two makes a semantic annotation possible. That there is a relationship can be seen on the website of one of the authors, where Semantic Business is linked with a semantic wiki.
The problem with both approaches (by Y. Lin and M. Fellmann) seems to me that they always need another tool. How can business managers be persuaded to first model their processes (which they don't seem to like that much) and afterwards also annotate these models in another tool? I guess this could be quite hard.
Therefore, our approach builds on the extension of a single tool. This can bring the problem that one is bound to a single modeling language for which this extension in the tool is created and that is of course not something we should aim for. Therefore, we'll leverage an existing well-known plattform that by now supports several modeling languages and a lot of more things and which usage is still growing more and more: the Eclipse plattform.
Therefore, we'll use the extension points that are one critical element in Eclipse and extend any existing EMF model with a semantic annotation. By this, we are not only bound to a specific modeling language (such as BPMN), but can support the semantic annotation for several existing modeling languages that already exist in Eclipse or will be integrated in Eclipse at a later time.
Our prototypical implementation will be based on the Eclipse project Java Workflow Tooling (JWT) that is a plattform for modeling, execution, simulating, deploying and monitoring any business process or workflow. More details on the project JWT as well as on our mechanism how this semantic annotation is made independent on the underlying metamodel will be described in the next blog post.