Whether or not the standard in some sense “solves” the problem, my experience is that this kind of interrelationship between different structural forms is not clear to many people. It was clear to me that the structures are in some ways interchangeable, but the interesting point to me is the psychological differences involved in the variations between what an identifier is understood as identifying, according to the different ways of formally structuring the information. Does anyone have any insights to share on this point?

these issues and questions were addressed and heavily discussed during the last nine years and are solved through international consensus by the ISO metadata framework standard ISO/IEC 19788-1 (MLR – Part 1: Framework).

The general idea is that everything can be expressed by elements, propoerties and their relations including any combinations of relations.

Any new relation can be established and defined by following the provided rules that are the core of this international framework standard.

The following parts of the multi-part standard will provide application profiles of Part 1.

I hope that you can find access to it (as you can only order it at ISO or your national standardization body).

Best wishes
Christian

I didn’t express myself properly. I agree that the description of a framework may be long; just that the way you describe a framework is naturally different from the way you describe a single competence concept / object.

I’ll need to allow a long description of the framework in the next diagram version!

I think your description of Atom vs. disjoint vs RDF is very helpful. Certainly the disjoint model is by far the most appealing and intuitive for health education.

Your pizza example, with the way the structure changes, is simplified but certainly does represent some of the changes we might see in health care.

Of all the frameworks I have seen in health care, none of them depend on their relationships to define an object. That is, any given object has a robust title and perhaps a definition; one does not depend on the fact that A is broaderthan B and broaderthan C to give A meaning. A can be understood independently and in its own right.

I agree with the notion that one should be able to change the structure without having to change the identifiers of the objects. The identifier of an object should only change if a significant and practically meaningful change to the text of the object occurs.

Your only argument that troubles me is, “The structure should not, however, have a long description anything like an ability concept.” As I have seen in health care, almost EVERY structure document/framework has a description, often a lengthy one, attached. This description may not contain the same kind of descriptive information that the description of a competency object would, but it is descriptive nonetheless. It is a narrative that tells humans what the framework is about, why it was designed, how to use it, etc. I believe the link betweent his information and the structure should not be discarded; in the MedBiq spec (as it is currently) we allow a element.

Sure, the final diagram is simply a staging post along the way, intended to reveal the changes from the previous version that was put up in #13. It is intentionally very much incomplete, and the task of the next couple of posts in this series is to fill it in. So your remark here is quite reassuring…

The use case is not only possible, it is quite close to a real example, just that I wanted to get the post out before I had the time to give chapter and verse. The fact is that in many NOSs, a unit was divided into maybe two elements. Look back at my post 8, where I introduced LANTRA unit CU5 (a common unit appearing across several NOS documents). It is called “Develop personal performance and maintain working relationships”, and was in May 2007 divided into two elements, “Maintain and develop personal performance” and “Establish and maintain working relationships with others”.

Look at similar NOS documents today, however, and the two elements are now units in their own right, CU5 and CU5A. Not exactly the case I was citing, but pretty near. There seems to have been a move to eliminate a level of structure from NOSs, and I wouldn’t be surprised if the kind of case I suggested was actually directly true.

I do agree that the ultimate arbiter of whether something has changed “substantially” is the author. Everyone wants people to be able to correct mistakes without having to coin a new identifier.

I’ll wait to see how it pans out before giving an opinion on the updated nested abilities approach. But, as you know, I wouldn’t go there for several other reasons.

I’m not sure about the example where you’ve eliminated one level of structure either. I’m not a competencies expert, but would a structure change like this? “rather flimsy, and removes it” seems a poor reason to make this type of change. I would suggest that this type of change might more usually be the result of a substantive change to the top level ability; therefore requiring another version. I accept that it *might* happen in the way you’ve described, but it doesn’t ring true as a definitive use case.

I’m coming round to the view that an ability identifier changes when the author wants it to. As an information wrangler I’d rather not manufacture unnecessary rules for the authors and other technical users of the data structures. So if a piece of structure changes in part of an ability definition, but the author doesn’t consider it important enough to change the identifier of the ability, or even a version number, then I’d stick with the author’s view. Of course, I’d certainly hope that the author’s systems were robust enough to have internal rules or guidance to the author. For example in a university validation system a programme probably doesn’t need re-validation if a single optional module changes, but it certainly would do if a core module delivering a specific programme level learning outcome were to be removed.

This approach puts the responsibility where it belongs – with the author. It also means (I think) that we can use a nested abilities approach, refreshing our re-used abilities whenever a change is indicated. Still need to work on specific use cases though.