(part of the InLOC Information Model)

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 LOC definition 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 LOC structure 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 a 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.