Hi
I have a remark about the use of some archetypes in CKM.
I think that it would be nice to have archetypes of some specific content, for example, medication, always of type cluster, and have container archetypes, for example in this case, of type action to hang them in a composition.
If this was a policy, then the idea of building blocks would be much more usable.
Best regards
Bert
Hi Bert,
I think your statements describe things as they are today - or maybe you meant something different?
- thomas
Hi Bert,
I think your statements describe things as they are today - or maybe you meant something different?
Thanks for replying
That is nice, I must have found a leftover from the past and I did not find this strategy somewhere formalized.
Is there description a formal strategy of desirable structures?
Best regards,
Bert
Hi Thomas, Now I read it back I see that my previous reply was not my.most understandable English.
I try again. Is there somewhere described that archetypes should be structured in cluster archetypes which fill slots in container entry archetypes?
I see that it is done a lot in CKM, but I also see (must be) leftovers in which the entry - archetypes contain the structures itself, and in this way disturb the building block idea.
Like in programming languages are described paradigms, it would be good to have that for archetypes. An advantage of formal structure descriptions would be that discussion would become possible. Another advantage would be that newcomers would have some directions.
So, that is why i hsve this question: are there some paradigms described which shape new archetypes for CKM?
Thanks
Bert
Bert,
there is no text book for that yet, although programming principles are generally applied these days. But just as in programming, one can build a class that doesn’t use a separate class for its inner structure, if that structure is not re-usable. There is undoubtedly some sub-optimal modelling in the CKM archetypes, but I suspect what you are looking for is some machine-processable general rule that you can use in software to e.g. always know that when you hit a CLUSTER, it will be a new archetype? I don’t think this kind of thing can ever be guaranteed.
What I foresee creating is a handbook of ‘patterns’ in the same sense as the Gang-of-for software patterns. It might be possible one day to machine discover which pattern a given archetype conforms to and to do something with that knowledge at runtime, but we are not there yet.
It is true, while I am thinking about this myself, I was indeed looking for a Gang of Four like pattern rules which makes the archetype development predictable, and also advises for efficiency and consistency, and indeed, also machine processable.
This is important, tell people to use a cluster-slot for a dataset, always do. If it does not exist, write it. And never use wild/wild (very wild) cards in those slots. Wild/wildcards should only be permitted in root container entry-archetypes, not in pointers to specific datasets.
There is a risk of rewriting archetypes, while there are similar archetypes, because they cannot find for what archetypes are already used for, or risk for including structures in a new archetype
But when you demand this kind of things, you also have the obligation to offer help, and that is possible. Because it is not anymore allowed to use wild/wild cards, you can machine generate a mindmap of all the existing archetypes. Not the overview mindmap which is already on CKM, that is just a translation of the tree on the left, but a dependency mindmap.
So for example (having the risk that it is a wrong example)
Medication-action can be replaced with:
Action
*> Cluster Medication Action
→ Medication
->> Product
->> Medication course, etc.
*> is a wild/wild card
→ is a more specific wild card
->> leaf node archetypes, only containing lists of leaf nodes, maybe only one level of structure
So, concluding, we need rules (pattern) and (machine generated) guidance, and a redesign of the existing archetypes following the rules and guidance.
These are my two cents
Bert