E-mail
Attending: Joel Farrell, Dan Rehak, Carl Singer, Valerie Smothers
Review of Web Services Guidelines Updates
The group went through the Web services guidelines and made minor edits. Valerie asked whether the example in section 10.4 should use the member services WSDL. Joel recommended keeping the current example and adding a link to the member services. Joel asked that Valerie post the revised document when complete and publicize to the MedBiquitous community.
ID Issues
Valerie provided some background on the OID question that was circulated to the group via e-mail. David Stumpf of United healthcare participated in the metrics working group meeting at the annual conference. During the meeting he questioned whether the group should use OIDS to identify survey items. He then sent more information to several people on the working group. Valerie questioned whether he wanted to make an official comment as part of the public review of medical education metrics. David responded with a formal comment on SCORM for healthcare, which was forwarded to the committee. SCORM for healthcare is outside of the scope of the public review. Such comments are submitted to the MedBiquitous executive committee as proposals for new standards development. Valerie would like the technical steering committee to provide some guidance to the executive committee regarding David's comments.
Joel asked how identification is currently handled in SCORM. Valerie replied that there is a catalog and entry within learning object metadata. Dan further clarified that the catalogue is a free text field. There are inconsistencies across how people have used the catalogue element, but it can specify that the entry is a URI or handle, among other things.
Carl commented that the comments are not within the purview of MedBiquitous. They may be something for ADL or LETSI to consider. Having a link to content does make sense, he added.
Dan added that you can end up with complex models of identification and registries to support them. Several people have party looked at this problem and there is no broadly accepted practice. He expressed a broader concern; that we may be heading down a road that each individual committee does identity differently. Implementer has to build similar registries because we haven't issued broader guidance.
Valerie commented that for finding content, particularly from with in electronic health records as David is interested in, we have looked at info buttons. That is a well-established standard designed for that scenario. With regards to how committees handle identity, there are different practices in different groups. The activity report uses a you are end called CCID for identifying credit certificates. The CC ID has the following format:
ccid:domainname:localidentifier
in contrast, medical education metrics uses a source/id pair, similar to catalogue and entry used in lom.
Joel recommended appending a summary paragraph to Dan's e-mail and forwarding that to the MedBiquitous executive committee. The e-mail with revisions appears below.
Assigning IDs in becoming more important, but still a mixed bag of solutions.
Standardization and best practices are generally applied in repository standards and specs, not in content specs. People don't want to overload the content spec with a "how to use" statement. Doing it in profiles of a content spec is OK.
Repository specs and projects focus on the general idea of assigning IDs and specifying their capabilities, but assume that a particular community will make the final decision of which ID choice to use. There is too much existing content and too many religious wars over which type of ID to use to specify any particular ID scheme in the spec. Communities then profile the spec to use one, or typically to use many types of ID, one stated by the community and any others that individual content producers want to use.
The most "common" community choice has been Handle for the "required" type of ID that must be present in addition to any producer assigned IDs.
There is an ongoing "open" IMS process to do a generic repository spec (LODE) that can be profiled. In part, it tries to model content at different levels, e.g., an ID for a SCO that is independent of where it is actually stored or encoded, and then other IDs for encoded or stored instances, so someone could reference the SCO without knowing which instance or encoding they wanted. This is still early work; good ideas but not wide-spread experience.
Assigning an ID typically brings with it some assumptions about what the ID means and what you can do with it, i.e., it is unique, it references sone thing, it is managed in some way over some known period of time (e.g., to permit defererencing), it is trusted, ... Developing policies, how to use guideance and goverance has been harder than technology.
The identifier element of LOM allows developers to include an identifier for SCOs and other types of content. Repositories and communities of practice can establish their own policies with regard to what type of identifier to use in that field. In the TSC's opinion, the format of the identifier should not be included in the standard.