Requirements voor terminologiebronnen

Living Standard,

This version:
https://netwerk-digitaal-erfgoed.github.io/requirements-terminologiebronnen/
Issue Tracking:
GitHub
Inline In Spec
Editor:
(Netwerk Digitaal Erfgoed)

Abstract

Dit document beschrijft de functionele en niet-functionele requirements waar terminologiebronnen aan moeten voldoen om gebruikt te kunnen worden in het Netwerk Digitaal Erfgoed (NDE).

1. Inleiding

Hoe kunnen gebruikers – zoals leerlingen, journalisten of wetenschappers – informatie over schilderijen van Rembrandt vinden, ongeacht de instellingen die deze informatie beheren? Dat lukt alleen als collectiebeheerders van instellingen gebruikmaken van dezelfde termen voor het beschrijven van dezelfde informatie. Bijvoorbeeld: door de term "schilderij" te benutten in plaats van "painting" of "kunstwerk". Of de term "Rembrandt van Rijn" in plaats van "Rembrandt".

Maar hoe weten collectiebeheerders welke termen er zijn? Door gebruik te maken van gemeenschappelijke terminologiebronnen, zoals thesauri of referentielijsten. Deze terminologiebronnen dienen dan wel aan bepaalde voorwaarden te voldoen zodat de termen in deze bronnen eenduidig gevonden en gebruikt kunnen worden.

Dit document beschrijft de voorwaarden in de vorm van functionele en niet-functionele requirements. De requirements hebben tot doel om de bronnen beter bruikbaar te maken voor collectiebeheerders en om de bronnen vindbaar te maken via het Termennetwerk van NDE.

De requirements zijn opgesteld door het project Gestandaardiseerde termen in het netwerk. Het project is onderdeel van het intensiveringsprogramma 2019-2020 van het Netwerk Digitaal Erfgoed. De requirements nemen de Digitaal Erfgoed Referentiearchitectuur 3.0 (DERA) als uitgangspunt. De requirements zijn een verdieping van DERA en kunnen een aanvulling vormen van een toekomstige versie van DERA.

Dit document beschrijft enkel de requirements die specifiek gelden voor bronhouders van terminologiebronnen. Daarnaast zijn er algemene requirements die gelden voor alle bronhouders, ongeacht het soort informatie dat zij aanbieden. Deze requirements worden uitgewerkt in een opzichzelfstaand document voor datasets. De requirements voor terminologiebronnen zijn dus een aanvulling op de requirements voor datasets.

Een begrippenkader opnemen, met begrippen en hun definities. Dit is bij voorkeur een separaat document dat ook gebruikt kan worden door andere documenten, zoals de Requirements voor datasets.

1.1. Doelgroep

Dit document is bestemd voor bronhouders van terminologiebronnen, waaronder hun informatiespecialisten, applicatiebeheerders en ontwikkelaars.

1.2. Status

Dit document is een concept en nog geen officiële publicatie.

2. Prioriteitstelling van requirements

Elke requirement is voorzien van een prioriteit. De prioriteit volgt de MoSCoW-methode:

Prioriteit Toelichting
Must have De requirement is noodzakelijk
Should have De requirement is belangrijk, maar niet noodzakelijk
Could have De requirement is gewenst, maar niet belangrijk
Would have De requirement is interessant, maar nu niet gewenst

3. Requirements

De requirements zijn zowel functioneel als niet-functioneel. Functionele requirements beschrijven de vereiste werking van een terminologiebron. Ze maken duidelijk welke functionaliteit een bron moeten bieden om gebruikt te kunnen worden in het Netwerk Digitaal Erfgoed. Niet-functionele requirements beschrijven hoe een terminologiebron de functionele requirements moet waarmaken, bijvoorbeeld met welke standaarden of technologieën. Deze requirements zijn vooral bedoeld voor de ontwikkelaars die het systeem voor de terminologiebron maken.

3.1. De terminologiebron maakt termen vindbaar via een koppelvlak

Prioriteit: Must have

Termen in een terminologiebron zijn alleen bruikbaar als ze gevonden kunnen worden door een collectiebeheerder. Voor optimale bruikbaarheid moet een collectiebeheerder vanuit haar eigen systeem kunnen zoeken naar termen, zonder daarvoor steeds naar het systeem van de terminologiebron te moeten gaan. Om dit mogelijk te maken dient een terminologiebron een koppelvlak – een endpoint – te bieden. Dit koppelvlak kan geautomatiseerd aangesproken worden door het systeem van de collectiebeheerder.

Het koppelvlak moet van een bepaald type zijn: een SPARQL-endpoint. Zo’n endpoint heeft zowel een krachtige zoektaal – SPARQL – als de snelheid die nodig is om zoekvragen van een collectiebeheerder tijdig te kunnen beantwoorden.

Discussie: Is het zinnig om SPARQL zo nadrukkelijk te eisen? Of zouden we dit moeten openlaten?

Deze requirement vereist niet dat een terminologiebron zelf een koppelvlak moet bieden. Een bronhouder kan ervoor kiezen om het koppelvlak van een ander platform te benutten, bijvoorbeeld van een organisatie met wie de bronhouder samenwerkt. Verder staat het een bronhouder vrij om, naast een SPARQL-endpoint, ook andere soorten endpoints te bieden om termen te vinden. Zoals een endpoint dat gebruikmaakt van Triple Pattern Fragments.

3.2. De terminologiebron maakt termen vindbaar via een voor mensen toegankelijke online zoekomgeving

Prioriteit: Could have

Een collectiebeheerder wil de mogelijkheid hebben om termen in een terminologiebron op te zoeken. Dit stelt haar in staat om een beeld te krijgen van de structuur en samenhang van de bron. Daarom dient de terminologiebron een online zoekomgeving te bieden die door de collectiebeheerder geraadpleegd kan worden. Voorbeelden van zoekomgevingen zijn die van de Cultuurhistorische Thesaurus, ErfGeo en ULAN.

Deze requirement is geen verplichting: niet elke bron heeft de mogelijkheid om een online zoekomgeving aan te bieden. Een bronhouder kan ervoor kiezen om de zoekomgeving van een ander platform te benutten, bijvoorbeeld van een organisatie met wie de bronhouder samenwerkt.

3.3. De terminologiebron publiceert termen met bepaalde metadatastandaarden

Prioriteit: Must have

Het systeem van een collectiebeheerder moet termen in een terminologiebron eenduidig kunnen verwerken. Dit wordt vergemakkelijkt als bronnen dezelfde metadatastandaarden gebruiken voor het publiceren van informatie over dezelfde soort termen, zoals personen, onderwerpen, plaatsen of gebeurtenissen.

Er bestaan verschillende metadatastandaarden die gebruikt kunnen worden, afhankelijk van het doel. Bijvoorbeeld: een standaard als SKOS is geschikt om thesaurustermen te beschrijven. Een standaard als Schema.org is generiek en geschikt om termen globaal te beschrijven. En een standaard als Person Name Vocabulary (PNV) is specifiek en geschikt om persoonsnamen fijnzinnig te beschrijven.

Door de verscheidenheid aan standaarden, soorten termen en toepassingsmogelijkheden is het mogelijk noch wenselijk om bepaalde standaarden voor te schrijven. Wel kunnen bronhouders en collectiebeheerders aangeven welke standaarden voor welke doelen gebruikt kunnen worden. Deze standaarden kunnen dan als aanbevelingen ('best practices') bij deze requirement gevoegd worden.

Discussie: Tabel opnemen met aanbevolen metadatastandaarden?

3.4. De terminologiebron publiceert bepaalde informatie over haar termen

Prioriteit: Must have

Een term in een terminologiebron kan alleen gevonden en begrepen worden door een collectiebeheerder als er ten minste bepaalde informatie over de term gepubliceerd wordt. Welke informatie dat is, is afhankelijk van het type term.

Bijvoorbeeld: bij de informatie over een persoon dient niet alleen diens naam gepubliceerd te worden ("Jan de Vries"), maar ook diens geboortedatum ("12 oktober 1816"). Zonder de geboortedatum is onduidelijk welke Jan de Vries bedoeld wordt. Een ander voorbeeld: bij de informatie over een geografische entiteit dient niet alleen de naam gepubliceerd te worden ("Utrecht"), maar ook de soort ("Gemeente"). Zonder de soort is onduidelijk of de provincie, gemeente of stad bedoeld wordt.

Onderstaande tabel bevat de informatie die idealiter voor elke term gepubliceerd wordt, ongeacht het type van de term:

Soort informatie Betekenis Toelichting
Identifier Een unieke identifier van de term De identifier dient een URI te zijn
Type Het type van de term, zoals een "Persoon", "Onderwerp" of "Plaats" Het type dient afkomstig te zijn uit een metadatastandaard, zoals schema:Person of skos:Concept
Naam De naam van de term Staat ook bekend als "label" of "voorkeurslabel"
Alternatieve naam Een alternatieve benaming van de term, zoals een synoniem Bijvoorbeeld: Rembrandt van Rijn is een alternatieve naam van Rembrandt
Definitie Een definitie of omschrijving van de term
Notitie Aanvullende informatie over de reikwijdte of het gebruik van de term Staat ook bekend als "scope note"
Gerelateerde term Een term die een (niet-hiërarchische) relatie met de term heeft Bijvoorbeeld: de term Theo van Gogh is gerelateerd aan Vincent van Gogh
Bovenliggende term Een term die hiërarchisch direct boven de term ligt Bijvoorbeeld: de term Noord-Brabant is de bovenliggende term van Nuenen
Onderliggende term Een term die hiërarchisch direct onder de term ligt Bijvoorbeeld: de term slagzwaard is een onderliggende term van zwaard

3.5. De terminologiebron publiceert relaties tussen haar termen als er relaties zijn

Prioriteit: Should have

Een terminologiebron kan relaties tussen termen bevatten. Bijvoorbeeld: een terminologiebron over personen kan een relatie hebben tussen Vincent van Gogh en Theo van Gogh. En een terminologiebron over geografische entiteiten kan een relatie hebben tussen Nuenen en Noord-Brabant. Als een terminologiebron relaties heeft, dient de bron deze toegankelijk te maken: de relaties geven context aan termen en helpen een collectiebeheerder om een besluit te nemen over de toepasbaarheid ervan bij het beschrijven van haar informatie.

Het systeem van de collectiebeheerder moet de relaties tussen termen geautomatiseerd kunnen verwerken. Daarom dient een bron de relaties op een machineleesbare manier te publiceren. De wijze waarop een bron dit dient te doen is afhankelijk van de aard van de relaties en van de metadatastandaarden van de bron. Bijvoorbeeld: als een bron SKOS gebruikt, kunnen relaties met eigenschappen als skos:broader, skos:narrower of skos:related gepubliceerd worden. Als een bron Schema.org gebruikt, kunnen relaties met eigenschappen als schema:isPartOf, schema:hasPart of schema:isBasedOn gepubliceerd worden.

Discussie: Een RDF-voorbeeld opnemen om de modellering van de relaties te laten zien?

3.6. De terminologiebron publiceert relaties met termen in andere terminologiebronnen

Prioriteit: Should have

Een term in een terminologiebron kan voorkomen in een andere terminologiebron. Bijvoorbeeld: de term Vincent van Gogh wordt beschreven in zowel RKDartists als Wikidata en de term fiets wordt beschreven in zowel de Cultuurhistorische Thesaurus als DBpedia. Maar hoe kan een collectiebeheerder te weten komen dat de termen over hetzelfde gaan? Dat lukt alleen als een terminologiebron dit aangeeft. Een terminologiebron dient deze relaties dan ook toegankelijk te maken: ze maken duidelijk hoe termen zich tot elkaar verhouden.

Er bestaan verschillende mogelijkheden voor een terminologiebron om naar termen in andere bronnen te verwijzen:

  1. Een terminologiebron verwijst naar zoveel mogelijk andere bronnen. Bijvoorbeeld: een bron verwijst naar zowel de AAT, DBpedia als de Cultuurhistorische Thesaurus. Collectiebeheerders kunnen hierdoor meteen zien hoe termen in de bron zich verhouden tot termen in andere bronnen. Het beheren van relaties met meerdere bronnen vergt evenwel een tijdsinvestering.

  2. Een terminologiebron verwijst alleen naar de bron die meer autoriteit heeft dan de eigen bron. Bijvoorbeeld: een bron verwijst enkel naar de AAT. Dit vergemakkelijkt het beheer voor een bronhouder: zij hoeft alleen de relaties met één andere bron te onderhouden. Maar het betekent ook dat er geen directe relaties tussen bronnen bestaan, enkel indirect via de autoritatieve bron.

  3. Een terminologiebron verwijst alleen naar de bron die de meeste verwijzingen naar termen in andere terminologiebronnen heeft. Bijvoorbeeld: een bron verwijst enkel naar Wikidata. Dit vergemakkelijkt het beheer voor een bronhouder: zij hoeft alleen de relaties met één andere bron te onderhouden. Daarentegen zorgt dit voor een afhankelijkheid van deze bron.

Discussie: Moet deze requirement een voorkeur uitspreken voor een van bovenstaande mogelijkheden?

Het systeem van een collectiebeheerder moet de relaties van termen geautomatiseerd kunnen verwerken. Daarom dient een bron de relaties op een machineleesbare manier te publiceren.

De wijze waarop een bron dit dient te doen is afhankelijk van de aard van de relaties en van de metadatastandaarden van de bron. Bijvoorbeeld: als een bron SKOS gebruikt, kunnen relaties gepubliceerd worden met eigenschappen als skos:exactMatch, skos:closeMatch of skos:broadMatch. Als een bron OWL of RDF Schema gebruikt, kunnen relaties gepubliceerd worden met eigenschappen als owl:sameAs of rdfs:seeAlso.

Discussie: Een RDF-voorbeeld opnemen om de modellering van de relaties te laten zien?

Een bron kan de relaties met termen in andere terminologiebronnen op twee manieren publiceren:

  1. Een terminologiebron publiceert de relaties als onderdeel van de reguliere informatie die de bron aanbiedt bij elke term.

  2. Een terminologiebron publiceert de relaties in een aparte dataset, een linkset. Deze aanpak is waardevol voor bronnen die de relaties met andere bronnen niet kunnen beheren of publiceren als onderdeel van de reguliere informatie van hun termen.

3.7. De terminologiebron publiceert de status van haar termen

Prioriteit: Should have

Een term in een terminologiebron heeft een levenscyclus. Een term wordt bijvoorbeeld eerst voorgesteld, dan goedgekeurd en daarna in gebruik genomen, om na verloop van tijd te komen te vervallen. Een terminologiebron dient door middel van een status duidelijk te maken in welke fase van de levenscyclus een term zich bevindt. Hierdoor kan een collectiebeheerder bepalen of zij de term wel of niet wil gebruiken. De ene collectiebeheerder wil bijvoorbeeld wel een kandidaatterm benutten, de andere collectiebeheerder niet.

Deze requirement doet geen uitspraak over de statussen die een terminologiebron moet ondersteunen: een bron bepaalt zelf hoe de levenscyclus van haar termen eruit ziet en welke statussen daarbij horen. Een bron kan ook besluiten om niet met statussen te werken. In dat geval mag een collectiebeheerder aannemen dat de termen goedgekeurd zijn en zonder voorbehoud gebruikt mogen worden.

Discussie: Is bovenstaande invulling van de requirement correct? Of is het juist wenselijk of nodig dat terminologiebronnen wel statussen gaan gebruiken – misschien zelfs dezelfde statussen? Ter illustratie: het Linked Data Registry van UKGov onderkent 11 statussen.

Het systeem van een collectiebeheerder moet de statussen van termen geautomatiseerd kunnen verwerken, bijvoorbeeld om een kandidaatterm van een goedgekeurde term te kunnen onderscheiden. Daarom dient een bron de statussen op een machineleesbare manier te publiceren.

De metadatastandaard die hiervoor gebruikt moet worden is afhankelijk van de levenscyclus die de bron hanteert voor haar termen. Bijvoorbeeld: een bron met een beperkte levenscyclus heeft behoefte aan een andere standaard om statussen uit te drukken dan een bron met een uitgebreide levenscyclus. Deze requirement schrijft daarom geen standaard voor.

Discussie: Zijn er metadatastandaarden die aanbevolen kunnen worden voor het publiceren van statussen? Bijvoorbeeld: The Publishing Status Ontology (PSO)?

3.8. De terminologiebron blijft verouderde termen publiceren in plaats van ze te verwijderen

Prioriteit: Must have

Een term kan na verloop van tijd wijzigen, zowel syntactisch als semantisch. Maar een term kan op een gegeven moment ook verouderen. Bijvoorbeeld: een term is niet meer accuraat of een term blijkt een doublure te zijn van een term die al in de bron voorkomt.

De verouderde term mag in dat geval echter niet verwijderd worden: een collectiebeheerder kan de term nog in gebruik hebben. In plaats daarvan moet de terminologiebron kenbaar maken dat de term niet meer gebruikt mag worden. Als een term niet meer accuraat is, kan de terminologiebron dit doen door er een specifieke status aan toe te kennen. Als een term een doublure is, kan de terminologiebron dit doen met de HTTP-statuscode 301 Moved Permanently en de locatie waar de gewenste term te vinden is.

3.9. De terminologiebron biedt een manier om nieuwe termen of wijzigingen aan termen voor te stellen

Prioriteit: Should have

Een collectiebeheerder kan ontdekken dat een bepaalde term in een terminologiebron ontbreekt of dat een bestaande term gewijzigd moet worden. Bijvoorbeeld: een bron kan de algemene term zwaard bevatten maar niet de specifiekere term slagzwaard. Of een bron kan de term Maximilliaan van Egmont (met twee "l"-en) bevatten terwijl Maximiliaan van Egmont (met één "l") bedoeld wordt. Daarom dient een terminologiebron een manier te hebben waarmee een collectiebeheerder wijzigingsvoorstellen kan indienen. Deze terugkoppeling verbetert de kwaliteit van de bron.

Deze requirement is geen verplichting: niet elke terminologiebron kan wijzigingsvoorstellen verwerken. Daarnaast geeft deze requirement niet aan hoe een collectiebeheerder wijzigingsvoorstellen moeten kunnen aandragen, bijvoorbeeld via e-mail, een online formulier of een API. Evenmin geeft deze requirement aan hoe het proces van verwerking eruit ziet, bijvoorbeeld het moment of de snelheid van verwerken of de wijze waarop een collectiebeheerder geïnformeerd wordt. Een terminologiebron bepaalt dit zelf.

Discussie: Is bovenstaande invulling van de requirement correct? Of is het juist wenselijk of nodig om tot een gestandaardiseerd proces te komen voor de verwerking van voorstellen van een collectiebeheerder?

Het systeem van een collectiebeheerder moet geautomatiseerd kunnen achterhalen of, en zo ja, hoe een terminologiebron voorstellen voor nieuwe termen of wijzigingen aan termen accepteert. Daarom dient een bron informatie hierover op een machineleesbare manier te publiceren.

Dit stelt het systeem in staat om bij een collectiebeheerder duidelijk te maken welke mogelijkheden een bron biedt en haar, indien gewenst, te begeleiden bij het indienen van voorstellen. Bijvoorbeeld: als een bron wijzigingen aan termen accepteert als die via een bepaald e-mailadres worden aangemeld, dan dient het systeem andere handelingen te verrichten dan als een bron wijzigingen via een API accepteert. In het ene geval moet een collectiebeheerder bijvoorbeeld zelf, handmatig, actie ondernemen, in het andere geval kan het systeem dit geautomatiseerd voor haar doen.

De informatie die een bron moet publiceren is afhankelijk van de mogelijkheden die een bron biedt voor het indienen van voorstellen. Bijvoorbeeld: voor het indienen per e-mail is andere informatie nodig dan voor het indienen via een API. Deze requirement schrijft daarom geen standaard voor.

Discussie Zijn er metadatastandaarden die aanbevolen kunnen worden voor het publiceren van dit soort informatie?

3.10. De terminologiebron publiceert informatie over veranderingen aan termen

Prioriteit: Could have

Termen in een terminologiebron veranderen. Nieuwe termen worden toegevoegd, bestaande termen gewijzigd. Voor collectiebeheerders is het van belang om te weten welke veranderingen zich voordoen. Zo kunnen zij achterhalen of zij aanpassingen moeten doorvoeren in de termen die zij gebruiken.

Bijvoorbeeld: als een collectiebeheerder een term gebruikt die komt te vervallen, dan wil zij dat te weten komen. Of als een collectiebeheerder op dit moment een bepaalde generieke term gebruikt en de terminologiebron voegt een nieuwe, specifiekere term toe die beter past dan de generieke term, dan wil zij daarover geïnformeerd worden. Daarom dient een terminologiebron kenbaar te maken welke veranderingen aan welke termen zich voordoen.

Deze requirement is geen verplichting: niet elke terminologiebron kan veranderingen bijhouden en publiceren. Bovendien geeft deze requirement niet aan hoe een terminologiebron veranderingen moet publiceren, bijvoorbeeld via een nieuwsbrief, mailinglijst, website of API. Evenmin geeft deze requirement aan wanneer een terminologiebron veranderingen moet publiceren, bijvoorbeeld eens per dag, week of maand, of proactief (voordat de veranderingen van toepassing zijn) of reactief (nadat de veranderingen van toepassing zijn). Een terminologiebron bepaalt dit zelf.

Discussie: Is bovenstaande invulling van de requirement correct? Of is het juist wenselijk of nodig om tot een gestandaardiseerde aanpak te komen bij het publiceren van veranderingen?

Het systeem van een collectiebeheerder moet geautomatiseerd kunnen achterhalen of, en zo ja, hoe een terminologiebron veranderingen aan termen publiceert. Daarom dient een bron informatie hierover op een machineleesbare manier te publiceren.

Dit stelt het systeem in staat om bij een collectiebeheerder duidelijk te maken welke mogelijkheden een bron biedt en haar, indien gewenst, te begeleiden om inzage te krijgen in de veranderingen. Bijvoorbeeld: als een bron veranderingen publiceert op een bepaalde webpagina, dient het systeem andere handelingen te verrichten dan als een bron veranderingen publiceert via een API. In het ene geval moet een collectiebeheerder bijvoorbeeld zelf, handmatig, actie ondernemen, in het andere geval kan het systeem dit geautomatiseerd voor haar doen.

De informatie die een bron moet publiceren is afhankelijk van de mogelijkheden die een bron biedt bij het publiceren van veranderingen. Deze requirement schrijft daarom geen standaard voor.

Discussie: Zijn er metadatastandaarden die aanbevolen kunnen worden voor het publiceren van dit soort informatie?

3.11. De terminologiebron publiceert informatie over de assen en onderwerpen van de termen

Prioriteit: Should have

Een collectiebeheerder wil informatie over de assen en onderwerpen van de terminologiebron kunnen opvragen. Informatie over de assen maakt duidelijk of een bron termen bevat die gaan over "wie", "wat", "waar" en/of "wanneer". Informatie over de onderwerpen maakt duidelijk wat de inhoud van een bron is. Op basis hiervan kan een collectiebeheerder een besluit nemen over het al dan niet gebruiken van de bron.

Bijvoorbeeld: de ene collectiebeheerder willen alleen gebruikmaken van een terminologiebron als deze personen ("wie"-as) beschrijft. En een andere collectiebeheerder wil alleen gebruikmaken van een bron als deze termen over het onderwerp "architectuur" of "Tweede Wereldoorlog" bevat.

De onderwerpen per terminologiebron lopen sterk uiteen. Deze requirement kan daarom geen onderwerpen voorschrijven die gebruikt moeten worden: een bron bepaalt dit zelf. Wel dienen de onderwerpen termen uit terminologiebronnen te zijn die voldoen aan de requirements van dit document.

Het systeem van een collectiebeheerder moet geautomatiseerd kunnen achterhalen welke assen een terminologiebron bestrijkt en over welke onderwerpen de bron gaat. Daarom dient een bron informatie hierover op een machineleesbare manier te publiceren. Bijvoorbeeld: als een collectiebeheerder alleen geïnteresseerd is in bronnen die over personen gaan, moet haar systeem dit kunnen herkennen.

Deze requirement is geen verplichting: niet elke terminologiebron is zo opgezet dat eenduidig gedefinieerd kan worden wat de assen en onderwerpen zijn.

Discussie:
  1. Zijn er metadatastandaarden die aanbevolen kunnen worden voor het publiceren van informatie over assen ("wie", "wat", "waar", "wanneer"), inclusief onderverdelingen (bijvoorbeeld voor "wie": deze as omvat "personen" en "corporaties")? Zou DCAT hiervoor gebruikt kunnen worden, met eigenschappen als dct:temporal of dcat:theme?

  2. Kan er een aanbeveling gedaan worden over de wijze waarop een bron haar onderwerpen kan publiceren? Bijvoorbeeld: door SKOS te gebruiken?

  3. Zou het voldoende zijn als een bron via rdfs:Class aangeeft welke typeringen zij hanteert? Dan kan het systeem van een collectiebeheerder daarnaar zoeken via SPARQL.

3.12. De terminologiebron publiceert informatie over de soort bron

Prioriteit: Could have

Een collectiebeheerder moet kunnen achterhalen wat de soort van de terminologiebron is, bijvoorbeeld een thesaurus, classificatiesysteem of trefwoordenlijst.

Het systeem van een collectiebeheerder moet de soort van een terminologiebron geautomatiseerd kunnen verwerken. Daarom dient een bron informatie hierover op een machineleesbare manier te publiceren.

Discussie:
  1. Is deze requirement nog van toepassing? Welk doel c.q. welke use case dient het? In hoeverre wordt deze requirement al gedekt door requirement 3.11?

  2. In hoeverre kan een terminologiebron eenduidig getypeerd worden, bijvoorbeeld als ‘thesaurus’ of ‘trefwoordenlijst’? Of zijn er ook hybride bronnen?

  3. Welke metadatastandaard kan gebruikt worden voor het publiceren van dit soort informatie? Ter illustratie: Asset Description Metadata Schema (ADMS) bevat een eigenschap "asset type" met waarden als "CodeList", "NameAuthorityList" en "Thesaurus".

  4. Deze requirement kan van belang zijn voor het Register en Termennetwerk. Bijvoorbeeld: het Termennetwerk wil alleen bronnen opvragen die van een bepaald type zijn, zoals een thesaurus, maar geen bronnen met "reguliere" informatie over erfgoedobjecten. Is deze requirement daarvoor nuttig? Of zou het Termennetwerk zelf moeten ‘ontdekken’ of bronnen ‘termen’ bevatten?

3.13. De terminologiebron publiceert haar termen volgens ISO-standaard 25964 als de bron een thesaurus is

Prioriteit: Should have

ISO-standaard 25964 beschrijft hoe thesauri gestructureerd moeten worden om termen beter vindbaar te maken. Hoe meer een terminologiebron hieraan voldoet, hoe bruikbaarder de bron is voor collectiebeheerders.

Discussie: In hoeverre is deze requirement een verplichting ("Must have")? Moeten of mogen thesauri zich aan de ISO-standaard conformeren?

3.14. De terminologiebron maakt termen vindbaar door te zoeken met operatoren

Prioriteit: Must have

Een collectiebeheerder weet soms niet welke term ze zoekt. In dat geval wil ze aan een terminologiebron geen precieze zoekvraag stellen (Maximiliaan van Egmont, slagzwaard) maar een ruime zoekvraag. Dit kan met wildcards of jokertekens. Bijvoorbeeld:

  1. De vraag *zwaard zoekt naar alle termen die eindigen op "zwaard" en vindt onder meer "slagzwaard" en "langzwaard".

  2. De vraag slag* zoekt naar alle termen die beginnen met "slag" en vindt onder meer "slagroom" en "slagmetaal".

  3. De vraag *zee* zoekt naar alle termen waarin "zee" voorkomt en vindt onder meer "zuiderzee", "zeeboeken" en "onderzeeboten".

Daarnaast weet een collectiebeheerder soms vrij nauwkeurig welke term ze zoekt. In dat geval wil ze aan een terminologiebron een vrij nauwkeurige zoekvraag stellen. Dit kan met Booleaanse operatoren. Bijvoorbeeld:

  1. De vraag kuitbroek OR kniebroek zoekt naar termen die "kuitbroek" of "kniebroek" zijn, maar niet bijvoorbeeld "klepbroek" of "heupbroek".

  2. De vraag sportbroek AND zwembroek zoekt naar termen die zowel sport- als zwembroek zijn, maar niet een van beide.

  3. De vraag broek NOT pofbroek zoekt naar alle termen die "broek" zijn maar niet "pofbroek".

Het systeem van een collectiebeheerder moet de ondersteunde operatoren geautomatiseerd kunnen verwerken. Op deze manier kan het systeem de beheerder ondersteunen bij het formuleren van zoekvragen. Daarom dient een bron haar zogeheten search capabilities op een machineleesbare manier te publiceren.

Discussie: Zijn er metadatastandaarden die gebruikt kunnen worden voor het publiceren van search capabilities?
Discussie: Deze requirement is nog te grof en moet gedetailleerd of opgesplitst worden. Welke zoekoperatoren moet een terminologiebron ten minste ondersteunen? Bijvoorbeeld: naast wildcards en Booleaanse operatoren zou er ook gezocht kunnen worden op basis van proximity of ranges. Of moet er ondersteuning zijn voor aanhalingstekens ("), om duidelijk te maken dat er naar een precieze reeks woorden gezocht moet worden in plaats van naar afzonderlijke woorden?

3.15. De terminologiebron vult zoekvragen automatisch aan ("auto-completion")

Prioriteit: Should have

Een collectiebeheerder wil zo efficiënt mogelijk zoeken. Daarom wil ze niet eerst een gehele zoekvraag invoeren alvorens te kunnen zoeken. In plaats daarvan wil ze een deel van een zoekvraag opgeven die vervolgens automatisch aangevuld wordt door de terminologiebron. Bijvoorbeeld: de zoekvraag Max wordt aangevuld tot Maximiliaan van Egmont. Vervolgens kan de collectiebeheerder een zoekactie naar de aangevulde zoekvraag starten.

Het kan gebeuren dat een gedeeltelijke zoekvraag van een collectiebeheerder aangevuld kan worden tot meerdere zoekvragen. Bijvoorbeeld: de zoekvraag Max wordt aangevuld tot Maximiliaan van Egmont, Max Lewin en Maximiliaan II Emanuel van Beieren. In dat geval dient de collectiebeheerder eerst de gewenste zoekvraag te selecteren en vervolgens een zoekactie te starten.

Discussie: Is deze requirement wenselijk of nodig? In hoeverre komt requirement 3.14 hieraan tegemoet door ondersteuning te bieden voor wildcards?

3.16. De terminologiebron zoekt termen met een bepaalde status of bovenliggende term

Prioriteit: Should have

Een collectiebeheerder wil termen vinden die zo goed mogelijk voldoen aan haar zoekvraag. Deze zoekvraag bevat een of meer woorden, zoals zwaard of Haarlem. Maar om te voorkomen dat een collectiebeheerder te veel resultaten terugkrijgt, wil zij haar zoekvraag voorzien van aanvullende criteria om de resultaten te beperken:

  1. Met criterium ‘status’ kan een collectiebeheerder aangeven dat zij alleen termen met deze status wil vinden (zie requirement 3.7). Bijvoorbeeld alleen goedgekeurde termen (en geen kandidaattermen of verouderde termen).

  2. Met criterium ‘bovenliggende term’ kan een collectiebeheerder aangeven dat zij alleen termen met deze bovenliggende term wil vinden. Bijvoorbeeld alleen plaatsen die tot Nederland behoren (en niet tot Zuid-Afrika ("Haarlem") of de Verenigde Staten ("New Haarlem")).

Discussie: Deze requirement is waarschijnlijk nog te grof en moet gedetailleerd of opgesplitst worden. Bijvoorbeeld: moet een collectiebeheerder – naast status en bovenliggende term – ook andere criteria kunnen opgeven? Of zou deze requirement opgesplitst moeten worden in twee requirements, een voor ‘status’ en een voor ‘bovenliggende term’?

3.17. De terminologiebron sorteert gevonden termen op relevantie

Prioriteit: Must have

Een collectiebeheerder wil termen vinden die zo goed mogelijk voldoen aan haar zoekvraag. Daarom sorteert de terminologiebron de gevonden termen op basis van relevantie: de termen die de zoekvraag waarschijnlijk het beste beantwoorden worden als eerste teruggegeven.

Deze requirement bepaalt niet wat ‘relevantie’ precies is – dat is afhankelijk van de terminologiebron, de aard van haar termen en de zoekvragen van een collectiebeheerder. Evenmin schrijft deze requirement voor hoe een terminologiebron dient te zorgen voor de sortering. Een bron kan bijvoorbeeld termen standaard sorteren op relevantie, zonder dat het systeem van een collectiebeheerder hiervoor iets hoeft te doen, maar een bron kan er ook voor kiezen om het systeem van de collectiebeheerder expliciet te laten aangeven dat termen op relevantie gesorteerd moeten worden (zoals met een ORDER BY-statement in een SPARQL-query).

Een terminologiebron mag naast relevantie ook andere mogelijkheden bieden voor het sorteren van termen, bijvoorbeeld alfabetisch op basis van hun naam. Dit is evenwel geen verplichting: het systeem van een collectiebeheerder kan deze sortering ook zelf verzorgen.

3.18. De terminologiebron publiceert beeldmateriaal van haar termen

Prioriteit: Could have

Een collectiebeheerder wil zo snel mogelijk kunnen vaststellen of de door de terminologiebron gevonden termen voldoen aan haar zoekvraag. Het helpt een collectiebeheerder als een bron niet alleen tekstuele informatie per term teruggeeft, maar ook visuele informatie, zoals een afbeelding. Visuele informatie stelt een collectiebeheerder in staat om te kunnen zien of een term relevant is. Bijvoorbeeld: het onderscheid tussen een "wipmolen" en een "weidemolen" hoeft op basis van een beschrijving niet meteen helder te zijn, maar met foto’s van beide wel.

Deze requirement is geen verplichting: niet elke terminologiebron kan beeldmateriaal van haar termen publiceren. Verder doet deze requirement geen uitspraak over de aard of kwaliteit van het beeldmateriaal, bijvoorbeeld het formaat (zoals JPG of Ogg) of de grootte. Evenmin geeft deze requirement aan of een terminologiebron het beeldmateriaal zelf moet aanbieden of kan verwijzen naar materiaal van anderen. Een terminologiebron bepaalt dit zelf.

Discussie: Moet deze requirement een advies geven of uitspraak doen over de metadatastandaard die gebruikt moet worden voor het publiceren van (de link naar) beeldmateriaal, zoals met edm:isShownBy, foaf:depiction of schema:image?
Discussie: Een RDF-voorbeeld opnemen om te laten zien hoe er naar beeldmateriaal verwezen kan worden?

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

References

Normative References

[NDE-DATASETS]
David de Boer; Netwerk Digitaal Erfgoed. Requirements for Datasets. URL: https://netwerk-digitaal-erfgoed.github.io/requirements-datasets/
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

Issues Index

Een begrippenkader opnemen, met begrippen en hun definities. Dit is bij voorkeur een separaat document dat ook gebruikt kan worden door andere documenten, zoals de Requirements voor datasets.