|Definition:||framework or structure of definitions of associated learning outcome or competence concepts, together with their properties and relations|
|Constraints:|| as LOC; and in addition:
A LOCstructure instance shall not have more than one combinationRules property in each (or no specified) language.
|Allowed:|| as LOC; and in addition:
A LOCstructure instance may have any number of comprisesAssociation properties, each with one LOCassociation instance.
|Notes:||InLOC does not specify any restriction on the number of any type of LOCassociation allowed within a LOCstructure, or with any particular LOCstructure or LOCdefinition as subject. In some cases, a maximum of one property of any type for a given scheme with a given LOCdefinition as subject would be expected. This is an area to be defined in application profiles.|
Sometimes, e.g. in C2i, there is one overall framework, but it has specialisms, or alternatives for different pathways. In general, the LOCstructure instances for specialisms may be represented within the overall LOCstructure instance.
Because all LOCassociation instances have their subject specified, logically it does not matter where these are actually represented. However, for a clear and intuitive representation, the overall LOCstructure should define all LOCdefinitions that are used in more than one specialism as LOC parts of the LOCstructure. Each specialist LOCstructure should have the LOCdefinition instances that are used only within that specialism as LOC parts.
The properties of LOCstructure
The relationship of LOCstructure instances to the associated LOCdefinitions is defined, not by the properties of the LOCstructure instance, but rather explicitly through LOCassociation instances. However, this cannot work in this way for the LOCassociation instances themselves, which must be directly tied to the LOCstructure. In a Semantic Web view, there must be triples relating the LOCstructure to each constituent LOCassociation. For XML, however, the property of LOCstructure and the class name of LOCassociation are often not distinguished, and there is no need to represent the property explicitly.
If, for any binding, the property (or predicate) needs to be made explicit, "comprisesAssociation" may be used appropriately.
Referring to a LOCstructure set out in another location
If a LOCstructure has nothing other than an id, and no LOCassociations, the id should be understood as identifying a location where it is set out. Where a LOC structure is set out, it would have at least several LOCassociations.