Information Technology Reference
In-Depth Information
Although not indicated, each RepInfoLabel also has a CPID which
points to the Representation Information for that RepInfoLabel,
which will not be another RepInfoLabel of the same type but instead
will be a simple text file - in order to end the recursion.
The above scenario describes the case where all transactions take place with a
single Registry/Repository, but of course any CPID may point to any one of what
may be a large network of Registry/Repositories. The RepInfo may also be held
locally, perhaps a cached copy of something held in a Registry/Repository.
In terms of the getting to the point at which the Representation Information is
adequate, this may be a human decision but some automation is possible.
This has been discussed at length in
Chap. 8
, summarised below. Support for such
automation is illustrated in Fig.
17.5
which shows users (
u1, u2
...
) with user profiles
(
p1, p2
- each a description of the user's Knowledge Base) with Representation
Information {
m1, m2
,
...
).
Take for example user
u1
trying to understand digital object
o1
. To understand
o1
,
Representation Information
m1
is needed. The profile
p1
shows that user
u1
under-
stands
m1
(and therefore its dependencies
m2, m3
and
m4
) and therefore has enough
Representation Information to understand
o1
.
When user
u2
tries to understand
o2
we see that
o2
needs Representation
Information
m3
and
m4
. Profile
p2
shows that
u2
understands
m2
(and therefore
m3
), however there is a gap, namely
m4
which is required for
u2
to understand
o2
.
For
u2
to understand
o1
, we can see that Representation Information
m1
and
m4
need to be supplied.
...
) to understand various digital objects (
o1, o2
...
interpretedUsing
User
Profile
RImodule
InfoObject
DataObject
m1
u1
p1
o1
m2
m4
o2
u2
p2
m3
Fig. 17.5
Modelling users, profiles, modules and dependencies