Please see the following post!

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.

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.

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.

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

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.

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.

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!