IESR Metadata Review September 2005: Background Information

Ann Apps

25 August 2005

Service Issues

These are some background thoughts on service descriptions triggered by discussions at the Distributed Service Registries Workshop and the issues about Services that were raised there.

A couple of questions about services in IESR were raised during the Breakout Sessions (note that these were questions not decisions, not everyone agreeing with the viewpoints):

1. Should IESR describe services as a primary focus, with the collections they provide access to as secondary? Currently it appears that IESR firstly describes collections followed by their services.
2. Should there be separate registries for informational and transactional services?

These seem to imply different views on the data. So rather than redesigning IESR and/or building a second registry, it is probably sufficient to provide an alternative service-oriented view of the data. In fact this was suggested in the proposal for the current phase of IESR funding (though not explicit in the project plan).

Thus IESR could provide:

• An alternative Z39.50 search that returns a list of service entities only. Eg. a search on 'collection subject = physics' and 'service type = z3950' (ie. find Z39.50 services that provide access to physics collections). This could be for both the full IESR view and the simple DC view of a description (ie 2 new result formats).
• Similarly a web search returning just services.

These would be service descriptions only. Or should the results be composite (ie include associated collection and agent records) replicating the 'collection view'? Or this could be yet another result format. However it is now possible to retrieve a single entity via the OpenURL interface if its identifier is known (though IESR XML only not DC but that could be implemented).

Should we also provide a similar agent-oriented view (may be more significant if we consider capturing institutions - see below)?

And should we then provide a corresponding Z39.50 result that is just collection descriptions in addition to the current composite one?

Should we provide OAI options to request by entity type, ie. just services? Perhaps we could use OAI sets for this, ie conceptually split our data into a set of collections, a set of services and a set of agents. On the other hand a retrieving application should be able to discard the entities it doesn't want quite simply.

As well as thinking about further IESR interfaces providing new views on IESR data, we need to think about whether there are further properties required in the service description metadata to support:

• a service-oriented view of IESR descriptions
• transactional services

Note that (1) above was intended to 'solve' sub-collection issues, where a single service provides access to a super-collection and a set of sub-collections. This is an issue we've discussed previously and decided to take a pragmatic view treating particular cases where this happens in what seems a sensible granularity, really leaving the decision on granularity with the resource provider. We need to avoid redesigning the IESR metadata from scratch!

IESR Requirements Implied by `Scoping Study into Institutional Profiling and Terms & Conditions Services'

Looking at the implications for IESR suggested in the above Scoping Study, this concentrates mainly on the implications for IESR metadata descriptions rather than any policy requirements about whether we do capture this information or who will describe it. The main purpose is to inform the IESR Metadata Review.

The document identifies several types of data that need capturing 'somewhere' to support these services. It also suggests some of this data could be in IESR and that there may be requirements for extensions to IESR data (without being explicit about which particular things). This data falls into broad categories:

Institutional data

This includes general information such as:

• formal name, address, etc.
• web page locations for various functions, including library catalogue, holdings
• roles: names and contact details for various top-level staff, including job titles that differ between institutions for the same role

The report suggests that an XML schema / DTD should be developed to capture this data. The definitive version should be held at an institution. But it could be harvested into an institutional profiling service and/or into IESR (hopefully someone it will be a requirement that this data has m2m interfaces).

We can already capture an institution as an Agent (though we need to add some contact information like address). It doesn't seem that we'd want to capture the whole range of detail the report suggests, but we could link to it if it is kept by the institution. Or we could describe it as a collection of data about an institution with services that are its access points.

Maybe we'd want to capture the institution and the library as separate Agents. Does this imply some 'isPartOf' relation between Agents and the need for an Agent Type, with an associated vocabulary, eg Institution, Library? Alternatively this relationship and 'type' information could be included in the institution data suggested above. Providing slots in IESR to capture this detail would 'open the door' to their use in a way that wold distort the IESR model, and a 'type list' is likely to be problematic.

Would there be a need to capture Agent descriptions that have no associated collections and services? Possibly this wouldn't arise as one would expect an institution to be running services.

Who will develop the XML schema to capture all the data the report suggests? This deosn't seem to be an IESR role. We wouldn't want this level of detail in IESR, eg whether an institution has 'Pro-Vice Chancellors' or 'Vice/Assistant Principals' and who they are. Though if it were harvestable we could hold a simplified version.

Something else we probably need to capture is the institution identifier as used for authentication, ie the Athens institution identifier, or whatever gets taken forward into Shibboleth (the Athens three-letter prefixes are deprecated).

Institutional telematic data

I think we can probably already describe these as services. Those identified in the report are:

LDAP service

We need to add an 'ldap' service type.

Z39.50, ie library OPACS

Can already be described.

IP range

Probably out-of-scope for IESR (see below)

Credentials for remote services

This is brokering proprietary m2m authentication requests, and providing a repository of these proprietary credentials. Maintaining and passing on such sensitive information seems to be completely outside IESR scope, though possibly we could link to information from the service description.

OAI repository

We can already describe this as a collection with an OAI-PMH service. Do we need to capture any more information about an Institutional Repository? 'This is a collection of stuff developed at this Institution covering many subject areas' doesn't seem very helpful for resource discovery.

OpenURL Resolver

We can already describe these. Do we need to include any further details in IESR? The OpenURL Router already captures details of these including details like link button images and IP ranges (see below). Maybe we could harvest this data into IESR (if the OpenURL Router had an OAI-PMH interface...). Or is it hoped that harvesting would be in the opposite direction?

Shibboleth Handle service

This is a transactional service with the Institution as Administrator. It is not clear if these would be registered in IESR or in the WAYF (Where Are You From) service for the Federation the institution belongs to. If these are in IESR then we need to add an appropriate service type. We do need to capture the Federation for all services with Shibboleth authentication.

Learning & Teaching Information

The report concludes that it is not clear yet how these objects should be described, but there should probably be a separate bespoke service to capture descriptions of this type of information. Probably to describe these resources in IESR will require new metadata properties. But we don't have enough knowledge at present to do this, so capturing such resources in IESR should be deferred (if not out-of-scope).

IP address ranges for institutions

The document suggests that UKERNA would be the best organisation to provide this service because they already maintain this data. It is unlikely that IESR could maintain this data and it doens't seem worth keeping a copy of it. However we could register a service provided by UKERNA. And we could make some suggestions about its interfaces, eg it needs m2m interfaces such as OAI-PMH. Certainly this service would be useful - at the moment services have to maintain their own lists. But it would be more useful if it could be associated with things like Athens institution identifiers.

Thus this data is out-of-scope for IESR apart from registering such a service, which should already be possible.

Subscriptions data

Capturing this information is the job of the institution's library portal. Many are already doing this. (The document does note that the use of OpenURL resolver and library portal technology had increased greatly since the original request for the study.) This data is out-of-scope for IESR. It is something that must be managed by local librarians - any suggestions of adding this to IESR's role are just an attempt to offload a maintenance headache! Also do libraries regard this as public information?

There is a question of the many smaller institutions that do not have library portals because they cannot afford them. Possibly there should be a national default service. The document does suggest places where subscription data may be available without needing local librarian input. But this is not IESR's role.

Possibly the library holdings information will form part of the institutional data.

Terms & Conditions data

The report discusses various ways of capturing rights information. This seems to be out-of-scope of IESR. However we can link to rights details. We already have 'useRights' for a collection which is 'free text but may include a URL', which needs splitting into separate properties for a text statement and a URI of machine-readable rights.

The report suggests IESR should also have a useRights property for a service. This would be both for a transactional service, and for an informational service that has specific rights requirements over and above, or different from, those of the collection.