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