| | |
|---|
Welcome and apologies | |
| | ECL reverse cardinality | | Question I have a doubt in expression constraints with reverse cardinalities: only non-redundant attributes have to be included in the cardinality count? For example, the following EC: << 105590001 |substance|: [3..3] R 246075003 |causative agent| = << 404684003 |clinical finding| returns this concept (among others): 72551001 |Metal fumes (substance)|. This substance is the causative agent of three clinical findings: 74800004 |Brass-founders' fever|, 72163003 |Metal fever| and 308905009 |Welders ague|. Both concepts, 74800004 |Brass-founders' fever| and 308905009 |Welders ague| are a type of 72163003 |Metal fever|. So the question is: does the EC above has to return 72551001 |Metal fumes (substance)|? Or this substance should be matched with [2..x] cardinality? (Please note that x corresponds to 2, 3...*). Proposed Answer (for discussion) At the moment, existing implementations (that I know of) seem to return 72551001 |Meta fumes (substance)|; and the SNOMED International Browser shows the 3 concepts that you mention in the list of causative agent "References" for the concept 72163003 |Meta fever|. However, whether or not this is the correct semantics for ECL comes down to how we interpret "redundant relationships". I think this may require a further discussion with the implementation community (which I can start through the SNOMED Languages Project Group). However, these are my current thoughts on how redundancy should be treated.... Given concepts X and Y, and attribute R: - IF relationship (X R Y) (i.e. "All X have an R relationship with some Y") THEN relationship (X R supertype(Y)) (i.e. "All X have an R relationship with some supertype of Y)
- IF relationship (X R Y) (i.e. "All X have an R relationship with some Y") THEN relationship (subtype(X) R Y) (i.e. "All subtypes of X have an R relationships with some Y")
An example of the first inference is: - IF relationship (|Copper fever|,|Causative agent|, |Copper fumes|) THEN relationship (|Copper fever|, |Causative agent|, |Metal fumes|)
- Therefore if both these relationships are true, then relationship (|Copper fever|, |Causative agent|, |Metal fumes|) is redundant
An example of the second inference is: - IF relationship (|Metal fever|,|Causative agent|, |Metal fumes|) THEN relationship (|Brass-founders' fever|, |Causative agent|, |Metal fumes|)
- Therefore if both these relationships are true, then relationship (|Brass-founders' fever|, |Causative agent|, |Metal fumes|) is redundant
If this logic above is correct, then the only non-redundant relationship involving a |Causative agent| of |Metal fumes| is the relationship (|Metal fever|, |Causative agent|, |Metal fumes|) ... in which case the concept |Metal fumes| should only be returned when the cardinality include [1]. For example: << 105590001 |substance|: [1..1] R 246075003 |causative agent| = << 404684003 |clinical finding| However, I would like to discuss this further with the implementation community, given this is not the way current implementation are working. | | Query Language - Recap from last week | | Examples: version and language Notes
- Allow nested where, version, language
- Scope of variables is inner query
|
| Examples: where Notes - Allow nested variable definitions, but recommend that people don't due to readability
- Scope of variables is the inner query
- No recursion e.g X WHERE X = 1234 MINUS X
- ie can't use a variable in its own definition
- ie X is only known on the left of the corresponding WHERE, and not on the right of the WHERE
| | Query Language - Combining language reference sets | | How do we support language preferences, which are defined over multiple language reference sets? For example: Assume: No concept has descriptions in 2 listed language refsets ... But if they do: do they override or are they additive? Option 1: PTs override (so order is important), and acceptable terms are additive. If there are 2 PTs, then the second PT is acceptable. Option 2: Use '+' to indicate additive, and ',' to indicate priority order (with override). For example:
| | Filters for Lexical Searching | | What filter keywords will we introduce for Term-based searching, and what are their exact meanings? - D.term
- D.term = "*heart*"
- D.term = wild:"*heart*"
- D.term = regex:".*heart.*"
- D.term = match:"hear att"
- D.term = (sv) wild: "*heart*"
- D.languageCode
- D.languageCode = "en"
- D.languageCode = "es"
- D.caseSignificanceId
- D.caseSignificanceId = 900000000000448009 |entire term case insensitive|
- D.caseSignificanceId = 900000000000017005 |entire term case sensitive|
- D.caseSignificanceId = 900000000000020002 |only initial character case insensitive|
- D.caseSignificance
- D.caseSignificance = "insensitive"
- D.caseSignificance = "sensitive"
- D.caseSignificance = "initialCharInsensitive"
- D.typeId
- D.typeId = 900000000000003001 |fully specified name|
- D.typeId = 900000000000013009 |synonym|
- D.typeId = 900000000000550004 |definition|
- D.type
- D.type = "FSN"
- D.type = "synonym"
- D.type = "definition"
- D.acceptabilityId
- D.acceptabilityId = 900000000000549004 |acceptable|
- D.acceptabilityId = 900000000000548007 |preferred|
- D.acceptability
- D.acceptability = "acceptable"
- D.acceptability = "preferred"
- ? D.acceptability = "unacceptable"
- FSN
- synonym
- definition
- preferredTerm
- preferredTerm = "*heart*"
- preferredFSN
- preferredTerm preferredFSN = "*heart*"
- acceptableTerm (literal)
- preferredTerm acceptableTerm = "*heart*"
- acceptableOrPreferredTerm
- preferredTerm = "*heart*"
- acceptableFSNacceptableNotPreferredTerm
- preferredTerm = "*heart*"
| | Confirm next meeting date/time | | Due to the April SNOMED business meeting in London, the next SLPG meeting will be held in 4 weeks at 20:00 UTC on Wednesday 25th April 2018. |
|