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
Search WWH ::




Custom Search