JISC Information Environment ArchitectureFunctional Model |
  |
JISC Information Environment ArchitectureFunctional Model |
|
This document attempts to extrapolate a high-level view of JISC Information Environment (IE) functionality from the JISC IE scenarios [1]. This overview is not intended to be exhaustive. Functionality will be required that is not discussed here and more detailed analysis of all areas of functionality will be needed before a detailed picture of the JISC IE functional model is obtained.
The notation and terminology of the Unified Modelling Language (UML) [2] are used. Units of behaviour that the JISC IE must support are referred to a 'use cases' and are shown as ovals in the diagrams. Again, it should be noted that this section does not provide a thorough model of JISC IE functionality and is certainly not intended to form a suitable basis for the design of actual systems, though it might help inform their development.
The JISC IE is described here as a 'system' with which the end-user can interact. There is however, no intention that the JISC IE be seen as a single system or service. The functionality described here may be offered by lots of different services and, in the general case, the desired functionality will only be available by combining several different JISC IE service components including the browser on the desktop, content provider services, institutional portals, subject gateways and local virtual learning environments. At this stage no attempt is made to map functionality to particular systems or services.
By providing a high-level view of the JISC IE functional model, we can begin to see the distributed service components that need to be offered in order to support the desired functionality. However, the JISC IE does not start from a blank sheet. As indicated in the introduction, many service components are already in place. This modelling helps to view those components in context and identifies gaps in current provision.
The use cases presented here are based on those developed for the MODELS Information Architecture (MIA) [3]. The four MODELS verbs - discover, locate, request, deliver - are taken as the starting point. These are the basic processes through which an end-user must move from having identified a need to obtaining a resource that they can use.
This is very a very generic model and is equally applicable to buying a car as it is to obtaining learning resources or research material online. We have modified and extended this basic model in a number of ways.
We have replaced the 'locate' and 'deliver' use cases with more generic 'detail' and 'access' use cases. We have also added a number of additional high-level use cases - in particular, 'useRecord' and 'useResource'. These actions show the end-user actually doing something with the resources they obtain. Delivering high-quality resources to the desktop is, after all, the whole point of the JISC IE. It is important to remember that what the end-user obtains at the end of the 'discover' and 'detail' use cases is a metadata record describing a resource. This will vary from a very minimal record (perhaps only consisting of the resource name and URL) to a very rich record (a full bibliographic record for example). The metadata record may be an end in it's own right - a course tutor building a hybrid reading list for his or her students may simply wish to add the metadata record to a reading list and share it with their students. Normally however, the metadata record forms the basis for a request to obtain the discovered resource. We show separate 'detail', 'request' and 'access' use cases. These steps are exemplified in the reality of moving from the discovery of a book, through locating an appropriate copy in a local library or from the cheapest online or high street bookshop, to the actual delivery or collection of the item. The same is true of online resources - digitised journal articles may be available through several suppliers; Web sites may be mirrored at several locations.
Identification is very important for the use cases following 'discover', although the form of identifier may change as the end-user moves from discovery to access. Nevertheless, the ability to persistently refer to particular resources, and to pass those references on to others, is one of the keys to a useful information environment.
Whilst discovery tends to be a fairly open process, locating, requesting and accessing a resource can only be carried out with knowledge of the access rights of the end-user. For this reason, it might be argued that the functionality of these use cases is best delivered by services offered within the institution of which the end-user is a member.
Each of these use cases is now described in more detail. We use the term 'resource' very generally, to indicate anything that might be of interest to the end-user, and 'item' to indicate a particular manifestation of a resource.
In order to support personalised services and to limit access to licensed resources, end-users are likely to have to be authenticated before interacting with the JISC IE. On initiating the 'enter' use case, by visiting the top-level Web page for a service for example, the user may be prompted for a username and password. This results in a new session being started. An initial 'landscape' is presented to the end-user based on their user-profile. The landscape may consist of a view of the resources to which that user has access rights and that correspond to the subject interest of the user.
Note that a 'guest' account may be available that offers a restricted landscape and functionality.
In this analysis we have chosen to break the discovery process into two parts. An initial phase of discovery, the 'survey' use case, is concerned with identifying the collections that are worthy of further investigation. This process is likely to involve narrowing down the collections presented as part of the 'landscape'. However, it may also involve the discovery of new collections that are not yet listed within the landscape.
The results of the 'survey' use case are a set of collections that warrant further investigation.
The 'discover' use case drills down into each of the collections identified during the initial survey. The intention is to discover a particular item of interest. The result of this activity is not the item itself, but a metadata record about that item.
It is likely that survey and discover can often be considered as parts of the same activity. Both make use of four 'discovery' strategies. Either a search-based approach is used (the 'search' use case), or a browsing approach is used (the 'browse' use case) or some kind of 'bookmark' list is used (the 'useSavedRecord' use case). The 'useSavedRecord' use case may make use of a personal set of bookmarks or a shared list - for example, a course reading list or a set of bookmarks exchanged between research colleagues. Finally, alerting mechanisms may be used (the 'alert' use case). In this case, the content provider alerts the end-user to the existence of a new or updated resource (items or collections), typically using email or a Web-based alerting mechanism.
As part of the 'search' use cases the system may provide some assistance with the search terms used, the 'assistQuery' use case. Typically this includes the use of a terminology service or thesaurus to improve the search terms used by the end-user in constructing a search query.
By the end of the 'discover' use case the end-user will have discovered a resource, for example a book (in which case they might know its title, author and ISBN) or a Web page (in which case they might know its title and URL).
Our model shows the 'locate' use case as being a specialisation of a more general 'detail' use case. This activity builds up knowledge about a particular resource to the point where enough is known that there is no ambiguity about the item that must be requested.
Note that Web resources often present the minimal case here because the URL is known at the end of the 'discover' use case - no further information is required in order to request the resource.
More generally, for example in the case of obtaining books or journal articles, it may be necessary to locate the most appropriate format, cheapest or nearest copy of a resource. The 'locate', 'getFormats', 'getRatings' and 'getConditions' use cases facilitate this process. The 'getConditions' use case results in information about the terms and conditions associated with a particular resource being passed from the provider to the user.
It is arguable whether the 'detail' use case forms the last phase of the discovery process or the first phase of obtaining the resource, or whether it is a separate process. Specific implementations may choose to implement the 'detail' use case in a variety of ways. In particular, selecting between multiple mirrored copies of a Web resource may be presented as an explicit choice to the end-user (as part of the 'detail' use case) or may be done behind the scenes as part of the 'deliver' use case below (in much the same way as Web caching is typically done).
At the end of the 'detail' use case the end-user has obtained a metadata record that is rich enough to unambiguously identify the particular item they want. This record may be an end in its own right. Typically however it will form the basis for obtaining the item itself. The 'useRecord' use case allows the end-user to do something with the record. Specifically, the 'saveRecord' use case supports adding the metadata record to a saved list of some kind (for example, a list of bookmarks or a course reading list). The 'share' use case supports the exchange of the record with other people.
Having sufficiently identified the particular resource that he or she is interested in, the end-user may attempt to obtain it. The 'request' use case allows the end-user to ask for a particular item. For Web resources this is typically as simple as clicking on a link - effectively the item is downloaded by the end-user (the 'download' use case). In other cases, delivery is initiated by the content provider - in response to an inter-library loan (ILL) request for example. In some cases authorisation will be required before the item is delivered (the 'authorise' use case) typically based on the authentication credentials presented earlier or on the IP address of the end-user's browser. Where items are not available free at the point of use, payment may be required before delivery. This would be covered by a 'pay' use case and would typically result in a credit card transaction, though this is not considered here.
Having obtained the resource the end-user will want to make use of it. This is covered by the 'useResource' use case. This phase is not dealt with in any detail here - fairly complex use cases are likely to be required to model this activity. The 'unpack' (unbundle a compound resource into its component parts), 'view' (display on screen or in hardcopy), 'process' (process data in some way), 'incorporate' (re-use resources, for example within multimedia essay), 'store' (save for later use) and 'share' (pass on to others) use cases are shown to indicate the kinds of functionality that might be required.