Child pages
  • 2011-09-07
Skip to end of metadata
Go to start of metadata

Meeting Information


September 7, 2011


8 PDT/11 EDT/16 BST

Attending: Tim Willet and Rosalyn Scott, co-chairs; Susan Albright, Mary Pat Aust, Dana Bostrum, Bob Englander, Simon Grant, and Valerie Smothers.

Agenda Items

1. Review minutes of last call

Tim summarized that on the last call Ann Burke and Bob Englander joined and reviewed the pediatric milestones and related challenges. That helped us understand the state of the effort. We will continue to have discussions with Bob and others. Once the Competency Framework is done, we can look at performance levels.  At the end of the call, Valerie presented documents submitted to ANSI. The public review of our announcement is complete, and there were no comments.

The minutes were approved.

2. Review minutes of TSCcall

Tim and Rosalyn spent a full hour speaking about work to date with the Technical Steering Committee (TSC). They specifically talked about the new includes element and allowing a framework to include a framework or allowing an object to be broader than a framework. They were fully supportive. They noted it could be challenging for a system resolving competency frameworks; the system would have to know how to interpret the relations. They also agreed that if using a portion of a framework the relations have to be restated. We got into early discussions about what to do when competency objects are retired. They did suggest that Competency Framework spec, Competency Object spec or both have an element that indicates if something is active or inactive. That requires more discussion.  Dan Rehak also suggested making it clear in the standard that hierarchical conflicts are forbidden.

3. Review updates to spec

Valerie reviewed the changes to the specification. Simon recommended defining hierarchical conflict. Valerie offered to follow-up with Dan Rehak about that. Susan recommended providing an example.

Tim clarified that any competency object referred to in a relation must also appear under includes, but that the opposite is not true. The group recommended adding language to clarify that to the definition of includes: “including anything included in a relations reference” pg 18/19.

4. Discuss next steps - see Retiring a CO

Valerie asked whether the standard was ready to submit to the standards committee.

Tim replied that further discussion of versioning was required. We don’t want to lose track of old competency objects. There are multiple ways to solve that problem that may require other information in the framework.

Susan asked if there was a situation where someone starts and finishes according to an older competency framework, but a newer framework would apply to newer students. The group agreed that could be the case.

Tim commented that if it is a minor change, like spelling change, you can use the same url. If there is a substantive change, we would require a new competency object to be published, and the old would be retired. We can’t say the new object replaces the old. The old object may be replaced by 2 or 3 competencies. Or 2 competencies could be replaced by 1.

Simon recommended using validity dates. Tim replied that publishers would not know when an object expires when they first publish it. Simon replied that you could leave the expiry date blank until the object is retired.

Tim created a new wiki page, retiring a Competency Object.

He added that you want people to map to version 2, but you don’t want version 1 mapping information lost. You still want people to find learning objects mapped to F when they look for learning objects related to D.

Rosalyn commented you can search for content using a specific version of a competency framework.

Tim agreed that if we allow the publication of multiple versions, systems should be aware of multiple versions. Another way to do this would be to mark the competency object as active/inactive. The Link from D to F could persist in the Competency Framework but be marked as inactive. Rosalyn commented that would get quite complex over time.

Susan commented that in software you often have a change history. Can we have that?

Tim replied that change history is usually human readable; the question is should there be something machine readable.

Rosalyn commented that changes should probably be text.

Simon commented that if you have a replaces and replaced by and attach dates, the software could chain through the links to determine the change history.

Rosalyn commented that having the ability to include a human readable change section would be good. Tim commented that could be available as supporting information. Susan recommended adding that to Best Practices.

The group asked Valerie to investigate Dublin Core and see if it provides a way to indicate that one document is a new version of another. Valerie agreed.

[Note: Dublin Core has isReplacedBy and replaces. LOM has the status element which has the following values:

  • draft: The component is in a draft state (as determined by the developer).
  • final: The component is in a final state (as determined by the developer).
  • revised: The component has been revised since the last version.
  • unavailable: The status information is unavailable.

There is no concept of an expiration date in Dublin core, but there is an expiration date in healthcare lom. LOM also has the concept of a publication date. i would propose adding a Status element and adding the Dublin Core isReplacedBy and replaces.]

Susan agreed to run the changes past Isarin.

Tim asked Valerie to go through the unresolved issues page and make sure the spec reflects the contents.


  • A human readable description of the change history of a competency framework should be included using the Supporting Information element as a best practice.

Action Items

  • Valerie will clarify the definition of hierarchical conflict and provide an example.
  • Valerie will add “including anything included in a relations reference” to the description of the includes element.
  • Valerie will investigate Dublin Core and see if it provides a way to indicate that one document is a new version of another. She will present solutions to the problems proposed for the next call.
  • Valerie will review the unresolved issues page and update the spec to reflect those decisions.
  • No labels