Importing Leap2A

Belongs to 2009-03/Leap2A specification

This page starts with a general description of the task of importing Leap2A information, and will continue by giving examples of the approach taken by PIOP partners.

Overall concepts
The overall task for systems importing Leap2A portfolio material is, for each set of related information, to identify the closest corresponding structure within their system, and then to populate it with the information presented.

For some Leap2A items, this will be fairly straightforward. For instance, if your system holds meetings as a particular type of thing, and if a Leap2A meeting is encountered, there is a good chance that the information relating to the Leap2A meeting will slot into your meeting structure. You will know roughly how much it does through you knowledge of exporting your meetings in Leap2A representation.

But for other items, particularly Leap2A entries, it may be less immediately clear where the information goes. You may need to take into account not only the type (in that case, an entry), but also some of the relationships and possibly categories.

Leap2A information does not have a defined order, and in any case, whatever order the information comes in, there can be no guarantee that all items will be defined before being referred to. Hence, before putting the information into your database, it will make sense to construct an overall map of the information, with a first pass through it, so that at a second pass, it will be clear what everything relates to and therefore where it should go.

For example, one could first build some temporary database tables.

One table would be the entry id and type table, where each atom:entry had noted
 * its ID (which would be unique)
 * its rdf:type

A second table could be a link table. For each atom:entry/link one could have Because the relationships can be noted at either end or both ends, it would be a good idea to go through at some point filtering out duplicate inverse relationships, where the same relationship between two entries has been noted using inverse relationships.
 * the relationship type
 * the source entry id
 * the destination entry id

A third, category table may or may not also be needed, which would have
 * the entry id (not necessarily unique)
 * the category scheme-term, made up by concatenating the scheme and the term strings

Relationship directions
It was noted in the Leap2A exporting page that some systems may not export all the relationships bidirectionally. For these systems, there may be a relationship one way, but not the other way.

A superior, sophisticated importing capability will be able to handle unidirectional relationships. A simple one may not, or may be able to handle only some unidirectionality. Please ensure that this aspect of your import, as well as export, is fully tested and documented.

Individual approaches
These should be documented in, or linked from, the PIOP partner pages.