Edurep:Voorbeeld Implementatie Aanbieder/en: verschil tussen versies

Uit Kennisnet Developers Documentatie
Naar navigatie springen Naar zoeken springen
(engels draft)
 
 
(6 tussenliggende versies door 2 gebruikers niet weergegeven)
Regel 1: Regel 1:
  +
<!--
{{PageTitleCustom|title=Example Implementation Provider|name=Edurep|image=true|imageurl=Edurep:Voorbeeld Implementatie Aanbieder/en}}
+
{{PageTitleCustom|title=Example Implementation Provider|name=Edurep|image=true|imageurl=Edurep:Voorbeeld Implementatie Aanbieder/en}}
In dit voorbeeld wordt een voorbeeld aanbieder beschreven, Uitgeverij Kubus, en hoe hun aansluiting op Edurep eruit zo moeten zien.
 
  +
-->
  +
{{Talen}}
  +
This example describes a fictitious provider, “Uitgeverij Kubus”, and what their connection to Edurep should look like.
  +
__TOC__
  +
== 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.
   
== Inleiding ==
+
== Roadmap ==
 
The project leader has decided to follow Edurep's [[Edurep:Leermateriaal Metadata Aanbieden|stappenplan]] plan for the connection.
Uitgeverij Kubus heeft een aantal leermaterialen ontsloten via hun website. Een aantal webredacteuren houden deze informatie up-to-date via het interne content management systeem. Daarmee is de metadata van de leermaterialen opgeslagen in een database. Na een gesprek met het Edurep team heeft de uitgeverij besloten om hun metadata via Edurep te ontsluiten.
 
 
== Stappenplan ==
 
De projectleidier heeft besloten het [[Edurep:Leermateriaal Metadata Aanbieden|stappenplan]] van Edurep te volgen voor de aansluiting.
 
   
 
=== Identifiers ===
 
=== Identifiers ===
Allereerst moeten er blijkbaar identifiers worden ge-exporteerd. Navraag bij de mensen van techniek leert dat elk leermateriaal in de interne database een unieke identifier krijgt die niet meer wijzigt. Omdat deze identifier ook wordt gebruikt voor het ontsluiten via de website, zijn daarmee deze links ook geschikt als object identifiers (bijv. <nowiki>http://uitgeverijkubus.nl/materialen/?id=1</nowiki>).
+
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. <nowiki>http://uitgeverijkubus.nl/materialen/?id=1</nowiki>).
   
=== Uitvoer naar NL-LOM of schema.org ===
+
=== Export to NL-LOM or schema.org ===
De volgende stap is het uitvoeren van de metadata in het NL-LOM formaat. Bij navraag blijkt dat de interne database de volgende gegevens bevat per veld:
+
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:
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
 
! id
 
! id
! titel
+
! title
  +
! description
! omschrijving
 
  +
! keywords
! trefwoorden
 
  +
! date of publication
! datum wijziging
 
! vak
+
! subject
 
|-
 
|-
 
| 1
 
| 1
Regel 39: Regel 42:
   
   
De meeste van deze informatie blijkt gelukkig gemakkelijk te mappen naar een NL-LOM of schema.org uitvoerformaat. Bijvoorbeeld leermateriaal 1:
+
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:
===== [[Standaarden:NL_LOM|NL LOM]] =====
+
==== [[Standaarden:NL_LOM|NL LOM]] ====
 
<syntaxhighlight lang="xml">
 
<syntaxhighlight lang="xml">
 
<lom xsi:schemaLocation="http://www.imsglobal.org/xsd/imsmd_v1p2 http://www.imsglobal.org/xsd/imsmd_v1p2p4.xsd">
 
<lom xsi:schemaLocation="http://www.imsglobal.org/xsd/imsmd_v1p2 http://www.imsglobal.org/xsd/imsmd_v1p2p4.xsd">
Regel 84: Regel 87:
 
</syntaxhighlight>
 
</syntaxhighlight>
   
===== [[Standaarden:Schema.org|Schema.org]] =====
+
==== [[Standaarden:Schema.org|Schema.org]] ====
 
<syntaxhighlight lang="json">
 
<syntaxhighlight lang="json">
 
{
 
{
Regel 114: Regel 117:
 
</syntaxhighlight>
 
</syntaxhighlight>
   
==== Statische velden ====
+
==== 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.
Echter, het blijkt dat er voor optimale vindbaarheid en zichtbaarheid wat meer informatie nodig is. Gelukkig blijkt daarbij ook dat de meeste informatie standaard ingevuld kan worden.
 
  +
* aggregation level: Since all output material is a lesson, this will be "3".
* aggregatieniveau: Aangezien al het uitgevoerde materiaal een les is, wordt dit "3".
 
* taal: Alles lessen zijn gemaakt in het Nederlands, dus "nl".
+
* language: All lessons are made in Dutch, so "nl".
* kosten: Het materiaal is niet gratis, dus dit wordt "yes".
+
* costs: The material is not free, so this becomes "yes".
* rechten: Het materiaal is niet rechtenvrij dus dit wordt "yes".
+
* rights: The material is not free of rights so this will be "yes".
* rechtenomschrijving: De rechten berusten bij de uitgever, dus iets als "Copyright Uitgeverij Kubus".
+
* rights description: The rights belong to the publisher, so something like "Copyright Uitgeverij Kubus".
* uitgever: Ook bekend, "Uitgeverij Kubus".
+
* publisher: Also known as "Uitgeverij Kubus".
* soort lesmateriaal: De lessen bevatten open opdrachten en toetsen, dus "open opdracht" en "evaluatie- en toetsmateriaal".
+
* type of teaching material: The lessons contain open assignments and tests, i.e "open opdracht" and "evaluatie- en toetsmateriaal".
* context: De bedoelde sector is de basisschool, dus "PO".
+
* 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
* leeftijdsgroep: Deze kan vrij breed worden ingevuld voor de doelgroep:
 
* eindgebruiker: Het leermateriaal is bedoeld voor studenten (ook al moet een leerkracht het kopen), dus "learner".
+
* end user: The learning material is intended for students (even if a teacher has to buy it), so "learner".
* formaat: Aangezien het leermateriaal op internetpagina's staat is het mimetype "text/html".
+
* formaat: Since the learning material is on internet pages, the mime type is "text/html".
   
==== Vakgebied ====
+
==== Subject ====
Tot slot moet ook het vakgebied worden ingevuld. In Edurep wordt het [[OBK:Hoofdpagina|OnderwijsBegrippenKader]] gebruikt als coderingssysteem voor vakgebieden en leerniveaus. Dit betekent dat alle vakgebieden in de interne database gemapt moeten worden met de corresponderende waarde in het OBK. Wanneer de waarden worden opgezocht, resulteert dit in de volgende mappingstabel:
+
Finally, this field must also be specified. In Edurep, [[OBK:Hoofdpagina|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:
   
 
{| class="wikitable"
 
{| class="wikitable"
! vak kubus
+
! Subject kubus
 
! obk id
 
! obk id
 
! obk label
 
! obk label
Regel 146: Regel 149:
 
|}
 
|}
   
Het uiteindelijke resultaat is te zien in het volgende [https://raw.githubusercontent.com/kennisnet/edurep-files/master/example/nllom-kubus.xml NL-LOM] of [https://raw.githubusercontent.com/kennisnet/edurep-files/master/example/json-ld-kubus.txt schema.org] record.
+
'''The final result can be seen in the following [https://raw.githubusercontent.com/kennisnet/edurep-files/master/example/nllom-kubus.xml NL-LOM] or [https://raw.githubusercontent.com/kennisnet/edurep-files/master/example/json-ld-kubus.txt schema.org] record.'''
   
=== Uitvoer naar Edurep ===
+
=== Export to Edurep ===
De uitvoer van de NL-LOM records geschiedt door middel van OAI-PMH. Dit protocol synchroniseert alle nieuwe leermaterialen die in de database worden gezet met Edurep. Om dit effectief te kunnen doen is er voor elk materiaal een laatste wijzigingsdatum nodig en gelukkig is deze beschikbaar.
+
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.
   
==== eerste keer ====
+
==== First time harvesting ====
Om Edurep in eerste instantie te vullen stelt de Edurep harvester de volgende vraag op de oaiprovider van Uitgeverij Kubus:
+
To initially fill in Edurep, the Edurep harvester makes the following request to the OAI provider of Uitgeverij Kubus:
 
<nowiki>http://www.uitgeverijkubus.nl/oaiprovider?verb=ListRecords&metadataPrefix=lom</nowiki>
 
<nowiki>http://www.uitgeverijkubus.nl/oaiprovider?verb=ListRecords&metadataPrefix=lom</nowiki>
   
Feitelijk worden hiermee alle records opgehaald in volgorde van laatste wijziging. Optimaal worden niet alle records tegelijk teruggegeven maar verdeeld over meerdere pagina's waarbij de aanbieder mag bepalen hoeveel records er pagina worden teruggegeven. Om serverload binnen de perken te houden, adviseert de technische afdeling bij de uitgever om 100 records tegelijk terug te geven. De sql query voor de eerste pagina ziet er dan ongeveer zo uit:
+
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:
   
 
<syntaxhighlight lang="sql">
 
<syntaxhighlight lang="sql">
Regel 161: Regel 164:
 
</syntaxhighlight>
 
</syntaxhighlight>
   
In de eerste respons naar Edurep toe staat in de zogenaamde [[Standaarden:OAI-PMH#resumptionToken|resumptionToken]] de referentie om de volgende 100 records op te halen. De Edurep harvest gebruikt deze referentie om de volgende 100 records op te halen als volgt:
+
In the first response to Edurep, the so-called [[Standaarden:OAI-PMH#resumptionToken|resumptionToken]] contains the reference to retrieve the next 100 records. The Edurep harvester uses this reference to retrieve the next 100 records as follows:
 
<nowiki>http://www.uitgeverijkubus.nl/oaiprovider?verb=ListRecords&resumptionToken=100-lom</nowiki>
 
<nowiki>http://www.uitgeverijkubus.nl/oaiprovider?verb=ListRecords&resumptionToken=100-lom</nowiki>
  +
This should translate into a query on the publisher database that looks something like this:
Dit zou op de uitgeversdatabase moeten vertalen naar query die er dan ongeveer zo uit ziet:
 
   
 
<syntaxhighlight lang="sql">
 
<syntaxhighlight lang="sql">
Regel 169: Regel 172:
 
</syntaxhighlight>
 
</syntaxhighlight>
   
==== synchroniseren ====
+
==== Synchronize ====
Wanneer Edurep alle records heeft binnengehaald zal Edurep eenmaal per dag langskomen om de wijzigingen van de afgelopen dag op te halen. Op 2013-12-15 zou Edurep de records ophalen die gewijzigd zijn vanaf 2013-12-14:
+
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:
 
<nowiki>http://www.uitgeverijkubus.nl/oaiprovider?verb=ListRecords&metadataPrefix=lom&from=2013-12-14</nowiki>
 
<nowiki>http://www.uitgeverijkubus.nl/oaiprovider?verb=ListRecords&metadataPrefix=lom&from=2013-12-14</nowiki>
   
De database query neemt dit ook mee:
+
The database query also takes this into account:
 
<syntaxhighlight lang="sql">
 
<syntaxhighlight lang="sql">
 
SELECT * FROM leermaterialen WHERE laatstewijziging > '2013-12-14' ORDER BY laatstewijziging DESC LIMIT 100;
 
SELECT * FROM leermaterialen WHERE laatstewijziging > '2013-12-14' ORDER BY laatstewijziging DESC LIMIT 100;
 
</syntaxhighlight>
 
</syntaxhighlight>
   
==== verwijderde leermaterialen ====
+
==== 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.
Het kan ook voorkomen dat leermaterialen worden verwijderd van de website omdat bijvoorbeeld de inhoud verouderd is. Echter wanneer het leermateriaal uit de interne database wordt verwijderd, kan deze verwijdering niet meer worden doorgegeven aan Edurep. Om alsnog de verwijderingen door te kunnen geven kan het raadzaam zijn om een aparte oai-tabel bij te houden waar de oai identifier, laatste wijzigingsdatum en delete status bijgehouden worden. Het originele leermateriaal kan worden verwijderd, en vervolgens in de oaitabel de delete status op 1 worden gezet en de laatste wijzigingsdatum geupdate.
 
   
 
[[Categorie:Edurep]]
 
[[Categorie:Edurep]]

Huidige versie van 19 sep 2023 om 11:51

Nl.gif Nederlands En.gif 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.