Cross-Search in Renardus Göttingen State and University Library, Germany (SUB) Dr. Heike Neuroth The Academic Subject Gateway in Europe

2 Inhalt Renardus Datenmodelle Warum? Definition Application Profile mit Beispielen Definition Namespace mit Beispielen Registries Renardus Ausgangssituation Renardus Application Profile Beispiele einzelner Elemente Cross-Search Collection Level Description Renardus Collection Level Description Ausblick, URLs

3 Warum Cross-search über heterogene und verteilte Metadatensammlungen zu High Quality Internet Ressourcen detailierte Beschreibung aller Subject Gateways als Ausgangsbasis für die homogene, qualitative Suche Definition eines Core Set an Metadaten für die gemeinsame Suche Verwendung von einheitlichen Standards, Codes, Regelansetzungen, etc. Renardus Application Profile Entwicklung eines Renardus Application Profile!

4 Application Profile (AP) beschreibt: welche Elemente für die Anwendung herangezogen werden welchen Namespaces sie angehören bei welchen Organisationen die Namespaces registriert, definiert und beschrieben sind welchen Bedingungen die einzelnen Metadatenelemente bei der Anwendung genügen sollen Guidelines für jedes Metadatenelement ein AP besteht aus mindestens einem Namespace

5 Beispiele APs DC-Education DC basierte Metadatenelemente, Audience (mit Level etc.) und einigen IEEE Learning Object Metadata (LOM) DC-Government DC basierte Metadatenelemente, DC-Gov Metadata Element Set (DC- GOVMES), DC-Gov Metadata Element Set Qualifiers (DC-GOVMES Qualifiers) mit Refinements zu Rights, Date, Subject, Relation etc. und dem Element Audience DC-Libraries DC basierte Metadatenelemente, DC-Library Metadata Element Set (DC-LMES), DC-Library Metadata Element Set Qualifiers (DC-LMES Qualifiers) mit Refinements zu Title (translated, uniform title), Subject (keywords, class. System..), etc. und den Elementen Audience und Holdings (under discussion!) aber auch andere Beispiele: EULER, RSLP,...

6 Namespace ist definiert im W3C: Namespaces in XML beschreibt: ein definiertes Set an Metadaten-Elementen innerhalb eines bestimmten Bereiches (z.B. domainspezifisch) definiert Semantik und Syntax für jedes Element (auch über Qualifier: Refinements und Encoding Schemes) kann auch Katalogisierungsregeln zu einem Element enthalten ist der eindeutige Identifier für ein Metadaten- element

7 Beispiele Namespace Dublin Core Metadata Element Set, Version 1.1: dc Dublin Core Qualifiers: dcq Dublin Core Education: dc-ed Dublin Core Education Qualifiers: dc-edq Agricultural Metadata Framework: fao IEEE Learning Object Metadata: ieee-lom RSLP Collection Description: rslpcld …

8 Registries zur Registrierung solcher APs und Namespaces Nachnutzung vorhandener Namespaces Definition eigener Namespaces Entwicklung eines domainspezifischen AP Beispiele SCHEMAS Projekt MetaForm (SUB) Dublin Core SCHEMAS MetaForm

9 Renardus Ausgangssituation Metadatenformate der Partner: meistens Dublin Core basiert einige hatten schon ein Mapping nach Dublin Core wenige sind homegrown Definition eines Core Sets an Metadaten Dublin Core basiert Elemente sollten von allen bzw. den meisten Partnern unterstützt werden Verwendung internationaler Standards, Codes, Regeln, etc. Einheitliche Semantik und Syntax

10 Renardus AP Renardus AP besteht aus vier Namespaces: dc: [DCMES version 1.1] Dublin Core Metadata Element Set, Version 1.1 (Dublin Core Namespace) dcq: [DCMES Qualifiers ( )] Dublin Core Qualifiers (Dublin Core Qualifiers Namespace) rmes: [RMES version 0.1, ] Renardus Metadata Element Set (Renardus Namespace) rmesq: [RMES Qualifiers version 0.1, ] Renardus Metadata Element Set (Renardus Namespace Qualifiers)

11 Beispiele Creator dc rmesq (for personal names: last name and first name in separate tags) Subject dc dcq rmesq (for Renardus partners specific Encoding Schemes + Ren-DDC) Country rmes rmesq

12 Cross-Search Feldbezogen: *IndexScan Title, Subject, Description (auch Simple Search=Basic Index) *Title Creator Description *DDC Classification (nur Captions) *Subject *(Document) Type Filterprozesse: (Document) Type (nach DCT1) Language Country

13

14 Collection Level Description Warum wichtig für Renardus Nutzer wählen Subject Gateways für ihre Suche aus Hintergrundinformationen zu jedem Subject Gateway in strukturierter Form (human and machine readable) Promotion, Registrierung der Subject Gateways RSLP schema (AP) DC basiert zusätzliche RSLP Metadatenelemente (z.B. cld:note, cld:legalStatus, cld:owner, etc.)

15 Renardus CLD (RCLD) RCLD DC basiert CLD (bzw. RSLP) basiert aber auch: Renardus spezifische Elemente, z.B. rcld:acronym, rcld:resourceLanguage, rcld:Z3950Location, etc. =damit eigenes AP! Tool von UKOLN nachgenutzt Partner können jederzeit updaten Renardus Broker holt sich die Infos vom Partner! XML/RDF und txt encodedhttp://renardus.sub.uni-goettingen.de/renap/rcld.html

16

17

18 Ausblick, URLs Entwicklung eines Namespaces für: Beschreibung der lokalen kontrollierten Listen wie z.B. Thesauri, Klassifikationssysteme, (Document) Type Listen der Partner (encoded über rmesq) auf der Basis von RSLP Renardus (?) Registry dafür (NKOS, OCLC etc. arbeiten ebenfalls daran) Renardus AP und Namespaces: Encoding in XML/RDF Anmelden in Registrieshttp://renardus.sub.uni-goettingen.de/renap/

Vielen Dank für Ihre Aufmerksamkeit Fragen, Anmerkungen... ?