The following items are to be included in an implementation guide/best practices guide.
- a thorough explanation of the term related as well as examples
- the recommendation to define competency categories in a URI referenced document if they are used
- the URI should be referenced in the scheme attribute of category
- A set of best practices around versioning, including:
- old versions should be retired, not deleted
- If a competency object changes in meaning, it should have a new identifier and its relationships within a competency framework should be reviewed.
- If more comprehensive change management is required, IMS lode should be used.
- Competency frameworks that change should have a new identifier.
- Strikeout/diff versions of changes to frameworks or competencies may be included using the supporting info tag.
- Recommend creation of two URI's for a framework: one that points to the specific version of the framework and one that points to whatever the most recent version is (look at w3c versioning and uris)
- Explore whether or not to include "retired" competencies in a new version of the framework with some indication that they are retired.
- If a competency does get retired, something in the comeptency object should indicate that it is no longer active. Things can still reference that object, but they will see it is no longer active.
- Develop best practices on how long retired frameworks and objects must be kept aropund - 20 years?
- A human readable description of the change history of a competency framework should be included using the Supporting Information element as a best practice.
See Competency Framework Implementation Guidelines.
Sample Competency Framework - Breakfast Cook