index

20120122_D3_5_eCOTOOL_CompAP_agro_v5

eCOTOOL Competence Application Profile adapted to agriculture, refined and optimised

General notes

This is a draft application profile for stand-alone competence definitions, illustrated as it might be for application to agriculture, based on the eCOTOOL Competence Model (technical), which is available as Deliverable D1.4.

Also in D1.4 there is a model of structures or frameworks integrating several competence definitions, which is not given here. The framework structure is less affected by considerations of sector. Readers should note that Sections 3 and 4 of this AP contain information that could equally well be given in a framework rather than alongside stand-alone definitions.

The eCOTOOL Competence Model additionally has provision for level definition, exclusively within frameworks, and level attribution, which may apply to competence definitions. For simplicity, this is omitted from here.

History

versiondatebychange
Comp A.22011-11-28SimonInitial version
Comp A.32011-12-08Simonvery small revisions
Comp A.42012-01-06Simonchanged name of some elements and added section 5 on level attribution
Comp A.52012-01-20Simonrestructured the short description; final modifications

Information model / application profile

Key to the table columns

element number
An identifying number for reference. The number corresponds to the numbering in the ECS. The number structure reflects the hierarchy of the information structure: e.g. the element 3.2.1 is part of the element 3.2.
N: multiplicity
This uses the normal conventions as used in UML and elsewhere for how many of a particular element are allowed within the parent element. "1" means that there must be exactly one occurrence of this within the containing element. E.g. 3.2.1 must occur exactly once within every 3.2 structure (of which there can be any positive number). "0..1" means that it may or may not occur, but not more than once. "*" means optionally any number of times. "1..*" means it must occur at least once.
element content
This gives an explanation of what the element is.
data format
(container)
no data is associated with this element, as it just contains the lower-level elements
string
plain unstructured text string of indefinite length
formatted text
a good option here within an XML binding would be XHTML [4], to preserve the integrity of an overall XML document
URI
identifier that would normally resolve to a web page with useful information about the thing identified
source spec
This column has suggestions for existing specifications on which to base the definition and format of the element.

Key to background colours

WhitePart of this information model
Light greyAn informative comment, not part of the information model
Dark greyA visual separator

Information model table

element number N element content data formatsource spec
 
1.   1

definition metadata

(container) -
1.1 1 identifier URI dcterms:identifier[2]
The identifier should be the canonical URI that identifies the particular definition.
1.2 1 default language language code dcterms:language[2]
xml:lang; RFC 5646 [1]
The default language is the language of the document as a whole. The content may also be expressed in any number of extra languages. In other bindings, this could be expressed as dcterms:language, but in an XML binding it would seem most appropriate to use xml:lang instead
1.3 * contributor string, URI dcterms:contributor[2]
1.4 0..1 creator string, URI dcterms:creator[2]
1.5 0..1 created ISO date dcterms:created[2]
rfc 3339
1.6 0..1 last modified ISO date dcterms:modified[2]
rfc 3339
 
2.   1

definition content

(container) -
2.1   1..* structured definition in one language (container) -
2.1.1 0..1 language language code xml:lang; RFC 5646; [1]

If this element is absent, there may only be one structured definition, and it must be in the default language given in 1.2.

2.1.2   1 short description container or string -
2.1.2.1 0..1 action verb(s) string -

This could be restricted to an agricultural vocabulary, if one were constructed. An unresolved issue is whether to have the short description able to contain plain text directly, or whether it would be better always to have the rest of short description, which would be the whole of the short description if there is no action verb.

2.1.2.2 0..1 rest of short description string -
2.1.3 0..1 full description formatted text XHTML [4]

If more than one of these structured definitions is given, they must all be in different languages, and one of them must be in the default language given in 1.2. This is then taken as the default structured definition.

2.2 0..1 context identifier URI -

This is an alternative to a full description, for cases where the definition is given in the context of a framework or other such structure, but quoted separate from, or outside that structure. One or other must be provided. This is important for short definitions of small granularity, where the complete content may only be a few words. For understanding the meaning of the definition, context needs to be supplied. To avoid ambiguity, only one such context is allowed.

 
3.   0..1

definition classification

(container) -

Classifying a definition may serve several purposes, each with their own types of classification scheme.

  1. It can be categorised according to its formal type, which may govern the syntax of the short definition, determining for example whether there is an action verb or other components. For example, the formal types given in the EQF are: knowledge; skill; competence.
  2. It may be categorised according to its economic sector. This will in turn govern which other classification schemes are relevant.
  3. It may be related to any number of relevant classification schemes, for example, subjects, products, occupations.

Because all these classification schemes have similar requirements for structure, they are here given within the same model structure, which is borrowed from Atom [5].

3.1   * category (container) atom:category
3.1.1 1 term string or URI atom:term
3.1.2 0..1 scheme string or URI atom:scheme
3.1.3 0..1 label string atom:label

Formal type

Agricultural learning outcomes fall into the normal pattern of abilities (skills or competences, or sometimes known as "performance criteria") and knowledge. It is seen as useful to make this distinction here, as this will determine whether the item has an action verb or not. Another common formal type classification follows the EQF: knowledge; skill; competence. The issue here is that skill and competence do not have different forms, and they may be difficult to distinguish objectively.

Economic sector

For European use, the proposed scheme is the Statistical Classification of Economic Activities in the European Community, Rev. 2 (2008), commonly referred to as "NACE". The NACE Rev. 2 classification scheme should be used the economic sector specifically relevant to the particular learning outcome. As NACE has no defined URI, element 3.1.1 should contain the string "NACE2"; element 3.1.2 should conform to the format given in the standard reference – i.e. EITHER a single capital letter OR two digits, optionally followed by a '.' character and more digits. Agriculture covers "A" by itself, and any numeric code starting with "01", "02", or "03". A letter MUST NOT be followed by numbers, as this is not a standard representation. Element 3.1.3 may contain any relevant string, preferably in the default language given in 1.2.

Agricultural classification schemes

The AGROVOC vocabularies may be used to indicate topics connected with a particular learning outcome or competence. If using AGROVOC, element 3.1.1 should contain the string "AGROVOC"; element 3.1.2 should contain the numeric AGROVOC code; and element 3.1.3 should contain any appropriate AGROVOC label, preferably in the default language given in 1.2.

Any other classification scheme may also be used, but for an effective adaptation to agriculture, particular allowed classification schemes should be listed. AGROVOC would be an obvious choice for topics related to a particular competence concept. It may also be agreed, for example, only to use the simple distinction between ability and knowledge for the formal type. These would be a matter of agreement between the stakeholders involved.

 
4   0..1

relations with other definitions

(container) -
4.1   * single relation (container) -
4.1.1 1 relationship URI vocabulary
4.1.2 1 other definition URI URI -

The vocabulary for relationships is based on SKOS with a little refinement. See more detailed discussion in the eCOTOOL Competence Model (D1.4), Section 5: "The eCOTOOL Competence Model (Technical)".

The basic relationships for hierarchical structures are skos:broader and skos:narrower, but for greater applicability these need to be supplemented with the information about whether they refer to necessary or optional parts. Therefore four extra sub-properties are introduced here. Optionality is more essential for defining qualification and curriculum structures than pure competence structures, but optionality may also be useful even there, if there is more than one way of achieving a desired outcome.

  • skos:narrower
    • eloc:hasNecessaryPart
    • eloc:hasOptionalPart
    • skos:narrowMatch
  • skos:broader
    • eloc:isNecessaryPartOf
    • eloc:isOptionalPartOf
    • skos:broadMatch
  • skos:closeMatch
    • skos:exactMatch
  • skos:relatedMatch
for skos:
the URI base is http://www.w3.org/2004/02/skos/core#
for eloc:
the URI base remains to be determined

These are the proposed meanings of the SKOS mapping properties [3]:

  • skos:exactMatch → this definition is recognised as equivalent to the other one
  • skos:broadMatch → this definition covers a subset of the other one
  • skos:narrowMatch → this definition covers a superset of the other one
  • skos:closeMatch → this definition overlaps with and is similar to the other one
  • skos:relatedMatch → this definition is related to the other one in a looser or different way

Within a sector, it is often useful to know how one particular definition of skill or competence relates to other commonly used definitions. The relationships here allow that, as well as enabling the clearly necessary hierarchical relationships within a single framework.

 
5.   0..1

level attribution

(container) -

Level attribution is not the same as level definition. It relies on a pre-defined level scheme or framework, and the level scheme cannot be defined within a single competence definition. The attribution associates the competence concept with a level in a scheme. Some sectors have sector-wide level schemes, and specifying which level schemes to use gives a good way of adapting this to a particular area of economic activity.

5.1   * level (container) -
5.1.1 1 scheme identifier string or URI -
The scheme is the overall framework that defines the levels. A commonly used scheme in Europe is the EQF. Nations have their own national frameworks. International level frameworks also exist. At present, few if any schemes have URIs, but they are needed for unambiguous identification. Note that the EQF itself comprises three distinct schemes, for knowledge, for skills, and for competence, and each one needs to be identified differently.
5.1.2 0..1 level identifier string or URI -
At least one of level identifier and level number is required. Where the levels are identified solely by numbers in the right sense, the level identifier and level numbers may be the same. The level identifier may also be used as a text label, where there is an effective level number.
5.1.3 0..1 level number number -
This may be used in addition to a level identifier in cases where the level identifier is not itself a number, or where the level identifiers are numbers in the wrong sense. It may also optionally duplicate a number present in the level identifier. If it is used, a higher level must be represented by a larger number. The number assigned need not necessarily be one explicitly defined in the level scheme. It could alternatively be a number between those defined. A level number may only be used without a level identifier in cases where the level scheme is unambiguously numeric in the correct sense.
 

Notes

[1] ISO 639-1 language codes
Viewable at Wikipedia or the Library of Congress.
The ISO codes are suggested for the Dublin Core dcterms:language, and referenced both by the XML documentation and by RFC 5646.
[2] Dublin Core
See the DCMI Metadata Terms
[3] Simple Knowledge Organization System
See http://www.w3.org/2004/02/skos/
[4] XHTML
An effective interoperability specification might need to specify a subset or profile of XHTML, to allow links and formatting, but probably not embedded content.
[5] The Atom Syndication Format, section 4.2.2
See http://tools.ietf.org/html/rfc4287