Linked Resource Model for modelling evolving systems (3rd PERICLES Technical Workshop in Grenoble, France)
Xerox Research Centre Europe (XRCE) organized a third technical workshop on using/extending the Linked Resource Model (LRM). The workshop was hosted by the XRCE in Grenoble, and took place on the 27-29 April 2015 (see blogs for the first two meetings). 
The LRM is an upper level ontology that is being developed within PERICLES, to enable the description of evolving digital ecosystems. Versions of the LRM that could be used to describe a static view of an ecosystem have already been presented in the first two workshops.
The third workshop focused on extensions/modifications of the previous versions but also on the presentation of the part of the model that can be used to model dynamic aspects (e.g. events, activities) and also introduced operational aspects related to the model (e.g. a language that can be used to take advantage of the information modelled using the LRM).
Following topics were on our agenda:
– Overview of the latest version of the LRM for modelling “static” aspects;
– Introduction to the concepts used to model “dynamic” aspects with the LRM;
– Domain-specific extensions of the LRM (Ecosystem, Art and Media, Science);
– Introduction to the language that will be used for executing operational aspects related to the LRM;
– The LRM service and its role in the PERICLES architecture.
Day 1 (27 April 2015)
LRM aspects related to a static view
We started the session with a presentation of three new concepts related to the modelling of resources.
1. Exogeneous vs endogeneous resources:
Exogenous resource: Exogenous resources are the things that “you model in the real world”. Endogenous resources: These resources describe the meta layer, the things that “you model in the representation system” and the concepts of modelling.
Distinction between exogenous ecosystem and endogenous representation system
2. Concrete vs abstract resources:
The distinction between concrete and abstract resources; abstract can capture the idea, whereas concrete is the realisation of it.
Aggregated resources are used to model facts that are composed of several sub-resources (abstract or concrete, endogenous or exogenous).
LRM aspects related to a dynamic view
We also presented new concepts used to model “dynamic” aspects with the LRM.
Resources of the time ontology are:
– Instant: a point in the time space with no time extension.
– Interval: It has a beginning, a distinct ending, and therefore, a duration.
– Temporal Entity: everything that has a kind of time information attached, so that it exists at a certain point in time.
Event and Activities
– Event is a time point with a particular semantic, and Activity is a time interval, therefore, has a starting, an ending, and a duration.
In the ensuing discussion we found that it might be beneficial to introduce the language that will be used for executing constraints/rules on the LRM rather than continuing with the initial plan. Jean-Yves therefore used an example to explain this language which is called ‘Pericles Action Language’ (PAL) for now.
Example : LRM-change-document.ttl: The example is about an XML document that can be checked according to its schema. The corresponding model is a specialisation of the LRM model for validating XML documents and a concrete realisation (doc1 with scheme1).
Question about fingerprint property: because schema is a subclass of digital resource it supports UID and fingerprint attributes. Different scenarios are possible for using the fingerprint, depending on the policy: either a schema must never change or a schema may change over time.
doc1 is related to schema1 and the validation result generates a dependency to validationReport01
In the example, there is a call out to an external validation service:
Call to external validation service (XmlValidation)
A mechanism that will govern the generation of the corresponding events (messages) has also been presented – called lrm:EventHandler. Three properties were presented:
– on -> which property to handle
– if -> when to handle
– do -> the action
lrm:EventHandler is defined as an lrm:Plan - to describe abstractly some action. In version 1 it was based on PROV. This has been changed now. The detailed specification of the lrm:EventHandler is below (extract from LRM-dynamic-schema.ttl):
lrm:EventHandler rdfs:subClassOf lrm:Plan;
The above definition intent is that every time an event is raised (on attribute), a PAL precondition (if attribute) will be evaluated, and if required, one or several PAL actions (do attribute) will be executed.
PAL is a mid-level (rule-like) language. The workflow can be described as: Define the action(s) to do in case of a particular event, test the condition(s) and execute the action(s). Every time an event happens, its handler will be processed by a yet to be developed service.
PAL is not yet finished. It will be part of the work for next year. Its name is likely to change as well...
Domain-specific extensions of LRM
In the afternoon of that day, we went on to present and discuss the domain-specific extensions we are working on. The most important extensions included:
Ecosystem: A discussion about how the ecosystem can be modelled using the LRM was carried out.
Semantic Web video decoding example: Simon Waddington (KCL) presented an example he has implemented where a dependency from video player to a video file is modelled in terms of Semantic Web Rule Language (SWRL). Such a rule is defined over several properties such as the frame rate, codec with the question: can the player play the video file?
This example does not currently use many LRM constructs and therefore helped highlight the difference with the PAL-based approach: the rules are included in the Dependency Object while in the SRWL approach the rules are separated from the ontology. To express this example with LRM: There would be a dependency from a video player to a video file and PAL-based behavior would be added to this dependency.
Art & Media (software-based art) example: Stratos Kontopoulos (CERTH) presented a LRM-based model for the consistent playback of video art. Used LRM and CIDOC-CRM ontologies to represent provenance related aspects. In that presentation SPARQL and (SPIN) have been used. This helped highlight that a number of different technologies can be used to represent rules relevant to dependencies (e.g. SPARQL, SWRL, PAL). They can even be used together, SPARQL is about querying on ontology, SWRL can work with the inference mechanism, the same with PAL, but has another aim. SWRL is only a recommendation and few tools support it. The question is: should we align the domain specific models towards the same formalism or allow a variety of formalisms (each one with each own advantages and disadvantages)?
Day 2 (28 April 2015)
At the beginning of the second day we recapped the conclusions and work of the first day. Most importantly:
- We planned a preliminary documentation of LRM (towards end of June) and PAL (deliverable due at the end of the project but an agile methodology will be followed i.e. XRCE will deliver PAL and documentation earlier).
- Re-iterated that topic maps are oriented more towards a human user, while the LRM ontology based on description logics is machine-processable oriented.
- A need for clarifying further what goes into the LRM service and how PET can generate (if required) corresponding information based on the models has been found.
- A possible way to strengthen collaboration would be to establish a working workshop that would take place every 3 months.
Dependency drifts and possible link to the LRM
Sándor Darányi (University of Boras) and Stratos Kontopoulos presented a possibility for integrating the LRM with the statistical approaches recently presented at the Pericles workshop ‘From Semantics of Change to Change of Semantics’. This included visualizing dependency drift, trying to see how dependencies evolve over time. One of the ideas was to express data as a heat map via two mode clustering (heatmap2D). This method is related to graph processing. A heat map does not need a massive amount of data. The idea is to map dependencies to vector space for two mode clustering:
- to see the chronological aspect (using timestamps)
- to see the conceptual aspect (the more interesting one?)
The dependencies are taken as binary input, divided into hard- and software together with criteria. The dependencies change over time. Clusters of similar technologies can be built (an example for software-based art was presented) and also identify trends, e.g. a shift from local installations to internet connected installations.
Events in the LRM
Jean-Yves Vion-Dury and Nikos Lagos from XRCE presented what activities and events stand for in the LRM and how they can be used to represent something that is happening in the ecosystem.
Nikos sketching the relation between events and activities on the whiteboard
Event: is subclass of Instant -> occurs at a time point. There are four events to describe our activities: Started, stopped, suspended, resumed.
A ChangeEvent can be used to express the creation, destruction or transformation of resources.
A TransformationEvent is related to the ID of a resource:
– same ID -> call it an update
– different ID -> this is a derivation
Other important aspects related to events include:
– An event starts an activity.
– An activity receives events and can emit events.
– Activities have the state: started, stopped, resumed, paused.
Activities and events can be used for recording provenance information and inferring the impact of a change. Johannes Biermann (University of Goettingen) remarked that this type of provenance sounds like audit trail (http://en.wikipedia.org/wiki/Audit_trail) from some IT systems for example from BPMN.
The image below shows the LRM event system. Each activity has a beginning and an end (start/stop) and can emit events (first half of the drawing). These events can start other activities. The second half of this drawing shows the provenance mechanism. It allows capturing which operation the activity has performed on the model, e.g. created resource X, deleted Y, used Z.
– An Activity can be triggered by an Event
– An Activity can receive and emit Events
– An Activity can create Resources
– An Activity can use Resources
– An Activity is executedBy an Agent
Rani Pinchuk (SpaceApps) remarked that if a person is acting as Agent, the Activity can depend on the person, because the person knows WHY to act.
Relation between Activities, Events, Resources, Agents
Functionality of the LRM service
After presenting the model of Activities and Events, the discussion turned to what the service that will be based on the LRM is going to offer. The picture below shows how the LRM service is envisioned to interact with the rest of PERICLES components.
The LRM Service should be able to respond to queries such as “Give me the neighbourhood of specific resources at a specific time point.”
This can be used for simulations: “How would the model look like, if such an action would be executed?”
A specific functionality of great importance is the approach invented in PERICLES by XRCE towards semantic versioning. Semantic versioning guarantees backwards compatibility; a paper on this topic is to be presented in ICSOFT-PT. The workflow with the LRM service that will offer semantic versioning is as follows:
- an update of a resource results in a “not checked” version,
- ask the service for a new version and for verification,
- get the new version, now the “checked” flag is set.
The version labels generated using this approach are strongly related to the resource they describe. The version can be characterized as micro, minor, or major according to the backward compatibility constraints and their corresponding computation. A resource can be at a verified and unverified state (qualified and non qualified). Verification mechanism can even be close to unit tests in software engineering.
Jean-Yves presented a versioning example based on the semantic versioning model with the software-based artwork by Bill Viola “Triptych”. The artwork class is abstract because there have been several realisations or modifications during the time of the artwork, but there is a driving idea as abstract concept behind it. In this example the update event specifies which specification is now followed (high resolution). A dependency is defined between different versions (e.g. V2 to V1). The different objects are not kept, but the deltas between the versions are.
Possible bottlenecks: defining the dependency rules (e.g. in PAL), getting dependency related information from other services.
For dependency rule definitions: templates and corresponding template composition sound like a promising solution.
Example containing more than one dependency
XRCE started working on examples that include more than one dependency more work is required on defining a composability operator for modular dependencies. Going to work on an example where a VideoPlayer is dependent on the OperatingSystem and the VideoFile to be played dependent on the player.
It turned out that it needs to be decided by XEROX how a dependency chain can be handled. There are two ways: the dependency chain is expressed with PAL. For this example it would mean that the rule needs to check the dependency between video file and video player and then the dependency between video player and operating system. If the video player does not run on the requested operating system it needs to recheck the whole chain to find another solution until it finds a video player that runs on the operating system (or emit an error if there is no solution). The downside of this solution would be that each dependency (rule?) needs to be aware of all the direct related neighbours.
The second option would be to just express the direct dependency from one object to the next. The LRM service needs then to go through all dependencies to find a solution to the query return a video player that can play X on operating system Y.
Day 3 (29 April 2015)
There are a lot of different ways of using the LRM, because it is an upper level ontology. One way to use it is via Entity Templates, an approach discussed at the beginning of the third day. For the Ecosystem (Video streaming example) WP5 partners have implemented something like this. The Jena definitions of the abstract resources can be seen as “Templates” especially together with the methods which define how to instantiate them. The concrete resources are the instantiations of these templates.
The rest of the morning was dedicated to wrapping up the workshop and defining next steps. Overall this workshop was very successful bringing together a number of different partners and achieving an important step towards using the LRM for modelling both dynamic and static aspects of evolving ecosystems.