Edurep:Metadata verwerking

Deze pagina tracht inzicht te geven in wat er met de metadata van aanbieders gebeurt in Edurep.

Validatie

Elk record wordt gevalideerd op conformiteit met de LOM xsd. Invalide records worden geweigerd in het harvestproces.

Automatische wijzigingen

Omwille van de kwaliteit van de metadata vult Edurep een aantal velden van de metadata indien deze niet zijn ingevuld door de aanbieder. Het gaat om:

• kosten: Edurep vult cost=yes in wanneer het /lom/rights/cost niet aanwezig is.
• uitgever: Edurep vult de repository_id in als publisher wanneer de aanbieder geen publisher meegeeft.

Ten behoeve van de optimale vindbaarheid van records tijdens de migratie naar het Begrippenkader, worden termen van "oude" vocabulaires gemapt naar termen uit het Begrippenkader en vica versa.

De terugmapping (van Begrippenkader termen naar "oude" vocabulairetermen) vindt plaats naar de nieuwste vocabulaires die voor een bepaald type beschikbaar waren. Bijvoorbeeld, de Begrippenkader "havo_3" wordt alleen teruggemapt naar vdex_classification_educationallevel_czp_20071115.xml en niet naar vdex_classification_educationallevel_czp_20060628.xml terwijl deze andersom wel wordt gemapt.

XSLT

Een deel van de automatische wijzigingen op de metadata vinden plaats in de Edurep broncode, een ander deel (met name de collectie-specifieke wijzigingen) door middel van zogenaamde XSLT's. Ten behoeve van de transparantie zijn deze XSLT's van elke collectie te bekijken op GitHub.

Doorlooptijd

De doorlooptijd van het verwerken van metadata in Edurep is de tijd tussen het inschieten SMO's of het ophalen van LOM bij de aanbieder en de beschikbaarheid in Edurep Search. Deze doorlooptijd is near-realtime en in de praktijk nauwelijks merkbaar. De primaire doelstelling van Edurep is de beschikbaarheid van het zoeken naar LOM/SMO's en het inschieten van SMO's. De doorlooptijd zal zoveel mogelijk worden geminimaliseerd.

vCard

Een VCARD in een centity wordt door Edurep gescand om te kunnen zoeken op "author" of "publisher". De geïndexeerde waarden zijn vervolgens ook beschikbaar in het "extra" x-recordSchema. Van de mogelijke variabelen in een vCard worden N, FN en ORG gebruikt als mogelijke waarden. Het eerste veld in een vCard wat voldoet aan deze variabelen wordt gebruikt. Een vCard moet voldoen aan versie 3.0. Hierbij zijn de FN, N en VERSION verplicht en niet leeg.

Deadlink Checker

De Deadlink Checker controleert of een LOM record een geldige en werkende URL bevat in het veld lom.technical.location. Een record kan één van de volgende statussen krijgen:

• OK: Het resultaat van de URL in lom.technical.location is een 2.x.x of 3.x.x HTTP status code
• NTL: Het LOM record bevat geen lom.technical.location (No Technical Location)
• FAILED: Het resultaat van de URL in lom.technical.location is een 4.x.x of een 5.x.x HTTP status code.
• UNCHECKED: Het is een nieuw of aangepast record die nog nooit door Edurep gechecked is.

Het resultaat van deze check is dat records met status FAILED niet in het antwoord op een zoekvraag worden teruggegeven.

De Deadlink Checker verstuurt de URL in de eerste waarde uit het veld lom.technical.location als een request. Op dit request zit een timeout van 5 minuten. Als de server binnen die tijd het request niet volledig beantwoord heeft wordt deze gemarkeerd als “FAILED”. Dit gebeurt dus ook als de data niet binnen 5 minuten gedownload kan worden. De status "FAILED" kan dus de volgende oorzaken hebben:

• De URL komt uit op een 2.x.x of 3.x.x
• De URL is niet conform de correcte notatie (niet urlencoded).
• De server is niet bereikbaar
• De data van het leerobject kan niet binnen 5 minuten worden gedownload, bijv. in geval van een film-bestand.

Ongeveer één keer in de week worden alle records met de status “OK” of de status “UNCHECKED” gecontroleerd. De records met de status “FAILED” worden elke dag gecontroleerd. Als de status gewijzigd is dan wordt dit in Edurep verwerkt.

NB: Het kan toch nog voorkomen dat sommige leerobjecten niet als een dead link worden aangemerkt doordat de URL uitkomt op een "landingspagina" die zich meldt als een OK ipv FAILED. Deze situaties zijn lastig te herkennen.

SMO Tag Volgorde

Na het inschieten van een SMO kan de volgorde van tags verschillen met de volgorde van de tags in het origineel. Wanneer bijvoorbeeld de tags "Eerste Wereldwereldoorlog" eerst bestonden kan dat na een indexering "Wereldoorlog Eerste" zijn. In een zoekapplicatie zou men bij het zoeken naar tags niet een exacte volgorde van tags moeten implementeren maar één waarbij een OR of AND operator wordt toegepast.