Edurep:Voorbeeld Implementatie Aanbieder/en

Edurep: Example Implementation Provider

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

he 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:
• 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.