Hi Vicente,
Yes - retrieving only primitive, or only fully defined concepts is a useful use case - as you say, particularly for things like proximal primitive parent authoring.
We have definitely considered this, and are planning for this to be included in broader SNOMED query language, which will essentially consist of ECL + filters. The filters will allow you to filter the results of an ECL query using RF2 fields, such as definitionStatusId.
This has been work-in-progress for a while now .... but will hopefully be ready to publish next year.
Kind regards,
Linda.
Thanks for your thoughts on this Ed.
I definitely agree with you that we should not be expanding the scope of ECL to allow things to be matched/returned that are not SNOMED concepts. However, we have been discussing this functionality in the context of the more expressive Query Language.
So while we haven't explicitly discussed recently where this refset functionality should be added, I personally agree with you that it would make sense to leave this for the more expressive Query Language (and not try to squeeze in concept-only reference set filters into ECL).
Linda.
Hi Vicente,
If those two relationships are in the same role group, then (a) is redundant (it is wholly implied by (b)) and would not appear in the Relationships file. If they are in separate role groups, then you have a situation analogous to your question A above.
Regarding transitive properties and other property chains, there is no special provision in ECL for these, but if you "wrap" your (sub)expression in a descendantsOrSelfOf then you will match all the concepts that are inferable due the role chaining. For example, <<A : B = C would become <<(<<A : B = C)
Provisional releases contain content that should be treated as somehow separate and distinct from normal production releases. However, to ingest, manipulate, and process with standard toolchains (e.g., terminology servers), it still needs to be identified while still remaining distinct from production content.
This proposal is that a parallel URI space (http://snomed.info/xsct) be set aside for such provisional releases. Mirroring the http://snomed.info/sct URI space, this would include:
Thanks Linda.
Most of this is actually familiar (from the behaviour of at least one of the old perl scripts), and in the meantime I'd salvaged similar material from the owl guide and various places on confluence after searching confluence for “self-grouped”.
My concern as to where this is going is that it risks polluting the relatively human-readable and understandable SCG (and associated syntax) form with MRCM-held authoring business rules and DL reasoner requirements; in particular the calls for ‘no more implicit grouping’.
The notion of ‘never grouped’ roles is relevant to modelling activities (“roles X, Y and Z should never be grouped with another role”) - fine. The notion of representing self-grouped roles is required for an owl-representation of role grouping to work as intended for DL classification, as you explain - fine. I also *think* I see, on the EAG site, a proposal (but it’s not clear from the slides) to automate the groping of many ‘ungrouped but groupable’ role sets. All of these can be enacted when/where they need to in the authoring and classification workflows, but I don’t see why any of these need to ‘leak out’ into the explicit SCG forms of expressions and expression constraints.
Ed
I see that this error pattern is back:
309635005 H/O: Admission in last year for diabetes foot problem
309636006 History of hospital admission in last year for hyperglycaemic disorder
...are both modelled as an FWEC and a PWEC.
The MRCM prohibition constraints that theoretically prevent this are still present, so it's odd that these sorts of constructs can still be created and published.
Currently ECL expressions can match (return) concepts that are either the source or the target of a relationship triple (target is accessed via the 'reverse' notation or 'dot notation', but not the relationship type (ie attribute name) itself.
For example, I can write:
<< 404684003|Clinical finding| : 363698007|Finding site| = <<66019005|Limb structure|
<< 404684003|Clinical finding| . 363698007|Finding site|
But I can't get all the attribute names that are used by << 404684003|Clini
I propose that the compositional grammar support comments in the same way as the ECL. Not just for completeness and symmetry with the other languages: I actually tried to comment out a portion of an expression before quickly realizing it made the expression illegal!
In programming languages, there are two purposes for an embedded comment syntax. The original, motivating one is to allow internal, localized documentation of subunits of a large program. The second, more frequently purpose (at least for me) is to "comment-out" parts of a program during development.
Both usages have merit for the ECL, certainly. Although the long syntax can help make constraints self-documenting, large or complex constraints need the human touch. And during development of a constraint, the ability to comment-out is essential, especially for those still learning the language.
Though SCG expressions tend to be smaller than ECL constraints, for me the ability to comment-out has been nearly as important while developing logic to operate on them (an ECL executor, for example). There may be use cases for documenting SCG expressions, but I'm not aware of any, and that wasn't my motivation for this proposal.
What should be the interpretation of cardinality of reverse attribute? Does the cardinality apply to the source or the destination of the relationship? Just to clarify!
I agree that both approaches could be useful, and as you suggest Daniel:
Approach #1 could be written as:
< 105590001 |Substance|: [3..3] R 127489000 |Has active ingredient| = *
Approach #2 could be written as:
<105590001|Substance|: R 127489000 |Has active ingredient|= (*:[3..3] 127489000 |Has active ingredient|= <105590001|Substance|)
It's interesting to consider that approach 2 can also be written using dot notation as:
(*:[3..3] 127489000 |Has active ingredient|= <105590001|Substance|).127489000 |Has active ingredient|
However, I can't think of an even mildly intuitive way of representing approach 1 using dot notation. Do we need one?
Kind regards,
Linda.
I now have a use case for sub-expressions in the attributeName part of an expression.
The use case is as follows. I have a focus concept and a set of attributes. I want to find all descendantsOrSelf of the focus concept that have exactly these attributes and no others.
So, I want something like:
<< 125605004 |Fracture of bone| :
[1..1] 363698007 |Finding site| = 23416004 |Structure of ulna|,
[1..1] 116676008 |Associated morphology| = 72704001 |Fracture|,
[0..0] 363698007 |Finding site| != 23416004 |Structure of ulna|,
[0..0] 116676008 |Associated morphology| != 72704001 |Fracture|,
[2..2] << 410662002 |Concept model attribute| = *
But this relies on the magic number '2' in this case, and won't easily generalise to cases where, for example, a single finding site might appear in multiple groups. What I think I need to be able to write is something like the following (which is not currently valid ECL):
<< 125605004 |Fracture of bone| :
[1..*] 363698007 |Finding site| = 23416004 |Structure of ulna|,
[1..*] 116676008 |Associated morphology| = 72704001 |Fracture|,
[0..0] 363698007 |Finding site| != 23416004 |Structure of ulna|,
[0..0] 116676008 |Associated morphology| != 72704001 |Fracture|,
[0..0] (<<410662002 |Concept model attribute| MINUS 363698007 |Finding site| MINUS 16676008 |Associated morphology|) = *
Update: cardinalities in the example above have been corrected to show [1..*] rather than the original cut-and-paste error of [1..1].
Linda Bird