Information Technology Reference
In-Depth Information
Furthermore we can organize dependency types hierarchically using rules. As
already stated, the motivation is to enable deductions of the form “
if we can do task
A then we can do task B
”. For example suppose that we want to express that if we
can edit a file then certainly we can read it. This can be expressed with the rule:
Read(X) :- Edit(X)
. Alternatively, or complementarily we can express such
deductions at the dependency level:
Readable(X,Y) :- Editable(X,Y).
Finally we can express the properties of dependencies (e.g. transitivity) using
rules. For example if the following two facts hold:
Runnable(
HelloWorld.class
,
JavaVirtualMachine
).
Runnable(
JavaVirtualMachine
,
Windows
).
then we might want to infer that the HelloWorld.class is also runnable under
Windows. This kind of inference (transitivity) can be expressed using the rule:
Runnable(X,Z) :- Runnable(X,Y), Runnable(Y,Z).
Other properties (i.e. symmetry) that dependencies may have can be defined
analogously.
8.2.1.2 Synopsis
Summarising, we have described a method for modelling digital objects and their
dependencies.
•
A Module can be any digital object (i.e. a document, a software application etc.)
and may have one or more module types.
•
The reliance of a module on others for the performability of a task is modelled
using typed dependencies between modules.
Therefore the performability of a task determines which the dependencies are. In
some cases a module may require all the modules it depends on, while in other cases
only some of these modules may be sufficient. In the first case dependencies have
conjunctive semantics and the task can be performed only if all the dependencies
are available, while in the second case they have disjunctive semantics and the task
can be performed in more than one ways (a text file can be read using
NotePad
OR
VI
).
8.2.2 Formalizing Designated Community Knowledge
So far dependencies have been recognized as the key notion for preserving the intel-
ligibility of digital objects. However since nothing is self-explaining we may result
in long chain of dependent modules. So an important question which arises is: how
many dependencies do we need to record? OAIS address this issue by exploiting the
knowledge assumed to be known by a community. According to OAIS a person, a
