Another successful work meeting on ontologies
The Centre for Research & Technology, Hellas (CERTH) hosted our fourth technical workshop on the Linked Resource Model (LRM), the LRM service, domain ontologies, ecosystem model and policies. The workshop took place in Thessaloniki, Greece, on 28-30 July 2015 (see the other blog entries of the past meetings   ). The LRM provides the concepts and languages for the other models, such as primarily the domain ontology models and the digital ecosystem model.
PERICLES is developing different ontologies, the progress on which formed the focus of the workshop, amongst them the current state of the LRM which is an abstract notation of resources and dependencies developed within this project; the art, media and science ontologies, concepts of those ontologies and their relation to LRM concepts; the current state of the ecosystem ontologies; the role of policies on the ontologies; the test bed and policy editor.
We first discussed the progress on the domain ontologies work and how they applied and refined the LRM ontology through the scenarios, neglecting to some extent the scenario content itself.
Art & Media domain ontologies
We first assessed the progress on the domain ontologies developed from concrete use cases scenarios from our two case studies (media art and space science) and are represented as a Web Ontology Language (OWL) ontology. The goal is to design these ontologies in a specific and generic enough manner as to make them useable for the concrete scenario and for similar scenarios.
For example, we looked at how both the abstract and concrete concept of “resource” has been adapted; there are agents, activities, specialisation of dependencies together with information about the intention of the dependency (conceptual, functional, compatibility). Figure 1 shows that a video artwork consists of four individual videos which are represented with an aggregated resource in the ontology.
Figure 1: Concrete and abstract resources example
Science domain ontology
In contrast to the art & media ontologies, the science ontologies use Topic Maps as ontology notation. The conceptual structure of a topic map ontology is closely related to the scenario because Topic Maps organise the knowledge with index and thesaurus, so the resulting ontology structure will be specific to the scenario. They look similar to mind maps and transfer the traditional human knowledge capturing methods into a computable form. For this workshop the focus was on how some of the Topic Map representations and this particular way of modelling could relate to LRM concepts.
The ecosystem ontology is a generic ontology for modelling a system together with humans (referenced as communities) that have a certain role, actions, digital objects, policies, processes and technical systems. It can be used to answer change related questions. It applies and adapts different LRM concepts to build the ontology.
Figure 2 shows a simplified graphical view of the ontology. New things are for example: agents in form of human, hardware and software, simplified dependency types, introduction of significance of the resources, refinement of the process and policy elements to incorporate results of other PERICLES tasks and introduction of dynamic activities.
Figure 2: Graphical view of the ecosystem ontologies (some attributes omitted for better readability)
Linked Resource Model (LRM)
There have been several iterations of the LRM, the new features added are:
- mutable and immutable resources, events can change resources to mutable and immutable
- resources can be frozen, this relates to the mutable/immutable concept
- delta can provide delta of a change from a resource
- conjunctive and disjunctive dependency types. Conjunctive means that a dependency gets activated if all resources have been changed, disjunctive means the opposite
- destroying of resources
- events that can start, stop and resume activities (endogenous and exogenous events)
- each activity has a duration. ActivityLifeEvent covers the lifecycle phases started, stopped, resumed, paused and predefined
- precise expression of time.
Linked Resource Model (LRM) service
In addition the LRM notation, a LRM service will be developed. The LRM does not only provide concepts for a static model, but also dynamic parts that can for example be used to express time, activities, actions, versions and rules. These parts of the model undergo a permanent change, so a piece of software is useful to maintain the dynamic components and provide an abstraction for other software components. Some of the planned features are:
- ontologies can be uploaded to the LRM service, so that the service can work on the uploaded ontology (e.g. add things, reasoning, …)
- functionality for insertion of triples or resources to an ontology
- semantic versioning of the resources
- navigation through the graph, including historic versions
- simulation and risk analyses based on the precondition and impact criteria.
PET2LRM is a standalone tool that converts the JSON output of the PET (PERICLES extraction tool) to a LRM-based output. It represents the environmental information that has been extracted by PET. Currently not all output is mapped, a concrete scenario would be useful if the tool should be developed further.
DigitalVideo ODP (Ontology Design Pattern)
This is an ontology model about the representation of digital videos which has been submitted to a portal called ontologydesignpatterns.org. This portal provides a collection of different OWL mini-ontologies that can be used as patterns. It was suggested to check if other domain ontology patterns can be submitted, for example a LRM dependency based one.
LRM and Topic Maps
The LRM and Topic Maps session was a continuation of the first session from day 1. It was about how some of the LRM concepts could be represented on a Topic Map ontology. For example a LRM aggregation - a combination of several resources - can be represented with “contained” in Topic Maps. Attributes like subjectLocator can be transformed to lrm:location, subjectIdentifier can be mapped to lrm:identification.
Topic Map explorer
This was a quick demonstration requested by the workshop participants to show the differences between querying OWL ontologies and Topic Maps. The Topic Maps Explorer is from an earlier project and allows querying information with natural language. The result is an extract of the ontology that answers the query in a graphical way (it looks similar to a mind map).
Roles of policies, LRM and the test beds, MICE (Model Impact Change Explorer) and policy editor
This was a longer session about how policies are handled in the ontologies, the tools that drive the policies and how they can be tested.
It is planned to have a component called MICE (Model Impact Change Explorer) which is responsible to visualize a change and provide certain user interaction points for handling a change on the test bed. It is necessary for MICE to interact with the different PERICLES components and models, for example with the LRM service. One interaction is synchronisation functionality between the test bed entity store and the LRM service.
The delta functionality of LRM sounds useful for visualising the change in MICE. Right now the delta supplied by the LRM is isolated to a single resource. For MICE it would be useful to get the delta for a set of resources as a sub graph. The simulation and consistency checking functionality of the LRM service might also be useful for MICE.
There are two ways how change can be introduced into the test bed scenarios: a policy or a model change. There was a longer discussion about the role of policies. With the LRM, policies can be expressed as resources that have preconditions and impacts. Evaluating these criteria can give the impact of a policy change. LRM provides a specific language for expressing the conditions. It is called ReAL (Resource Action Language) and is currently under development. It enables to have rules on the ontology.
In the ecosystem model, policies are abstract and the realisation of them is represented with dependencies. The policies are part of the model and contain the global behaviour of the components as free text. They need to be manually mapped into an executable form in a form of processes. Since the model is aware of the dependencies between all entities, it can return the affected entities if a policy gets changed. There are ideas on supplying validation processes for the policy implementation to check the validity of the ecosystem model.
The quality assurance policies are similar to normal policies, but they do not contain a behaviour as policy statement. Instead they specify a validation criteria and can operate and report on entities. The QA policies can be executed on different conditions: a model update - an entity is added, removed, changed and as regular check to validate the condition of the entities. A failed validation should be reported to MICE.
There is also the task for creating a policy editor. The current idea is to have linked pieces: an editable textual expression and something that can execute the policy. If for example a parameter “3 days” is changed into “7 days”, then the editor can transform the edit into the executable piece. This has of course some limits. It needs to be investigated how the policy editor can be used on the test bed scenarios. The executable part could be for example a rule that is expressed with LRM ReAL.
Ecosystem Java API
The Java API for the ecosystem ontology was presented to the group. It is expresses as Java code and uses Apache Jena Framework. Instead of manually writing the OWL ontology structure, the Java API ensures that the ontology is constructed in a uniform way and different output formats can be easily generated. The second benefit is that it provides an API for creating concrete instances of the ecosystem model. The ecosystem model itself is abstract and the API enables the creation of models for a concrete scenario.
The API ensures that the instances of the entities will be created in a standard way; it can provide templates and some details can be automatically added. This ensures a valid ontology (instance) construction. It also allows to directly perform SPARQL queries and connect the model with different reasoner components. This has the benefit that a scenario can be used by a piece of software and tested on the test bed.
We followed up on the session “Roles of policies, LRM and the test bed, MICE and policy editor” with the question about how to test them. Policies contain an abstract, a textual description about a desired behaviour. They need something executable in a form of one or more processes. They can be part of a workflow or trigger a workflow. A QA policy is also a kind of workflow that produces a validation report as output. This approach allows testing them on the test bed since it is workflow driven. We identified the following items to continue the work:
- There is a policy change scenario example which should be updated to show the links and communication to the different PERICLES tools, including the policy editor
- The policy editor needs to be aware of dependencies
- There needs to be a defined set of trigger points for policies.
PERICLES partners (from left Panos Mitzias, Marina Riga, Simon Waddington, Johannes Biermann, Stratos Kontopoulos, Nikos Lagos, Tania Petsouka, George Antoniadis, Rani Pinchuk, Fabio Corubolo)