Structural relations for competence concepts

(13th in my logic of competence series)

My recent thoughts on how to represent the interplay between competence definitions and structures seem to be stimulating but probably not convincing enough. This post tries to clarify the issues more thoroughly, at the same time as introducing more proposals about the structural relationships themselves.

Clear explanation seems always to benefit from a good example. Let me introduce my example first of all. It is based on a real ability — the ability to make pizzas — but in the interests of being easy to follow, it is artificially simplified. It is unrealistic to expect anyone to define a structure for something that is so straightforward. But I hope it illustrates the points fairly clearly.

I’m imagining a British Society of Home and Amateur Pizza Makers (BSHAPM), dedicated to promoting pizza making competence at home, through various channels. (The Associazione Verace Pizza Napoletana does apparently exist, however, and organises training in pizza making, which does have some kind of syllabus, but it is not fully defined on their web site.) BSHAPM decides to create and publish a framework for pizza making competence, liberally licenced, that it can be referred to by schools, magazines, and cookery and recipe sites. A few BSHAPM members own traditional wood-fired pizza ovens which they occasionally share with other members. There are also some commercial pizza outlets that have an arrangement with the BSHAPM.

The BSHAPM framework is about their view of competence in making pizzas. In line with an “active verb” approach to defining skills, it is simply entitled “Make pizza”. The outline of the BSHAPM framework is here:

  • prepare pizza dough
    • with fresh yeast
    • with dried yeast
    • with non-yeast raising agents
  • form dough into a pizza base
    • by hand in the air
    • with a rolling pin on a work surface
  • prepare a pizza base sauce from available ingredients
  • select, prepare and arrange toppings according to eater’s needs and choices
  • prepare complete pizza for baking
  • bake pizza
    • in kitchen oven
    • in a traditional wood-fired oven
    • in a commercial pizza oven

The framework goes into more detail than that, which will not be needed here. It also specifies several knowledge items, both for the overall making pizza framework, and for the subsidiary abilities.

Clearly the ability detailed in the BSHAPM “make pizza” framework is a different ability to several other abilities that could also be called “make pizzas” — for instance, the idea that making pizzas involves going to a shop, buying ready-made pizzas, and putting them in the oven for an amount of time specified on the packaging.

As well as the BSHAPM framework, we could also imagine related structures or frameworks, for:

  • all food preparation
  • general baking
  • making bread
  • preparing dough for bread etc.

So, let’s start on what I hope can be common ground, clarifying the previous post, and referring to the pizza example as appropriate.

Point 1: Frameworks can often be seen as ability definitions. The BSHAPM concept of what it takes to “make pizza” represents an ability that people could potentially want to claim, provide evidence for, or (as employers) require from potential employees. It could be given a long description that explains all the aspects of making pizza, including the various subsidiary abilities. At the same time, it defines a way of analysing the ability to make pizza in terms of those subsidiary abilities. In this case, these are different aspects or presentations of the same concept.

Point 2: Each component concept definition may be used by itself. While it is unlikely that someone would want to evidence those subsidiary abilities, it is perfectly reasonable to suppose that they either could form part of a course curriculum, or could be items to check off in a computer-based system for someone to develop their own pizza-making skills. They are abilities in their own right. On the other hand, it is highly plausible that some other curriculum, or some other learning tracking system, might want not to represent the subsidiary abilities as separate items, particularly in cases where the overall competence claimed were at a higher level. In this case (though not generally) the subsidiary abilities are reasonably related to steps in the pizza making process, and we could imagine a pizza production line with the process at each stage focusing on just one subsidiary ability.

Point 3: The structure information can in principle be separated from the concept definitions. Each ability definition, including the main one of “make pizza” and each subsidiary one, can be defined in its own right and quoted separately. The “rest” of the framework in this case is simply documenting what is seen as part of what: the fact that preparing pizza dough is part of making pizza; baking the pizza is part of making pizza, etc., etc.

Point 4: The structure information by itself is not a competence concept, and does not look like a framework. One cannot claim, produce evidence for, nor require the structural links between concepts, but only items referred to by that structure information. It is stretching a point, probably beyond breakage, to call the structural information by itself a framework.

Point 5: Including a structured ability in a framework needs choice between whether to include only the self-standing concept or to include all the subsidiary definitions. To illustrate this, if one wanted to include “make pizza” into a more general framework for baking skills, there is the question of the level of granularity that is desired. If, for example, the subsidiary skills are regarded as too trivial to evidence, train, assess, etc., perhaps because it would be part of a higher level course, then “make pizza” by itself would suffice. It is clearly the same concept though, because it would be understood in the same way as it is with its subsidiary abilities separately defined. But if all the subsidiary concepts are wanted, it is in effect including a structure within a structure.

These initial points may be somewhat obscured by the fact that some frameworks are very broad — too broad to be mastered by any one person, or perhaps to broad to have any meaningful definition as a self-standing competence-related concept. Take the European Qualifications Framework (EQF), for example, that has been mentioned in previous posts (4; 10). We don’t think of EQF being a single concept. But that is fine, because the EQF doesn’t attempt to define abilities in themselves, just level characteristics of those abilities.

There are other large frameworks that might be seen as more borderline. Medicine and the health-related professions provide many examples of frameworks and structures. The UK General Medical Council (GMC) publishes Good Medical Practice (GMP), a very broad framework covering the breadth of being a medical practitioner. It could represent the structure of the GMC’s definition of what it is to “practice medicine well”, though that idea may take some getting used to. The question of how to include GMP in a broader framework will never practially arise, because it is already quite large enough to fill any professional life completely. (Ars longa, vita brevis…)

It is for the narrower ranges of ability, skill or competence that the cases for points 1 and 5 are clearest. This is why I have chosen a very narrow example, of making pizza. For this, we can reflect on two questions about representation, and the interplay between frameworks and self-standing concept definitions.

  • Question A: What would be a good representation of a structure to be included within a wider structure?
  • Question B: What difference is there between that and just the main self-standing concept being included?

So let’s try to elaborate and choose a method for Point 3 — separating self-standing concept definitions from structural information. Representing the self-standing concepts is relatively clear: they need separate identifiers so that they can be referred to separately, and reused in different structures. The question to answer first, before addressing A and B is how to represent the structure information.

  1. Option one is to strip out all the relations, and bundle them together separately from all the concept definitions. “Make pizza” at the broadest, and the other narrower abilities including “bake pizza”, would all be separate concepts; the “structure for” making pizza would be separately identified. The “make pizza” framework would then be the ensemble of concept definitions and structure.
  2. Option two is to give an identifier to the framework, where the framework consists of the concepts plus the structure information, and not give an identifier to the structure information by itself.

Let’s look again at this structural information with an eye on whether or not it could need an identifier. The structural information within the imagined BSAPHM framework for making pizza would contain the relations between the various ability concepts. There would be necessary part and optional part relations. A necessary part of making pizza the BSAPHM way is to make the dough, but how the dough is made has three options. Another necessary part is to form the pizza base, and that has two options. And so on.

So, perhaps now we are ready to compare the answers to the questions A and B asked above. To include one self-standing concept in another framework requires that the main concept is represented with its own identifier, because both an identifier for the framework, and an identifier for the structural information, would imply the inclusion of subsidiary abilities, and those are not wanted. To include the framework as a whole, on the other hand, there is a marked difference between options one and two. In option one, both the identifier for the main concept and the identifier for the structural information need to be associated with the broader concept, to indicate that the whole structure, not just the one self-standing concept, is included in the broader framework. Even if we still have the helpful duality of concept and structure, the picture looks something like this (representing option 1):

2011-05-24_structural_option_1

If we had to represent the concept and structure entirely separately, the implementation would surely look still worse.

Moving forward, option two looks a lot neater. If the framework URI is clearly linked (though one structural relation) to the main concept definition, there is no need for extra optional URIs in the relations. It’s worth saying at this point that, just as with so many computational concepts, it is possible to do it in many ways, but it is the one that makes most intuitive sense, and is easiest to work with, that is likely to be the one chosen. So here is my preferred solution (representing option 2):

2011-05-23_structural

To propose a little more detail here: the types of relationship could cover which concepts are defined within the framework, and specifying the main concept, as well as the general broader and narrower relationships, in two variants — necessaryPart and optionalPart. (I’ve now added more detailed justification for the value of this distinction in post 15 in this series.)

[The following paragraph was altered after reconsideration, 2011-05-26]

One of the practical considerations for implementation is, what has to happen when something that is likely to change, changes? What can and cannot change independently? It seems clear (to me at least) that if a framework changes substantially, so that it no longer expresses the same ability, the main concept expressed by that framework must also change. Evidence for a “make pizza” concept whose structure does not include preparing dough doesn’t provide full evidence for the BSHAPM concept. It is a different concept. On the other hand, if the long description of the concept remains the same, it is possible to have a different structure expressing the same concept. One obvious way in which this is possible is that one structure could for BSHAPM pizza making could include just the abilities listed above, while a different structure for exactly the same ability concept could include a further layer of detail, for example spelling out the subsidiary abilities needed to make a pizza base in the air without a rolling pin. (It looks tricky: I’ve seen it once but never tried it!) Nothing has actually changed, but it is more detailed with more of the subsidiary abilities made explicit.

These arrangements still support the main idea, valuable for reuse, that the concept definitions can remain the same even if they are combined differently in a different framework.

There are two other features that, for me, reinforce the desirability of option 2 over option 1. They are, first, that various metadata can be helpfully shared, and second, that a range of subsidiary competence concepts can be included in a framework. Explanation follows here.

[The following paragraph was altered after reconsideration, 2011-06-08]

First, I am now saying that you can’t change a framework structure substantially without changing the nature of the main competence concept that stands for competence in the framework abilities together as one. The structure or framework would probably be called be something like “the … framework” where the title of the main concept goes in place of the dots. The two titles are not truly independent, but need differentiation, because of the different usage (and indeed meaning) of the competence structure and the competence concept.

Second, if we have an identified framework including a main concept definition as in option 2, there seems no reason why it should not, in the same way, include all the other subsidiary definitions that are defined within the framework. This seems to me to capture very well the common-sense idea that the framework is the collection of things defined within it, plus their relationships. Concepts imported from elsewhere would be clearly visible. In contrast, if the structural information alone is highlighted as in option 1, there is no obvious way of telling, without an extra mechanism, which of the URIs used in the structure are native to this framework, and which are imported foreign ones.

There are probably more reasons for favouring option 2 over option 1 that I have not thought of for now — if on the other hand you can think of any arguments pointing the other way, please preferably comment below.

If I had more time to write this, it would probably be more coherent and persuasive. Which reminds me, I’m open to offers of collaboration for turning these ideas into more tightly argued and defended cases for publication somewhere.

But there is more to finish off — I would like to cover the rest of the relationships that I see as important in the practical as well as logical representation of competence.

However, after writing the original version of this post, I have had some very useful discussions with others involved in this area, reflections on which are given in the next post.

10 thoughts on “Structural relations for competence concepts

  1. lets see if it can mangle it into a form I grok

    concepts = nodes
    framework = graph = edges + nodes

    so to construct different graph and you want to refer to an external node (from another graph) with dependant nodes you might need that bit of the graph, so you need a reference to the original graph to be able to locate the sub-graph and its relevant nodes.

    clear as mud, but I think I agree with option 2!

  2. Option 2 is what we’re trying out in the InteropAbility Project (http://www.interopability.org/).

    Important note (I think) on Point 5: using ‘make pizza’ in this context implies ALL the subsidiary skills, because these are implicit in the ‘make pizza’ definition. Actually you are merely using this level of granularity for convenience – the subsidiary skills are there in the background. It’s vital not to think of this as just any old ‘make pizza’, because the competence is clearly defined and constrained by the referenced definition. What you cannot do is take this ‘make pizza’ competence, use it at a general level and show evidence that the learner can go to a shop, buy a frozen pizza and stick it in the oven (regardless of the success of the learner in that skill).

    I’ve been having interesting verbal discussions with colleagues today about what ‘re-use’ means, especially in relation to the detailed content or structure of a competence. You could re-use a competence by importing the details and making use of it within your own system. If you import someone else’s competence, you MUST (in my view) import the whole thing or at least all the references to all the subsidiary competencies, or else you run the profound risk of not realising that ‘make pizza’ includes ‘baking pizza in a commercial pizza oven’. You may choose to import and re-develop the ‘make pizza’ competence to exclude commercial pizza making – then you could (and should) publish the new competence, referring appropriately to the original ‘make pizza’ competence from BSHAPM.

    Alternatively you could simply reference the BSHAPM ‘make pizza’ competence and show your learners the competence details on screen, without storing it. Then for example your learners might log evidence against the competence, and your system can store this, using its ID. Note that if the evidence was against a subsidiary competence, the function to reference the subsidiary competence could treat this as a separate competence, logging that ID instead of the full ‘make pizza’ competence. How this is handled becomes an implementation issue, not an information model or data specification issue. We must simply ensure that each separate competence has IDs and relationships.

  3. Secondary note: why do we need separate URIs in this model for the competence and the structure? It seems to me that there is no need to separately address the structure, because the structure is an intimate and essential part of the competence.

  4. Alan, thanks for your comments.

    On the secondary note first, the point of separate URIs is twofold. Logically, the two URIs stand for different, though closely related things. The concept URI stands for the concept expressed (yes, through the structure) and the structure URI stands for the concept plus all the other concepts in their structure. It makes sense to say that you can’t evidence a structure, but only a concept.

    Then, if you want to include one structure within a broader structure, you need to know somehow if you’re including just the concept, or the whole structure of all the contained concepts plus the relations between them. Having the two distinct URIs gives you a very neat and easy way to do that, and indeed a suitable hook for an API to return different sets of information.

    I’ll reply to your other comment separately.

  5. Simon

    Re “The concept URI stands for the concept expressed (yes, through the structure) and the structure URI stands for the concept plus all the other concepts in their structure.”

    Can you give a use case for when you want to gather the structure but not the concepts in the structure, or vice versa, bearing in mind that the “concept expressed” is defined at least partly through its structure?

    Alan

  6. Alan

    I think Matt (1st comment above) got the idea OK, but still I could be clearer. I don’t see the exact requirements you mention. Indeed, I don’t rate my “option 1″ exactly because we don’t need to identify the structure without any concepts in it. My positive point is illustrated by the pizza example. It seems to me perfectly plausible that making pizza, as understood by the BSHAPM, could appear as a single node in a much wider food preparation framework, with the subsidiary abilities being only implicit in the (long) description. But for other purposes, say a lower level home baking framework, it would be useful to have all the abilities explicitly identified. The two URIs refer to those two cases, as far as I can see adequately and reasonably intuitively.

  7. I also am not sure about the need to separate out the concept and structure. The top level structure is a concept, as you say “Frameworks double as ability definitions”. So why do we need to define them separately? They’ll each have their own URI by virtue of both being competence concepts, so why do we need to call one concept and the other structure?

    And in Matt’s analysis, he says: ” to construct different graph and you want to refer to an external node (from another graph) with dependant nodes you might need that bit of the graph, so you need a reference to the original graph to be able to locate the sub-graph and its relevant nodes.” But if the sub-graph has a URI why do I need to reference the ‘original’ graph? When I access the sub-graph I can see all the dependencies from there….if I am creating a new competence for bread making that includes dough making why would I need to reference Pizza making?

    Also – if I am referencing dough making in the the pizza context then I should have to take any concepts that are dependents of dough making in this context. If they don’t apply and I want to import the competence concept then that concept is different to what I require; I am creating a NEW competence, which is different from import or reuse.

  8. Karim (and Matt)

    I’m saying we need to distinguish concept and structure because they behave differently, and we want them to behave differently.

    We have, I think, two concerns that run in parallel for building tools dealing with abilities / competence definitions. The first concern is what the ability actually involves. We can judge how much of an ability a person has independently of how we choose to structure or teach that ability, e.g. based on a long description. How we judge is rightfully more to do with assessment. The second, lesser concern is how we want to formally structure that ability. The formal structure can be in terms of a user interface — how many, and which, subsidiary abilities we want to display, track, account for, measure, etc. This “interface” can be through computer screens or through paper forms.

    The point about sub-graphs is just that I may or may not have made a particular sub-graph explicit with an identifier as part of the main graph. If I haven’t, then to get the structure of that sub-graph you need to look at the whole graph and trace down to the ability that you are interested in — not hard. Alternatively, you could decide to explicitly define and identify each (sub-)graph (though why call it a sub-graph if it is defined in its own right?) but that could be seen as needless extra effort, not reflecting the way that the practical activity of defining structures and frameworks is actually carried out.

    Yes, if you want to define your own version of bread-making ability that uses the dough-making ability from BSHAPM “make pizza”, then if dough-making had a separately defined and identified structure, you could use it; and if not, you could either define it, or just include the dough-making and whichever subsidiary abilities you want into your new structure.

    Your last paragraph has a nice point. I agree and disagree. If you want to use the dough-making ability concept from the BSHAPM framework, it must be the same concept, yes, but you might choose to structure it differently, or to a different granularity, as long as the content is the same. And I hope you agree with my carefully reconsidered point in the main post above, that e.g. choosing to add another layer of detail doesn’t necessarily change the concept, it just changes the structure. Or perhaps you could regroup the components in different ways. The BSHAPM pizza making concept could retain its identity while being given a different structure for instance by grouping preparing and forming dough together into an ability called “manage dough” or something. Or the sauce, toppings and preparation (I usually sprinkle extra oregano and drizzle olive oil on) could be combined into one. And so on. Structures are lightweight; it is the ability concepts that we want to be as persistent and reused as possible, so that we have the maximum opportunity to cross-reference claims, assessments and requirements.

  9. Secondary note: why do we need separate URIs in this model for the competence and the structure? It seems to me that there is no need to separately address the structure, because the structure is an intimate and essential part of the competence.