Child pages
  • Working Page... Inter-Competency Relationships
Skip to end of metadata
Go to start of metadata

The table below summarizes the potential features of intra-competency relationships being considered by the group, as well as the proportion of reviewed outcome frameworks and survey respondents who wish to express the feature.

Relationship Element

Explanation

% of organizations surveyed that use element (n=23)

% of reviewed frameworks that include element (n=11)

Proposed status for our specification

Other comments

Unique ID

A UID for the relationship itself

n/a

0

Required. alphanumeric.  one only.

 

Type

The logical type of relationship

91 (hierarchical); 68 (non-hierarchical)

100 (hierarchical); 
9 (non-hierarchical)

Required. Controlled list.  One type only per relationship.

Consider using SKOS standard.  See table below for further discussion.

Qualifier/Quantifier

Data about the link itself (rather than about the competencies), e.g. strength of relationship

-

0

Exclude.

Have no concrete examples for this yet.

Classes

Groupings of competencies (under categories, roles, etc.)

100

-

Exclude.

This is better represented as a higher level in the hierarchy.

Competency Framework Metadata

Metadata fields to describe the framework itself (rather than the Competency Objects within it)

82

100

Include.  Specific elements not yet determined.

May include:

  • Framework title
  • Description
  • Version
  • Copyright
  • Authors
  • Publisher
  • etc.



Below is a running list of types of relationships that may exist between two competencies, as identified by the members of the working group.  This list will help the group to understand the nature of competency frameworks in use, and the kinds of relationships the MedBiq specification ought to facilitate.  Please note this list represents relationships between two competencies within the same framework only; we will later investigate the types of relationships that may exist between competencies and other data (eg. learning objects, curricula, etc.).

Please review the list as it exists and feel free to use the "Edit" tab of this page to add more items to the list!

All relationships are listed in the form "X has relationship to Y," which can be interpreted as "Competency X has relationship to Competency Y." 

Relationship Type

Description

Logical Implications

Proposed status for our specification

Comments

X is a parent of Y

Standard logical hierarchical type of relationship.

Implies Y is a child of X (Y is a sub-competency of X; Y is a part of X).  Logically, also implies that attainment of Y contributes partially to the attainment of X.

Include.  Multiple children and/or parents allowed per competency.  Circular links prohibited (e.g. X is a parent of Y, which is parent of Z, which is a parent of X).

Do we need a way to quantify how much Y contributes to X?  Do we need to specify whether Y is necessary or sufficient for attainment of X?

X enables Y

Competency X must be attained before competency Y can be attained, because X enables Y, but there is not necessarily a hierarchical relationship.

Implies that someone who has attained Y has also attained X.

Exclude.

Represented by X being a child of Y.  Group could not think of an example where this was not sufficient.

X see also Y

Might be used to draw a user's attention to other competencies in the framework that are similar to X, but not logically related to X.

None.  Used only to inform the viewer of similar competencies that might be of interest.

Include.

For example, a competency related to IV insertion might be similar to a competency related to rehydration therapy.

X supports Y

Two distict competencies, where Y is performed better if X is also attained.

None.

Exclude.

As suggested by Ronald Harden as a way to laterally relate the three circles of the Scottish Doctor.  On further discussion, it seemed too complicated (i.e. depends on the learner in question, context, etc.) to be hard-coded into the framework.

X and Y enable each other

?

Implies that someone who has attained X or Y has also attained the other.

Exclude.

As suggested by David Price.  Is this the same as X enables Y plus Y enables X?  Decision to exclude based on lack of example and complexity as per item above.


  • No labels

5 Comments

  1. I would propose to replace superficial pre-requisite relation with  enabling one having more sound sense.

    I already did necessary corrections, which you are welcome to undo

    Thanks

    Vlad

  2. I would also add "is a part of" relation, which is very fundamental. So, the whole picture may look like follows:

    • X is a part of Y.  (all content of X belongs to Y) Standard logical type of relationship.  Implies simply that entire X is a part of whole Y (e.g., X is a sub-competency of Y).  Logically, also implies that attainment of X contributes partially to the attainment of Y. Implies also that someone who has attained Y has definitely attained X.
    • X enables Y.  (some content of X belongs to Y) Competency X is worth to attain before competency Y can be attained, because X enables Y, but X is not necessarily is a complete part of Y.  Implies that someone who has attained Y may also attained some of X.
    • X is similar to Y. (content of X and Y is the same) Might be used to draw a user's attention to other competencies in the framework that are similar to X.  Could be thought of as a "see also" type of relationship.  For example, a competency related to IV insertion might  be similar to a competency related to rehydration therapy.
    • X is a parent of Y. (content is different) Standard hierarchical relationship among autonomous self-sufficient entities.  Implies Y is a child of X.  Logically, also implies that attainment of X provides the context for the attainment of Y as well as that attainment of Y may contribute to attainment of X. Implies also that someone who has attained X may also attained Y, which is not necessarily. Example: complete self-sufficient parent X may include a link to "more detail", which is a self-sufficient child Y.

    But it requres polishing yet.

    Thanks

    Vlad

  3. Thanks for contributing, Vlad.  Could you clarify how "X is a part of Y" is NOT simply the inverse of "Y is a parent of X"?
    Tim

  4. Tim, you are right:

    1) if we define a parent Y as an entity including its child X completely, then "X is a part of Y" = "Y is a parent of X".

    2) If we define a parent Y as an entity including its child X partially, then "X enables Y" = "Y is a parent of X".

    3) we can also define that a parent  Y and child X as autonomous self-sufficient entities having different content. (as I did it above in my 2nd comment)

    Looks like I was wrong, a parent-child relation can be derived from any 3 basic relations (not just from one):

    • X is a part of Y.  (all content of X belongs to Y) Standard logical type of relationship.  Implies simply that entire X is a part of whole Y (e.g., X is a sub-competency of Y).  Logically, also implies that attainment of X contributes partially to the attainment of Y. Implies also that someone who has attained Y has definitely attained X.
    • X enables Y.  (some content of X belongs to Y) Competency X is worth to attain before competency Y can be attained, because X enables Y, but X is not necessarily is a complete part of Y.  Implies that someone who has attained Y may also attained some of X.
    • X is similar to Y.(content of X and Y is the same) Might be used to draw a user's attention to other competencies in the framework that are similar to X.  Could be thought of as a "see also" type of relationship.  For example, a competency related to IV insertion might  be similar to a competency related to rehydration therapy.

     So it is up to us, which definition of a parent or child to use.

    Any idea which one (or many) do we need?

     Thanks

    Vlad

  5. From further discussions with the group, it seems we definitely need some kind of parent-child relationship.  In the case of "X is a parent of Y" we still have to decide whether:

    • This means all of Y is part of X (i.e. Y is part of X; and Y enables X);
      • Could also imply that having attained X, one has definitely attained Y (i.e. Y is necessary for X);
      • Or could not make this implication (i.e. Y is part of X but not necessary for X);
    • This means some of Y is part of X (i.e. Y enables X).  In this case, if one has attained X, they have attained some part of X; or
    • We leave it to the end-user to select what the hierarchical relationship means.

    For the sake of simplicity, I lean towards the first definition.  In all the competency frameworks I reviewed, the impication was that children are part of their parent comptencies.  What the frameowks did not explicitly state, however, is whether all children were necessary for a learner to achieve the parent.

    There is also definite need for a "see also" relationship that carries no logical implications - it simply directs the viewer to similar competencies that might be of interest.