Representing defining and using ability competency and similar concepts

Practicalities

For definitions to be published

What we want is a feasible path for people to adopt this approach in gradual stages, each of which is easy, offers adequate motivation, and makes sense in itself. If you like, you could see this as development methodology for the approach as a whole. If people can agree on a direction, not necessarily to implement in the short term, then gradual progress can be made in a coherent direction so that the effort that is put in is not wasted.

The progress through these steps may take substantial time. The revision cycle for public definitions of ability or competence is typically years, so even when people agreed the route they wish to proceed along, it is likely to take years to implement fully. The important step in every case is the first available one along the path. In nearly all cases, this is currently step one.

1. Accept any kind of plain web pages as definitions of ability or competency, at stable URLs. This will at least allow human reading, and provide usable URLs.
2. Convert to "Cool URIs". To do this fully may entail:
• creating a URI for each ability concept, not directly corresponding to a web page
• establishing a "303" redirect to a web page giving information about the concept
• making that information page machine processable to extract semantic data.
3. Further steps depend on the kind of web page chosen for the URI to resolve to.
• If plain HTML, put in link elements in the head to represent the RDF.
• If XML in RCDEO or RDC format, put RDF into the metadata section. (This needs further elaboration.)
• If XHTML, use RDFa
4. Add RDF with SKOS mapping properties initially by bilateral agreement: pairs of defining agents agree mutually to refer to each others' definitions.
5. As bilateral agreements become too cumbersome, encourage the evolution of common definitions.

For individual definitions

In a portfolio, people sometimes want to describe their own abilities in terms that are not necessarily commonly used, or directly applicable to requirements for positions. In this case, the ability can could be described just within a claim to possess the ability, and not have any independent identifier. If, however, the author wants to describe an ability and refer to it beyond a single claim to have it, it would make sense for it to be defined within the portfolio itself. At least when information concerning that ability was transferred between different systems, the ability would have a separate, internal identifier, and that would allow it to be identified as part of any package of portfolio information.

Similarly, for job or course requirement, those responsible can create a definition that can be referred to. A useful one may be, for example, one that spells out parts that contribute to it, using better-known definitions.

In each case, ideally the definition would have SKOS mapping property links with other, better known definitions. A standard way of doing this is yet to be agreed.

Next: qualification and assessment.