This section is extracted from the deliverable D4.1 Initial version of environment information extraction tools [Corubolo, F. et al (2014)]
Please refer to the further reading list for the names referenced to in [ ]
The point of view taken in this research is that of observing a digital object (DO) and its environment, aiming to support their use and reuse, and supporting DO appraisal, making very few assumptions on the whole ecosystem (the institutional or system aspects of the environment). This allows us to focus on the properties that are independent of the system aspects and do not rely on the existence of the system or institution.
Dependency definition
We define dependency as a directed relationship from entity A (source) to entity B (target), that expresses necessity/prerequisite/precondition of B in order to make use of A. In a different form, we view a dependency as: in order to use the source entity A, you need the target entity B.
In this definition, a dependency is always qualified by a use: one can assume there can be more than one use of an entity. This assumes that the users will naturally have an objective, a purpose of use when accessing a resource. Although we cannot know in advance the future uses for an entity, we consider that dependencies covering different user communities will likely cover a broad set of uses, and monitoring the change in use by user communities will be the best option to address future uses. Even if some dependent entities can be replaced by other entities in an environment, as for example by using another word processor to edit a text fragment, our focus is on the currently established dependencies in the environment. For more information on “entities” and “ecosystem”, please check out the module on “Digital Ecosystem” or [Ludwig 2014].
Dependencies at the type and instance level
We defined dependencies to connect different entities, but there are distinctions to be made based on the type of entities:
Dependencies from or to:
● Instance level:
○ Software or services: these will link an entity to a service, a process or a software component that is necessary (or useful) in order to make use of some data. For example, in the case of an application that makes use of a web service. This can be considered as a form of dynamic data.
○ Static data (single digital objects and their dependency): to make sense of file ‘anomaly.doc’ you need to also have access to ‘errorcodes.txt’ and ‘whereisthat.cvs’.
● Type level:
○ Software or services: to use data in format X you also usually need application Y or service Z.
○ Static data: to interpret this type of data you usually need this other type of data.
The distinction between type and instance level dependencies will be particularly relevant for later work on dependencies, and it has to be made explicit, as “Significant Environment Information” will likely involve both types of entities.
It is of course possible to further classify dependencies by a number of facets, such as re-playable or not re-playable dependencies; time-dependant or not time-dependant; dependencies for the different aspects, both from the technical environment and from the human or not strictly system bound environment; semantic dependencies etc.