IESR Metadata Review and Service Types

IESR is currently undertaking a review of its metadata schema. Details are at http://iesr.ac.uk/metadata/reviews/review-200702.html. Comments are welcome, either on this Blog or to IESR personnel.

One particular area that may be of interest is developing a list of Service Types (item 2.3 on the review list). I suggest rechristening these `Service Functions' and partly using the registry services functions list proposed for ISO 2146 (There doesn't appear to be a standard to reference yet, but they are listed in http://www.nla.gov.au/nla/staffpaper/2005/pearce1.html). This list is:

Common Services: Authenticate; Authorise; Pay
Metadata Services: Contribute; Save; Alert; Harvest
Discovery Services: Find; Locate; Request
Delivery Services: Resolve; Supply; Lend; Reserve
User Services: Register; Ask; Personalise; Monitor

There is also a much longer, finer-grained (in places) service genre list within the e-Framework, but many items are very e-learning specific (and the length would probably confuse our contributors and users): http://www.e-framework.org/Services/Genres/ServiceGenreRegistry/tabid/655/Default.aspx

However we may need some additions. Terminology is on our current list - e-Framework has `Map terms', the generalistion of which would be Map. IESR Use Case step 6.1a1 / scenario is looking for a `format validation' service, of which the generalisation would be Validate (the Use Case could find `format' in the description). e-Framework has `Validate Courses' but that is too specific. Some others from e-Framework which seem significant: Annotate; Archive; Rate (which would include: assess, classify, recommend); Translate.

This makes a suggested list (which would be annotated with provenance in documentation):

• Alert


• Annotate


• Archive


• Ask


• Authenticate


• Authorise


• Contribute


• Find


• Harvest


• Lend


• Locate


• Map


• Monitor


• Pay (would Purchase be better?)


• Personalise


• Rate


• Register


• Request


• Reserve


• Resolve


• Save


• Supply


• Translate


• Validate

Although it would be preferable to use an existing standard list, there does not seem to be a suitable one. The advantage of maintaining our own IESR list is that it gives us flexibility for future extensibility.

Some service types could be filled automatically by data creation software for particular service protocols:

ftp: Request; Contribute
ldap: Locate
oai-pmh: Harvest; Request
opengis: Find
opensearch: Find
openurl: Locate
rss: Alert
rsync: Request
soap: Request
sru: Find
srw: Find
webcgi: Find
z3950: Find

Correlation with other digital library work in this area:

Obtain; Get: Request
Put: Contribute
Search: Find, and in some cases also Request (eg. Z39.50 Search/Retrieve)
Publish-Subscribe: Alert

Service Registries at the DNS Level

During the OCKHAM Registry Experiment meeting held in Seattle, USA, on 16-17 January 2007, there was some discussion about the possibility and practicalities of implementing a service registry at the DNS level.

This could be based on the technology used by Zeroconf/Bonjour (http://en.wikipedia.org/wiki/Zeroconf). If this is enabled with a service discovery mechanism, it allows for dynamic connection to services. Zeroconf is utilised by iTunes to automate music sharing by users who are on the same sub-net. RFC 2782 (http://tools.ietf.org/html/rfc2782) specifies fields in DNS records, which if set can enable automatic discovery of suitable services of a particular type.

At the meeting Dan Chudnov was quickly able to set up a demo of this in action, using some service data records he'd gathered from IESR via OAI-PMH.

Clearly developments at the DNS level are complementary to initiatives like IESR and OCKHAM. It allows for discovery of services that implement a particular protocol or serve a particular function. IESR's `transactional services' probably include those that would lend themselves to `low level' service discovery. But it doesn't seem to me possible to use this method to implement use scenarios that are based on discovery via IESR's and OCKHAM's rich collection descriptions, i.e. discovery of `informational services'.

Experiments of low level service discovery are outside of IESR's scope, but it seems to me they are worth pursuing. Maybe this area would make a good student project for someone somehwere.

Demonstrating use of registries

The OCKHAM team organised a meeting in Seattle this week to bring together registry providers and some potential registry users. The potential users were some of the projects funded by the National Science Digital Library (NSDL) and included the New Jersey Institute of Technology's the General Recommendation Engine, Utah State University's Services to Link Opencourseware Repositories and the NSDL (one of these services is the wonderfully-named Scrumdidilyumptious) and the Pathways resources of the NSDL itself.

The meeting was held in the Seattle Public Library's Central Library, an innovative building which was opened in 2004. One of its features is a 'Book Spiral' which connects four floors of books and is decorated by Dewey Decimal numbers set into the floor, to help library users find their way around.

The Midwinter Meeting of the American Library Association is taking place in Seattle. This is a huge affair, with 15,000 librarians attending, according to the Seattle Times which published an editorial on the importance of librarians on 19 January. The generally positive buzz about libraries and librarians in Seattle was refreshing.