Child pages
  • Vocabulaires
Skip to end of metadata
Go to start of metadata

The contents of this page are obsolete. Please refer to Principes.

De sleutelwoorden MOET, MOET NIET, VEREIST, ZAL, ZAL NIET, ZOU, ZOU NIET, AANBEVOLEN, KAN, en OPTIONEEL in deze specificatie dienen geïnterpreteerd te worden volgens IETF RFC 2119.

Algemeen

Principe V1.

 

 

Hiërarchie

Statement:

Vocabulaires buiten veld 9.2 MOETEN NIET hiërarchisch zijn.

Rationale:

 

Implications:

 

Relations:

 

Principe V2.

 

 

Granulariteit

Statement:

Granulariteit MOET meerwaarde bieden.

Rationale:

Bij het definiëren van vocabulaires is het risico groot dat de granulariteit zeer groot wordt gemaakt in een poging een concept in het grootst mogelijke detail te beschrijven zonder dat dit meerwaarde biedt. Dit maakt het gebruik en de beheerbaarheid van dergelijke vocabulaires onnodig complex.

Implications:

  1. Granulariteit kan in een later stadium altijd worden verhoogd.

Relations:

 

Principe V3.

 

 

Registratie

Statement:

Het wordt AANBEVOLEN gebruikte vocabulaires anders dan LOMv1.0 te registereren*.

Rationale:

Vocabulaires bieden pas meerwaarde wanneer de achterliggende semantiek eenduidig te interpreteren is. Voor de beheerbaarheid van een service is het van belang dat de semantiek van vocabulaire stabiel blijft. Registratie dient hierbij een tweeledig doel:

  1. het stelt de service in staat kennis over een vocabulaire op te halen, en
  2. de registratie vervult hierbij een trust functie t.a.v. de stabiliteit.

Implications:

 

Relations:

9, #V8

*) Een vocabulaire is geregistreerd indien het de bij de Vocabulaire Bank van EduStandaard (http://vocabulairebank.edustandaard.nl) een van de statussen "Concept", "Definitief", "Teruggetrokken" heeft.

Systeem-eisen

Principe V5.

 

 

Interoperabiliteit

Statement:

Een systeem MOET LOMv1.0 kunnen interpreteren.

Rationale:

Zie Informatiemodel principe 1.

Implications:

 

Relations:

1

Principe V6.

 

 

Toleratie

Statement:

Een systeem MOET NIET niet stuklopen als er ongeregistreerde vocabulaires worden aangeboden.

Rationale:

Zie Informatiemodel principe 9

Implications:

 

Relations:

9

Principe V7.

 

 

Vrijheid

Statement:

Een systeem KAN in staat zijn ongeregistreerde vocabulaires te intepreteren.

Rationale:

Een systeem moet de vrijheid hebben een eigen publiek te bedienen.

Implications:

 

Relations:

9

Implementatie-eisen

Principe V8.

 

 

Interpreteerbaarheid

Statement:

Voor vocabulaires anders dan LOMv1.0 MOET een VDEX beschikbaar zijn.

Rationale:

Niet alle services hebben kennis van alle vocabulaires. Bovendien zijn is het aannemelijk dat vocabulaires dynamisch zijn. De service moet in staat zijn de kennis over vocabulaires autonoom op te kunnen ophalen.

Implications:

  1. Voor vocabulaires anders dan LOMv1.0 MOET het source-element de URI naar de desbetreffende VDEX bevatten.
  2. Voor vocabulaires anders dan LOMv1.0 MOET de waarde van het value-element overeenkomen met de desbetreffende term in de VDEX.

Relations:

9

VDEX-eisen

Hier moeten nog eisen komen ten aanzien van vocabulaires. Bijvoorbeeld voor de vocabulaire identifiers en de termidentifiers, maak ook ten aanzien van het gebruik van hierarchische structuren en/of relationship definities. Een verwijzing naar de registratie procedure en eisen aan het inhoudelijk en technisch beheer moet deze opsomming van eisen complementeren.

  • No labels

1 Comment

  1. Unknown User (nllomreview)

    Teun de Lange, teun@intraquest.nl

    Het naast elkaar bestaan van verschillende vdexen voor eenzelfde 'purpose' (in de terminiologie van veld 9 waar deze kwaal heerst), beperkt de praktische bruikbaarheid en waarde van zowel de betreffende vdexen als -erger nog - van de metadata die op basis van de vdexen is aangebracht in ernstige mate.

    Een nieuwe vdex moet pas worden gemaakt als er absoluut geen (internationale) voorbeelden van vergelijkbare vdexen zijn. Men kan vervolgens besluiten om de bestaande vdex onveranderd te gebruiken of uit te breiden, waarbij bestaande id's worden overgenomen en nieuwe id's worden toegevoegd conform dezelfde systematiek. Van nul beginnen is vrijwel nooit zinvol.

    Id's en Entry's moeten uniek zijn voor een hele vdex, dat geldt ook voor hiërarchisch opgezette vdexen. Als een eind-node alleen juist interpreteerbaar is, indien een zoeksysteem rekening houdt met de bovenliggende tree, betekent dat een enorme en niet te verantwoorden belasting van het zoekproces.

    Traditionele classificatiesystemen zoals UDC en SISO kunnen zeer goed als bron dienen van id's en omschrijvingen voor meer gespecialiseerde vdexen. Dit komt o.a. de vertaalbaarheid zeer ten goede.

    Goed ingevulde omschrijvingen (Entry's) zijn - naast unieke Id's - zeer belangrijk in een context waarin veel content zonder vdexen is gemetadateerd en dus alleen 'full text' vindbaar is.

    Het zou erg praktisch zijn als van elke vdex het meest recente exemplaar een 'constante' url (zonder datum in de naam) zou hebben (taak EduStandaard). Dan kunnen systemen die van de vdexen gebruik maken automatisch de nieuwste versie kiezen.

    Vdexen zijn er om te voldoen aan de praktische eisen van de gebruikers, niet als een vorm van waarheidsvinding van de makers.