InLOC — Information Model
for Learning Outcomes and Competences

 

 

This document was prepared by the InLOC team:
Simon Grant, Mike Collett, Marc Van Coillie, Jan Górecki, Jad Najjar, Cleo Sgouropoulou, Christian M. Stracke

 

 

 

2013-04-12

 

 

---

Contents

1. Overview and Orientation
2. Scope of the InLOC Model
3. Terms, definitions and abbreviations
4. The core features of the InLOC model
   • Defining and attributing levels
5. Model diagram in the style of UML
6. InLOC classes and their constraints
   • The abstract LOC class
   • The LOCdefinition class
   • The LOCstructure class
   • The LOCassociation class
   • The subject class
   • The scheme class
   • The object class
7. InLOC properties and relationships
   • InLOC specified direct properties
   • The type property
     • The LOCrel type
     • The by type
     • The category type
     • The credit type
     • The level type
     • The topic type
   • The number property
   • InLOC specified compound properties
   • InLOC specified relationships
   • Inheritance of properties
8. List of references

Overview and Orientation

This document provides and defines the Information Model for InLOC – "Integrating Learning Outcomes and Competences".

A brief overview of the InLOC Model

InLOC models the information that enables the definition both of intended learning outcomes and of competences (LOCs). That information is important to personal, professional and vocational development, human resources and employee performance management, training and education, whether in the workplace or in school, vocational or higher education.

InLOC helps with the management and exchange of learning outcomes and competences, by defining common characteristics of learning outcomes and competences and modelling them in formats that can be shared.

There are two main things that are modelled:

• a learning outcome or competence (LOC), taken separately from other ones;
• a structure that contains several LOCs (learning outcomes and/or competences).

LOC definitions

Each learning outcome or competence is associated with information. It has to have a globally unique identifier to uniquely distinguish it from other LOCs, and to support reuse and access. Titles or names are not enough, as the same title in different contexts may signify different LOCs.

Information that is useful to define a learning outcome or competence:

• To help people understand what the LOC is, it can be given a name and a description. These can be available in more than one language.
• Level and credit schemes are often used to indicate progression or to support comparison of learning, education or training. Each learning outcome or competence can be associated with one or more levels and credits. These are usually taken from a list of possible values, such as Level A, Level B etc.
• It can be useful to categorize a learning outcome or competence in some way. In particular it can have a topic, usually taken from a defined source such as a subject classification. General categories other than topic can also be represented.

It is expected that a learning outcome or competence will have other management information (metadata) associated with it. This can include things like owner, dates when it was created or edited and version number.

Structure

Most learning outcome and competence definitions exist as part of a structure or framework.

A structure arranges learning outcomes or competences using relationships between them. They may be grouped together under a heading or can be arranged in a tree or other structure. LOCs can be made up of other LOCs that may be required or optional. There may also be rules about how LOCs can be combined.

Like each distinct LOC definition, a structure will have management information associated with it.

Use and reuse

A single LOC definition or structure can be exchanged, for example as a file or through an online service. One likely format is XML, though others are possible.

To help systems interact with each other, any LOC definition can be reused in another structure, together with a reference to where it came from. Alternatively, relationships can be made between LOCs to indicate that one is the same, broader than or similar to another.

Application

InLOC will enable framework and system developers to describe and digitally exchange LOC definitions and structures in a wide range of educational and employment contexts. LOCs can, for example:

• be associated with resources to help teachers find and use them
• be added to learner profiles to show they have achieved certain levels of knowledge or skill.
• be used in job applications or profiles to help job finding and employee management.

Scope of the InLOC Model

The InLOC Information Model is intended to facilitate linking and sharing LOC information across a wide range of related ICT systems, such as:

• university student information systems;
• recruitment systems;
• appraisal systems;
• e-portfolio and related systems used by individuals to manage their CVs or professional profiles;
• systems supporting the development of competence, whether owned by the individual, their company, or some third party;
• social networks with LOC information, whether private ones operated by educational institutions or businesses, or public ones open to all on the Internet.

InLOC is designed just for the representation of the definitions and structures of learning outcome, competence, and similar concepts, not for the representation of information about individuals, about assessment of individuals, about the actual attainment of learning outcomes by individuals, or about the possession of skill or competence by individuals.

InLOC only deals with a way to represent and structure information about learning outcomes and competence, and does not set out any specific learning outcome or competence definitions or structures for any application area. It provides a common format in which those definitions and structures may be represented, so that ICT systems can handle the information in standardised ways, more efficiently and effectively than would otherwise be possible.

Definitions of learning outcomes and competence, expressable in InLOC format, are intended to be referred to in several contexts:

• assessments of them
• individuals claiming to have attained them
• results of assessments of individuals in them
• courses or other learning opportunities which intend to result in them
• resources for learning education or training related to them.

In each of these contexts, there is other relevant information that is not appropriate for representation according to InLOC, and which is therefore not covered in the InLOC Information Model.

Terms, definitions and abbreviations

For the purposes of this documentation, the following terms and definitions apply.

competence

proven ability to use knowledge, skills and personal, social and/or methodological abilities, in work or study situations and in professional and personal development

(EQF)

learning outcome

what a learner is expected to know, understand, or be able to do after successful completion of a process of learning

(shortened from ECTS Users Guide)

NOTE: The full proper term is "intended learning outcome", and unless it is clear from the context that the reference is to the actual outcome of learning in a person, "learning outcome" should be understood to mean "intended learning outcome" throughout this documentation.

LOC

learning outcome or competence

LOCs

learning outcomes and/or competences

LOC definition

formulation in words of a distinct LOC concept

NOTE: A LOC definition expresses a concept about the characteristics of people. For any LOC definition, there should be the possibility of there being evidence that would be relevant to what a person is able to do in respect of that LOC.

LOC structure

assemblage of LOC definitions, together with expressions about their metadata, properties and relationships

NOTE: In the context of InLOC, documents and frameworks are represented by LOC structures.

RDF

Resource Description Framework

URI

uniform resource identifier

The core features of the InLOC model

Features to be modelled

Definitions and structures

The primary distinction modelled by InLOC is between:

• definitions of distinct learning outcome or competence ("LOC") concepts;
• structures of these definitions, which could be expressed as documents containing them.

There are many examples of such documents, several of which were reviewed and studied as part of the InLOC project. They range from the very general, such as the European Qualifications Framework [EQF], which covers broadly applicable levels of learning outcome; through detailed expositions of the competences related to a particular professional area, such as the European e-Competence Framework "for ICT Professionals in all industry sectors" [e-CF]; to detailed definitions of required knowledge and skills, such as in the numerous UK National Occupational Standards [UKNOS].

Each structured document contains several – often very many – distinct concepts, each of which is expressed in an often short piece of text. A concept may be so specific that it can be assessed as being possessed / attained or not (InLOC calls this a "binary" concept); or may be one on which people can be ranked according to their ability (InLOC calls this a "rankable" concept); or may be more general or imprecise, not affording ranking people, but nevertheless where some evidence for people's ability in the area could in principle be provided.

In some documentation, including [UKNOS] mentioned above, a definition appears to be in terms of a structure — a LOC concept is defined in terms of its component parts. This is one of the aspects of common usage that needs to be resolved by any representation. The InLOC approach is discussed below.

Relationships

One vital role for a framework, document or structure of learning outcomes or competences is to relate distinct definitions together. A document explicitly or implicitly relates the concepts that are included within it. A LOC document or structure implicitly or explicitly states which concepts are understood as part of which other concepts. Typically, one sees broader concepts analysed in terms of their constituent narrower concepts; one may see examples given; one may see levels of concepts defined. All of these express the structural relationships between the concepts in the given area.

Less often, but still significantly, one sees comparative or associative relationships that are not primarily structural. Two concepts appearing in different places may be regarded as the same or similar; or there may be sequences where some learning outcome or competence should follow on other ones. The concepts related in this way may be defined either within the same structure, or in different structures.

In every case, for any relationship one can distinguish and identify the subject of the relationship, what the relationship is, and the object related to.

Properties

A "property" in this sense means any information specific to one distinct substantive item – in InLOC's case, this means specific to a definition or to a structure. There is an important distinction to be made, from the point of view of information modelling, between different kinds of property.

• Some properties are "literal" properties. These include: identifier; title; description; significant dates. There is no more to these properties than their plain descriptions. For example, a title does not refer to anything: it is simply a title. Literal properties do not need any separate identifier of the property's content.
• Some properties are best given with an identifier for the object. For example, giving only an author's or contributor's name risks ambiguity, unless that contributor is also identified uniquely. This pattern is the same as for relationships: one needs to be able to identify the subject, the given property, and the object.
• Some properties are best given using two variable identifiers. Classification is a good general example. To identify something as belonging to a category, one needs to know both the category scheme, and the term within that scheme. If the category scheme is not restricted, there are two identifiers that are not fixed in advance (here: "variable").

There are other such properties, needing two variable identifiers, that are of particular interest to learning, education and training.

• Topics are generally expressed, very like categories, in terms of both a topic catalogue, and a topic within that catalogue.
• Educational credit is typically expressed in terms of both a credit scheme and a level, and then additionally a numeric credit value.
• Levels – which may relate to education, training, occupation or profession – need to be expressed, to avoid confusion, in terms of both a level scheme or framework, and a level within that scheme or framework.

Some of the potential options for modelling

These features can in principle be modelled in any of a range of ways.

Models that match the domain structure relatively closely

An approach that has often been taken in the past is to look at each relationship and property separately, and devise a separate model for each relationship and each property. This approach can be applied to the data structures within programs, to database design, or to the design of XML schemas. Every different significant item of information may have its own structure.

This approach means that every different domain will have a different model. Related items of information are grouped together, but this grouping is not flexible, and does not allow different points of view. For something like a LOC structure, this would mean a large set of different elements, each potentially with different rules.

Models that are technically simple

As an example of an extremely simple technical model, the RDF model essentially reduces all information into "triples" of subject, predicate and object. Every domain has the same model.

For InLOC, the RDF approach would be well matched to expressing literal properties, and properties that can be fully expressed by a single resource identifier. The disadvantage is that to express more complex properties, such as are found in the InLOC domain, requires added complexity of representation, due to the highly abstract basic forms. RDF can naturally be used to represent InLOC information, but the specification of how InLOC information is to be represented in RDF must go beyond the RDF specification itself.

Models that balance domain structure and simplicity

There are several examples of approaches that fall between these two extremes. The Atom Syndication Format, for example, has general purpose structures that are meaningful, such as category, link, and person. The fact that these are not specific to any one domain area has resulted in Atom being used for purposes other than representing blog feeds.

Topic Maps [TM] is a standard way of representing knowledge structures that is completely general, but perhaps more helpful to human understanding than plain RDF. Rather than splitting everything into triples, for example, a Topic Maps association groups together more information about a relationship than simply the URI of the "property", as done in RDF.

How InLOC models these features

The InLOC model is another case of choosing a middle path. The InLOC model is simple, but avoids the extra complication of expressing essentially complex information in a representation that is too simple to represent it well. Because no "end users" ever need to see the form of any InLOC representation of any information, the target audience for the InLOC model are technical staff who are responsible for the ICT systems that store and communicate that information, and for the ICT systems that allow non-technical staff to interact with InLOC structures and definitions.

The three concepts that are core to the InLOC model are: the LOC definition; the LOC structure; and the LOC association.

LOC definition

The LOCdefinition is modelled as directly containing just its own literal properties. The title and description properties are the very essence of the definition, and any dates, rights, or version supplied would be details that cannot have different interpretations or conflicting variants. Only including literal properties keeps the LOC definition itself simple and very easy to understand.

There are many benefits from allowing reuse of definitions, and the properties contained within a LOC definition will be true in the context of any reuse.

A LOC definition is not considered, within InLOC, to include its structure, and therefore it does not consist of other LOC definitions. The point was raised above, that sometimes LOC concepts are defined in terms of their structure and a set of narrower definitions, but nevertheless, the ideas of definition and structure are sufficiently distinct to allow InLOC to draw a clear distinction. If a structure of components were seen as an integral part of a LOC definition, that would greatly reduce the potential for reuse. It is always possible to provide alternative structures containing the same core LOC definition, including varying the depth of structure.

In InLOC, the relationships between LOC definitions is given by the LOC associations that are constituent parts of the LOC structure.

LOC structure

A LOCstructure is likely to have properties of its own. For consistency, nearly all the literal properties apply equally to LOC definitions and to LOC structures. The dates, rights and version are more likely to belong primarily to LOC structures than to an distinct LOC definition, and LOC definitions may inherit those properties. The LOC structure may also have a literal "combination rules" property that specifies how the LOC definitions included in the structure may be combined.

Where the documentation of a LOC definition effectively consists of a LOC structure and narrower definitions, InLOC still identifies the structure and all the definitions separately. The minimum that must be directly provided for a LOC structure is simply its own unique ID, and the details of the structure, relating the LOC definitions together, is provided by LOC associations belonging to the LOC structure.

More guidance on this matter is provided in the Guidelines section on How to follow InLOC.

LOC association

For the sake of simplicity of the model, InLOC represents all relationships, and properties that require one or two identifiers, within the same structure, the LOC association.

Each LOCassociation has a type, a subject, a scheme, and an object. It may also have a number that is used in specific circumstances only. The type serves to distinguish how the rest of the information is used. Each type covers one part of the core features introduced above.

Relationships between LOC definitions

For these, the LOCassociation has type LOCrel, standing for "LOC relationships". The scheme is the particular relationship, and the object is the object of the relationship. More detail is given when discussing the relationships.

For one particular relationship only – hasDefinedLevel – the association number is used. See InLOC treatment of levels.

Authorship / ownership information

For this, the LOCassociation has type by. The scheme gives the particular property, and the object holds both identifier and name of the relevant agent. One variable identifier is sufficient here – the relationship identifier is taken from a fixed list of four well-understood values, taken from Dublin Core [DCMI], as restricting values of well-understood properties is a good way towards interoperability.

General categories

To represent this information, much as in Atom, the LOCassociation has type category. The scheme holds the category scheme classifying the structure or definition, and the object holds the term within that scheme, and any associated labels.

Credit values

Here, the LOCassociation has type credit. The scheme holds the credit scheme, the object holds the level, if needed, and the actual credit value is put into the special number field.

Levels of LOC definitions in (externally defined) level schemes or frameworks

For these, the LOCassociation has type level. The scheme holds the level scheme; the object holds the level identifier and/or label, and the actual numeric level is put in the special number field.

Associated topics

For these, the LOCassociation has type topic. The scheme holds the catalogue, or similar list from which the topic is taken, and the object holds the topic itself, which could be either or both of an identifier or labels.

Summary of LOC associations

The core of a LOCassociation instance is therefore like a Semantic Web "triple", but the LOC association has more information in it than a triple. Each component (corresponding to the components of a triple) may link together one machine-processable and unambiguous id, and any number of human-readable labels, designed to accommodate as many languages as desired.

If a relationship or attribute has just one variable object to identify, then the relationship, drawn from a fixed list, is represented in the scheme, and the object is as expected.

If a property has two variable components, the generic aspect is represented in the scheme, and the specific aspect is represented in the object. The type of LOCassociation is used to distinguish each different property with two variable components.

Defining and attributing levels

For a helpful worked example including levels, please see the relevant parts of InLOC explained through example in the Guidelines.

The idea of defining levels

Some LOC documentation defines levels. A classic example in Europe is the European Qualifications Framework (EQF). There are many other more specific examples of frameworks or similar structures that define levels, a few of which have been examined for the InLOC project, including:

• the European Common European Framework of Reference for Languages [CEFR]
• the Australian Core Skills Framework [ACSF]
• the European e-Competence Framework [e-CF]
• the UK Vitae Researcher Development Framework [VRDF]

In some cases these are not called "levels", but some other name. The name is not important, and the common ground is that in each case, there is the idea of possible progression, with higher "levels" (or other term) coming after, and subsuming, lower ones. The assumption is always that someone at a higher level is also able to do the things that are able to be done by someone at a lower level of the same competence.

Binary and rankable definitions

For a definition to be effective as a level definition, one must be able to answer the question, "has this person attained or reached this level?" with possible answers yes or no (not yet). As there are only two possible answers, the kind of definition that can be used as a level definition is called "binary" in InLOC documentation. The kind of learning outcome or competence that it is a level of is then called "rankable" in InLOC documentation, as it allows people to be ranked in order of that learning outcome.

The idea of attributing levels

Given that a level has been defined, any particular learning outcome or competence can be attributed that level. For example, qualifications are routinely given levels on national qualification frameworks, and mapped directly or indirectly to the EQF. Modules, and even distinct intended learning outcomes within modules or courses are also often mapped to level frameworks like the EQF.

None of this attributing, or mapping, plays a part in the definition of the EQF levels, and as such, it is quite a separate activity.

Defining levels in InLOC

InLOC can represent any scheme or framework that defines levels. Two kinds of level definition are frequently seen in existing LOC documentation, as follow. They are seen either separately or together.

Generic levels applicable across a framework

This is where there are levels, stages, etc. that apply right across a framework or other structure. Sometimes they are explicitly designed to apply very widely. The e-CF (the basis for the Guidelines example) has the first; the EQF is a well-known example of the second.

1. The definitive description of each level is represented as a LOCdefinition.
2. The LOCstructure for the level framework includes LOCassociations that
   • have LOCrel as the type
   • have the LOCstructure as subject
   • have hasDefinedLevel as the scheme.id
   • have the LOCdefinition of the generic level as object
   • have a number representing the number associated with the defined level.

Levels of specific LOC definitions

This is seen in many occupational frameworks, including the e-CF in the Guidelines example.

1. The definitive description of each level is represented as a LOCdefinition.
2. What these are levels of is also represented as a LOCdefinition.
3. The LOCstructure for the level framework includes LOCassociations that
   • have LOCrel as the type
   • have the LOCdefinition that the level is of as subject
   • have hasDefinedLevel as the scheme.id
   • have the LOCdefinition of the particular level as object
   • have a number representing the number associated with the defined level.

In cases where both generic and specific levels are defined, the generic levels may be related to the specific levels through LOCassociations of type LOCrel, and scheme.id either hasLOCpart or a sub-relationship, but not hasDefinedLevel.

The significance of the InLOC number property

The number is often taken directly from the level framework documentation, but this is not always possible. Occasionally, a level system uses non-numeric level values, or uses numeric values where a higher level value means a lower level of competence. To enable automatic comparison of levels, it is essential that all level numbers work in the same sense. Any InLOC representation of level definitions must ensure that each level is given a plain decimal number in the standard sense, i.e. where a greater number represents a higher level of competence, or an intended learning outcome that subsumes a lower level one. If suitable numbers are not provided in the documentation, they must be agreed for representing level definitions in an InLOC structure.

Attributing levels in InLOC

In many competence frameworks, levels are not defined in the sense above, but rather levels from a different framework, already existing, are attributed to the LOCdefinitions of the competence framework. This can be represented simply in InLOC using the level type of LOCassociation.

1. Create a LOCassociation within the LOCstructure.
2. The type of the LOCassociation is level.
3. The subject is the LOCdefinition having a level attributed to it.
4. The scheme is the level scheme containing the level definition.
5. The object is the attributed level:
   • the object id may be the identifier of the particular level, if there is an identifier
   • the object label may be the term used for the particular level – this is particularly useful for non-numeric levels.
6. The number is the attributed level number.

The attributed level number would often be a level number that has been explicitly defined in the level scheme, but it is not necessarily so. It is perfectly possible to attribute a level number that is between defined numbers, though the meaning of this may not be well-defined. For instance, one could attribute an EQF level 4.5 to something that appeared to fall between the definition of EQF level 4 and of EQF level 5.

Definition mixed with attribution

In some cases, a level system defines levels and also maps these to the levels in another framework. This is simply represented in InLOC by doing both of the above.

Examples

The example worked through in the Guidelines section on InLOC explained through example includes defining and attributing levels.

Model diagram in the style of UML

This informative diagram illustrates the underlying model, but is not normative. Implementation structures may follow this diagram more or less closely.

The classes LOCdefinition and LOCstructure are both subclasses of the abstract LOC class, because the kinds of property directly relevant to each are very similar. Values of these properties may be quite different between a related LOCdefinition and LOCstructure.

InLOC classes

The InLOC Information Model defines the following classes.

• The abstract LOC class covers the common points of LOCdefinition and LOCstructure.
• The LOCdefinition class defines the model of a separate LOC definition.
• The LOCstructure class defines the model of a LOC framework or structure.
• The LOCassociation class defines a single model covering both relationships and compound properties.
• The subject, scheme, and object classes play roles within a LOCassociation, depending on the type.

The abstract LOC class

In InLOC, "LOC" stands for "learning outcome or competence", and "LOCs" for "learning outcomes and/or competences". The LOC class defines the properties that both definitions and structures have in common. In practice, only LOCdefinition or LOCstructure classes are used; the LOC class is "abstract" in the terms of object oriented design.

The LOC definition class

The LOC structure class

LOC structures and sub-structures for specialisms

Sometimes, e.g. in C2i, there is one overall framework, but it has specialisms, or alternatives for different pathways. In general, the LOCstructure instances for specialisms may be represented within the overall LOCstructure instance.

Because all LOCassociation instances have their subject specified, logically it does not matter where these are actually represented. However, for a clear and intuitive representation, the overall LOCstructure should define all LOCdefinitions that are used in more than one specialism as LOC parts of the LOCstructure. Each specialist LOCstructure should have the LOCdefinition instances that are used only within that specialism as LOC parts.

If a LOCassociation is relevant only within the context of a particular specialism, then it should be placed inside the corresponding substructure LOCstructure.

The properties of LOCstructure

The relationship of LOCstructure instances to the associated LOCdefinitions is defined, not by the properties of the LOCstructure instance, but rather explicitly through LOCassociation instances. However, this cannot work in this way for the LOCassociation instances themselves, which must be directly tied to the LOCstructure. In a Semantic Web view, there must be triples relating the LOCstructure to each constituent LOCassociation. For XML, however, the property of LOCstructure and the class name of LOCassociation are often not distinguished, and there is no need to represent the property explicitly.

If, for any binding, the property (or predicate) needs to be made explicit, "comprisesAssociation" may be used appropriately.

Referring to a LOCstructure set out in another location

If a LOCstructure has nothing other than an id, and no LOCassociations, the id should be understood as identifying a location where it is set out. Where a LOC structure is set out, it would have at least several LOCassociations.

The LOC association class

LOC association is a hybrid class – one structure serving two different roles. Firstly, it represents the structure of a LOCstructure, relating LOCdefinitions together. Secondly, it provides a structure to hold properties that have more than one piece of information in them – called "compound properties". One set of these compound properties is the well-known Dublin Core ones relating a resource to agents, as creator, contributor, publisher and rights holder. Features of the InLOC Model, above, provides more detail.

Model of LOCassociation class

Each LOC association has:

Direct and inverse LOCassociations

Where the subject and the object of a LOCassociation both have an id, and where the scheme id has a defined inverse (see InLOC properties), it may be possible to represent a LOCassociation either way round. InLOC does not specify which of two possible equivalent LOCassociations should be preferred. There are, however some constraints to be observed.

1. Because the id of the subject is mandatory, it is not possible to represent a LOCassociation where the subject has no id. Such a LOCassociation shall always be represented with the subject representing the relevant LOCstructure or LOCdefinition that has an id, and the item without a specified id playing the role of object.
2. To avoid possible confusion, if an object has a id, that id shall be represented explicitly as part of every LOCassociation object in which it occurs.
3. InLOC makes no distinction between a direct and an equivalent inverse LOCassociation.
4. InLOC attaches no significance to whether a LOCassociation is represented only directly, or with both direct and equivalent inverse LOCassociations, where both subject and object have explicit ids.

The subject class

Interpretation

The subject of a LOCassociation is the LOCdefinition or LOCstructure for which the LOCassociation represents a relation or compound property. Exactly one instance of subject must appear in each LOCassociation instance, and nowhere else.

Instances of subject shall have an id equal to one of the ids of a LOCdefinition associated with the LOCstructure, or the id of the containing LOCstructure itself. The subject of the LOCassociation is either a LOCdefinition, a LOCstructure, or an equivalent entity.

Labels should only be used for the subject if it is outside the current InLOC document. In most common examples this does not happen. When the subject of the LOCassociation is defined externally it may be useful to give one or more labels for the subject.

The scheme class

For any one scheme.id, there should be no more than one scheme.label in any given language, or with no specified language.

Interpretation

If the id is present together with one or more labels, every label should be a label for the resource identified by the id. Thus, all labels should be equivalent in meaning.

Depending on the type of the LOCassociation, scheme may mean one of several things.

The object class

For any one object.id, there should be no more than one object.label in any given language, or with no specified language.

Interpretation

If the id is present together with one or more labels, every label should be a label for the object identified by the id. Thus, all labels should be equivalent in meaning.

Depending on the type of the LOCassociation, the object may mean one of several things.

InLOC properties and relationships

InLOC specifies three different kinds of properties or relationships.

• InLOC's direct properties are those that are properties of the classes of the main InLOC information model. These include both the literal properties of InLOC classes, and properties linking different classes of the InLOC model. These can be seen in, or inferred from, the UML diagram. Two of these direct properties in particular deserve fuller explanation:
  • the type property, along with an explanation of each specified type;
  • the number property.
• InLOC's compound properties are expressed through LOCassociations, linking LOCstructures and LOCdefinitions to information with a structure significant for interoperability. The by type of LOCassociation is the only one of these for which InLOC specifies scheme.ids.
• InLOC's relationships are also expressed through LOCassociations. The subject and object of a relationship LOCassociation are each a LOCstructure or LOCdefinition. The scheme in a relationship LOCassociation plays a role rather like a RDF "predicate" linking the subject and object resources. InLOC specifies the allowed scheme.ids for relationships.

Using these three kinds of properties or relationships, InLOC specifies a mechanism for property inheritance, to avoid the necessity of repeating properties that are by nature common to many LOCdefinitions. The relationships table specifies the relationships through which inheritance passes or is passed, while the tables for the direct properties and compound properties specify which properties are inherited.

InLOC specified direct properties

InLOC's direct properties are those that are properties of the classes of the main InLOC information model. These include both the literal properties of InLOC classes, and properties linking different classes of the InLOC model. The properties, and the classes they are properties of, can be visualised in, or inferred from, the UML diagram.

Features of natural language properties

The natural language properties:

• abbr
• combinationRules
• description
• label
• rights
• title

may all be present multiple times, but no more than one instance is allowed for each language, and one without any language. If there is one with no language attribute, it is the default for use in language contexts where no more appropriate one is given.

The furtherInformation property may be repeated any number of times in any language, or none. If there is more than one furtherInformation property in one language, and more than one language used in furtherInformation properties, then all furtherInformation properties should have a language specified.

For a normative statement of multiplicity constraints, see the documentation for what the property is of.

The properties title and abbr should be plain text, and for an XML binding, the data type given within the XSD is xs:token. The other four properties may be structured, e.g. in HTML, and if any HTML or other XML markup appears in an XML binding of InLOC, the values of these properties should be enclosed in CDATA sections.

The type property

This is one of InLOC's direct properties.

Type considered alternatively as a property of scheme

In certain circumstances, it is possible to regard type as a property of scheme, rather than LOCassociation. This variation of the information model is possible only if, within any given information set, all LOCassociations with the same scheme.id have the same type.

Interpretation

Types of LOC association

The meaning of a LOCassociation depends on its type.

Meaning of LOC association parts

The type also determines the meaning of the remaining parts of the LOCassociation, as follows.

For further detail, see the sections on each type, below.

The LOCrel type

A LOCassociation of type LOCrel relates a LOCstructure or LOCdefinition to another LOCstructure or LOCdefinition.

LOCassociation properties with LOCrel as the type

Values of scheme id for LOCrel

The specified values for scheme.id when the LOCassociation is of type LOCrel are given with the InLOC relationships.

NOTE: InLOC distinguishes, on the one hand, defining levels (using this type, LOCrel) and, on the other hand, attributing external levels (using another type, level). See Defining and attributing levels.

The by type

A LOCassociation of type by gives structured information about an agent involved with the subject of the LOCassociation.

LOCassociation properties with by as the type

The 4 specified values for scheme.id for this LOCassociation type are intended to be equivalent in meaning to the same terms in the DCMI. These are listed as compound properties.

The object of these LOCassociations is an "agent", which is comparable with dc:Agent and with Atom person constructs

The category type

A LOCassociation of type category serves to categorise any LOCstructure or LOCdefinition according to any classification scheme.

LOCassociation properties with category as the type

As noted, this information structure allows a superset of the elements defined within the Atom category element.

The credit type

A LOCassociation of type credit documents educational credit that applies to a LOCstructure or LOCdefinition. The value in that credit scheme of successful attainment of the subject LOC is represented; the credit scheme is identified, and a level is given if appropriate.

LOCassociation properties with credit as the type

The CEN Workshop Agreement from January 2010 – CWA 16077, "Educational Credit Information Model" – provides a model for this. From CWA 16077:

• "Scheme" is represented here as scheme.id if a URI, or scheme.label if a string;
• "Level" is represented here as object.id if a URI, or object.label if a string;
• "Value" is represented here as number.

The level type

A LOCassociation of type level gives the level attributed to a LOCstructure or LOCdefinition in some external level scheme or framework.

LOCassociation properties with level as the type

This type of LOCassociation is only to be used for attributing level values to a learning outcome or competence definition, where the level is taken from an external level scheme or framework defined independently of the subject LOCdefinition. It must not be used as a mechanism to define levels in a framework that defines levels. To define levels according to InLOC, the LOCrel LOCassociation must be used.

This LOCassociation indicates the level (given in the object) of the subject LOCdefinition in a level scheme that has already been defined independently, and represented here in the scheme.

The topic type

A LOCassociation of type topic gives the topic of a LOCstructure or LOCdefinition according to some topic (or "subject") catalogue, taxonomy, etc..

LOCassociation properties with topic as the type

The number property

This is one of InLOC's direct properties.

Number considered alternatively as a property of object

In certain circumstances, it may be possible to regard number as a property of object rather than LOCassociation. This is possible only if
every LOCassociation with the same object.id either has the same number (if it is given) or has no defined number.

Interpretation

The meaning of the number property depends on the type of LOCassociation.

InLOC specified compound properties

InLOC's compound properties are expressed through LOCassociations, linking LOCstructures and LOCdefinitions to relevant well-structured information. The types of compound property in InLOC are:

• by
• category
• credit
• level
• topic

The by type of LOCassociation is the only one of these for which InLOC specifies scheme.ids, as below.

InLOC specified relationships

The relationships that InLOC specifies are designed to cover the most common and useful set of relationships between parts of frameworks or other LOC structures. The information about relationships is split into three tables:

• the names of the relationships with their intended interpretations
• URIs and labels
• information relevant to an ontology, about the nature of the relationships

Name and interpretation

URIs and labels

Ontology

These relationships are represented in LOCassociations. The subject and object are each a LOCstructure or LOCdefinition, while the scheme is one of the above list of relationships. The scheme appears rather like a RDF "predicate" linking the subject and object resources. Possible subjects and objects are given below along with other information concerning the nature of these relationships.

In this table, "LOCstructure" has been shortened to "structure", and "LOCdefinition" shortened to "definition", to reduce the width of the table.

Inheritance of properties

Heritable properties are noted in the tables for direct properties and compound properties. Whether a relationship passes on those heritable properties is shown in the relationships table: "passes on" means that heritable properties of the subject are by default inherited by the object; "is passed" means that heritable properties of the object are inherited by the subject. A property is only inherited if not explicitly defined – that is, a property defined locally takes precedence over a property that would have otherwise been inherited.

The intention is that property inheritance should make as much intuitive sense as possible. But ICT systems require a way of calculating what is to be inherited, and thus there is a need to specify precise rules. The general principles of property inheritance in InLOC are given below, each followed by one possible algorithmic specification of that aspect of inheritance. These algorithmic formulations are given here as informative, as they would need to be well tested in practice before becoming normative.

Inheritance should only happen within a given LOCstructure. The concept of "within" is defined thus:

1. S is a LOCstructure (providing the context for being "within")
2. Q is "immediately within" P in the context of S if
   • S comprises a LOCassociation A
   • the type of A is LOCrel
   • the subject of A is P,
   • the scheme.id of A is hasLOCpart or any of its sub-relationships
   • the object of A is Q.
3. R is within P in the context of S if
   • either R is immediately within P in the context of S
   • or R is immediately within Q in the context of S and Q is within P in the context of S.

One of the design points of InLOC is to allow different structures and definitions to be revised separately, while maintaining the identity of what has not changed. LOCstructures and LOCdefinitions may be modified separately at any granularity, which is why the modified property is not inherited.

As an additional guard against inappropriate inheritance when using borrowed LOCdefinitions, properties are not inherited across any relationship between LOCdefinitions that have different primaryStructures, nor from a LOCstructure to a LOCdefinition with a primaryStructure not equal to that LOCstructure. This is reflected in the rules below.

Inheritance of primaryStructure

When a LOCdefinition is "borrowed" from an external structure, it is important to note its primaryStructure as from that original external structure. Properties are not inherited by a LOCdefinition that has a different primaryStructure to what it is immediately within.

If D is a LOCdefinition with no explicitly defined primaryStructure, S is a LOCstructure, and

• either
  • D is immediately within S in the context of S
• or
  • C is a LOCdefinition with primaryStructure either explicitly given or inferred as S
  • D is immediately within C in the context of S

then the primaryStructure of D is inferred to be S.

Inheritance of heritable properties with literal values

Heritable literal values are simply inherited in a straightforward way, by LOCdefinitions that are immediately within, and have the same primaryStructure as, what they inherit from.

If:

• A is a LOCstructure
• B is either the same as A, or a LOCstructure or a LOCdefinition within A in the context of A
• C is a LOCstructure or a LOCdefinition within B in the context of A
• C has a declared or inherited primaryStructure that is either B (if B is a LOCstructure) or the same as for B.
• B has the heritable direct property P with literal value V
• C does not have an explicitly defined value of the property P

then it may be inferred that C has the property P with value V.

Inheritance of "by" properties

Compound properties of type by are inherited in a similar way, though the differences mean that expressing it precisely is rather more complex.

If:

• A is a LOCstructure
• B is either the same as A, or a LOCstructure or a LOCdefinition within A in the context of A
• C is a LOCstructure or a LOCdefinition within B in the context of A
• C has a declared or inherited primaryStructure that is either B (if B is a LOCstructure) or the same as for B.
• Y is a scheme.id
• A has a LOCassociation where the subject is B, the type is by, the scheme.id is Y and the object is O
• A has a LOCassociation where the subject is B, the type is LOCrel, the object is C and the scheme.id is hasLOCpart (or any sub-relationship, as above) – that is, C is immediately within B
• A has no LOCassociation where the subject is C, the type is by and the scheme.id is Y

then a LOCassociation with subject C, type by, scheme.id Y and object O may be inferred as comprised by A.

List of references

[Atom] Atom Syndication Format (text, html)

[ACSF] the Australian Core Skills Framework (informative website; InLOC page)

[CEFR] the European Common European Framework of Reference for Languages (informative website; InLOC page)

[CWA_16077] CWA 16077:2010 "Educational Credit Information Model". Available either at DIN or from CEN by FTP

[DCMI] DCMI Metadata Terms

[e-CF] European e-Competence Framework (informative website; InLOC page)

[ECTS] ECTS users guide (informative website)

[EQF] The European Qualifications Framework (informative website)

[ISO_639] ISO 639-1 (informative article)

[RDFS] RDF Vocabulary Description Language 1.0: RDF Schema

[SKOS] Simple Knowledge Organization System SKOS reference

[TM] ISO/IEC 13250:2003 "Topic Maps" (informative article)

[UKNOS] UK National Occupational Standards (informative website; InLOC page)

[VRDF] the UK Vitae Researcher Development Framework (informative website; InLOC page )

[W3C-DTF] W3C: Date and Time Formats