April 2007 Versie 0.6
Motto:
Cool URI's don't change
What makes a cool URI?
A cool URI is one which does not change. What sorts of URI change?
URIs don't change: people change them.
(c)1998 Tim Berners-Lee
http://www.w3.org/Provider/Style/URI.html
[Literatuur|#Literatuur]
[Bijlage 1 Begrippen|#Bijlage1]
[Bijlage 2. Voorstel voor gefaseerde implementatie URN:NBN in DARE-verband|#Bijlage2]\\
\\
\\
\| Status versie 0.6: besproken en goedgekeurd in de vergadering van de Repository Managers
\\
d.d. 5 april 2007, DARE, SURF, Utrecht.
\\
Wijzigingen:
\\
1. In het schema: "Huidige Identifiers voor "information assets"" (pg 5) zijn wijzigingen
\\
opgenomen voor de Technische Universiteit Eindhoven en de Rijks Universiteit Groningen.
\\
2. Op pg 7 is een betere verwijzing opgenomen naar: Hans-Werner Hilse and Jochen Kothe, Implementing Persistent Identifiers \[Hilse/Kothe, 2006\].
\\
3. Op de kaft is het DARE-logo opgenomen \|
\\
\\
*Werkgroep*
De werkgroep _persistente identifi{_}ers was als volgt samengesteld:
Niels Rozenboom, Universiteit Leiden
Maarten Hoogerwerf, DANS
Peter Ruijgrok, Universiteit Utrecht Laurens Sesink, DANS
Hubert Krekels, Wageningen Universiteit Maurice Vanderfeesten, DARE
Marlon Domingus, Universiteit Leiden (vz)
\\
\\
\\ |
Momenteel is er binnen de Nederlandse instellingen die participeren in DARE geen uniforme manier voor de implementatie van persistente identifiers van de metadata records binnen de afzonderlijke institutionele repositoria. Gerelateerd aan metadatarecords wordt persistentie van identifiers hier bedoeld in de betekenis van zowel 'naming' als 'resolving'.
Resolving van de digitale objecten (bitstreams), gekoppeld aan deze metadata, gebeurt
vooralsnog in het geheel niet op een wijze die persistent is. Hoewel binnen het oai-pmh-
protocol alleen de eis geldt dat een verwijzing naar een metadata-record persistent is, wordt in dit rapport ook de persistentie
Er zijn verschillende redenen waarom het voor de hand ligt om zeker op een nationale schaal, maar beter nog om op een internationale schaal uniformiteit na te streven op het gebied van persistentie van identifiers. Beheer(s)baarheid is een belangrijk argument bij de betrokken instellingen vanuit hun rol als (oai)data-provider, maar ook vanuit hun rol als (oai)service-provider. Vanuit DARE is er het belang om naar robuustheid te streven van de IR-gerelateerde nationale infrastructuur. Tenslotte is het voor de eindgebruiker wenselijk om te kunnen vertrouwen op de robuustheid en betrouwbaarheid van DARE-diensten met als zwakste schakel juist de naming en resolving van resources binnen de DARE-services en data.
Met persistente identificatie in DARE-verband wordt technische gezien feitelijk bedoeld:
identificatie van resources (zowel metadata en bitstreams) op een persistente, (server)locatie-onafhankelijke manier (lees: urn-implementatie, geen url-implementatie). Om dit te implementeren is naast techniek een model nodig. NBN is hiervoor een voor de hand liggende kandidaat.
In dit rapport wordt een voorstel gedaan voor een identifier van het type: URN:NBN:
URN:NBN:landcode:identificerende_string
Het heeft als voordeel op het DOI-alternatief dat het gebaseerd is op standaarden en niet op
een concrete toepassing van een leverancier. De werkgroep beschout de URN:NBN-oplossing als de meest toekomstvaste en generieke oplossing. De werkgroep verkeert tevens in de veronderstelling dat alle betrokken partijen met een minimum aan implementatie-inspanning de vruchten kunnen dragen van deze oplossing. Hierbij vervullen de Koninklijke Bibliotheek en DANS mogelijk een cruciale rol, respectievelijk als NBN-registry/agency en ontwikkelaar nationale URN:NBN-resolver
Tevens stelt de werkgroep een gefaseerde implementatie voor, zoals nader toegelicht in Bijlage 2.
Tenslotte beveelt de werkgroep aan om na een nationale oplossing samen met Duistland en eventuele andere landen te kijken naar de mogelijkheid van een global URN:NBN-resolver.
M. Domingus
Momenteel is er binnen de Nederlandse instellingen die participeren in DARE geen uniforme manier voor de implementatie van persistente identifiers van de metadata records binnen de afzonderlijke institutionele repositoria. Gerelateerd aan metadatarecords wordt persistentie van identifiers hier bedoeld in de betekenis van zowel 'naming' als 'resolving'. (Zie voor de definities van de in dit rapport gebruikte begrippen in Bijlage 1:. Begrippen.)
Resolving van de digitale objecten (bitstreams), gekoppeld aan deze metadata, gebeurt
vooralsnog in het geheel niet op een wijze die persistent is. Hoewel binnen het oai-pmh-
protocol alleen de eis geldt dat een verwijzing naar een metadata-record persistent is, wordt in dit rapport ook de persistentie
Er zijn verschillende redenen waarom het voor de hand ligt om zeker op een nationale schaal, maar beter nog om op een internationale schaal uniformiteit na te streven op het gebied van persistentie van identifiers. Beheer(s)baarheid is een belangrijk argument bij de betrokken instellingen vanuit hun rol als (oai)data-provider, maar ook vanuit hun rol als (oai)service-provider. Vanuit DARE is er het belang om naar robuustheid te streven van de IR-gerelateerde nationale infrastructuur. Tenslotte is het voor de eindgebruiker wenselijk om te kunnen vertrouwen op de robuustheid en betrouwbaarheid van DARE-diensten met als zwakste schakel juist de naming en resolving van resources binnen de DARE-services en data.
Vanuit DARE zijn de volgende doelstellingen geformuleerd (Maurice Vanderfeesten, Identifier Impact van huidige situatie. November 2006.) die gerealiseerd zouden moeten worden met een persistent identifier nieuwe stijl:
Voor wat dit laatste punt betreft zie ook: *What is wrong with URLs?* \[§ 1.3 Hilse/Kothe, 2006\] |
So what is wrong with the currently used URL-approach? We already mentioned that from a user's point of view links appear to be 'broken'. This is mostly due to one of the following:
(a) the document is no longer available, or the document is available, but was
(b) relocated so that it is now accessible using a different domain name,
(c) relocated on the same Internet server so that it is now accessible with an other file system path or query specification.
Tevens is door DARE een inventarisatie gemaakt van de huidige stand van zaken van implementaties van identifiers (ibidem):
Huidige Identifiers voor "information assets"
Instelling |
Systeem |
Type identifier |
Toelichting |
|---|---|---|---|
Amsterdam University Press |
ARNO |
db volgnummers + persitentie |
ARNO's kunnen elk |
Erasmus Universiteit Rotterdam |
Dspace |
Handle |
|
Fontys Hogescholen |
ARNO |
db volgnummers + persitentie |
ARNO's kunnen elk |
KNAW |
i-Tor |
db volgnummers |
|
NWO |
i-Tor |
URLs zijn "Cool URIs". Ze |
|
Open Universiteit Nederland |
Dspace |
Handle |
|
Radboud Universiteit Nijmegen |
Dspace |
Handle |
|
Rijks Universiteit Groningen |
Wildfire |
intern PNN en DBI |
|
Technische Universiteit Delft |
CMS+OAI-PMHtoolkit |
In Delft gebruiken ze in de OAI- |
|
Technische Universiteit Eindhoven |
Eigen ontwikkeling op basis van het Vubissysteem |
Vubis recordnummer. |
|
Universiteit Leiden |
Dspace |
Handle |
|
Universiteit Maastricht |
ARNO |
URL die in identifier zit, direct naar de file danwel jump off page in de repository wijst in plaats van naar een tussenliggende resolver. |
|
Universiteit Twente |
ARNO |
db volgnummers + persitentie afspraken (niet resolvable) |
ARNO's kunnen elk bepalen welke URL ze gebruiken. Wel kun je bij elke ARNO aan de URL zien wat van wat voor type het is (jop/obj) |
Universiteit Utrecht |
Dspace |
Handle |
|
Universiteit van Amsterdam |
ARNO |
een systeem met stabiele |
|
Universiteit van Tilburg |
ARNO |
db volgnummers + persitentie afspraken (niet resolvable) |
ARNO's kunnen elk bepalen welke URL ze gebruiken. Wel kun je bij elke ARNO aan de URL zien wat van wat voor type het is |
Vrije Universiteit Amsterdam |
Dspace |
Handle |
|
Wageningen Universiteit & ResearchCentrum |
CMS+OAI-PMHtoolkit |
oai:domein:repository/db |
|
Voor de wenselijke oplossing van een te implementeren identifier zijn er een aantal typen (technische) randvoorwaarden: vanuit het OAI-PMH 2.0 protocol, de oplossing dient een W3C-standaard te zijn nu en in ieder geval in de voorzienbare toekomst en er zijn een aantal functionele randvoorwaarden waar vanuit de in DARE participerende instellingen op zal moeten worden geanticipeerd en worden hieronder door de werkgroep voorgesteld. Hieronder volgt een opsomming van de eisen en randvoorwaarden.
Vanuit het OAI-PMH 2.0 protocol gelden 2 eisen voor de identifier:
1. A unique identifier unambigiously identifies an item within a repository; the unique identifier is used in OAI-PMH requests for extracting metadata from the item.
2. The format of the unique identifier must correspond to that of the URI (Uniform Resource Identifier) syntax.
All URNs have the following syntax (phrases enclosed in quotes are REQUIRED):
<URN> ::= "urn:" <NID> ":" <NSS>
where <NID> is the Namespace Identifier, and <NSS> is the Namespace Specific String. The leading "urn:" sequence is case-insensitive.
1. Er dient een unieke identifier te zijn voor elke metadata-record dan wel een jump off page. Deze identifier dient zowel te identificeren als toegang te verschaffen tot de resource (in dit geval zijnde de metadata)
2. Er dient per bitstream een unieke identifier te zijn. Deze identifier dient zowel te identificeren als toegang te verschaffen tot de resource (in dit geval zijnde de bitstream)
3. De unieke identifier heeft een syntax die verhuizingen van de resource (zowel metadata als bitstream(s)) toestaat zonder dat een verhuizing om redenen van identificatie of resolving een wijziging van de syntax van de identifier vereist.
4. de resolving van de identifier, dus het toegang verlenen tot de betreffende resource (zowel metadata als bitstream(s)) dient op generieke wijze te geschieden.
5. Om na verhuizing van een combinatie van metadata-record en bijbehorende
bitstream(s) de resolving goed te laten plaatsvinden is er een resolver buiten de
specifieke in DARE participerende partijen vereist, die de rol van nationale resolver vervult voor DARE-doeleinden. Zie ook een schematische voorstelling van deze situatie hieronder.
\\ Technische gezien komen eigenlijk alleen twee oplossingen in aanmerking voor het beschreven probleem en de bijbehorende randvoorwaarden: URN en DOI/Handle. Hieronder wordt geschetst hoe deze oplossingen zouden kunnen werken en wat de sterke / zwakke punten zijn van de oplossing.(Zie voor een zeer uitgebreid en volledig overzicht van verschillende benaderingen van implementatie van persistente identifiers ook: Hans-Werner Hilse and Jochen Kothe, Implementing Persistent Identifiers \[Hilse/Kothe, 2006\].) |
Een digital object identifier (doi), zoals veelal gebruikt door uitgevers om een specifieke publicatie te identificeren, is in feite een implementatie van een handle. Een handle is een wereldwijde url-based implementatie van een secure name resolution. Het Handle Systeem kent een prefix toe aan een partij die handles mag toekennen aan (in de regel) metadata en zorgt voor een wereldwijde resolving van die url in handle -syntax naar de (server)locatie die door de betreffende handle-toewijzer is
De syntax van een handle is: <Handle> ::= <Handle Prefix> "/"<Handle Suffix> Voorbeeld:
"10.1045/april2006-paskin" is an identifier (also known as a Digital Object Identifier (DOI), an
implementation of the Handle System) for an article published in D-Lib Magazine. It is defined under
the prefix (naming authority) "10.1045", and its suffix (local name) is "april2006-paskin". Bron: http://www.handle.net/overviews/handle-syntax.htmlhttp://www.handle.net/overviews/handle-syntax.html
Voor meer informatie zie ook Bijlage 1: "Begrippen".
Hieronder is een visualisatie van de beschreven opties bij gebruik van het DOI/Handle systeem.
Deze optie gaat uit van een Third party Registration Agency, zoals CrossRef. Het voordeel is dat met een dergelijke RA al het werk uit handen wordt genomen. CrossRef zorgt namelijk dat je op eenvoudige wijze een persistent-identifier aan je wetenschappelijke content kunt koppelen. Crossref kan worden gezien als een betrouwbare en ervaren organisatie die DOI's registreren. Verder biedt deze organisatie services, zoals het gebruik van OpenURL, reference linking en biedt het een doorzoekbare metadata database. Het nadeel is dat we er ook naar betalen. RA's zijn vrij om hun eigen prijs te bepalen. RA's betalen op hun beurt een paar cent per DOI naam aan de IDF. CrossRef rekent voor local hosting $20.000, plus jaarlijks $0.06 - $1.00 per DOI.
Wil een repository zich aansluiten bij CrossRef dan zijn een van de eisen van CrossReff dat de repository de eigenaar is van het artikel. Dit is vaak niet het geval met Open Access, bij uitgevers vaak juist wel. Verder gaat CrossReff uit van uit van full-text werken en niet van datasets, video's, audio bestanden etc.. Het is overigens de vraag of CrossRef zal toestaan dat Voor DSpace gebruikers is het overigens relatief eenvoudig handles om te zetten naar DOI door een DOI-prefix / DSpace-prefix / DSpace-suffix. http://hdl.handle.net/1887/4550 wordt bijvoorbeeld http://dx.doi.org/10.1575/1887/4550.
Deze optie heeft voordelen: er is een bestaande technische infrastructuur en er is een
organisatie die de relevante diensten kan beheren en als toekennende instantie kan
functioneren. Vraag is echter of alle gewenste resources (zowel metadata als digitale objecten)
een doi toegekend zullen kunnen krijgen en wat de mate van verwarring bij de eindgebruiker is als aan hetzelfde digitale object meerdere doi's worden toegekend (bijvoorbeeld een vanwege een uitgever en een andere vanwege een repositorium).
Een ander alternatief is een urn-implementatie. De werkelijke uitdaging zou zijn de urn, die
reeds goede diensten heeft bewezen als identifier sec, ook resolvable te maken. In Duitsland is daar reeds enige tijd goede ervaring mee en is er op nationale schaal zelfs al een urn- implementatie in productie. Zie bijvoorbeeld:
Een repositorium in Kassel: https://kobra.bibliothek.uni-kassel.de/https://kobra.bibliothek.uni-kassel.de/ Kent een identifier toe aan een publicatie, bijvoorbeeld:
urn:nbn:de:hebis:34-2007032817560
dat op nationale schaal wordt geresolved door de Deutsche Nationalbibliothek via:
http://nbn-resolving.de/resolverdemo-eng.php/http://nbn-resolving.de/ResolverDemo-eng.php
Het voorbeeld levert of een url:
Of het document in het repositorium in Kassel.
Binnen de Duitse URN-implementatie is er tevens gebruik gemaakt van het National
Bibliography Number (NBN). NBN is geen internetstandaard, maar een manier om unieke en persistente identifiers te gebruiken zoals toe te kennen door nationale bibliotheken. Zie ook: http://www.rfc-archive.org/getrfc.php?rfc=3188/http://www.rfc-archive.org/getrfc.php?rfc=3188 Voor de syntax van NBN is in 2001 voorgesteld:
Declaration of syntactic structure:
The namespace specific string will consist of three parts: prefix, consisting of either a two-letter ISO 3166 country code or other registered string and sub-namespace codes, delimiting characters (colon (
, or hyphen 
, and NBN string assigned by the national library.
NBN is een toepassing binnen het URN-framework. De combinatie van URN en NBN
inclusief een urn-resolver biedt dus een goede oplossing voor een DARE identifier, zoals
omschreven. Voorwaarden hierbij zouden zijn dat de implementatie van een urn-resolver bij een betrouwbare partner wordt ondergebracht en dat de Koninklijke Bibliotheek als NBNtoekenner kan en wil functioneren.
Data Archiving and Networked Services \[DANS - [http://www.dans.knaw.nl/nl/]<span style="color: #0000ff"><a href="http://www.dans.knaw.nl/nl/">http://www.dans.knaw.nl/nl/</a></span> \]heeft aangegeven om onder bepaalde voor de hand liggende condities de ontwikkeling van een nationale URN-resolver voor zijn rekening te willen nemen. Ook het beheer van deze nationale resolver zou een taak van DANS kunnen worden. |
De Koninklijke Bibliotheek zou binnen Nederland de rol van NBN-registrant / toekenner kunnen vervullen. De toekenning van NBN's door de KB zou voorts met de individuele instellingen \[in DARE participerende instellingen\] moeten worden gerealiseerd en met de te ontwikkelen nationale URN:NBN-resolver. De KB zou hiermee een belangrijke innovatie faciliteren op het gebied van identificatie en resolving van Nederlandse resources. |
Voor een schematisch overzicht van een URN:NBN-oplossing op nationale schaal en zelfs wereldwijde schaal zie:
Door middel van een apart MetadataPrefix kan via OAI informatie over identifiers (bijv. urn, locatie en status) worden geharvest. Voordelen van deze methode zijn:
-het OAI-protocol is bij de verchillende repositories reeds geimplementeerd
-het is reeds toegepast door de duitse nationale bibliotheek
-het combineert het gemak van decentraal beheer / verantwoordelijkheid met centrale informatie. Een snelle greep uit de voordelen:
Op dit moment bestaat er geen Global URN resolutie mechanisme. Wel ziet IANA \[Internet Assigned Numbers Authority - [http://www.iana.org/]<span style="color: #0000ff"><a href="http://www.iana.org/">http://www.iana.org/</a></span>\] wereldwijd toe op het toekennen van URN namespaces 'for Public Identifiers' - zie: [<span style="color: #0000ff">www.iana.org/assignments/urn-namespaces</span>|http://www.iana.org/assignments/urn-namespaces/] \[NBN is bij IANA geregistreerd als een van deze public identifiers\]. |
Voorstel: gebruik als generieke identifier de urn met gebruikmaking van NBN met bijvoorbeeld de syntax
URN:NBN:landcode:identificerende_string
Deze oplossing voldoet nl. aan alle randvoorwaarden zoals gedefinieerd (toelichting vereist inzake toepassing NBN) en is niet gebonden aan een specifieke implementatie van een leverancier (DOI/Handle), maar is gebaseerd op algemene standaarden.
Nadere opmerkingen mbt de syntax van een urn (Met dank aan Lucas van Schaik voor nuttige ideeën en adviezen op dit punt.)
Het ligt voor de hand de implementatie van een URN:NBN te faseren. Zie voor een voorstel daartoe Bijlage 2. In essentie zou je eerst URN:NBN willen implementeren voor de metadata en pas daarna voor bitstreams. Vervolgens zou je ook de implementatie van URN:NBN voor metadata kunnen faseren door eerst de toekenning en presentatie van deze identifiers te realiseren en pas daarna de volledige resolving functionaliteit.pg 11 / 24
Conclusie
NBN:URN voldoet aan alle voorwaarden die aan de te ontwikkelen DARE-identifier zijn
gesteld. Er is reeds ervaring met een URN:NBN-oplossing op nationale schaal, voor zover het metadata betreft. Met de juiste partijen zouden ook de bitstreams kunnen worden geïdentificeerd en geresolved met de URN:NBN-identifier.
Met persistente identificatie in DARE-verband wordt technische gezien feitelijk bedoeld:
identificatie van resources (zowel metadata en bitstreams) op een persistente, (server)locatie-onafhankelijke manier (lees: urn-implementatie, geen url-implementatie). Om dit te implementeren is naast techniek een model nodig. NBN is hiervoor een voor de hand liggende kandidaat.
In dit rapport wordt een voorstel gedaan voor een identifier van het type: URN:NBN. Het heeft als voordeel op het DOI-alternatief dat het gebaseerd is op standaarden en niet op een concrete toepassing van een leverancier. De werkgroep beschout de URN:NBN-oplossing als de meest toekomstvaste en generieke oplossing. De werkgroep verkeert tevens in de veronderstelling dat alle betrokken partijen met een minimum aan implementatie-inspanning de vruchten kunnen dragen van deze oplossing. Hierbij vervullen de Koninklijke Bibliotheek en DANS mogelijk een cruciale rol, respectievelijk als NBN-registry/agency en ontwikkelaar nationale URN:NBN-resolver
Tevens stelt de werkgroep een gefaseerde implementatie voor, zoals nader toegelicht in Bijlage 2.
Tenslotte beveelt de werkgroep aan om na een nationale oplossing samen met Duistland en eventuele andere landen te kijken naar de mogelijkheid van een global URN:NBN-resolver.
\[Hakala, 2003\] Hakala, Juha, (NBN), _Identification of Electronic Resources_, 2003, [http://metadata-wg.mannlib.cornell.edu/forum/2003-01-29/juhahakala.ppt/]<span style="color: #0000ff"><a href="http://metadata-wg.mannlib.cornell.edu/forum/2003-01-29/juhahakala.ppt">http://metadata-wg.mannlib.cornell.edu/forum/2003-01-29/juhahakala.ppt</a></span>\\ \\ \[Hoogerwerf, 2006\] Hoogerwerf, Maarten, _Persistent Identification and linking of Datasets_. Student Thesis, 2006 |
\\ \[Paskin, 2006\] Paskin, Norman, (DOI) _Naming And Meaning: Key To The Management Of Intellectual Property In Digital Media_, 2006, 0609079IPDM |
\[Weibel, 2006\] Weibel, Stuart, (OCLC), [http://weibel-lines.typepad.com/]<span style="color: #0000ff"><a href="http://weibel-lines.typepad.com/">http://weibel-lines.typepad.com/</a></span> And various e-mail and telephone contact. |
\[Hilse/Kothe, 2006\] Hans-Werner Hilse and Jochen Kothe, _Implementing Persistent Identifiers_\\ Published by Consortium of European Research Libraries, London, [<span style="color: #0000ff">www.cerl.org</span>|http://www.cerl.org/] European Commission on Preservation and Access, Amsterdam, [<span style="color: #0000ff">www.knaw.nl/ecpa</span>|http://www.knaw.nl/ecpa/] November 2006. ISBN 90-6984-508-3 Available as PDF at [<span style="color: #0000ff">www.cerl.org</span>|http://www.cerl.org/] and [<span style="color: #0000ff">www.knaw.nl/ecpa</span>|http://www.knaw.nl/ecpa/] Identifier urn:nbn:de:gbv:7-isbn-90-6984-508-3-8 (resolving service [http://nbn-resolving.de/]<span style="color: #0000ff"><a href="http://nbn-resolving.de">http://nbn-resolving.de</a></span> ) ([http://nbn-resolving.de/urn:nbn:de:gbv:7-isbn-90-6984-508-3-8/]<span style="color: #0000ff"><a href="http://nbn-resolving.de/urn:nbn:de:gbv:7-isbn-90-6984-508-3-8">http://nbn-resolving.de/urn:nbn:de:gbv:7-isbn-90-6984-508-3-8</a></span> ) \\ |
\[OAIPMH 2.0\] _The Open Archives Initiative Protocol for Metadata Harvesting. Protocol_ Version 2.0 of 2002-06-14. Document Version 2004/10/12T15:31:00Z [http://www.openarchives.org/oai/2.0/openarchivesprotocol.htm]<span style="color: #0000ff"><a href="http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm">http://www.openarchives.org/OAI/2.0/openarchivesprotocol.htm</a></span> |
Tim Berners-Lee, Roy T. Fielding, Larry Masinter. (January 2005). "Uniform Resource Identifier (URI): Generic Syntax". Internet Society. RFC 3986; STD 66. http://gbiv.com/protocols/uri/rfc/rfc3986.htmlhttp://gbiv.com/protocols/uri/rfc/rfc3986.html
\\ \\ *Harvester* \[OAIPMH-definitie\] \\ A harvester is a client application that issues OAI-PMH requests. A harvester is operated by a service provider as a means of collecting metadata from <span style="color: #0000ff">repositories</span>. \\ Zie: OAI-PMH 2.0: [http://www.openarchives.org/oai/openarchivesprotocol.html#definitionsconcepts/]<span style="color: #0000ff"><a href="http://www.openarchives.org/OAI/openarchivesprotocol.html#DefinitionsConcepts">http://www.openarchives.org/OAI/openarchivesprotocol.html#DefinitionsConcepts</a></span>\\ \\ *Repository* \[OAIPMH-definitie\] \\ A repository is a network accessible server that can process the 6 OAI-PMH requests in the manner described in this document. A repository is managed by a data provider to expose metadata to <span style="color: #0000ff">harvesters</span>. To allow various repository configurations, the OAI-PMH distinguishes between three distinct entities related to the metadata made accessible by the OAI-PMH. \\ \*resource - A resource is the object or "stuff" that metadata is "about". The nature of a resource, whether it is physical or digital, or whether it is stored in the repository or is a constituent of another database, is outside the scope of the OAI-PMH. \*item - An <span style="color: #0000ff">item</span> is a constituent of a repository from which metadata about a resource can be disseminated. That metadata may be disseminated on-the-fly from the associated resource, cross-walked from some canonical form, actually stored in the repository, etc. \*record - A <span style="color: #0000ff">record</span> is metadata in a specific <span style="color: #0000ff">metadata format</span>. A record is returned as an XML-encoded byte stream in response to a protocol request to disseminate a specific metadata format from a constituent item. \\ Zie: OAI-PMH 2.0: [http://www.openarchives.org/oai/openarchivesprotocol.html#definitionsconcepts/]<span style="color: #0000ff"><a href="http://www.openarchives.org/OAI/openarchivesprotocol.html#DefinitionsConcepts">http://www.openarchives.org/OAI/openarchivesprotocol.html#DefinitionsConcepts</a></span>\\ *Item* \[OAIPMH-definitie\] \\ An item is a constituent of a repository from which metadata about a resource can be disseminated. An item is conceptually a container that stores or dynamically generates metadata about a single resource in multiple formats, each of which can be harvested as <span style="color: #0000ff">records</span> via the OAI-PMH. Each item has an <span style="color: #0000ff">identifier</span> that is unique within the scope of the repository of which it is a constituent. \\ Zie: OAI-PMH 2.0: [http://www.openarchives.org/oai/openarchivesprotocol.html#definitionsconcepts/]<span style="color: #0000ff"><a href="http://www.openarchives.org/OAI/openarchivesprotocol.html#DefinitionsConcepts">http://www.openarchives.org/OAI/openarchivesprotocol.html#DefinitionsConcepts</a></span>\\ \\ \\ *Unique Identifier* \[OAIPMH-definitie\] \\ A unique identifier unambigiously identifies an item within a repository; the unique identifier is used in OAI-PMH requests for extracting metadata from the item. Items \\ \\ \\ \\ \\ \\ may contain metadata in <span style="color: #0000ff">multiple formats</span>. The unique identifier maps to the item, and all possible <span style="color: #0000ff">records</span> available from a single item share the same unique identifier. The format of the unique identifier must correspond to that of the <span style="color: #0000ff">URI (Uniform Resource</span> <span style="color: #0000ff">Identifier)</span> syntax. Individual communities may develop community-specific <span style="color: #0000ff">URI</span> schemes for coordinated use across repositories. The scheme component of the unique identifiers must not correspond to that of a recognized URI scheme unless the identifiers conform to that scheme. Repositories may implement the <span style="color: #0000ff">oai-identifier</span> syntax described in the accompanying <span style="color: #0000ff">Implementation Guidelines</span> document. \\ Unique identifiers play two roles in the protocol: \\ 1. Response: Identifiers are returned by both the <span style="color: #0000ff">ListIdentifiers</span> and <span style="color: #0000ff">ListRecords</span> requests. 2. Request: An identifier, in combination with a <span style="color: #0000ff">metadataPrefix</span>, is used in the <span style="color: #0000ff">GetRecord</span> request as a means of requesting a <span style="color: #0000ff">record</span> in a specific metadata format from an item. Note that the identifier described here is not that of a resource. The nature of a resource identifier is outside the scope of the OAI-PMH. To facilitate access to the resource associated with harvested metadata, repositories should use an element in metadata records to establish a linkage between the record (and the identifier of its item) and the identifier (URL, URN, DOI, etc.) of the associated resource. The mandatory Dublin Core format provides the identifier element that should be used for this purpose. \\ Zie: OAI-PMH 2.0: [http://www.openarchives.org/oai/openarchivesprotocol.html#definitionsconcepts/]<span style="color: #0000ff"><a href="http://www.openarchives.org/OAI/openarchivesprotocol.html#DefinitionsConcepts">http://www.openarchives.org/OAI/openarchivesprotocol.html#DefinitionsConcepts</a></span>\\ \\ \\ *Record* \[OAIPMH-definitie\] \\ A record is metadata expressed in a single format. A record is returned in an XML\- encoded byte stream in response to an OAI-PMH request for metadata from an item. A record is identified unambigiously by the combination of the <span style="color: #0000ff">unique identifier</span> of the item from which the record is available, the metadataPrefix identifying the metadata format of the record, and the <span style="color: #0000ff">datestamp</span> of the record. The XML-encoding of records is organized into the following parts: \*_header_ \- contains the unique identifier of the item and properties necessary for selective harvesting. The header consists of the following parts: o the <span style="color: #0000ff">unique identifier</span> \- the unique identifier of an item in a repository; o the <span style="color: #0000ff">datestamp</span> \- the date of creation, modification or deletion of the record for the purpose of <span style="color: #0000ff">selective harvesting</span>. o zero or more <span style="color: #0000ff">setSpec</span> elements - the <span style="color: #0000ff">set</span> membership of the item for the purpose of <span style="color: #0000ff">selective harvesting</span>. o an optional status attribute with a value of deleted indicates the withdrawal of availability of the specified metadata format for the item, dependent on the repository support for <span style="color: #0000ff">deletions</span>. \*_metadata_ \- a single manifestation of the metadata from an item. The OAI-PMH supports items with multiple manifestations (formats) of metadata. At a minimum, repositories must be able to return records with metadata expressed in the <span style="color: #0000ff">Dublin Core</span> format, without any <span style="color: #0000ff">qualification</span>. Optionally, a repository may also disseminate other formats of metadata. The specific metadata format of the record to be disseminated is specified by means of an argument - the <span style="color: #0000ff">metadataPrefix</span> \- in the <span style="color: #0000ff">GetRecord</span> or <span style="color: #0000ff">ListRecords</span> request that produces the record. The <span style="color: #0000ff">ListMetadataFormats</span> request returns the list of all metadata formats available from a repository, or for a specific item (which can be specified as an argument to the <span style="color: #0000ff">ListMetadataFormats</span> request). \*_about_ \- an optional and repeatable container to hold data about the metadata part of the record. The contents of an about container must conform to an XML Schema. Individual implementation communities may create XML Schema that define specific uses for the contents of about containers. Two common uses of about containers are: o \_rights statements+: some repositories may find it desirable to attach terms of use to the metadata they make available through the OAI-PMH. No specific set of XML tags for rights expression is defined by OAI-PMH, but the about container is provided to allow for encapsulating community-defined rights tags. o _provenance statements_: One suggested use of the about container is to indicate the provenance of a metadata record, e.g. whether it has been harvested itself and if so from which repository, and when. An XML Schema for such a provenance container, as well as some supporting information is available from the accompanying <span style="color: #0000ff">Implementation Guidelines</span> document. \\ \\ \\ Zie: OAI-PMH 2.0: [http://www.openarchives.org/oai/openarchivesprotocol.html#definitionsconcepts/]<span style="color: #0000ff"><a href="http://www.openarchives.org/OAI/openarchivesprotocol.html#DefinitionsConcepts">http://www.openarchives.org/OAI/openarchivesprotocol.html#DefinitionsConcepts</a></span>\\ \\ \\ *Persistent* \[OAIPMH-definitie\] The repository maintains information about deletions with no time limit. A repository that indicates this level of support must persistently keep track of the full history of deletions and consistently reveal the status of a deleted record over time. \\ *Identifier* \[W3C-definitie\] An identifier embodies the information required to distinguish what is being identified from all other things within its scope of identification. Our use of the terms "identify" and "identifying" refer to this purpose of distinguishing one resource from all other resources, regardless of how that purpose is accomplished (e.g., by name, address, or context). These terms should not be mistaken as an assumption that an identifier defines or embodies the identity of what is referenced, though that may be the case for some identifiers. Nor should it be assumed that a system using URIs will access the resource identified: in many cases, URIs are used to denote resources without any intention that they be accessed. Likewise, the "one" resource identified might not be singular in nature (e.g., a resource might be a named set or a mapping that varies over time). \\ Zie: Tim Berners-Lee, Roy T. Fielding, Larry Masinter. (January 2005). "Uniform Resource Identifier (URI): Generic Syntax". Internet Society. RFC 3986; STD 66. [http://gbiv.com/protocols/uri/rfc/rfc3986.html]<span style="color: #0000ff"><a href="http://gbiv.com/protocols/uri/rfc/rfc3986.html">http://gbiv.com/protocols/uri/rfc/rfc3986.html</a></span> |
*Resource* \[W3C-definitie\] \\ This specification does not limit the scope of what might be a resource; rather, the term "resource" is used in a general sense for whatever might be identified by a URI. Familiar examples include an electronic document, an image, a source of information with a consistent purpose (e.g., "today's weather report for Los Angeles"), a service (e.g., an HTTP-to-SMS gateway), and a collection of other resources. A resource is not necessarily accessible via the Internet; e.g., human beings, corporations, and bound books in a library can also be resources. Likewise, abstract concepts can be resources, such as the operators and operands of a mathematical equation, the types of a relationship (e.g., "parent" or "employee"), or numeric values (e.g., zero,one, and infinity). \\ Zie: Tim Berners-Lee, Roy T. Fielding, Larry Masinter. (January 2005). "Uniform Resource Identifier (URI): Generic Syntax". Internet Society. RFC 3986; STD 66. [http://gbiv.com/protocols/uri/rfc/rfc3986.html]<span style="color: #0000ff"><a href="http://gbiv.com/protocols/uri/rfc/rfc3986.html">http://gbiv.com/protocols/uri/rfc/rfc3986.html</a></span>\\ \\ *URL* \[W3C-definitie\] The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location"). Zie: Tim Berners-Lee, Roy T. Fielding, Larry Masinter. (January 2005). "Uniform Resource Identifier (URI): Generic Syntax". Internet Society. RFC 3986; STD 66. [http://gbiv.com/protocols/uri/rfc/rfc3986.html]<span style="color: #0000ff"><a href="http://gbiv.com/protocols/uri/rfc/rfc3986.html">http://gbiv.com/protocols/uri/rfc/rfc3986.html</a></span>\\ *URI* \[W3C-definitie\] A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. The following are two example URIs and their component parts: \\ foo://example.com:8042/over/there?name=ferret#nose \_/______\____\__\__/_____\__\__/ \_\__\____\__/ __/ |
scheme authoritypathquery fragment
_____________________ |
__ |
*URN* \[W3C-definitie\] \\ Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document sets forward the canonical syntax for URNs. A discussion of both existing legacy and new namespaces and requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. \\ All URNs have the following syntax (phrases enclosed in quotes are REQUIRED): |
<URN> ::= "urn:" <NID> ":" <NSS>
where <NID> is the Namespace Identifier, and <NSS> is the Namespace Specific String. The leading "urn:" sequence is case-insensitive. \\ Moats, R., URN Syntax. RFC 2141, May 1997. [http://www.ietf.org/rfc/rfc2141.txt/]<span style="color: #0000ff"><a href="http://www.ietf.org/rfc/rfc2141.txt">http://www.ietf.org/rfc/rfc2141.txt</a></span>\\ \\ *NBN* \[W3C-definitie\] \\ National Bibliography Number (NBN) is a generic name referring to a group of identifier systems utilised by the national libraries and only by them for identification of deposited publications which lack an identifier, or to descriptive metadata (cataloguing) that describes the resources. In many countries legal (or voluntary) deposit is being extended to electronic publications. \\ \\ J. Hakala, Using National Bibliography Numbers as Uniform Resource Names. RFC: 3188. October 2001. [http://www.ietf.org/rfc/rfc3188.txt/]<span style="color: #0000ff"><a href="http://www.ietf.org/rfc/rfc3188.txt">http://www.ietf.org/rfc/rfc3188.txt</a></span>\\ |
*Handle / Handle System®* \[IDF-definitie\] \\ The <span style="color: #0000ff">resolution</span> component of the <span style="color: #0000ff">DOI System</span>. A general-purpose distributed information \\ system designed to provide an efficient, extensible, and secured global name service for use on networks such as the Internet. The Handle System includes an open set of protocols, a namespace, and a reference implementation of the protocols. The DOI System is one implementation of the Handle System; hence a DOI name is a <span style="color: #0000ff">handle</span>. The Handle System if made up of <span style="color: #0000ff">local handle services</span>. |
*Identifier* \[IDF-definitie\] \\ (1) An unambiguous string or "label" that references an entity (e.g. ISBN 0-19-853737-9). \\ (2) A numbering scheme: a formal standard, an industry convention, or an arbitrary internal system providing a consistent syntax for generating individual labels or identifiers (1) denoting and distinguishing separate members of a class of entities (e.g. ISBN, or DOI® Syntax NISO Z39.84). \\ (3) An infrastructure specification: a syntax by which any identifier (1) can be expressed in a form suitable for use with a specific infrastructure, without necessarily specifying a working mechanism (e.g. URI). \\ (4) A system for implementing labels (identifiers (1)) through a numbering scheme \\ (identifiers (2)) in an infrastructure using a specification (identifiers (3)) and management policies (e.g., <span style="color: #0000ff">DOI System</span>). \\ Zie: [http://www.doi.org/handbook_2000/glossary.html#hs/]<span style="color: #0000ff"><a href="http://www.doi.org/handbook_2000/glossary.html#hs">http://www.doi.org/handbook_2000/glossary.html#hs</a></span>\\ |
The Handle System is only one component of the DOI System
The Handle System provides a general-purpose global name service enabling secure name resolution over the internet, designed to enable a broad set of communities to use the technology to identify digital content independent of location. The DOI System utilises the Handle System as one component in building an added value application, for the persistent, semantically interoperable, identification of intellectual property entities.
One component of the DOI System is the Handle System, and its implementation in the DOI System has been supplemented by expanded technical infrastructure and features specific to DOI System applications. \\ \\ Zie: [http://www.doi.org/factsheets/doihandle.html]<span style="color: #0000ff"><a href="http://www.doi.org/factsheets/DOIHandle.html">http://www.doi.org/factsheets/DOIHandle.html</a></span>\\ \\ *DOI* \[IDF-definitie\] \\ A DOI name - a digital identifier for any object of intellectual property. A DOI name provides a means of persistently identifying a piece of intellectual property on a digital network and associating it with related current data in a structured extensible way. \\ Zie: [http://www.doi.org/faq.html#1/]<span style="color: #0000ff"><a href="http://www.doi.org/faq.html#1">http://www.doi.org/faq.html#1</a></span>\\ |
DOI: URI implementation
The Uniform Resource Identifier (URI) specification is IETF RFC 2396, URI Generic Syntax, currently under revision as RFC 2396 bis. URIs formally encompass URNs as a sub set. In practice, the URI specification defines (1) an implementation more often called the Uniform Resource Locator, a location on a file server, commonly accessed using the http protocol though other protocols are allowed; (2) a syntax for referencing in XML, through which e.g. ISBNs can be specified as URIs. This provides a single framework which can accommodate any other identifier for referencing, but it is not as such persistent (since persistence is not determined by the specification but by the practical implementation). Conflating these two causes confusion. URLs, as currently understood, are demonstrably not persistent; redefining them as URIs doesn't fix that.
DOI: URN implementation
The URN (Uniform Resource Name) specification is RFC 2141 URN Syntax. In practice, the URN specification defines (1) a formal registration process as a urn namespace, e.g., urn:doi:10.1000/1 and (2) accompanying specifications to implement a series of functional requirements for such namespaces.
Peter Ruijgrok
Basis Functionaliteit (realisatie uiterlijk 1.1.2008)
A. We moeten overeenstemming krijgen over de URN.
Verantwoordelijk: Werkgroep DOI in samenspraak met Willie Wortel en KANO
Alhoewel de werkgroep URN's van het formaat 'NBN' voorstelt, moet het mogelijk zijn om persistente identifiers te ondersteunen van andere formaten omdat de repositories andersoortige Persistente Identifiers kunnen bevatten, bijvoorbeeld na een verhuizing van objecten naar een repository toe.
Gevolg is dat, in theorie, een Universiteit volledig kan kiezen voor een DOI of een Handle-systeem maar toch past binnen de gekozen oplossing. Dit omdat een DOI, Handle of ander systeem gerepresenteerd kan worden in een URN en daarmee nog steeds centraal geresolved kan worden.
Theoretisch is daarmee de noodzaak weg om 'allemaal tegelijk' over te schakelen naar de URN's van het formaat NBN. Binnen grenzen kan een universiteit zijn eigen tijdschema bepalen om over te schakelen op URN/NBN .
B. Er moet een centrale resolver worden ontwikkeld. Verantwoordelijk: DANS |