Summary of contributing data discussions
Stakeholders' Meeting
26 June 2003
Confirmed that Excel or XML templates will be made available by the project for pilot data providers. Excel would not be used by some people in principle. An XML DTD will be provided to enable in house validation. Anticipated that from October a web based data entry form will be available. In future, IESR will be able to harvest OAI descriptions from service providers automatically. It was suggested that XML descriptions could be published on the service providers' websites and collected by a spider.
Data providers aware of the funding allocated to produce their descriptions. Should be possible to deviate from proposal. Issue with level of records to be provided. Services that are made available past a certain date will not be described in the pilot.
Guidelines to "What is a collection?" necessary. Been a problem in the past to agree on this. Collection might be "something with an access point". Resistance to grouping individual texts as collections. One manuscript comprising many digital images might be a collection. Fundamental difference in outlook between librarians and archivists - needs resolving. Terminology problematic. Users don't care much. Internal discussion in pilot necessary. Initially portals will be using the registry. Need a pragmatic view. Something that has an access point is a collection. Portal can only interact with e.g. a Z-target - no point in describing all collections under that Z-target separately. "Service" term a problem. A service only has one collection. Applied this model to libraries. Metadata all in one catalogue - no distinction between collections. How to translate this model. One library management system with everything in one catalogue is a problem, depending on how "collection" is defined. Service might be the JISC definition of a service, as defined in service providers' JISC Service Level Agreements.
In national context: JISC funded services presented to users therefore useful as starting point.
Any transactional services in mind for pilot? No. Edina "PC to OS Grid Reference" might be nice, neat transactional service.
No limit to free-text fields in metadata. Limit could be added for administrative reasons but no theoretical limit in metadata attributes/software.
How long should a description be? RDN catalogue guidelines useful to ensure roughly same ground covered and same length. Quality assurance guidelines required and procedures to get data in and out of the registry.
Projects covered in full registry? Or just services? Similar issues to services as projects. Must be sorted before pilot becomes full service registry.
Service descriptions must be accessible to service provider. Nearly all services have finite planned lifetime. Should this be captured in registry? Temporal aspect to service helps users decide whether to use it. (Information might even be useful to JISC.) Too difficult to describe this information to end-user, once it has reached them via portal. Users used to internet resources disappearing. What happens when services disappear? Records should be dropped automatically. Records should not de deleted. Rather they should be marked as deleted.
Access control and authentication a big issue. Who is allowed to update records? E.g. Edina should not be allowed to update MIMAS records. Should be addressed post-pilot. Could use URL as identifier to check who is authorised to update records.
How will registry deal with takeovers of service providers? It was suggested that a current awareness service or change alerting service (another shared service) would be required to check.
Issue with same collection being offered by two services. E.g. a journal being offered by two services, with different date thresholds. Is the journal two collections or just one? From a user view a journal is clearly one collection. From an administrative viewpoint have to be treated as two collections. Fact of life that there are multiple instances of public material - not a problem, unless portal wants single entry for journal available from many places. Who then writes top-level description?
Reuse of records, i.e. modification of records obtained from registry: users will want to modify records. IPR issues. Modification and re-purposing of records required. If modification allowed then workflow issues to keep records in step. Good to have a relatively consistent licence policy for these records. Strong recommendation that anyone should be allowed to modify records if not for commercial gain. Users need to be alerted about new or updated records. RSS channel possible but not in scope for pilot.