Fortunately, no one’s comments here affect this, so I think I’ll just go ahead and do it. If you want to know what I used to think, please ask!

Alan

The issue seems clear to me. The consequence of the approach you describe here is that if an ability appears more than once in a framework (and they often do) it will either be duplicated or some extra mechanism will have to be brought in (as I think Karim was mentioning) to cross-refer between the separate instances of the same subsidiary ability.

The approach I recommend is, rather: that all the constituent abilities are listed, flat; and that all the relationships are listed. I would have thought that this approach is actually easier, not more difficult, to translate into a relational database, as it is structured in a similar way.

Bearing in mind what Simon has said:
“One does not author a structure independently of authoring the concept definition itself.”
“The structure cannot be represented without the main concept definition.”

Our view is that ‘the structure’ is part and parcel of the competence definition itself. In fact a ‘competence’ without a structure is simply a competence that hasn’t yet been de-composed, or doesn’t need further decomposition. Therefore, in information management terms, we have an ‘ability’ that is usually related to one or more other abilities via defined relationships (which may use SKOS relationships). In many cases these will be of the narrowerThan / broaderThan type, though other types are readily envisaged.

In this approach, defining a competence includes defining a structure, if there are relationships to sub-competences or siblings. Whether or not to define a structure becomes a matter for the author and is related to the usage to which the competence will be put. If the competence is part of an NOS, for example, then a rigorous approach to structure will be needed. If the competence is a broad-brush skill for a ‘once off’ application in an ePortfolio, for example, then it may be unstructured.

In our approach the competence therefore has a single identifier (and we naturally hope / expect that to be a URI leading to human-readable and computer-consumable material of defined types).

We then get a structure like this:

Ability
. Relationship
. . TypeOfRelationship
. . Ability
. . . Relationship
. . . . TypeOfRelationship
. . . . Ability
. . . Relationship
. . . . TypeOfRelationship
. . . . Ability
. . . Relationship
. . . . TypeOfRelationship
. . . . Ability
. Relationship
. . TypeOfRelationship
. . Ability
. Relationship
. . TypeOfRelationship
. . Ability

Or of course:

 Ability