Pericles project
Promoting and Enhancing Reuse of Information throughout the Content Lifecycle taking account of Evolving Semantics

Blog

A technical workshop in Grenoble



A technical workshop in Grenoble

A technical workshop in Grenoble

 Jean-Yves Vion-Dury, Nikolaos Lagos, Jean-Pierre Chanod

Xerox Research Centre Europe

January 7, 2014

 

In early December 2013, we organized a small technical workshop at the Xerox European Research premises, in Grenoble, France to present our latest thoughts on the LRM (Linked Resource Model), which represents the Xerox core contribution to Pericles. The hope was that partners would question and challenge our thoughts, in the light of their own expertise and of their general expectations of the LRM, which is still under construction.

At the workshop were colleagues from King’s College, the Universities of Gottingen, Liverpool and Borås and from Thessaloniki-based CERTH. Other Pericles partners could have usefully contributed to this workshop, but the intent of this first of a kind meeting was to keep it small. We will certainly hold similar workshops in the future to consider additional concerns and the expertise brought by our consortium at large.

 

 

The Xerox Research Centre Europe

In short, the LRM is to establish unifying models to describe heterogeneous resources and their dependencies in the context of digital preservation. During the  current first phase of the project, we have targeted the definition of a static view of the LRM, that puts in place the key concepts and tools to preserve the descriptions of various digital ecosystems, especially those relevant to our two exciting use cases i.e. space and media, brought by SpaceApps, BUSOC and Tate.

Later in the project we will focus on capturing the evolution of such ecosystems over time, enriching the model with languages and tools that describe temporal aspects and change. This is based on the idea that digital ecosystems are dynamic and not fixed in time. The model must therefore not only be able describe the core digital entities (Resources) of the ecosystem but also provide the concepts and mechanisms to describe its evolution in a controlled manner and in a way that maintains its essential properties.

At the current stage of the project, we need to finalize the static model. By anticipating the consequences of dynamicity, the static model must consider the following points:

-       Dependencies between resources should be made explicit because they are the natural expression of the most basic consistency criterion of the global system.

-       Some objects in the model must have the ability to operate on the system (we call these objects Operators), as change must result from some activity or operation.

 

Based on such considerations, our initial vision of the LRM was shared in June 2013. This version was organized around the 3 notions of resource, dependency and operator.

 

 

 

In the following iteration, considering the PROV ontology (http://www.w3.org/TR/prov-o/) as a reference to capture provenance information, we decided to reuse/integrate the main PROV concepts of Entity, Activity and Agent:

To this end, we defined the LRM Resource class as a subclass of PROV:Entity, with the particular distinction that this LRM Resource class should actually denote the so-called Digital Resource, which we defined as follows:

A digital resource is a data structure whose (principal) components are digital material, or data, plus a unique identifier for this material reference.

In this vein, dependencies are defined as instances relating resources. More precisely, an entity A dependent of entity B is modelled using a particular instance D related to B by a From link, and to A by a To link.  More generally, one may relate a dependency instance to several source entities and to several target entities.

At the onset of the December workshop, we viewed Dependency as a subclass of the Digital Resource class, implicitly suggesting it should have a digital content extension, which in our mind was useful to address the reflexivity principle we pushed as a key property[1] of the LRM.

 

 

 

 

 

This hypothesis raised a number of issues and questions from our partners, and led to intense and productive discussions. In particular, the possibility of having dependencies between dependencies seemed unclear to them, with respect to the semantics of change.

The workshop was particularly fruitful in understanding the various implicit requirements and understandings of what a dependency is, and how it relates to change, i.e. to the dynamic view of digital ecosystems.  

To overcome the identified issues, we propose, as a first step, to redefine the model while preserving the essential principles. This means reconsidering dependencies, as suggested by our partners, (i) as first class objects which are not a priori digital resources, (ii) through the notion of change (in association with some operation).

 

First we redefine subclasses as shown in the following graph:

 

 

According to PROV predicates and classes, this allows us to redefine the dependencies, as well as the provenance information between entities as follows:

 

 

 

 

 

We need, however, to do more than this. Whereas PROV “tells what happened in the past”, the notion of dependency we all have in mind, especially in the context of digital preservation, is about the future i.e. the idea that some potential change inside a dependency graph may impact the ecosystem as soon as a transformative action is undertaken, and provided that this action involves modified entities. In other words, any dependency should be conceived with respect to a predefined action scheme that establishes the semantics of the change, at some level of detail. Therefore, where the “wasGeneratedBy” relation defined in PROV expresses the trace of a dependency, the full significance of the latter can only be grasped in a more abstract way, as directly related to a potential action scheme involving the modified resources.

These considerations will be central to the next iteration towards defining the LRM which we are working hard on!

 

 

 



[1] By reflexivity, we mean modelling the LRM infrastructure as a particular instance of the LRM model

Add a comment