Interim Information Model

Skip to end of metadata
Go to start of metadata
(Thinking has moved on since this Interim draft – please now see the current Information Model)

ELM Information Model for Learning Outcomes and Competences

Interim draft towards a CEN Workshop Agreement

By the InLOC team

2012-06-29

Foreword

The accompanying Interim Guidelines document gives background to, and explanation of this model.

This Interim Information Model is also available as the submitted PDF: 20120629_InLOC_Interim_Report_IM.pdf.

Issues arising from further discussion and consultation on the Interim documents are recorded at Interim Issues.

Contents


Introduction to the InLOC model

This CWA provides and defines the InLOC Information Model: InLOC – "Integrating Learning Outcomes and Competences" – models information defining intended learning outcomes and competences (LOCs). That information is important to personal, professional and vocational development, training and education, whether in the workplace or in school, vocational or higher education.

Representing such information, for the purposes of interoperability of learning (and other) technology, involves looking at how others have similarly represented such information effectively in the past, retaining what currently and appropriately works well, and adding what is needed. Two specifications that have been widely reused in this way are the Dublin Core Metadata Initiative's DCMI Metadata Terms and more recently the W3C's Semantic Web work on SKOS. The team brought their knowledge of existing specifications together, and assessed them against surveyed stakeholder requirements. It became apparent that existing specifications were not fit for this purpose, in different ways.

While some of the Dublin Core terms are envisaged as having literal ranges, other terms have ranges that are potentially structured – for example, DC terms dealing with authorship have the class "Agent" as their range. InLOC takes the innovative step of treating these different kinds of properties differently. The literal properties (including title and description) that are closely tied to their respective resources are used in the customary way. But for the more complex properties, which tend to be more loosely associated with the resource they are describing, InLOC introduces a new general purpose property class. Topic, level and credit value are often associated with intended learning outcomes, and are all commonly represented using more than one field, and InLOC uses this new class to represent them.

The resulting InLOC specification is both simple and highly expressive. While RDF has an extremely simple foundation, the complexity of the compound properties that InLOC needs to handle, and the extra information that needs to be given about relationships, invite richer treatment. Dublin Core is simple, but not directly designed for representing highly structured information. SKOS helps well in representing general-purpose hierarchical structures, but current practice in representing learning outcome and competence information needs more than taxonomic trees. Atom is another good example of a useful general purpose representation, but intended learning outcome and competence information has substantially different requirements. InLOC has taken up these challenges.

The InLOC team offer this new specification as a solution that is able to express the rich diversity of current learning outcome and competence information, so that systems using that information can interoperate effectively. Though it deals with information that is rich and complex, the InLOC specification is simple and flexible, and thus should be quite easy to implement and to work with. It would be especially gratifying were InLOC to come to be recognised as a useful new model for other areas involving structures with reusable components.


Scope of the InLOC Model

The InLOC Information Model is a model of information about intended learning outcomes or competences (LOCs), to enable its sharing across systems, sectors and domains. It distinguishes the main characteristics both of individual LOC definitions, and structures (often called "frameworks") of LOC information. LOC information is represented independently of its use in any particular context, target group, organisation or individual. This 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 an individual or a company; and relevant social networks, whether private ones operated by educational institutions or businesses, or public ones open to all on the Internet. There are many and varied uses of this information, and they could be categorised in several ways. The central point is simply that they all use, manage or refer to information about learning, development and competence.

InLOC does not set out any LOC concept definitions or structures, but rather, 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.

InLOC's scope is focused on representing the information just about LOC definitions and structures, independently of their being applied to particular people. Through this clear scoping, InLOC structured information can be referred to not only in the context of individuals claiming to have attained learning outcomes or competences, but also from representations of course ("learning opportunity") information, and representations of information about resources for learning education or training, irrespective of the media used by those resources.

InLOC expressly does not attempt to represent any information about individuals, about courses or about other resources for learning, in the belief that the most effective and flexible way of representing information across the whole learning technology sector is to work towards standardising the representation of limited, well-defined, self-contained areas of information, together with simple ways of cross referencing between these separate representations. It is an approach that has been described in the phrase "small pieces, loosely joined".


Terms, definitions and abbreviations

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

competence

the 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

statement of what a learner is expected to know, understand, or be able to do after successful completion of a process of learning (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".

LOC

learning outcome or competence

LOCs

learning outcomes and/or competences

NOTE: The intention of the term "LOC" is to play a role similar to the recently popularised term "competency", covering "knowledge", "ability", and other such concepts. The advantage of the term "LOC" is that, being artificial, it can be designated explicitly to apply to learning, education and training, to recruitment and employment, and to personal and professional development.


The InLOC Model specification

The InLOC Model is built on the basis of:

  • distinguishing assessable LOC definitions from the LOC structures that contain and relate them;
  • giving a common structure to compound properties of LOC definitions or structures;
  • giving a common structure, including a number, to relations between LOC definitions and structures.

Many examples of existing definitions, frameworks and structures, related to learning outcomes and competences can be represented according to this model, with minimal levels of ambiguity.

InLOC Model Core Concepts

LOC definition

A LOC definition (class name: LOCdefinition) instance expresses a concept of a learning outcome or competence, against which a person (or, less often, a group or organisation) can be assessed. It is through being defined that people can understand what the concept refers to, and thus agree on the assessment of a person against that concept. Definitions of the same concept are equivalent if all assessment outcomes are the same whichever of the definitions is used. Assessment does not have to be grading. A qualitative assessment based on a collection of related presented evidence is still an assessment.

If a description describes something that someone is able to do (a competence), or something that someone may have learned (a learning outcome), it could belong to a LOC definition. If the described concept is not related to individual knowledge, ability, or personal characteristics, or if there is no way of making a claim to the concept and supporting it with evidence, then the concept does not fit as a LOC definition.

LOC definitions directly and logically contain only their Simple atomic properties, which is the information (or metadata) essential either to the defining the meaning of the described LOC concept, or to its immediate use or reuse. Compound properties of a LOC definition are represented using the LOCproperty class, but as these other properties attributed may vary according to different authorities, the LOC properties belong not to the LOC definition, but instead to a containing LOC structure.

LOC structure

A LOC structure (class name: LOCstructure) instance serves to define a set of LOC definitions that are included in that structure, to define the relations that exist between those LOC definitions, and to define LOC properties of the same LOC definitions. LOC definitions are logically included in a LOC structure through explicit LOC relations, rather than directly by means of containment through the presentation or format. It is immaterial whether the representation of LOC definitions is sequentially included in the LOC structure or not. This means that LOC definitions from elsewhere can be as easily included as ones defined along with the LOC structure.

A LOC structure instance will have properties of its own. Simple properties are represented as Simple atomic properties of the LOC structure, and compound properties as LOC property instances, with the LOC structure identified as the subject of the LOC property instance.

To allow reuse of whole frameworks, lesser LOC structures can be represented as part of greater LOC structures.

A LOC structure may represent what is called a "framework" or "occupational standard" in existing examples.

LOC property

LOC property (class name: LOCproperty) instances are the compound properties of LOC concepts. Whereas Simple atomic properties have a single value, LOCproperty instances have their own internal structure. The LOCproperty class structure helps to ensure that datatypes are predictable and information is processed easily. A LOC definition or a LOC structure may be the subject of a LOC property, but the LOC properties logically belong to the innermost containing LOC structure, not a LOC definition, even if their presented position is inside the representation of a LOC definition.

LOC relation

LOC relation (class name: LOCrelation) instances, representing relationships between instances of LOCdefinition or LOCstructure, comprise a major part of the content of a LOC structure. Because LOCrelation instances have no date and authorship metadata of their own, they inherit these and other properties from their containing LOCstructure. They must therefore appear contained within the LOC structure they belong to. Even if their presentation happens to be within a LOCdefinition instance, they are not regarded as logically contained by it. LOC relations cover relations between LOC definitions, between LOC structures, and either way between LOC definitions and LOC structures.

InLOC Model diagram

Figure 1 illustrates the InLOC Model using some UML conventions.

Each box in the diagram relates to a Class. No cardinality is specified for any association. Lines with an unfilled triangle shape indicate a subclass relationship. Lines with a filled diamond shape represent an association with a composition relationship, where the associated parts have no independent existence.

InLOC Resources

Note on the use of the prefix "inloc:"

The prefix "inloc:" is used both as a namespace and a CURIE prefix. The current intention is for "inloc:" to stand for and be substituable by the URI "http://purl.org/net/inloc/", but if a better option is provided by CEN before the finalisation of any CWA or EN, this will be considered.

Classes

The following classes are defined for InLOC.



Class name: LOC
URI: inloc:LOC
Label: LOC
Definition: abstract superclass denoting any learning outcome or competence definition or structure
Constraints: A LOC instance shall not contain more than one dc:language property.
  NOTE: in XML, this may be implemented as an xml:lang attribute of the LOCstructure or LOCdefinition element.
A LOC instance shall contain at least one dc:identifier property.
A LOC instance shall not contain more than one dc:title property in each (or no) language.
  NOTE: all dc:title properties of the same LOC instance should be as close as possible in meaning.
A LOC instance shall not contain more than one inloc:abbr property in each (or no) language.
  NOTE: all inloc:abbr properties of the same LOC instance should refer to the same concept.
A LOC instance shall not contain more than one dc:description property in each (or no) language.
  NOTE: all dc:description properties of the same LOC instance should be as close as possible in meaning.
A LOC instance shall not contain more than one dc:rights property in each (or no) language.
  NOTE: all dc:rights properties of the same LOC instance should be as close as possible in meaning.
A LOC instance shall not contain more than one dc:created property.
A LOC instance shall not contain more than one dc:issued property.
A LOC instance shall not contain more than one inloc:validityStart property.
A LOC instance shall not contain more than one inloc:validityEnd property.
A LOC instance shall not contain more than one inloc:version property.
Allowed: A LOC instance may contain any number of dc:modified properties.
A LOC instance may contain any number of inloc:furtherInformation properties.
A LOC instance may contain any number of inloc:LOCrelation instances.
  NOTE: it is expected that a LOC structure would contain at least several LOCrelation instances.
A LOC instance may contain any number of inloc:LOCproperty instances.
  NOTE: all LOCproperty instances, as well as all LOCrelation instances, must be contained in a LOC structure, directly or indirectly.
A LOC instance may contain any number of inloc:LOCdefinition instances.
  NOTE: whether or not a LOC instance contains a LOCdefinition instance is purely a matter of presentation, and makes no difference to the logic. The logic is determined by includes relations between LOCstructure and LOCdefinition instances.
A LOC instance may contain any number of inloc:LOCstructure instances.
  NOTE: whether or not a LOC instance contains a LOCstructure instance is purely a matter of presentation, and makes no difference to the logic. The logic is determined by hasPart relations between LOCstructure instances.
NOTE: whether or not a LOCdefinition instance contains any instances of LOCproperty or LOCrelation is purely a matter of presentation, and makes no difference to the logic.
Comments: This class is abstract and has no immediate instances of its own. All instances of LOC are actually instances of LOCdefinition or LOCstructure.
(See proposed changes in Interim Issues)


Class name: LOCdefinition
URI: inloc:LOCdefinition
Label: LOC definition
Definition: definition of an individual separate learning outcome or competence concept
Constraints: as LOC
Allowed: as LOC
Relations: LOCdefinitions are related to LOCstructures exclusively through LOCrelation instances with the relationshipTypeID of inloc:includes and inloc:isIncludedIn
Comments:  


Class name: LOCstructure
URI: inloc:LOCstructure
Label: LOC structure
Definition: framework or structure of definitions of learning outcome or competence concepts
Constraints: A LOCstructure instance shall not contain more than one combinationRules property in each (or no) language.
  NOTE: all combinationRules properties of the same LOCstructure instance should be as close as possible in meaning.
Allowed: as LOC
Relations: LOCstructures are related to LOCstructures exclusively through LOCrelation instances with the relationshipTypeID of hasPart and isPartOf
Comments:  


Class name: LOCrelation
URI: inloc:LOCrelation
Label: LOC relation
Definition: information about a relation between LOC definitions or structures
Constraints: A LOC relation instance shall contain exactly one inloc:LOCsubjectID property.
A LOC relation instance shall contain exactly one inloc:LOCobjectID property.
A LOC relation instance shall contain exactly one inloc:relationshipTypeID property.
A LOC relation instance shall not contain more than one inloc:number property.
Allowed: A LOC relation instance may contain any number of inloc:relationshipTypeLabel properties.
Comments: All LOCrelation instances must be contained, directly or indirectly, in a LOCstructure instance. They inherit their metadata such as dates and authorship from the closest enclosing LOC structure that specifies any such metadata.


Class name: LOCproperty
URI: inloc:LOCproperty
Label: LOC property
Type: Class
Definition: structured information about compound properties relating LOC definitions or structures to other information
Constraints: A LOC property instance shall contain exactly one inloc:LOCsubjectID property.
A LOC property instance shall contain exactly one inloc:propertyType property.
A LOC property instance shall not contain more than one inloc:schemeID property.
A LOC property instance shall not contain more than one inloc:particularID property.
A LOC property instance shall not contain more than one inloc:number property.
Allowed: A LOC property instance may contain any number of inloc:schemeLabel properties.
A LOC property instance may contain any number of inloc:particularLabel properties.
Comments: All LOCproperty instances must be contained, directly or indirectly, in a LOCstructure instance. They inherit their metadata such as dates and authorship from the innermost enclosing LOC structure that specifies any such metadata.


Attribute Properties

Simple atomic properties of the LOCdefinition and LOCstructure classes

Simple atomic properties that are the same as the corresponding ones from DCMI Metadata Terms


URI: inloc:created
http://purl.org/dc/terms/created
Label: Date Created
Domain: LOC
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Definition: Date of creation of the resource.
Comments: Same as dc:created


URI: inloc:description
http://purl.org/dc/terms/description
Label: Description
Domain: LOC
Range: (not constrained)
Definition: An account of the resource.
Comments: Same as dc:description


URI: inloc:identifier
http://purl.org/dc/terms/identifier
Label: Identifier
Domain: LOC
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Definition: An unambiguous reference to the resource within a given context.
Comments: Same as dc:identifier


URI: inloc:issued
http://purl.org/dc/terms/issued
Label: Date Issued
Domain: LOC
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Definition: Date of formal issuance (e.g., publication) of the resource.
Comments: Same as dc:issued


URI: inloc:language
http://purl.org/dc/terms/language
Label: Language
Domain: LOC
Range: http://purl.org/dc/terms/LinguisticSystem
Definition: A language of the resource.
Comments: Same as dc:language


URI: inloc:modified
http://purl.org/dc/terms/modified
Label: Date Modified
Domain: LOC
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Definition: Date on which the resource was changed.
Comments: Same as dc:modified


URI: inloc:rights
http://purl.org/dc/terms/rights
Label: Rights
Domain: LOC
Range: http://purl.org/dc/terms/RightsStatement
Definition: Information about rights held in and over the resource.
Comments: Same as dc:rights


URI: inloc:title
http://purl.org/dc/terms/title
Label: Title
Domain: LOC
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Definition: A name given to the resource.
Comments: Same as dc:title


Simple atomic properties defined within InLOC


URI: inloc:abbr
Label: abbreviation
Domain: LOC
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Definition: abbreviation for the title of a LOCstructure or LOCdefinition
Comments:  


URI: inloc:combinationRules
Label: combination rules
Domain: LOCstructure
Range: (not constrained)
Definition: rules, dictated by the authority defining the LOCstructure, governing the combinations of narrower defined LOC concepts that are accepted as fulfilling the broader defined LOC concept
Comments:  


URI: inloc:furtherInformation
Label: further information
Domain: LOC
Range: (not constrained)
Definition: any information relevant to the LOCstructure or LOCdefinition
Comments: This is completely free format, so has no defined range. One possibility is to represent it as embedded XHTML. Another is simply to give a URL leading to further information held elsewhere. No media are forbidden.


URI: inloc:validityStart
Label: validity start date
Domain: LOC
Range: http://www.w3.org/2006/time#DateTimeDescription
Definition: date from which the issuing authority intends the LOC to be used for its main purposes
Comments: For XML use http://www.w3.org/2001/XMLSchema#date


URI: inloc:validityEnd
Label: validity end date
Domain: LOC
Range: http://www.w3.org/2006/time#DateTimeDescription
Definition: date after which the issuing authority does not intend the LOC to be used for its main purposes
Comments: For XML use http://www.w3.org/2001/XMLSchema#date


URI: inloc:version
Label: version
Domain: LOC
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Definition: string allocated by the issuing authority, to a LOC, differentiating it from other similar LOCs with the same title or identifier
Comments:  


Properties shared between the LOCrelation and LOCproperty classes



URI: inloc:LOCsubjectID
Label: subject identifier
Domain: LOCrelation or LOCproperty
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Definition: identifier of the LOC that is the subject of the relation or property
Comments: Recommended format: HTTP URI – for XML use http://www.w3.org/2001/XMLSchema#anyURI


URI: inloc:number
Label: number
Domain: LOCrelation or LOCproperty
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Definition: number associated with the relation or property
Comments: Use a data type that specifies a decimal number – e.g. with XML use http://www.w3.org/2001/XMLSchema#decimal. this is used in particular for level definition relations, where the number given is the defined level number within the defined scheme.


Properties of the LOCrelation class



URI: inloc:LOCobjectID
Label: object identifier
Domain: LOCrelation
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Definition: identifier of the LOC that is the object of the relation
Comments: Recommended format: HTTP URI – for XML use http://www.w3.org/2001/XMLSchema#anyURI


URI: inloc:relationshipTypeID
Label: relationship type identifier
Domain: LOCrelation
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Definition: identifier of the relationship type
Specified
allowed
values:
One of:
Comments: Recommended format: HTTP URI – for XML use http://www.w3.org/2001/XMLSchema#anyURI


URI: inloc:relationshipTypeLabel
Label: relationship type label
Domain: LOCrelation
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Definition: human-readable label standing for the relationship type
Comments: Repeatable once per language. The label must not introduce any substantially new information. It must be nothing more than a label for the concept or resource identified by the relationshipTypeID.


Properties of the LOCproperty class



URI: inloc:propertyType
Label: property type
Domain: LOCproperty
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Definition: type of property within InLOC
Specified
allowed
values:
One of:


URI: inloc:schemeID
Label: scheme identifier
Domain: LOCproperty
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Definition: identifier of the scheme, source or finer type
Specified
allowed
values:
There are no specified values, except in the case of propertyType by, where schemeID should be one of:
Comments: Recommended format: HTTP URI – for XML use http://www.w3.org/2001/XMLSchema#anyURI


URI: inloc:schemeLabel
Label: scheme label
Domain: LOCproperty
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Definition: human-readable label for the scheme, source or finer type
Comments: Repeatable once per language. The label must not introduce any substantially new information. It must be nothing more than a label for the concept or resource identified by the schemeID.


URI: inloc:particularID
Label: particular identifier
Domain: LOCproperty
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Definition: identifier of the particular term, property or agent
Comments: Recommended format: either HTTP URI, or string that can be concatenated with the schemeID to form a new particular valid URI.


URI: inloc:particularLabel
Label: particular label
Domain: LOCproperty
Range: http://www.w3.org/2000/01/rdf-schema#Literal
Definition: human-readable label or name for the particular term, property or agent
Comments: Repeatable once per language. The label must not introduce any substantially new information. It must be nothing more than a label for the concept or resource identified by the particularID.



Related documents

  • The Interim Guidelines presents the accompanying guidelines and request for comments.
  • The XML InLOC project web page links to some very early drafts of example XML, together with an XSD.
  • Example analyses are available from the Stakeholders InLOC project web page.
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.