This document is part of the MIA Requirements Analysis Study being carried out by UKOLN under the MODELS initiative. This draft is made available for comment and can not yet be considered complete.
Version 0.3 (Prepared after July 26th Meeting)
Tracy Gardner with Paul Miller and Rosemary Russell - Monday
September 13th 1999
Version 0.2
(Draft version for discussion) Tracy Gardner with Paul Miller and
Rosemary Russell - Monday July 5th 1999
This document describes the user functionality of a hybrid information environment. The MODELS verbs - discover, locate, request, deliver - are used as the basis for the model which is then extended to support the behaviour required in a general hybrid information environment.
The notation and terminology of the Unified Modelling Language (UML) are used. Units of behaviour that the system must exhibit are referred to as `use cases' and are shown as ovals in diagrams. Complex use cases are described in terms of the steps that they include; variations from the main path through the use case and additional actions that may optionally take place, are also described.
Since MIA is a generic system architecture the use cases do not describe a particular hybrid information environment, instead they provide a starting point for the specification of actual systems. The use cases can be reused and specialised for the requirements of an actual system. The chosen use cases are expected to be required by a full-featured hybrid information environment, but less complex systems may only use a subset of the use cases. Some use cases support alternatives for some behaviour and specific systems may not wish to offer all options - for example some systems may not wish to offer guest access to services. Additionally, some use cases may not describe behaviour in sufficient detail for specific systems.
The basic behaviour of a hybrid information system is
concerned with the discover-locate-request-deliver sequence of
actions - the MODELS verbs. The <<extend>> notation
allows one action to be performed as an add-on to another. Note that
locate may be initiated by the user, or it may initiated by the
system during the discover phase (showing locations along with other
resource description information). We also allow the possibility that
a user may request an item without having selected a location, the
system may then perform the locate step, either offering the user a
choice of locations or selecting one based on the user's preferences.
This general approach supports the following specific examples:
Bibliographic details and location information have separate providers. Users first discover resources at the `work' level, and then locate selected resources to move to the `instance' level. This scenario is likely where various libraries may hold copies of the same book or journal. This approach may also be used when multiple publishers hold electronic copies of articles.
Bibliographic details and (possibly multiple) location information have the same providers. Location information is returned to the user during resource discovery, for example we may have a web document with its locations on various mirror sites.
The request step is started after the discover step, a location must be selected during item request. For example, a user may request a piece of software and then be offered a choice of mirror sites.
Only bibliographic details are shown to the user during discovery, the user does not perform an explicit locate step, a suitable version will be returned when a user requests a resource at the `work' level. For example, users may not be shown multiple locations of a web document, when they request it they will be directed to their nearest mirror.
In a hybrid environment we may expect to have a mixture of behaviours. The common factor is that sufficient information about a resource must be available before delivery takes place.
A further consideration is that the deliver step may take place outside the system boundary, for example a physical document being delivered via ILL, for tracking and logging purposes we would expect the provider to initiate a deliver step within the system, even if the actual delivery is outside of the system. In the case of electronic resources, the actual delivery may be made through the system.
The level at which resources are discovered may vary and this affects the way that a user interacts with the system. There may be multiple editions or versions of the same work (in which the content differs), the same work may be available in multiple formats or languages (in which the content is the same but the presentation is different, and there may be multiple copies or locations for the same version and format of a work.
MIA has previously treated the locate step as a separate act in which the user participates, this approach fits well with a hybrid library environment in which many of the resources are physical books or journals that may be available from multiple libraries. In more general hybrid information environments, this is not the only way in which the locate step may happen, as discussed above. Additionally, the location of a resource is not the only detail that may need to determined before it can be delivered. As well as specifying the location, there may be further details that are required to fully specify a deliverable resource. We represent the acquisition of the versions, formats, languages, or locations of a resource (and other details as appropriate) using detail use cases. Before a resource can be delivered all details must be specified, we use the term `instance' to refer to a resource that is detailed to a level where there is no ambiguity over what is required.
Different levels of detail may be required during resource discovery, depending on context. Alternate formats (Word, RTF, PDF, HTML, etc) may be displayed during resource discovery, or format selection may be seen as an activity that occurs after a resource has been discovered.
A further kind of detail is the terms and conditions associated with a resource. The user may be offered a selection of terms and conditions associated with an object. For example, there may be a cost associated with a particular resource, and this may vary across providers. There may also be alternative terms and conditions for different usage scenarios, for example, it may be possible to license a piece of software for different amounts of time, or buy it outright.
Detail use cases obtain and display a choice of details that can be used to narrow the set of instances that correspond to a particular resource. Since detail use cases provide a list of resources (e.g. the same document in multiple languages), they could be seen as just another form of discover.
The arrow notation in the diagram means that locate, format and conditions are all specialised versions of the detail use case. A particular HIE may only support some of the detail use cases listed here, and it may add further ones of its own.
In order to support tailored information landscapes it is necessary to introduce functionality to support an authenticated user accessing a hybrid information environment. Typically, a hybrid information environment will also maintain information concerning the current session, for example, a shopping basket and the results of the most recent search. This behaviour requires enter and exit use cases.
We assume that other functionality is only available once the
enter use case has been carried out and the user has logged in. Many
systems will wish to offer a guest login as well as a member login.
For a guest user the information landscape can only be configured
based on the current session; more advanced configuration based on
user profiles will not be possible. Success Result: The user enters
an authenticated session and is presented with a tailored information
landscape. The usual path through the Enter scenario is:
User initiates Enter use case (e.g. by loading a top-level web page)
User provides user-name and password.
New session is started and initial information landscape is displayed based on user profile.
Variations:
1a) The Enter scenario may be initiated by the system if the user attempts to access a service that requires authentication.
2a) User may select guest access instead of providing a user-name and password for member access. If so, features that require users to be authenticated will not be available or functionality will be limited.
3a) If the Enter scenario was initiated when a user tried to access a service that requires authentication then they will be returned to the service they were attempting to access after a successful authentication.
3b) Continue an existing session rather than starting a new one, and then display information landscape based on existing session.
3c) Authentication fails, return to step 2 for user to try again.
Some systems may offer an explicit exit from the system which may log the user out (requiring re-authentication to enter the system) and may clear the current session; behaviour on exiting the system may vary, the user could be returned to the enter page or shown an exit screen. Specific systems may fix this behaviour or offer different options based on preferences in a user profile.
The logout use case may also be initiated by the system, say after a time-out period, and similarly with the end session use case.
The discover use case is concerned with using `tools' to move through the information landscape. There are many specialisations of discover including free-text search, metadata search, browse, view bookmarks, what's new, cited references, cited by, etc. Different systems will offer different discover services, and different discover services will be available in different contexts. The usual path through a discover use case is:
User selects discover tool.
User enters required configuration parameters.
Service providers provide results.
Results are presented to user.
Variations:
1a) The system may make the tool available without the user having to select it, for example, a free-text search box may appear on every page.
2a) The tool may be partially or completely configured based on the current information landscape, user profile and/or session information. For example, a cited-by tool may be configured by the resource that the user is currently viewing, so that simply clicking on the cited-by icon will provide a list of the resources that cite the current resource.
2b) For complex tools, the user may be taken through a series of requests for parameters.
3a) There may be too many results, in which case tools for refining the search may be offered. (Selecting such a tool will start a new instance of the discover use case.)
3b) There may be no appropriate results, in which case the user will be offered a choice of discover tools to try again.
Extensions:
1.1 If the requested service is only available to some users then an authorisation check must be made. [MIA-Authorise] If authorisation fails then the user will be informed and returned to their most recent location in the information landscape.
Remember use cases are concerned with recording information that the user is currently viewing so that it can be retrieved in the future. Remember use cases may be used to add to a persistent bookmarks list, a shopping basket for the current session or a list of saved searches.
User selects resource(s).
User selects remember tool.
System stores (references to) selected resource(s) so that they can be retrieved.
Variations:
1a) The resource(s) to be remembered may be selected based on the current context. For example, selecting a bookmark tool when viewing a description of a single resource may add that description to the user's bookmark list.
User selects item(s) to request.
User selects request tool.
User confirms request.
Provider of item delivers item to user.
Variations:
1a) Item(s) are selected by context.
2a) The request use case may be selected by another use case, such as
3a) User hasn't selected an item so one (or more) must be selected before they can confirm the request.
Extensions:
Current selection is displayed and may be modified.
Authorisation check.
Rights agreement offered to user. [Agree use case.]
Perhaps the most obvious form of Use is displaying a resource, for example an image, within the system. Use may be an explicit act on the part of the user or it may be invoked by another activity, for example, requesting an image may cause it to be downloaded and then displayed. Additionally, some systems may choose to allow users to attempt to display a resource without first requesting it, the request and download steps must then be invoked before the resource is finally displayed.
In some cases, resource may be `active', such resources come with their own program and can be run, either inside or outside of the system, and example is a map comes with a program to allow the user to zoom in and out. The metadata for such resources must provide sufficient information, in an appropriate format, for the resource to be launched from the system. Running an active resource is another kind of usage.
In a general hybrid information environment, we cannot necessarily assume that all resources are free at the point of access. An extension of MIA is to consider how rights management issues affect the user's (and provider's) interactions with the system. INDECS provides an event-based model for transactions or `deals'. From the <indecs> metadata model:
A typical rights transaction involves three events: an agreement between two or more persons which allows at least one of them to carry out a permitted act (typically a usage event), normally for a consideration in the form of some other event (typically a payment). The agreement may be preceded by another event, an offer, made publicly or privately.
Within the MIA model, an agreement is initiated when a user makes a request, we can see an offer as an add-on piece of functionality that can occur as part of a request when terms and conditions are associated with a resource, in such a case, an offer is followed by an agreement - the user accepts the terms and conditions and the request can then be completed. In the case that multiple service providers are able to provide the same resource, multiple sets of terms and conditions may be offered so that the user can select the one that best meets their requirements (e.g. the cheapest or the one that will be delivered soonest), in some cases the same resource may be offered under different sets of terms and conditions by the same provider (e.g. at academic and commercial rates).
The permitted act is accessing the resource, which may involve the user downloading the resource, or the provider delivering the resource. It is assumed that use events are always preceded by an access so that an appropriate agreement is also required in that case. In other cases the agreement may be implicit with a transaction being initiated when an access event takes place. An attempt to access a resource without making first making a request, and thereby creating an agreement, may trigger a request, with the access only continuing once the request has been completed.
Payment could be handled in various ways, users may pay directly with a credit card, their institution may be charged, or they may pay money into the broker with the broker making payments to the service providers.
The basic path through the transaction use case is:
User requests resource. [Request use case.]
Provider offers terms and conditions under which resource can be accessed. [Offer use case.]
User selects and accepts appropriate terms and conditions and an agreement is recorded. The payment mechanism is also agreed upon at this point. [Agree use case.]
Provider requests payment for access to resource. Payment is made by the user, or by the broker on the user's behalf. [Payment use case.]
User accesses resource. [Access use case.]
Variations:
4 and 5 may be reversed.
2a) There may be no terms and conditions under which the resource can be offered to the requesting user (e.g. a student may be attempting to access a resource that only tutors can access).
3a) User may reject terms and conditions. Transaction is terminated.
4a) User may not be able to provide a suitable form of payment; if the resource has already been accessed then the transaction will remain incomplete, if the resource has not yet been accessed then the transaction may be terminated.
5a) User may be refused access to resource if an appropriate agreement is not in place.
Locate (and other `detail' use cases) could be considered to be kinds of Discover - the user is still obtaining further information and discovering objects in greater detail. In discussions with service providers, there has been a preference to treating Locate as a distinct activity, and this has been extended to other services that allow the user to specify a particular `instance' of a resource/work to provide Detail services. Feedback required on chosen solution.
An initial attempt has been made to incorporate rights management into the MIA use cases based on recommendations from the meeting on July 26th and on the INDECS model. This provides a basis for discussion of rights management issues in MIA but more work is needed to determine the requirements for rights management in MIA. One issue is identifying the items to which rights management must apply, as well as applying to actual resources there may be access control issues for accessing services and resource descriptions.
A number of Discover services are listed. Should MIA describe a set of frequently used Discover services in detail? Other functionality that could be added includes user profile management and saved list (bookmarks, shopping basket, etc) management.
Are there other supporting services of similar importance to Remember? One possibility is services based on saved lists, such as bookmarks, for example, we might want to convert the list of bookmarks to a standard bibliography format such as REFER or BibTeX. This could be modelled as Use functionality, treating the bookmark list itself as a resource.
Currently, the focus is on resource discovery rather than resource creation and resource description. Should MIA include use cases for entering information into the system. Currently, only the Remember use cases add information. Other use cases that provide input could include annotation, quality ratings, modification of existing resources and submission of new resources.
A potential next step would be to develop an object model that can support the above functionality within the MIA architecture. This would require definitions of concepts such as resource, identifier, service, saved search, user, deal, etc., and the relationships between them. Should such a model be developed?
Comments to Tracy Gardner - t.a.gardner@ukoln.ac.uk - UKOLN