Features

Here is a simple list of the features being analysed by InLOC. The list is linked to a page for each feature, where the features are explained, and links given to examples of the features in practice.

The model described can be either explicit (as in a specification) or implicit in the stakeholders data or practice. If a source covers separate more than one LOC, it might be useful to duplicate this table, and fill in once for one single LOCs, and once for frameworks or LOC structures. For each feature, record if it is present or not.

For each new stakeholder or source page, please copy this table complete with links, fill in the empty column with 1 or 0, and replace the explanatory note with a note about that feature for the stakeholder or source being reported.

As the individual features pages are completed, we will get a better picture of which features we want to implement, and how.

The features pages

Each feature page is intended to serve several functions.

  1. Initially, it clarifies what we mean by the feature, so we are all recording the same thing.
  2. Next, as the stakeholder/source examples are filled in, the feature page will point to notable examples of that feature.
    • We do not want or need a list of all the examples that use that feature, but only the ones that are of particular interest to InLOC. These include:
      • the clearest requirements for the feature;
      • the best current examples of how to handle this feature;
      • and perhaps any examples that warn of how not to handle the feature.
    • On the feature page, each link to a selected stakeholder/source page should be within just one short list item explaining the link very briefly.
    • All the detail about how the stakeholder or source requires or handles that feature should be on the stakeholder/source page, not the feature page. This helps to keep all the stakeholder/source information together.
  3. When all (or at least most of) the stakeholder/source information is in place, we can suggest on the feature page how we intend to deal with this feature in the InLOC model.
  4. Finally, the page can record the decisions we reach in consensus on what we decide about the feature and how to represent it.

We want to avoid sub-pages under any of the features pages, to avoid unnecessary navigation. If everything is kept short and clear, it should fit well on just one page.

№ Features ? notes
00 More than one model   Is there more than just one model? E.g., are competence definitions and competence structures modelled differently or separately? (Note what distinction is made.)
01 Identifiers   What has identifers, definition or structure or whatever, and what kind of identifier
02 Hierarchy (internal)   Are items arranged in a structure with broader-narrower relationships? This may be implicit in a document or file structure. The levels in the hierarchy may also have meaning attached. The structure may by polyhierarchical, that is an item may appear in more than one position in the hierarchy. (Note if poly or not.)
03 Internal relationships   Are items related in other ways to items in the same structure, beyond hierarchical? Other relationship types might include prerequisites, etc. (Note which.)
04 External relationships   Are items related to other items outside of the source framework or structure (external classes or entities)? E.g. to indicate equivalent definitions in other structures. (Note which.)
05 Conditionality / optionality   Are there LOC items that are optional or conditional within a parent LOC, rather than (the default) mandatory? E.g. a composite skill may be defined as a set of core skills plus 3 out of 10 optional skills. (Give examples.)
06 Text syntax   Do titles or descriptions have a rigid internal syntax? The most common example will be e.g. short descriptions always starting with action verbs. (Note the syntax.)
07 Structured identifiers   Do identifiers have defined parts, e.g. subject and level information? (M2.25 could represent mathematics level 2 item 25.) (Note the parts.)
08 Classification   Are items classified according to facets or properties? For example a type of competence or a topic. Categories will usually be assigned values from a controlled set. (Some categories may be dealt with specifically for example level below.) (Note what categories are used.)
09 Level attribution   Can a LOC have external levels associated with it? (Note which level structures are referred to.)
10 Level definition   Are levels defined? (Note how levels are defined, including how generic or specific they are, and whether they have just one definition, or are defined by examples.)
11 Context   Does the model feature explicit and separate representation of the context of a LOC? This includes range and scope. (May need to explain what is meant by context in each case.)
12 Evidence and assessment   Does the model cover the requirements or processes for assessing LOCs, or what evidence is relevant?
13 Extensions   Does the model explicitly allow the adding of extensions, e.g. more specific versions of a LOC? (Note how.)
14 Profiles   Does the model cover aggregating arbitrary sets of several LOCs (e.g. in order to create a job profile)
15 Adaptation   Does the model allow structures to use externally-defined LOCs and adapt them to a context? (How?)
16 Definition by example   Does the model use examples to help define LOCs or levels? (Note how examples are used.)
17 Learning resources   Does the model include related learning resources? (Note how the model relates resources to LOCs.)
18 Learner records   Does the model include individual claims to having LOCs? (Note how the relationships are represented.)
19 Multilinguality   Is there an explicit model of multilinguality in the LOC documentation or practice?