(part of the Interim Information Model)
|This class has been superseded by the relation class, into which it is folded.|
These are the compound properties of LOCs, in the sense that they go beyond having a single value (as is the case with Simple atomic properties, but have their own internal structure. This structure helps to ensure that datatypes are as expected for any particular field.
Rather than using several different bespoke formats for different kinds of compound property, the innovation in InLOC is to have one common format for all, which seems to be adequate to representing the property types required to represent the Stakeholders and sources that have been surveyed as part of the InLOC work.
Model of the LOCproperty class
|LOCsubjectID||1||identifier of relation subject||assumed to refer to LOCstructure or LOCdefinition|
|propertyType||1||URI vocab defined by InLOC||see below for values|
|schemeID||0..1||a unique identifier – recommended: http URI||see below for semantics|
|schemeLabel||0..* (1 per language)||any human-readable strings||only labels for schemeID; no new info|
|particularID||0..1||a unique identifier – recommended: http URI or string to append to scheme URI||see below for semantics|
|particularLabel||0..* (1 per language)||any human-readable strings||only labels for particularID; no new info|
|number||0..1||must be a decimal number – recommended: positive integer||for credit, level, etc.|
InLOC specifies only the following property types:
- inloc:credit (as in CWA 16077)
- inloc:level (as attributed, not defined)
- inloc:category (the default LOC property type)
and, though with somewhat different semantics (see Alternative IM for a different approach)
- inloc:by (authors and other agents)
These will have HTTP URIs assigned for InLOC use. Other extension properties may be defined by other authorities, but they must still use the same structure.
Overall multiplicity: any number of any type of LOCproperty is allowed for any LOCstructure or LOCdefinition. In some cases, a maximum of one property of any type for a given scheme identifier would be expected. This is an area to be defined in application profiles.
The label fields schemeLabel and particularLabel may have an optional language attribute. If no language attribute is given, the label is the default label in cases where the expected language has none defined for that language.
InLOC specified types
|LOCsubjectID||identifier of relation subject||identifier of relation subject||identifier of relation subject||identifier of relation subject||identifier of relation subject LOCstructure or LOCdefinition|
|schemeID||topic taxonomy or scheme or catalogue URI||level scheme id||credit scheme URI||scheme URI, as Atom||InLOC uses DCMI terms with range Agent: dc:contributor; dc:creator; dc:publisher; dc:rightsHolder|
|schemeLabel||topic taxonomy or scheme or catalogue label||level scheme label||credit scheme label (typically an abbreviation)||scheme label (not in Atom)||any local human-readable label for the relationship type|
|particularID||topic id||level id||credit level URI||term (as Atom, defined by scheme)||agent body (person or organisation) URI|
|particularLabel||topic name||level label||credit level label||label, as Atom||agent body (person or organisation) name|
|number||probably not used, but could be ordinal priority (1 as first)||level number (greater number = more skill or competence)||credit value (additive within a given scheme)||could be ordinal priority (1 as first)||optional precedence (e.g. 1 = 1st author, etc.)|
It is only in the "level" and "credit" LOCproperty types that the number attribute has a pre-defined meaning. In the other types, it may be used as an ordinal priority, for example to represent sorting order. The assumption is that in any presentation where order is significant, lower numbers are presented before higher numbers.
- This is level as attributed, not as defined
An item on a numeric scale, or from a defined set of levels, stages, phases, or similar construct that can be represented numerically.
It is common practice to allocate educational levels to several items within learning education and training. Frameworks such as the EQF exist so that they can be referred to, and act as a point of cross-reference. However, level attribution does not (and logically cannot) act as a definition of any level. Level definition is done through an appropriate LOCrelation.
See also the Level attribution feature.
- The representation of credit should be consistent with CWA 16077
- CWA 16077 has just three fields: scheme, level and value. URIs are preferred for scheme and level, but any string is allowed. For InLOC, it is recommended that if a field value is a URI, it is put in an identifier field, and if not, in a label field.
- http://purl.org/net/cm is close.
- category to be consistent with Atom. The fields equivalent to Atom are (b), (d) and (e). The field (c) is extra information not represented in Atom.
- property type is close to atom:category
A generic property to support extensions containing information about the property and providing one or more values for it.
See also the feature Classification.
- by covers all properties whose range is an Agent. Often these will be common across a framework. The semantics of this type is less similar to the others than they are to each other.
These are also possible but do not necessarily fit into a core model.
- Action – the type of activity the item involves, for example taken from Bloom's Taxonomy. This is related to the Text syntax feature, and could be represented through a category LOCproperty – see also Classification.
Type of action was discussed in CEF and EUN projects. Mike
- Weighting – the relative importance of an item in a set – should be dealt with through combination rules.
Note that the prefix "dc:" is used throughout InLOC to refer to the http://purl.org/dc/terms/ namespace, not the /elements/1.1/ namespace.