Edurep:Voorbeeld Implementatie Aanbieder/en
 Nederlands
|
 English
|
This example describes a fictitious provider, “Uitgeverij Kubus”, and what their connection to Edurep should look like.
Introduction
Publisher Kubus has made a number of learning materials available via their website. A number of web editors keep this information up to date via the internal Content management system. The metadata of the learning materials is thus stored in a database. After a conversation with the Edurep team, the publisher decided to make their metadata accessible via Edurep.
Roadmap
The project leader has decided to follow Edurep's stappenplan plan for the connection.
Identifiers
First of all, identifiers must be exported. Consultation with the technical people reveal that each learning material in the internal database is given a static unique identifier (it never changes). Because this identifier is also used for access via the website, URL links are also suitable as object identifiers (bijv. http://uitgeverijkubus.nl/materialen/?id=1).
Export to NL-LOM or schema.org
The next step is to output the metadata in the NL-LOM format. Upon further investigation it appears that the internal database contains the following data per field:
| id | title | description | keywords | date of publication | subject |
|---|---|---|---|---|---|
| 1 | optellen onder de 10 | Les en toets voor optellen onder de 10 | optellen, rekenen | 2013-12-09 | rekenen |
| 2 | bomen tekenen | Les basis boom tekenen. | boom, natuur, tekenen | 2013-11-08 | tekenen |
Fortunately, most of this information turns out to be easy to map to an NL-LOM or schema.org output format. For example for learning material 1:
NL LOM
<lom xsi:schemaLocation="http://www.imsglobal.org/xsd/imsmd_v1p2 http://www.imsglobal.org/xsd/imsmd_v1p2p4.xsd">
<general>
<title>
<langstring xml:lang="nl">optellen onder de 10</langstring>
</title>
<catalogentry>
<catalog>URI</catalog>
<entry>
<langstring xml:lang="x-none">http://www.uitgeverijkubus.nl/materialen/?id=1</langstring>
</entry>
</catalogentry>
<description>
<langstring xml:lang="nl">Les en toets voor optellen onder de 10</langstring>
</description>
<keyword>
<langstring xml:lang="nl">optellen</langstring>
</keyword>
<keyword>
<langstring xml:lang="nl">rekenen</langstring>
</keyword>
</general>
<lifecycle>
<contribute>
<role>
<source>
<langstring xml:lang="x-none">http://purl.edustandaard.nl/vdex_lifecycle_contribute_role_lomv1p0_20060628.xml</langstring>
</source>
<value>
<langstring xml:lang="x-none">publisher</langstring>
</value>
</role>
<date>
<datetime>2013-12-09</datetime>
</date>
</contribute>
</lifecycle>
<technical>
<location>http://www.uitgeverijkubus.nl/materialen/?id=1</location>
</technical>
</lom>
Schema.org
{
"@context": {
"schema": "https://schema.org/"
},
"schema:datePublished": "2013-12-09",
"schema:description": {
"@language": "nl",
"@value": "Les en toets voor optellen onder de 10"
},
"schema:identifier": "http://www.uitgeverijkubus.nl/materialen/?id=1",
"schema:keywords": [
{
"@language": "nl",
"@value": "optellen"
},
{
"@language": "nl",
"@value": "rekenen"
}
],
"schema:name": {
"@language": "nl",
"@value": "optellen onder de 10"
},
"schema:url": "http://www.uitgeverijkubus.nl/materialen/?id=1"
}
Static fields
However, it turns out that for optimal findability and visibility, additional information is needed. Fortunately, it also appears that most information can be entered as constants.
- aggregation level: Since all output material is a lesson, this will be "3".
- language: All lessons are made in Dutch, so "nl".
- costs: The material is not free, so this becomes "yes".
- rights: The material is not free of rights so this will be "yes".
- rights description: The rights belong to the publisher, so something like "Copyright Uitgeverij Kubus".
- publisher: Also known as "Uitgeverij Kubus".
- type of teaching material: The lessons contain open assignments and tests, i.e "open opdracht" and "evaluatie- en toetsmateriaal".
- context: The sector in question is primary school, i.e. "PO".
- age group: This can be defined quite broadly for the target group: 4-8
- end user: The learning material is intended for students (even if a teacher has to buy it), so "learner".
- formaat: Since the learning material is on internet pages, the mime type is "text/html".
Subject
Finally, this field must also be specified. In Edurep, OnderwijsBegrippenKader is used as a coding system for subject areas and learning levels. This means that all subject areas in the internal database must be mapped with the corresponding value in the OBK. When the values are looked up, it results in the following mapping table:
| Subject kubus | obk id | obk label |
|---|---|---|
| rekenen | b48fa351-4561-44c7-a071-ebfd6103eec3 | Rekenen |
| tekenen | 5cb7f440-c370-4056-b30d-f57130cccede | Tekenen |
The final result can be seen in the following NL-LOM or schema.org record.
Export to Edurep
The NL-LOM records are exported using OAI-PMH. This protocol synchronizes all new learning materials that are added to the database with Edurep. To do this effectively, each material requires a last modified date, and fortunately it is available.
First time harvesting
To initially fill in Edurep, the Edurep harvester makes the following request to the OAI provider of Uitgeverij Kubus:
http://www.uitgeverijkubus.nl/oaiprovider?verb=ListRecords&metadataPrefix=lom
This actually retrieves all records in order of last modification. Optimally, not all records are returned at the same time, but rather spread over multiple pages, with the provider being allowed to determine how many records are returned per page. To keep server load within limits, the publisher's technical department recommends returning 100 records at a time. The SQL query for the first page will look something like this:
SELECT * FROM leermaterialen ORDER BY laatstewijziging DESC LIMIT 100;
In the first response to Edurep, the so-called resumptionToken contains the reference to retrieve the next 100 records. The Edurep harvester uses this reference to retrieve the next 100 records as follows:
http://www.uitgeverijkubus.nl/oaiprovider?verb=ListRecords&resumptionToken=100-lom
This should translate into a query on the publisher database that looks something like this:
SELECT * FROM leermaterialen ORDER BY laatstewijziging DESC LIMIT 100, 200;
Synchronize
When Edurep has retrieved all records during the First time harvesting, Edurep will visit once a day to retrieve the changes from the past day. On 2013-12-15 Edurep would retrieve the records that changed from 2013-12-14:
http://www.uitgeverijkubus.nl/oaiprovider?verb=ListRecords&metadataPrefix=lom&from=2013-12-14
The database query also takes this into account:
SELECT * FROM leermaterialen WHERE laatstewijziging > '2013-12-14' ORDER BY laatstewijziging DESC LIMIT 100;
Removed learning materials
It may also happen that learning materials are removed from the website because, for example, the content is outdated. However, when the learning material is deleted from the internal database, this deletion can no longer be passed on to Edurep. In order to still be able to report deletions, it may be advisable to maintain a separate oai table where the oai identifier, last modification date and delete status are kept. The original learning material can be deleted, and then the delete status in the oai table can be set to 1 and the last modification date updated.