Concertation Day on the Bath ProfileThis brief report captures a number of key points from discussion throughout the day. Queries should be addressed in the first instance to Paul Miller <P.Miller@ukoln.ac.uk>.
The current text of the Profile appears to make references to 'lists', 'indexes' and 'database fields' almost interchangeably, causing some confusion. The text should be checked to ensure that each of these terms is being used correctly and unambiguously.
Verity Brack, from the eLib RIDING project, suggested that Innopac's product did not appear to support cross-index searching (searching Author and Title together, say). As it stands, the Profile remains silent upon the need for such functionality, perhaps assuming it to normally be available. Does the Profile need to make statements about such basic levels of functionality within its Conformance levels?
The Profile needs to clarify behaviour in at least two cases:
It was agreed that positive feedback was important to the user, meaning that targets might normally be expected to return at least the value of the Use Attribute in which the searcher's search term was found. Beyond this, should we also be offering guidance on a larger recommended minimum return? Title, Author, Subject, Identifier, perhaps? There was discussion of a separate document on Best Practice and implementation guidelines, within which much of this information might usefully be found. Should the Profile, however, be saying anything about this subject?
The Profile proposes three "Levels of Conformance", of which Level 0 is the lowest. This Level is intended to allow a large number of existing implementations to become compliant with the Profile with minimal changes to their systems. It was questioned whether or not the requirements set at this Level were too low to be useful for genuine interoperability. There was also a query as to how much evidence there really was that implementations would be able to meet Level 0's requirements. It was suggested that text implying that achievement of Level 0 conformance was 'easy' should be removed or justified.
There was some discussion as to which services might be conformant already, and how we might go about testing this. The Profile suggests, for example, that Level 0 conformance should be relatively easy to achieve for existing services. This might imply that well structured services in the UK such as the Clumps are likely to reach Level 0 conformance without significant changes. Attendees felt that this might not be the case.
Following explanation of the evolving plans for some conformance testing in Texas and Canada, there was interest in setting up similar arrangements locally in the UK or at a European level. Such conformance testing would require development of a set of test data, as well as the design of a suite of suitable tests. To be done properly, this will involve a degree of new funding, but is a vital step if the true value of a Profile such as this is to be realised.
It was pointed out that, whilst a vendor might produce a product which is conformant with the Profile, local considerations often mean that installed products differ quite significantly from each other and from the 'norm' of the default product as supplied. There is therefore an awareness raising task to be done in convincing individual sites of the need to procure products which conform to the Profile in the first place and of ensuring that any changes they make locally do not detract from Profile conformance. Again, such a publicity effort is likely to require extra funds.
It was suggested that any UK extensions to the Profile intended to meet the needs of the DNER might usefully include the stipulation that a link to a Collection Level Description be required as part of the result set returned to users querying DNER resources.
Whilst it is unrealistic to add UKMARC to the Profile itself, it is feasible to add this as a requirement in any UK extension to the Profile. As an extension to the Profile, this requirement would be in addition to any requirement the Profile currently makes. At Level 0 Conformance, then, the requirement would be that systems support SUTRS, UKMARC, and one of MARC21 or UNIMARC. At Level 1, SUTRS, UKMARC, MARC21 and UNIMARC.
It was suggested that JISC might usefully explore development work on tools such as USEMARCON and those developed for ONE. Crossnet and the University of Oxford, for example, are apparently already running a proxy service which automatically translates UKMARC to MARC21 and vice versa, without the user knowing. Such a tool, provided nationally, might ease some of the problems faced in the UK where some systems use UKMARC and others MARC21, and prevent the need for local additions which make it harder for vendors to comply with the Profile.
It was suggested that a UK-specific version of the IndexData Z-Spy robot might usefully be developed, extending the information currently gathered by IndexData to include issues related to the Bath Profile, and DNER service delivery.
It was stressed that we should remember the less advanced state of Z39.50 in the public library and Further Education sectors, both due to the steep technical learning curve these sectors are required to face, and because of the possible potential of having them procure brand new systems in the future, free of any baggage, and capable of embracing the Profile fully if they are appropriately encouraged.
Interest was expressed in acquiring funding for a study to generate explicit crosswalks between the Bath Profile and a number of the major Profiles already in use (CIMI, GILS, ONE,...).
There was some discussion over the selection of the 'Any' Use Attribute within the Profile. It was agreed that this Use Attribute was preferred to the related 'All', but it was suggested that guidance on indexes which 'Any' might appropriately include should be written in to any Best Practice document.
The Profile currently (e.g. section 5.A.) suggests that an Author search will search on "matches in fields containing names used as main entry, added entry, or series author", whilst a Subject Search will "search subject fields (e.g., topical subject, geographical subject, title as subject, and names as subject) with no expectation that it will be searching a particular authoritative subject heading list". It was suggested that certain systems are likely to store all names together in a single index, making it impossible to distinguish names-as-authors (a book by Charles Dickens) from names-as-subjects (a book by Paul Miller which is about Charles Dickens.)
The current statement in Section 1, that Conformance Level 0 "should not require product development" is felt to be misleading, and should be removed.
It was suggested that support for Segmentation might usefully be added at Level 1.
It was suggested that more examples might usefully be added to clarify the text.
The lack of Phrase Searching capability in Functional Area A was queried. This perhaps needs re-examining?
It was suggested that Relation Attributes 2 and 4 might be useful for Date Searches.
There is a conflict of semantics between the Date of Publication Search in Functional Area C, Level 1 (Use Attribute 31) and the definition of Dublin Core's Date, to which this search maps.
The DTD in Appendix D should be modified to reflect the fact that Dublin Core 1.1 is now available.