mekomsolutions
Concepts should have "Member of" and "Answer to" columns
I propose adding two columns to the Concepts domain: "Member of" and "Answer to."
"Member of" will allow a concept row to specify what concept sets (semicolon-delimited) the concept should be a member of. "Answer to" similarly for answers.
| Uuid | Fully specified name:en | Same as mappings | Description:en | Data class | Data type | Member of |
|---|---|---|---|---|---|---|
| 54014540-311d-11ec-8d2b-0242ac110002 | Set of senses | CIEL:SENSE_SET | Set of all available senses | ConvSet | N/A | |
| 5d1e9aa1-311d-11ec-8d2b-0242ac110002 | Smell | CIEL:SMELL | Smell | Misc | N/A | Set of senses |
| 6878804b-311d-11ec-8d2b-0242ac110002 | Taste | CIEL:TASTE | Taste | Misc | N/A | Set of senses |
| 6b29ee43-311d-11ec-8d2b-0242ac110002 | Touch | CIEL:TOUCH | Touch | Misc | N/A | Set of senses |
| 6da4eb30-311d-11ec-8d2b-0242ac110002 | Sight | CIEL:SIGHT | Sight | Misc | N/A | Set of senses |
| 703404f7-311d-11ec-8d2b-0242ac110002 | Sound | CIEL:SOUND | Sound | Misc | N/A | Set of senses |
This will solve the problem of concept sets being unwieldy. Right now we have to choose between a potentially unreadably long semicolon-delimited list in a single cell, and increasing the maintenance burden by creating another file using the conceptsets domain.
Credit to @mseaton for the idea.
We can support a delimited set of sets as described, but in my opinion we should be striving to avoid delimited values within a delimited row and discouraging/avoiding cell values that are of unbounded length and could become unmaintainable.
What I'd prefer is for us to have a column header named "Member of:Set of senses", with a column value that can be truthy. I believe this will be a better practice way of maintaining these associations. If someone wants to support membership in lots of sets, or answers to lots of questions, this will require more columns - but this makes things a lot more explicit and easier to manage (IMHO).
I was going to say +100 here, as it would make something like defining a set of diagnoses in a single file much easier, but one design challenge I'm seeing:
- On one hand, I wouldn't want the the "Member of" column to be the exclusive owner of all sets a concept could be a member of... I'd want to allow concept_set domains to add a concept to other sets; but this would make it impossible to "remove" a member from a set just by removing it from the "Member of" column.
@mogoodrich - it is a good point. One way in which I think we need Iniz to evolve is in the handling of objects that multiple domains may contribute to. There are several examples of this - and how it has potentially caused problems that are only really solved by deleting checksum files and reloading everything from scratch. Some examples are locations, locationtags, and locationtagmaps domains, or concepts and conceptsets, and ocl domains. Metadatasharing domain also may affect things broadly, though particularly concepts.
Metadatasharing aside, the way I think things are generally designed is that there is a primary domain for a given type - for example, the locations domain is the primary one for locations, and the concepts domain is the primary one for concepts, and when, say, the concepts domain loads, it wipes all of the concept sets, answers, mappings, etc for a given concept when it recreates it. The current problem with this is that if the concepts domain has changed files (so the checksum differs), the concepts domain will reload and all related objects like conceptsets and concept answers will reset. But if the conceptsets domain does not have a changed file, then the set members will not reload, as it's checksum will not have changed.
What I think we need to put in place is more sophisticated handling of domain reloads based on related object changes. For example, the concepts, conceptsets, and ocl domains all should likely all reload if there are changes to any of them.
One result of this is that there really should never be any need to user the Void/Retire column for concept sets. Simply removing the line from the conceptsets CSV, or removing the member from the Concepts csv should result in the concept set member being removed, since the way the concepts domain functions is to first clear all set members and then build them back up again.
@mks-d and @ibacher FYI ^^ Let me know if you have opinions.
@brandones / @mogoodrich / @mseaton is this still current or we can close this issue?
It is still current AFAIK @mks-d , though at PIH we don't use the concept domain particularly heavily, so I'm not overly invested. I do think my last large comment above (which is not specifically about this ticket, but calls for a different ticket) is something we should deal with. There are definitely examples / bugs we have run into where metadata gets screwed up upon Iniz loading because some files have changed and others have not between Iniz loads and they both touch the same domains, which leads to inconsistent results.