(part of the Guidelines)

Extending InLOC

If extra information needs to represented that is not specified by InLOC, it could be added in some other way to an InLOC representation. However, such additions will not be able to be interpreted correctly by external systems, so these are only useful for internal communication, or where specific agreements are made between the communicating parties. This is often called application profiling. Anyone interested in building application profiles of the InLOC specification could read the CEN CWA Guidelines and support for building application profiles in elearning (pdf) in addition to the explanation given in this section.

Further information

If it is desired to put in extra information into an InLOC representation without affecting, for example, XML validation, it is possible to include any information, both about LOC structures and definitions, as furtherInformation. Any attributes may be added to indicate the nature and role of the information, and for an XML binding, any information containing markup that would interfere with XML validation may be enclosed in a CDATA section.

Extending unchecked vocabularies

This will not affect validation unless the vocabulary is somehow checked, which is it not in e.g. the proposed XML XSD.

Vocabulary for the LOC association type "LOCrel"

Representing the structure of LOC information – that is, the way in which LOC structures and definitions relate together – is done with InLOC relationships, which are represented as LOCassociations of type "LOCrel". The scheme.id is taken from the list of URI values specified by InLOC, listed as the InLOC relationships. InLOC can be extended by adding new relationships to this list, providing they do not duplicate or overlap with the existing ones.

For example, if there were a need to document what LOC definitions had nothing in common, it could be done with an extra relationship.

Vocabulary for the LOC association type "by"

The type "by" is intended to be used to represent information about authorship, or anything relating a structure or definition to agents (people or organisations). The list of possible values may be found with the InLOC compound properties, and is drawn from Dublin Core. It is easy to imagine other possible relationships for use with agents that can be added in place of these, and these could be used, as long as they did not duplicate or overlap with the existing kinds of compound properties.

For example, one could add extra scheme.id values indicating who had reviewed a particular LOCstructure or LOCdefinition, or who had authorised its publication. Alternatively, one could imagine an organisation with a person with responsibility for a particular competence. That would also be suitable for representing through the "by" type of compound properties.

New types of LOC association

The types of LOCassociation group together properties with related semantics, and all LOCassociations must have a type for this reason. The defined types for InLOC are listed on the type page.

It is possible to invent and use some other type, for any compound property not adequately covered by the property types already specified by InLOC. But as the types will typically be checked (as they are by the XSD in the XML binding), the validation files or mechanism will also need to be changed accordingly.

For instance, in a system where there are substantially different kinds of topic, they could be represented by new types instead of the plain InLOC topic.

Next: Referencing InLOC information