Mapping from InteropAbility to InLOC

In the following table, based on the information in the InteropAbility specification, "IA" stands for "InteropAbility".

IA element IA definition InLOC mapping notes
interopAbility The root element of the InteropAbility document. LOCstructure +
LOCdefinition
See note below on basic elements.
ability   LOCdefinition See note below on basic elements.
abilityRef     See note below on relationships.
category An unordered typology of the ability. LOCassociation: category Follows Atom.
dc:created The date the author made the resource. (same) One of InLOC's Simple atomic properties.
dc:creator The author of the ability. LOCassociation: by Only one element in IA, so can only represent common name OR URI.
dc:description Defines the ability. (same) One of InLOC's Simple atomic properties. Similar treatment of multilinguality.
dc:educationLevel Position in an ordered list of items indicating academic difficulty. LOCassociation:level InLOC treatment is more expressive.
exemplaryEvidence A description or reference to an example of the type of evidence required. (does not map) could be part of InLOC furtherInformation
expiry The date the authorisation terminates. validityEnd One of InLOC's Simple atomic properties. See note below on validity.
forUser The group of people that the scale is intended to be used by; for example peer, individual, tutor, assessor. (does not map) Part of the IA "scale" structure.
dc:identifier An unambiguous reference to the resource within a given context. (same) One of InLOC's Simple atomic properties. IA recommends: "URI leading to human readable text"
interopAbilityDescription Overview of the framework or structure. dc:description See note below on basic elements.
interopAbilityTitle The name of the framework or structure. dc:title See note below on basic elements.
dc:issued The date the resource was made available. (same) One of InLOC's Simple atomic properties.
key Look up entity in a scaleItem element. (does not map) Part of the IA "scale" structure.
leadIn Optional preliminary text for title. (does not map) could be part of InLOC furtherInformation
lowerBound The minimum permitted value in a scaleItem. (does not map) Part of the IA "scale" structure.
dc:modified The date the resource was changed. (same) One of InLOC's Simple atomic properties.
dc:publisher Organisation responsible for making the resource available. LOCassociation: by Only one element in IA, so can only represent common name OR URI.
purpose Reason for use of the scale, for example 'for assessment'. (does not map) Part of the IA "scale" structure.
relationship A formal description of the link between one ability and another ability. LOCassociation See note below on relationships.
resource A link to or description of materials that are associated with or support the ability. furtherInformation InLOC is less expressive here.
dc:rightsHolder The organisation responsible for approval, accreditation or validation of the ability. LOCassociation: by Only one element in IA, so can only represent common name OR URI.
scale An ordered typology of the ability. (does not map) See note below on scales in IA.
scaleItem A node in a scale element. (does not map) Part of the IA "scale" structure.
shortTitle A shortened form of the title of the resource. abbr One of InLOC's Simple atomic properties. See note below on shortened forms.
dc:source A related resource from which the described resource is derived. LOCassociation  
dc:title The name of the resource. (same) One of InLOC's Simple atomic properties.
typeOfRelationship Describes the nature of the association between two ability elements. (similar) See note below on relationships.
upperBound The maximum permitted value in a scaleItem. (does not map) Part of the IA "scale" structure.
dc:valid The date the resource was given its seal of approval by the authority. validityStart One of InLOC's Simple atomic properties. See note below on validity.
value Descriptive item in scaleItem element. (does not map) Part of the IA "scale" structure.

Basic elements

IA has two very similar elements, "ability" and "interopAbility", corresponding only roughly to InLOC's LOCdefinition and LOCstructure, but with an important difference. The main difference is that where InLOC envisages separately identifying a definition and its structure, IA puts the two together. The two elements "interopAbilityTitle" and "interopAbilityDescription" result from the fact that sometimes a structure ("interopAbility") gives a description of the structure itself ("interopAbilityDescription") that is not suitable to describe the ability (dc:description). This is not needed in InLOC, because the LOCstructure and the LOCdefinition are in all cases identified separately, with their own titles (dc:title) and definitions (dc:definition).

If an IA "interopAbility" element does in fact describe an "ability", that is, something that can potentially be assessed, then InLOC will separate that into two, with the LOCstructure instance picking up the "interopAbilityTitle" and "interopAbilityDescription", and a main LOCdefinition element picking up the rest of the "interopAbility" element.

Relationships

Relationships in IA and InLOC are represented somewhat differently.

In IA, every relationship is contained within an "ability" or "interopAbility" element. The subject of the relation is implicitly defined as the containing ability or interopAbility element. The object of the IA relationship is then either another ability element, which may be represented at that point in the XML tree, or an "abilityRef", which simply holds the identifier of the ability element expanded elsewhere in the XML tree.

In InLOC, to avoid any possibility of confusion, LOCassociations take only one form, where the identifiers of the subject and object are given explicitly. Thus, relations may appear anywhere within a LOCstructure without ambiguity. The relationships between LOCdefinitions are never defined implicitly, so LOCdefinitions can be placed anywhere relative to other ones.

Similar care is needed in both approaches to ensure that relations implied in the layout are made explicit correctly.

The list of relationships suggested for IA is given on the InteropAbility page. Here is a table relating the IA relationship types to ones that are also envisaged in InLOC.

IA direct IA inverse InLOC direct InLOC inverse notes
hasSubAbility isSubAbilityOf skos:narrower skos:broader  
isOptionalPartOf   isOptionalPartOf hasOptionalPart  
requires isRequiredBy hasPreRequisite isPreRequisiteOf  
isRelatedTo   skos:related   (symmetric)
isExactMatchOf   skos:exactMatch   (symmetric)
isNearMatchOf   skos:closeMatch   (symmetric)

Validity

There appears to be substantial confusion about the intended usage of the DCMI term "valid". Some sources, including examples given by DCMI themselves, suggest that the range of "valid" is a string representing an ISO 8601 interval. Other suggestions include using a structure with start and end dates as the object of "valid". There is also some support for the IA usage of "valid" as the start of validity.

If they are to be single date fields, at least one must be defined, so for maximum coherence InLOC defines a pair of elements, validityStart and validityEnd.

Scales

IA has an elaborate system of scales, with at 8 of the above elements involved. InLOC instead has a different approach to defining levels, which enables each level criterion itself to be seen as a LOCdefinition, which fits in with the usual way these are presented. See the level section of InLOC's LOCassociation.

Shortened forms

IA gives the "shortTitle" element as a possible element in which to represent shorter versions of titles. It is not used in the Researcher Development Framework examples.

InLOC has identified the requirement to represent, e.g. the European Qualification Framework levels as "EQF 5" etc, and therefore there needs to be an abbreviated form "EQF" or similar to facilitate this.

InLOC specifies an element "abbr", because an element of that name is widely used for similar purposes in various specifications.