(part of the Guidelines)
- How to follow InLOC in the structuring of LOC information
- Recognising LOC definitions
- Identifying the LOC structure
- Associating your definitions within the structure
- More information about your structure or framework
- Compound properties that have some structure
- What to leave out
- Important information that is often not represented in paper documentation
The aim of this section is to explain, in basic terms, what someone needs to do in analysing an existing framework or other structure of learning outcomes, skills or competence (LOCs), in order to represent this in InLOC terms. It should be read after looking at the example in the previous section, InLOC explained through example, though not all the detail of the last section needs to be understood.
For ease of communication, this section will use the 2nd person, "you", for the person who is analysing LOC-related information. The assumption is that you are trying to put some information about learning outcomes or competence into InLOC format. Here, it is explained how you can apply the InLOC conceptual model to the information of interest to you. This is referred to here as "your" information, "your" structure and definitions, etc., because it is of your interest, independently of whether you are the owner of the documentation.
This explanation is a basic one, which deals with the most likely cases. To appreciate this section fully, you will need to be looking at documentation about your learning outcomes and/or competences. You are taken through the process of thinking about your information in InLOC terms.
In order to represent and store information in InLOC format, you will need to use some ICT tools. This section does not explain the use of any such tools, but will prepare you for using any such tool.
Before reading this, you may also find helpful the Overview and Orientation, and the Information Model section on the Features of the InLOC Model, which introduces the ideas of the LOC structure, the LOC definition and the LOC association.
To represent your information in the InLOC style, the first thing you need to do is to clarify what your LOC definitions are. This is absolutely essential to InLOC analysis.
In principle, if a single piece of text refers to one concept that could be assessable, or for which you could gather evidence, you can take it as defining a LOC concept. Don't worry at this stage about how vague it is. Even if it is only one word, that may still be fine. Typically, there may be many different layers of LOC information in a single document, and they will mostly be LOC definitions. Looking at the previous section, you will see how LOC definitions were recognised at several different levels. To visualise this, red outlines have been drawn round each identified LOC definition, and you could do something similar on paper documentation.
Things that people might be able to do are all LOC definitions. Statements about what people have to know, or know about, or understand, are also LOC definitions, where they underpin effective abilities. Role and task definitions can be considered as LOC definitions, because people may or may not be able to fill them – they may be assessed, and evidence considered about how well people perform tasks or fulfill roles.
If the question "how well are you able to do this?" is meaningful, looking at a single piece of text, along with its context, then that will be a LOC definition. Other indicative questions are "are you good at this?", "how much do you know about this?", or simply "can you do this?". For more general or vague LOC definitions, you may be able to ask "what can you do in the area of ...?" or "what evidence do you have for this area of competence?", so they are still LOC definitions.
On the other hand, a definition of a tool is not in itself a LOC definition. Knowing about a tool may be a LOC definition, but you do not have to know much about e.g. a car or a computer to use them.
Notes about scope are not in themselves LOC definitions, but rather are about the range of applicability of LOC concepts. Someone does not necessarily need to know about the limits of an ability in order to have it, though recognising the range of one's effectiveness may itself be a useful piece of knowledge to have, and therefore may be defined separately in a LOC definition.
The process of clarifying each LOC definition continues through deciding on a title, a description, or both.
Titles look like names of concepts. If it's a sentence, it probably isn't a title. Titles can sometimes be just one word, as the example in the previous section, "PLAN". Recall that the title must the title of a LOC concept that could be assessed, or for which evidence could be provided. If the title is not like that — for example, containing the terms "unit", "structure", "framework" — then it might in fact be a LOC structure instead.
Descriptions are generally longer than titles, though the boundary is not perfectly clear. But you should make the same decision for each piece of text that has the same role in your model. The distinction between titles and descriptions in practice is not great, but mainly in how they are shown on a page or screen.
For InLOC purposes, every LOC definition will need to have either a title or a description, and it may have both. Quite often, the narrowest LOC definitions, at the low end of your hierarchy, have a definition and nothing else – no title. In the previous section, the levels and the examples were like short phrases or sentences, that did not look like titles, so these pieces of text were taken as descriptions. On the other hand, the e-CF "e-Competences" have both a title and a description.
Your LOC structure will in many cases be the whole document you are looking at. The LOC structure is always what contains and relates the LOC definitions you have identified. This may be called a "framework", or possibly something like an occupational "standard", or a "unit".
The simple case is where the documentation defines all the LOC definitions within it. It is less simple when a LOC structure "borrows" LOC definitions defined elsewhere, but usually this is fairly obvious and self-explanatory.
There may be a substantial amount of information in the LOC structure apart from the LOC definitions, and this will be dealt with later.
Sometimes (e.g. in [UKNOS]) a document that obviously defines a structure has a title that could quite reasonably be the title of a LOCdefinition. Individual UK NOS documents are small, and typically could be seen as expressing structure for a main LOCdefinition in terms of LOCdefinitions with a finer granularity.
- Start out by assuming that, for documents of this kind, there are two distinct entities, the LOCstructure and the main contained LOCdefinition.
- Give them each their own identifier.
- The title of a LOCdefinition should be the title of the learning outcome or competence itself, and should not e.g. have any of the words "framework", "structure", "unit" or "standard" in it, because none of these name a human characteristic ability. A separate title for the LOCstructure is not required by InLOC, but if it is nevertheless desired, it should be something that does not look like it could be directly assessed. Anything like "Structure of ..." would clearly imply a structure rather than a definition.
- Look through the descriptive text in the document, putting any description of the usage or purpose in the description of the LOCstructure, and the description of the assessable human knowledge or ability is in the description of the LOCdefinition.
- For literal direct properties, consider carefully whether the metadata refers to the LOCdefinition, or the LOCstructure, and allocate accordingly. They may or may not be the same. If they apply to both, put the property in the LOCstructure, from where it will be inherited by the LOCdefinitions within it.
- If a structure really holds no more than a definition and some relations of that definition:
- a title or description for this kind of LOCstructure is not mandatory in InLOC
- if a separate title for the structure is nevertheless desired, prefix something like "Structure for ..." before the definition name
- invent a suitable identifier for the structure that is not identical to the identifier for the definition
- relate the structure to the main definitions with a "hasLOCpart" LOCassociation of type LOCrel.
Typically, your documentation will describe a hierarchical structure, with one or more LOC definitions at the "top", and with these analysed into narrower LOC definitions, until you get to a level or granularity where further analysis is of less value.
First, you need to state that your structure contains the top level definitions you have identified. To deal with this in InLOC, you create a LOC association for each one of these relations – that is, one for each top level LOC definition. Then, you need to say how the LOC definitions relate to each other. For example, if they were simply of the form "A consists of B, C and D" then you would record three LOC associations representing A having each of the three LOC definitions B, C, and D as parts.
For all of these relations, you can also record the inverse one if you like, if it helps in your documentation. However, any effective system will understand that if A has B as a part, then it follows logically that B is a part of A. This discussion continues using only the first kind of relationship.
To represent these part relations most generally, InLOC uses the relationship "hasLOCpart". But there are four more specific ways to be a part, described here, which should be used if appropriate.
If some of your components are just examples, then instead of "hasLOCpart" you should use "hasExample". You can recognise a list of examples, because they are not exhaustive, and it appears that other different examples could be added to their list. When you have evidence for examples, that is suggestive, not conclusive evidence for what they examples are of.
You may not call them "levels": your term may be "stages", "phases", or something else. The essential feature of levels, under whatever name, is that having a learning outcome or competence at a higher level implies having the lower levels as well. Typically, the level definitions may look quite similar, and you can ask the question, whether a particular level has been attained or not, with the answers "yes" or "not yet". If, on the other hand, your learning outcome or competence definition allows people to be ranked in order, or in several categories, on that competence, then it is not itself a level definition, though it may have level definitions defined on it.
Each level definition is still a LOC definition, but when defining levels, instead of the relationship hasLOCpart you should use "isDefinedLevelOf". This applies both to generic levels that apply across a framework, and specific levels of particular learning outcomes or competences.
If you have levels that are defined across your whole framework, these are generic levels. If you have descriptors for each level, in general, then that becomes the description for the LOC definition defining your generic level. Your generic levels may have abbreviations, too ("abbr"). The specific levels will use the same numbers as you define for your generic levels, but in contrast applied to specific learning outcome or competence definitions, so the specific level definitions will relate to the particular learning outcome or competence, more specifically than the generic level definition. You can then relate the specific level definitions as examples of the generic levels. This is all illustrated clearly in the e-CF example above.
When defining levels, you must give each level you are defining a decimal number (most simply, a whole positive number) where the greater numbers mean higher levels of learning outcome or competence. In the simplest cases, the number will be the number used in your documentation to indicate the level. But sometimes, the levels go the other way, with the lesser number being the higher level; and sometimes levels do not have simple numbers. To ensure that levels are correctly comparable, the number given as part of the InLOC representation must be such that the greater number is the higher level of ability.
Defining and relating the levels will then complete your task of relating your LOC definitions together. The overall structure will probably be tree-like, though sometimes branches recombine. In particular, when generic levels are defined, each specific level branches both from the specific competence it is a level of, and from the generic level.
Let us assume that your LOC structure is the whole document you are wanting to represent in InLOC. The title of the document will be the title of the LOC structure, and you will probably be able to find some text within the document that can serve as the description of the structure as a whole. Apart from the title and description, look for the following kinds of information, that are "properties" of the structure as a whole.
Is your document a framework that has an abbreviation that is commonly known, or in common use? If so, note that InLOC will represent it as an "abbr" property.
If you are going to publish your structure, you should consider carefully how you want others to use them. Without dealing with the legal side, which may vary between countries, you can still state you intentions, however easy or difficult it is to enforce them. You could use the popular Creative Commons licences, but also include your own explanation of what you permit and what you would like people not to do.
InLOC gives a "rights" property for this, as plain text.
InLOC defines 5 properties representing dates relevant to your documentation, and the first three properties are given names from Dublin Core. None are required, but the most appropriate ones should be used to represent dates that either appear in your documentation, or are otherwise known.
- created is the date of creation of your document.
- modified is any date of revision.
- issued is the date on which your document was published, or distributed.
- validityStart is the beginning of the period when the documentation is considered valid or in force.
- validityEnd is the end of the period when the documentation is considered valid or in force.
Dates, along with rights, will be assumed to be inherited by all the LOC definitions in the LOC structure, as long as they are not borrowed from some other structure. This means that you won't need to repeat these properties for each LOC definition.
Sometimes, different versions are produced of essentially the same documentation. Different version are likely to have different dates. But to aid distinction between LOC structures with the same title and description, InLOC provides a version property where the version identifier can be recorded.
Apart from the structure itself, the titles, definitions, etc, the examples, and the levels, there may be other things in your documentation that might be useful to represent in a way that can be processed automatically. In InLOC, the following information is represented in LOC associations, as for the relations between LOC definitions discussed above. Each of these compound properties uses a different type of LOCassociation.
The selection of compound properties used in InLOC reflects both general purposes and properties more specific to the context of learning, education or training.
- "creator" (including author)
- "rightsHolder" – that is, a person or body that holds rights in or to your documentation.
These "by" properties are inherited by LOC definitions within a LOC structure, so you will not need to repeat them, but none of the other compound properties are inherited.
This is the "category" type of LOCassociation. It is used for any classification of the LOC structure as a whole, or any LOC definition. Categories are here (as most places) represented by referring to classification scheme, and a term from that scheme.
In some newer educational credit schemes, credit is attached not only to courses, but also to the achievement of learning outcomes in ways not involving a fixed course. For that reason, InLOC allows a "credit" type of LOCassociation, where the credit scheme, the educational level, and the credit value can all be separately represented.
This "topic" type of LOCassociation is similar to category, but rather than classifying a LOC definition, it classifies the subject matter implied in a structure or a definition. There are places for a catalogue or equivalent, and an entry or term within that catalogue.
Separately from defining levels, it may be useful to associate a LOC definition with a level in another level scheme or framework. InLOC defines a "level" type of LOCassociation, which allows separate representation of the external level scheme, the level within that scheme, and a definite number for that level.
There may be other information in your documentation, that is not itself a LOC definition, or one of the pieces of information specified above about a LOC structure or LOC definition. However, it is presumably there for a purpose, and so InLOC allows it to be recorded for human reading – though it will not be automatically comparable to other such information. All of this further information — for example intended use, context, scope, etc. may be represented in InLOC with one or more furtherInformation properties. There could be an explanation of how you expect your learning outcome or competence to be assessed, or what evidence is relevant. The documentation might state what learning resources or courses will help toward a LOC. Within InLOC, the furtherInformation property of a LOCstructure or LOCdefinition is where this can be placed. Often, this information will have a formal and structured representation elsewhere, and it is not the task of InLOC to reproduce this. Courses will be described in course catalogues, and may refer to InLOC information. Personal achievements and qualifications may be in an e-portfolio that refers to InLOC information, and so on. But this information has no proper place in InLOC.
You should take particular care that your LOC definitions are not tied closely to information that is not relevant in another context that the LOC is relevant in, and then they will be able to be reused.
For use in ICT systems, it is vital to have clear identifiers that are universally unique. The practice in paper documentation varies considerably. Sometimes one sees codes within a document or group of documents, and where these appear, it makes sense to incorporate these codes into the proper identifiers that are needed in InLOC, for each LOCstructure and each LOCdefinition.
If a LOCstructure has a proper unique identifier, then by using that along with internal codes for each LOCdefinition it may be straightforward to generate all the necessary universally unique identifiers for each LOCdefinition. It may be that a tool helps in this.
A LOCstructure or LOCdefinition may have more than one identifier, particularly if it is used in different contexts. However, for the integrity of InLOC representations, in this case one identifier must be used as primary. Other identifiers are regarded as secondary, but are placed in extraID properties, so that they can also be recognised and processed by ICT systems.
Paper-style documentation is usually in just one language, with a separate document produced for any translation. It is self-evident which language a document is written in. This is not always obvious for electronic documentation. InLOC allows both the representation of an overall language for documentation, and the representation of a language for each piece of information that is intended for human reading. This allows an InLOC representation to be multilingual, without needing different language versions to be published separately.