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.

Implications:

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.

Implications:

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.

Implications:

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.

Implications:

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.

Implications:

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.

Implications:

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.

Implications:

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.

Implications:

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 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.

Implications:

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 resulution strategie gehanteerd: VEREIST gaat voor AANBEVOLEN gaat voor OPTIONEEL.

Implications:

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.