Algemeen onderliggend principe

Statement:

Wijk zo weinig mogelijk af van het IEEE LOM informatiemodel.

Rationale:

Om interoperabiliteit met communities buiten het Nederlands onderwijs te waarborgen moet zo min mogelijk van de standaard worden afgeweken.

Implicaties:

1. Semantiek van velden wordt niet veranderd.
2. Er wordt zo min mogelijk afgeweken van de standaard datatypen.

Consistentie van semantiek.

Statement:

Gebruik LOM velden zoveel mogelijk waarvoor ze zijn bedoeld.

Rationale:

Dit verhoogt de (inter)nationale interoperabiliteit.

Implicaties:

1. lom/general/identifier/entry ZOU NIET gebruikt moeten worden om naar de fysieke locatie van bijvoorbeeld een preview of het leerobject zelf te verwijzen (zie veld 1.1.2 identificatiecode).
2. lom/general/identifier/catalog MOET de zelfde definitie hebben als IEEE LOM (zie veld 1.1.1 Schemanaam) in afwijking van de LORElom definitie voor dit veld.

Verplichte velden.

Statement:

Het gebruik van verplichte velden is VEREIST.

Rationale:

Het is voor diensten en gebruikers van belang een minimale set aan metadata te kunnen verwachten. Gebruik van dergelijke velden is daarom VEREIST.

Implicaties:

1. Records met ontbrekende verplichte velden voldoen niet aan de afspraak.
2. Implementaties MOETEN het gebruik van verplichte velden afdwingen.

Aanbevolen velden.

Statement:

Het gebruik van aanbevolen velden wordt AANBEVOLEN.

Rationale:

Bepaalde velden leveren grote meerwaarde wanneer zij betekenisvol worden ingevuld. Het gebruik van dit soort velden is in beginsel zeer gewenst. In sommige vallen is het echter niet mogelijk een zinvolle invulling te geven aan een veld. Het VEREISEN van dergelijke velden leidt in dat geval tot het niet voldoen aan de afspraken wanneer het niet wordt ingevuld of vervuiling wanneer het veld niet zinvol wordt gebruikt. Gebruik van dergelijke velden wordt daarom AANBEVOLEN, maar is niet VEREIST.

Implicaties:

1. Records met ontbrekende aanbevolen velden voldoen wel aan de afspraak.
2. Implementaties ZOUDEN zoveel mogelijk het gebruik van aanbevolen velden moeten afdwingen.

Business Rules.

Statement:

Het gebruik van velden waarvoor een business rule geldt kan naar gelang de context VEREIST of AANBEVOLEN zijn.

Rationale:

In een aantal gevallen is het niet zinvol het gebruik van bepaalde velden VEREIST te stellen terwijl in andere gevallen juist het tegenovergestelde geldt. In deze gevallen wordt de logica waarbinnen het gebruik VEREIST of AANBEVOLEN is vastgelegd in een business rule. Het gebruik van veld A is hierdoor afhankelijk van de waarde van veld B. Business rules MOETEN NIET conflicteren met elkaar of andere afspraken. Condities voor een business rule MOETEN NIET afhankelijk zijn van de waarde in meer dan één veld.

Implicaties:

1. Records die niet voldoen aan de Business Rules voldoen niet aan de afspraak.
2. Implementaties MOETEN het voldoen aan de business rules afdwingen.

Afgeraden velden.

Statement:

Afgeraden velden ZOUDEN NIET gebruikt moeten worden.

Rationale:

Het gebruik van bepaalde velden, zoals extensies, is zo specifiek dat te verwachten valt dat het meerendeel van de services deze velden niet of nauwelijks kunnen betekenisvol kunnen interpreteren. Omdat hierin vastgelegde informatie in de meeste gevallen verloren gaat wordt het gebruik van deze velden daarom afgeraden en gaat de voorkeur uit deze informatie op andere wijze vast te leggen.

Implicaties:

1. Extensies ZOUDEN NIET gebruikt moeten worden.
2. Implementaties MOETEN NIET stuklopen op de aanwezigheid van extensies.

Optionele velden.

Statement:

Het gebruik van alle overige velden is OPTIONEEL.

Rationale:

Rijke metadata vergroot de vindbaarheid van hiermee geassocieerde objecten. Het gebruik van vrijwel alle velden is daarom tenminste OPTIONEEL.

Implicaties:

1. Implementaties MOETEN NIET stuklopen op de aanwezigheid van optionele velden.

Leeg == Ontbrekend

Statement:

Empty elements MOETEN als ontbrekend worden beschouwd.

Rationale:

Velden zonder waarde zijn niet betekenisvol. Daarom MOET een dienst deze velden negeren en effectief als ontbrekend beschouwen.

Implicaties:

1. Records met verplichte velden die aanwezig zijn, maar geen (juiste) waarde bevatten voldoen niet aan de afspraak.

Tolerantie

Statement:

Een service ZOU binnen redelijke grenzen zo tolerant mogelijk moeten zijn naar aanbieders die niet geheel conformeren aan de NL LOM afspraken.

Rationale:

Het is waarschijnlijk dat er records aan services aangeboden zullen worden niet geheel voldoen aan de NL LOM afspraak, bijvoorbeeld omdat zij zijn opgebouwd volgens oude afspraken of afspraken uit een andere community implementeren die slechts minimaal van NL LOM afwijken. Tegelijkertijd is er voor gebruikers (zowel aanbieders als afnemers) niets frusterender dan het niet kunnen vinden van een data omdat er minimaal wordt afgeweken van de norm. Daarom ZOU een service zelf maatregelen moeten nemen om zoveel mogelijk content vindbaar te maken, ook als deze ten dele afwijkt van de NL LOM afspraak.

Implicaties:

1. Bij ontbrekende verplichte velden ZOU de service een eigen intepratie moeten hebben.
2. Bij ontbrekende verplichte velden is KAN de service het betreffende record afwijzen.

Conflicten

Statement:

Conflicten in het gebruik van velden MOETEN altijd in de volgorde VEREIST, AANBEVOLEN, OPTIONEEL worden opgelost.

Rationale:

Het is denkbaar dat in de evolutie van de afspraak er (tijdelijke) onvolkomenheden zullen ontstaan, bijvoorbeeld wanneer de ene business rule het gebruik van een veld verplicht stelt en de andere het gebruik aanbevolen. Om toch te zorgen dat de afspraak werkbaar blijft, wordt de volgende conflict resolution strategie gehanteerd: VEREIST gaat voor AANBEVOLEN gaat voor OPTIONEEL.

Implicaties:

1. Wanneer business rule 1 het gebruik van een veld x VEREIST en business rule 2 het gebruik van veld x AANBEVEELT, is het gebruik van veld x VEREIST.

Hiërarchie

Statement:

Vocabulaires buiten veld 9.2 MOETEN NIET hiërarchisch zijn.

Rationale:

Hiërarchie wordt door de standaard niet ondersteund in velden anders dan veld 9. Hier hiërachie introduceren betekent een aavullende gelaagdheid over de standaard leggen waardoor compatibiliteit in het geding komt.

Implicaties:

1. Wanneer hiërarchie voor velden buiten veld 9 gewenst is, dient aanvullend veld 9 te worden gebruikt.

Relaties:

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.

Implicaties:

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

Relaties:

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.

Implicaties:

Relaties:

9, #V8

Interoperabiliteit

Statement:

Een systeem MOET LOMv1.0 kunnen interpreteren.

Rationale:

Zie Informatiemodel principe 1.

Implicaties:

1. Alle systemen moeten kennis hebben van het IEEE-LOM schema en hierin gedefinieerde vocabulaires.

Relaties:

1

Toleratie

Statement:

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

Rationale:

Zie Informatiemodel principe 9

Implicaties:

1. Alle systemen moeten om kunnen gaan met de loose binding van IEEE-LOM. # Systemen mogen ongeregistreerde vocabulaires negeren.

Relaties:

9

Vrijheid

Statement:

Een systeem KAN in staat zijn ongeregistreerde vocabulaires te intepreteren.

Rationale:

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

Implicaties:

1. Systemen mogen eigen community specifieke vocabulaires gebruiken. # Systemen mogen ongeregistreerde vocabulaires negeren.

Relaties:

9

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.

Implicaties:

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.

Relaties:

9