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. |
Principe 1. |
|
---|---|
|
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: |
|
Principe 2. |
|
---|---|
|
Consistentie van semantiek. |
Statement: |
Gebruik LOM velden zoveel mogelijk waarvoor ze zijn bedoeld. |
Rationale: |
Dit verhoogt de (inter)nationale interoperabiliteit. |
Implications: |
|
Principe 3. |
|
---|---|
|
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: |
|
Principe 4. |
|
---|---|
|
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: |
|
Principe 5. |
|
---|---|
|
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: |
|
Principe 6. |
|
---|---|
|
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: |
|
Principe 7. |
|
---|---|
|
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: |
|
Principe 8. |
|
---|---|
|
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: |
|
Principe 9. |
|
---|---|
|
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: |
|
Principe 10. |
|
---|---|
|
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: |
|