Using an Application Profile Based Service Registry Ann Apps Mimas, The University of Manchester, UK

DC20072 Outline Purpose and use of JISC Information Environment Service Registry (IESR) IESR domain model IESR Application Profile Benefits of Application Profile in practice IESR future

DC20073 What is IESR? Aim: assist other applications to discover and use appropriate materials JISC Information Environment –Collections of resources for researchers, learners, teachers in UK Middleware Registry of: –Collections of resources –Services that provide access Funded by JISC: Mimas, UKOLN

DC20074 Service Registry Use Registry Client / Portal Collection / Service Register / ContributeDiscover Invoke

DC20075 IESR Use Cases Ideas about possible uses Dynamic Harvest into local registry –Effectively dynamic Static by portal application builder By a person By a service application Contribute by Editor or Harvest

DC20076 Metasearch Portal Scenario Physicist, Mary: literature survey about Higgs-Boson particle Portal discovers bibliographic collections about particle physics with Z39.50 –Vocabulary service needed Portal provides to Mary result of Z39.50 cross-search using ‘Higgs-Boson’ in ‘title’

DC20077 Benefits of Dynamic Use Portal –Amalgamated set of resources IESR provides: –Discover: resource collections –Locate: access details –Invoke: interface connection details Portal builder doesn’t need to know about all resources Users discover collections unaware of

DC20078 IESR Use by a Person Application developer looking for suitable Web Services to plug in Materials science lecturer: resources to recommend to students Aeronautical engineer: find RSS feeds for personal portal Funding Body: collection management tool

DC20079 IESR Domain Model Collection Service Agent administrator owner hasService

DC IESR Entities Collection: –Aggregation of resources Service: –System that provides one or more functions Informational service: –Provides access to a collection Transactional service: Other functionality Agent: –Collection owner / Service administrator

DC IESR Application Profile Documents IESR Metadata –Set of properties for each entity Based on CEN Guidelines –Semantics –Occurrence Additional Attributes –Searchable –General / Specific Attributes –Extended to capture a description set

DC IESR Metadata Properties Collection Metadata based on DCCAP (based on RSLP Collection Description) –Plus some specific IESR properties Service Metadata bespoke –DC properties where possible –Connection details – interface property – uses appropriate standard

DC Example Imported Property Name:title Term URI: Label:Title Defined By: Source Def:A name given to the resource IESR Def:The name of the collection Condition:This is the single main title of the collection and must be present DataType: Occurrence:Min: 1; Max: 1 Searchable:4, 1097; title

DC Another Imported Property Name:type Term URI: Label:Access Method Defined By: Source Def:The nature or genre of the resource IESR Def:Technical type of interface to service Enc Scheme: DataType: Occurrence:Min: 1; Max: 1 Searchable:1148; accessmthd

DC Example IESR Property Name:usesControlledList Term URI: Label:Uses Controlled List Defined By: Source Def:A classification scheme used by collection Enc Scheme: DataType: Occurrence:Min: 0; Max: unbounded Searchable:20, 1040, 1112; classn

DC IESR XML Schema Data supplied in XML (old DC-in-XML) Serialisation of Application Profile –Properties -> XML elements –Vocab Encoding Schemes -> XML Attributes Not possible to impose Occurrence –Need extra validation checks DC element refinements as comments Not possible to constrain enc schemes Reluctant to change to new DC-in-XML

DC Application Profile Issues Multiple entities: description set IESR specific terms now have `standard’ URIs, eg itemType –Reluctant to change now schema in use –Document mapping in AP comment Balance of correctness and completeness against practical usability –Onerous data contribution

DC Application Profile Benefits Inform Use Cases –All properties should have a use –Find gaps in properties / vocab terms Inform data input –Web form editor –Mappings for harvested data Human readable documentation of data specification is significant benefit

DC Metadata Schema Use OCKHAM Registry (US NSDL) –Outcomes of NSF projects CETIS / DEST: eLearning/Admin in Australia aDORe Digital Object Repository (LANL) Australian Partnership for Sustainable Repositories: collection description service Standards development: –DC Collections AP: now conformant –NISO Metasearch Initiative CD Spec

DC IESR Future Funded until July 2009 More content –E.g. JISC Collections; England NHS Persistence and quality of content Further application development Further service registry research and international collaboration Demonstrate and encourage viable use

DC An Application Profile in Practice Central data specification to inform –Development of IESR –Application developers –Promotion of IESR Metadata Schema Realise domain model into concrete application Formal, but human readable, specification Invaluable for communication

DC IESR Details Thank You! Questions?