Oversendelsesbrev - Håndbok for bruk av metadata i norske forskningsarkiv

Oversendelsesbrev - Håndbok for bruk av metadata i norske forskningsarkiv Styringsgruppa for NORA oppnevnte i 2010 en arbeidsgruppe for å utarbeide en felles håndbok med anbefalinger for registrering av metadata i åpne norske forskningsarkiver. Arbeidsgruppa leverte sitt forslag til CRIStin (som da hadde overtatt ansvaret for NORA) i mai 2011. Dette forslaget ble sendt på høring blant interesserte institusjoner. Høringen ble avsluttet 15.august 2011. Det kom i alt inn 13 høringssvar på håndboka. Arbeidsgruppa ble så bedt av CRIStin om å gå gjennom høringsuttalelsene og gjøre eventuelle revideringer i forslaget til håndbok. Mange av høringsuttalelsene ga nyttige innspill som er bakt inn i dette reviderte forslaget som med med dette sendes over til CRIStin. Mandat I NORA-prosjektets tidlige fase ble det utarbeidet en anbefalt metadatastandard for norske forskningsarkiver, basert på ukvalifisert Dublin Core-metadata. Vårt oppdrag var å gå gjennom denne, og foreslå endringer og presiseringer, og på denne måten lage et utkast til en håndbok for metadata til bruk i norske forskningsarkiver. Arbeidsgruppa fikk frihet til å bruke kvalifiserte Dublin Core-elementer i sitt forslag. På denne bakgrunn definerte vi vårt mandat til å utarbeide en håndbok for metadata basert på kvalifiserte Dublin Core-elementer. Arbeidsgruppa har ikke drøftet bruk av andre alternative metadataskjema både fordi vi definerte dette som å ligge utenfor vårt mandat og fordi Dublin Core er den standarden som er klart mest brukt blant forskningsarkiv på verdensbasis. Arbeidsgruppa ser likevel at mer avanserte metadataskjemaer kan være aktuelle i framtida og deler delvis bekymringen som kom frem i høringsrunden om at Dublin Core på noen områder ikke er framtidsrettet nok. Et eventuelt ønske om å utarbeide anbefalinger for bruk av mer avanserte metadataskjemaer (inkludert linked data ) mener vi imidlertid må vurderes av CRIStin og det norske forskningsarkivmiljøet som et annet og nytt prosjekt. Anbefalinger og videre arbeid Etter vår mening bør håndboka fungere mer som en anbefaling enn som en standard som arkivene må følge. Arbeidsgruppa vil oppfordre CRIStin til å iverksette noen konkrete tiltak: 1. Tilgjengeliggjøring av håndboka Denne håndboka bør gjøres tilgjengelig på nett på en lettfattelig måte. En måte å gjøre dette på kan være å la håndboka inngå i NORAs wiki-sider http://www.ub.uit.no/wiki/openaccess/index.php/nora. Det bør i tillegg åpnes for at eventuelle lokale tilpasninger eller registreringspraksiser skal kunne gjøres tilgjengelig på samme sted. 2. Opprette en eksempelsamling på nett Håndboka vil trolig bli mer brukt dersom det også opprettes en eksempelsamling for hva som er best practice for registrering av ulike typer artikler, mastergradsoppgaver, doktorgradsavhandlinger og andre dokumenttyper. Det vil

være naturlig at denne eksempelsamlinga kobles sammen med og ligger på samme nettsted som håndboka. 3. Revisjon av Norsk inndeling av vitenskapsdisipliner Flere av høringssvarene peker på at Norsk inndeling av vitenskapsdisipliner er mangelfull på flere fagområder. Eksempelvis mangler kunstfagene helt i denne inndelingen. Arbeidsgruppa deler denne oppfatningen, og anbefaler at CRIStin tar et initiativ overfor UHR for å få revidert Norsk inndeling av vitenskapsdisipliner. 4. Videre arbeid med håndboka Det er avgjørende at håndboka til enhver tid blir oppdatert. CRIStin bør derfor oppnevne en ekspertgruppe som arkivene kan rådføre seg når de er i tvil om eller har spørsmål om registrering av metadata. Denne gruppa bør også ha ansvaret for at håndboka er oppdatert til enhver tid. 5. Prosjekt-IDer CRIStin bør etablere en syntaks for alle forskningsprogrammer som har innført et krav om egenarkivering for å få prosjektstøtte. Forskningsprogrammer som er omfattet av OpenAIRE har en slik syntaks. Andre forskningsprogrammer, som er støttet av f.eks Norges Forskningsråd, bør få en lignende syntaks. Dette bør registreres i feltet dc.relation.projectid. 6. Revisjon av NORAs standard for dokumenttyper I arbeidet med håndboka har vi ikke gjort en grundig revurdering av dokumenttypene, ettersom disse ble revidert for relativt kort tid siden (2009). Noen av høringsuttalelsene pekte på at den eksisterende standarden for dokumenttyper er mangelfull. Listen er i stor grad laget med utgangspunkt i de tekstbaserte arkivene. Vi har nå utvidet listen ved å inkludere 5 dokumenttyper som spesielt er aktuelle for institusjoner som har kunstfaglige utdanninger. Vi ser at det kan være et behov for å revidere listen ytterligere. Vi mener derfor at CRIStin bør vurdere om det er behov for å revidere standarden for dokumenttyper. 7. Retningslinjer for metadata i innleveringssystemer CRIStin bør vurdere om det er behov for å etablere felles retningslinjer også for metadata i innleveringssystemer for masteroppgaver og ressurser i lukkede arkiv. Flere institusjoner har slike innleveringssystemer eller er i gang med å få slike innleveringssystemer. Utdypning av vurderinger Vi ønsker i forbindelse med oversendelsen å utdype våre vurderinger på noen punkter. Registrering av tittel og undertittel: Vi har vurdert to måter å registrere tittel og undertittel på: 1. Registrere tittel slik det anbefales i AACR, dvs. at hoved- og undertittel skilles med : (kolon). 2. Tittel registreres som beskrevet i ressursen. Hvis det ikke finnes noe skilletegn mellom over- og undertittel kan punktum, bindestrek registreres (valgfritt). Arbeidsgruppa har valgt alternativ 2 av hensyn til brukervennligheten. Det er slik tittelen er registrert på ressursen og slik forfatter selv vil forvente å få opp tittel ved søk. Det vil være uheldig å registrere tittel på annen måte i metadata enn slik den fremkommer i fullteksten som følger med innførselen. Mange artikler vil overføres fra CRIStin, som igjen får artikkeldata fra utgiver. Det vil være naturlig å benytte de samme dataene i arkivene som i CRIStin. Autoritetsregistre: Autoritetsregistere bør i størst mulig grad benyttes for registrering av forfattere/opphavsmenn. Det er imidlertid vanskelig å finne et autoritetsregister som dekker

alt. De mest aktuelle autoritetsregistrene er etter vårt skjønn BIBSYS autoritetsregister, Felles Studentsystem (FS), CRIStins forskerregister og Virtual International Authority File (VIAF). Emneord: Vi har valgt å ta inn flere ulike klassifikasjonssystemer under dc.subject som egne underelementer. Vi ser ikke noe problem med at det finnes mange slike underelementer. Det er kun dc.subject.nsi (Norske vitenskapsdisipliner) vi foreslår som obligatorisk gitt at ressursen har en dekkende klassifikasjon i Norske vitenskapsdisipliner. Opphavsmann og bidragsyter: Vi anbefaler at creator brukes for den som skaper et verk (opphavsperson), mens contributor brukes for de som bidrar til et verk. I de fleste tilfeller, men ikke alltid, vil creator ha opphavsrett til verket, mens contributor ikke vil ha det. Arbeidsgruppa anbefaler å bruke en ikke-uttømmende liste som kun omfatter de mest aktuelle alternativene for elementene opphavsmann (dc.creator) og bidragsyter (dc.contributor). I stedet benyttes sekkepostene dc.creator.other og dc.contributor.other for det som ikke dekkes av underelementene. Arbeidsgruppa mener det er bedre om institusjonene heller legger til egne underelementer for dc.creator og dc.contributor dersom de har lokale behov for det, enn å operere med en uttømmende liste i håndboka. Det bør imidlertid oppfordres til at bruk av lokale underelementer deles på samme sted som håndboka, slik at lista etter hvert kan utvikles videre. Dokumenttyper: Vi anbefaler at det tas inn 5 nye dokumenttyper i NORAs standard for dokumenttyper : Design product (Designprodukt), Exhibition (utstilling), Patent (Patent), Performance (Forestilling) og Work of art (Kunstverk). Dette er dokumenttyper som spesielt er aktuelle for institusjoner som har kunstfaglige utdanninger. Dato: Vi skiller mellom dc.date.issued og dc.date.available, der førstnevnte er utgivelsesdato og sistnevnte er dato for innlemmelse i arkivet. Vi tror vi har fått presisert og eksemplifisert godt hvordan dette skal håndteres for de ulike dokumenttypene. Format: Dc.format genereres automatisk av DSpace på filnivå (bitstream), og NTNUs Diva benytter tilsvarende. dc.format anbefales også av DRIVER. dc.format har fem hovedtyper med underkategorier: text, application, image, audio og video. dc.format sier imidlertid ikke noe om den fysiske, digitale manifestasjon på filnivå. For eksempel vil en PDF-fil kategoriseres som applikasjon og ikke som tekst. Av den grunn er det behov for å også å ta i bruk dc.type.resource. Ressurstype: dc.type.resource er brukt for å beskrive ressurstype. Dette gjør det mulig å beskrive en ressurs bedre på filnivå. DCMI har en anbefaling av et vokabular for elementet type http://dublincore.org/documents/dcmi-type-vocabulary/ som kan brukes for å beskrive ressurstyper. Disse er i dag i bruk i ODA og TEORA. Relasjon: Håndboka anbefaler bruk av seks felt for å beskrive relasjoner mellom ressurser: haspart,

ispartof, hasversion, isversionof, URI og projectid. 1 De fem første er en del av DCMI sin standard, mens det sjette er anbefalt i OpenAIRE-retningslinjene. Nedenfor beskrives vår anbefalte bruk av de fem første feltene nærmere. Relasjon brukes for å henvise til en relatert ressurs i form av tekst/sitering, og/eller en lenke. Dette kan være til en relatert ressurs som finnes innenfor eller utenfor arkivet. DCMI anbefaler at en relatert ressurs identifiseres ved bruk av et formelt identifikasjonssystem. I håndboka åpner vi for at feltene kan brukes for å registrere mer informasjon om relaterte ressurser enn dette. En slik bruk av feltet gjør at brukerne i større grad kan få en forståelse av relasjoner mellom ressurser ved lesing av innførslene som finnes i arkivene, fordi feltene vil inneholde mer informasjon. Dette vil være nyttig spesielt ved registrering av de artikkelbaserte doktorgradsavhandlingene. Relasjons-feltene kan for eksempel brukes til: Å henvise mellom forskjellige versjoner av en ressurs (hasversion og isversionof), for eksempel mellom manuskriptversjon og publisert versjon av samme artikkel. Forskjellige versjoner av en ressurs registreres som separate innførsler i arkivene, og ikke som filer i samme innførsel. Å lenke til andre versjoner eller deler av en ressurs i eget eller i andre arkiver (relation.uri). Dette feltet er tilpasset bruk av lenker. Bruk av relation.uri fungerer best ved registrering av én-til-én forhold mellom ressurser siden det ikke er mulig å vite hvor lenken fører. Å henvise mellom hoveddel (kappe) og artikler i artikkelbaserte doktoravhandlinger (haspart og ispartof). Når det gjelder registrering av artikkelbaserte doktorgradsavhandlinger så finnes det flere muligheter. En løsning kan være å registrere kun bibliografiske opplysninger om artiklene i haspart, og eventuelt lenke til de artiklene som kan tilgjengeliggjøres som egne innførsler i arkivet. I haspart kan det legges inn tittel eller hele referansen til den publiserte artikkelen, og eventuelt lenke til posten i arkivet. For artikler som ikke kan legges i arkivet kan det eventuelt lenkes til den publiserte versjonen (DOI) på utgivers nettsider. Problemet med å bruke disse feltene for å lenke mellom relaterte ressurser, er at det legges HTML-koder inn i et felt som ikke er tilpasset dette formålet. En alternativ løsning kan være å registrere alle artikler som inngår i en doktoravhandling som egne innførsler i arkivet, selv når det ikke er mulig å legge ut artikkelen som fulltekst. I feltet dc.relation.haspart kan man så lenke til arkivposten for hver enkelt artikkel, og også lenke den andre veien via dc.relation.ispartof, slik som beskrevet ovenfor. Dette alternativet brukes av NTNUs DIVA i dag. Et minus med denne løsningen er at arkivet vil inneholde poster uten fulltekst, og dermed da ikke vil være 100% Open Access. Merk at det anbefales at de bibliografiske opplysningene om en ressurs, for eksempel en artikkel i en antologi, skal registreres i feltet identifier.bibliographiccitation (se forklaring nedenfor). Relasjonsfeltene illustrerer et av problemene ved å bruke Dublin Core. Det finnes ikke gode metoder for å lage relasjoner og hierarkier mellom dokumenter. Siden det er vanskelig å gi en klar anbefaling på hvordan man best skal registrere relasjoner mellom 1 Håndboka dekker kun noen av underelementene for dc.relation. Arbeidsgruppa har kun tatt med de underelementene som vi anser som de mest aktuelle. Følgende underelementer fra DCMI er ikke tatt med i anbefalingene: hasformat, isformatof, isreferencedby, isreplacedby, isrequiredby. Ved bruk av disse underelementene bør man følge anbefalingene til DCMI.

ulike ressurser, spesielt når det gjelder de artikkelbaserte avhandlingene, har vi i håndboka istedenfor gitt noen eksempler på hvordan dette kan gjøres. Rettigheter / Access Rights: Under dc.rights registreres informasjon om rettighetshaver mens dc.rights.uri brukes for å henvise til gjeldende lisens for dokumentet. For å imøtekomme kravene fra OpenAIRE, har vi definert en egen underkategori for tilgangsrettigheter: dc.rights.accessrights Populærvitenskapelig sammendrag: Et nytt underelement (dc.description.popularized) er innført for å kunne legge inn popularisert sammendrag i tillegg til et vitenskapelig sammendrag. Det er primært for doktorgradsavhandlinger at det er meldt et behov for denne kvalifikatoren, men den kan selvsagt også brukes for andre dokumenttyper. Et slikt felt bidrar til å styrke formidlingen av doktoravhandlingene og vitenskapen. Fagfellevurdering: Et eget felt er opprettet for fagfellevurdering - dc.type.peerreviewed. Vi foreslår at feltet gjøres obligatorisk for alle ressurser som registeres. Hensikten med dette er at man lettere skal kunne se hva som er fagfellevurdert og hva som ikke er det. Dette betyr samtidig at Fagfellevurdert / Peer reviewed fjernes i listen over dokumenttyper i NORA-standarden, jevnfør http://www.ub.uit.no/wiki/openaccess/images/1/15/dokumenttyper_nora_09.pdf. Bibliografisk sitering: Dette er et av de feltene som arbeidsgruppa har vært aller mest i tvil om. DCMI anbefaler å bruke dc.identifier.bibliographiccitation for bibliografisk sitering mens DRIVER anbefaler bruk av feltene dc.source (for digitalisert materiale) 2 og dc.relation (for digitalt originalmateriale). En stor utfordring med Dublin Core er at standarden legger all siteringsinformasjon i ett enkelt felt, nemlig dc.identifier.bibliographiccitation. Dublin Core har altså ikke støtte for at f.eks. årgang eller sidetall for tidsskriftsartikler registreres i egne felt. Dette er opplagt en klar ulempe med Dublin Core. Arbeidsgruppa har likevel endt opp med å velge å følge DCMIs standard, til tross for at dens svakheter. Vi mener at siteringsinformasjon heller bør defineres i et eget skjema som ligger utenfor Dublin Core. Dublin Core foreslår at dette kan gjøres i et eget metadataskjema ved å registrere som OpenURL ContextObject med Key-encoded values 3. Den bibliografiske referansen kan eventuelt trekkes ut maskinelt fra dette metadataskjemaet slik at dc.identifier.bibliographiccitation genereres automatisk. Vi mener at arkivene bør vurdere å implementere en slik løsning av hensyn til muligheten til å gjenbruke data. Uten egne felt for bibliografisk informasjon, vil det være vanskelig for eksempel å eksportere referanser til referansehåndteringsverktøy som EndNote, Reference Manager og Zotero. 2 Anbefalingen av. dc.source er uklar hos DRIVER siden de samtidig henviser til DCMI sin anbefaling om å bruke dc.identifier.bibliographicalcitation. Se DRIVER Guidelines s. 75 3 Guidelines for Encoding Bibliographic Citation Information in Dublin Core Metadata, http://www.dublincore.org/documents/dc-citation-guidelines/

ISSN-nummer og ISBN-nummer: Arbeidsgruppa anbefaler at ISSN-nummer og ISBN-nummer vanligvis registreres i feltene dc.source.issn og dc.source.isbn. Unntak er når en hel bok/rapport osv. registreres. Da bør dc.identifier.isbn brukes. Begrunnelsen for dette er at ISSN og ISBN-nummer for en artikkel, bokkapittel, konferanseinnlegg osv. ikke er en unik identifikator. Disse bør derfor registreres som kilde i feltet dc.source. For hele bøker/rapporter osv. vil derimot ISBN være en unik identifikator som bør registreres i feltet dc.identifier. OpenAIRE-anbefalingene: Det bør tas høyde for anbefalingene fra OpenAIRE i arkivene, og arbeidsgruppa har derfor innarbeidet OpenAIRE-kravene i utkastet til håndboka. Dette betyr at vi anbefaler å bruke dc.date.embargoenddate og at denne kvalifikatoren erstatter de embargofeltene som brukes av Dspace i dag (dc.embargo.liftdate og dc.embargo.terms). Vi anbefaler også at feltet dc.relation.projectid tas i bruk. Dette feltet er obligatorisk for forskning som er omfattet av OpenAIRE-kravene, dvs utvalgte deler av EUs 7. rammeprogram, og dette skal registreres i henhold til en fastsatt syntaks. Vi mener det med fordel også kan etableres en felles syntaks for registrering av prosjekt-id for prosjekter under Norges Forskningsråd, som omtalt tidligere i dette brev. Mange av dataene som skal brukes av OpenAIRE vil formodentlig komme fra CRIStin. Nøyaktig hvordan integrasjonen mellom arkivene, CRIStin og OpenAIRE skal foregå må avklares. Med vennlig hilsen Ingrid Cutler, UB Bergen Arild Skalmeraas, Høgskolen i Telemark, biblioteket Kristian Seterås, Havforskningsinstituttet, biblioteket Leif Longva, UB Tromsø