| | |
|---|
Welcome and apologies | @Former user (Deleted) | |
Actions from last week | @Former user (Deleted) | Actions from last week: Additional use cases for term searching in ECL? Search types? Include regex? Does anyone have a regex ABNF? Language features required in ECL?
|
Introducing term searching to ECL | @Former user (Deleted) | Syntax {{ term = [ termSearchType : ] "String" }} Term Search Type Wild Card Match (collation) - e.g. ??? Perl Regex - e.g. *** Word Prefix Any Order - e.g. Default (word prefix any order) - e.g. {{ term = "hear att" }} {{ term = "*heart*“ }}
Potential Examples << 64572001 |Disease| {{ term = “heart”}} << 64572001 |Disease| {{ term = “heart”, languageCode = "en"}} << 64572001 |Disease| {{ term = “heart”, languageCode = "en"}} AND << 64572001 |Disease| {{ term = “hjärta”, languageCode = "sv"}} << 64572001 |Disease| {{ term = “heart”, languageCode = "en"}} {{ term = “hjärta", languageCode = "sv"}} << 64572001 |Disease| {{ term = “heart”, languageCode = "en"}} OR << 64572001 |Disease| {{ term = “hjärta", languageCode = "sv"}} << 64572001 |Disease| ( {{ term = “heart”, languageCode = "en"}} OR {{ term = “hjärta", languageCode = "sv"}} ) << 64572001 |Disease| ( {{ term = “heart” AND term = “hjärta"}} (<< 64572001 |Disease|: |Associated morphology| = *) {{ term = “heart”, languageCode = "en", }} {{ term = “hjärta", languageCode = "sv"}}
(<< 64572001 |Disease| {{ term = “*cardio*” }}) MINUS (<< 64572001 |Disease| {{ term != “*heart*” }}) ?? << 64572001 |Disease| {{ term = “*cardio*” }} MINUS << 64572001 |Disease| {{ term != “*heart*” }}
Use Cases Intentionally define a reference set for chronic disease. Starting point was ECL with modelling; This misses concepts modelled using the pattern you would expect. So important in building out that reference set. Authors quality assuring names of concepts Checking translations, retranslating. Queries for a concept that has one word in Swedish, another word in English AU use case would have at most 3 or 4 words in match Consistency of implementation in different terminology services Authoring use cases currently supported by description templates A set of the "*ectomy"s and "*itis"s
Questions Do we include 'typeId' - e.g. << 64572001 |Disease| {{ D.term = “*heart*”, typeId = 900000000000013009 |Synonym| }} Do we include 'type' - e.g. << 64572001 |Disease| {{ D.term = “*heart*”, D.type = synonym }} Do we include 'languageCode' - e.g. << 64572001 |Disease| {{ D.term = “*heart*”, D.type = synonym, D.languageCode = “en” }} Do we include 'caseSignificanceId' - e.g. << 64572001 |Disease| {{ D.term = “*Heart*”, D.caseSignificanceId = 900000000000017005 |case sensitive|}} Do we include 'caseSignificance' - e.g. << 64572001 |Disease| {{ D.term = “*Heart*”, D.caseSignificance = sensitive }} Do we include 'language' and 'version' - e.g. << 64572001 |Disease| {{ term = “*heart*” }} VERSION = http://…, LANGUAGE = (999001881000000108|Gastro LRS|, |GB English|) Do we include syntactic sugar - e.g. << 64572001 |Disease| {{ preferredTerm = “*heart*”, languageRefSet = en-gb}} << 64572001 |Disease| {{ fullySpecifiedTerm = “*heart*”, languageRefSet=en-gb}} << 64572001 |Disease| {{ acceptableTerm = “*heart*”, languageRefSet = en-gb}} << 64572001 |Disease| {{ preferredTerm = “*heart*”}} FROM version = X, language = Y
Do we use/require the "D" at the start of "term"? How does this relate to description templates? How does this relate to SNOSTORM implementation. Packaging - Do we (over time) extend ECL with all the new Query Language features, and define a set of example ECL profiles - e.g. "Basic ECL", "ECL with basic term searching", "ECL with filters".
|
Executing maps | @Former user (Deleted) | Proposed extension to ECL to support the execution of maps |
Returning attributes | @michael lawley | Proposal from Michael: 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|Clinical finding| |
URI Standard | @Former user (Deleted) | |
Query Language
- Summary from previous meetings | @Former user (Deleted) | 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
|
Keywords for Term-based searching: 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.acceptabilityId D.acceptability
Additional Syntactic Sugar FSN synonym synonymOrFSN textDefinition Unacceptable Terms
|
Language preferences using multiple language reference sets |
Linda
Just a quick observation re. 'Does anyone have a regex ABNF?' The nearest thing I can find is at the end of section 9 here (http://pubs.opengroup.org/onlinepubs/9699919799/), divided into BRE and ERE sections.
Regarding the homework from last call, I'm struggling to see what the language-independent defaults (for all the variables in section 9 of the agenda) should be for a lightweight 'ECL with basic term searching', not to mention other unstated assumptions related to Daniel's comments about collation and character normalisation/accent handling. Default substrate is currently defined as:
"the set of active components from the snapshot release (in distribution normal form) of the SNOMED CT versioned edition currently loaded into the given tool"
I'd assume that this necessarily includes the loading of at least one LRS, and as section 10 indicates, the logic for combining multiple LRSs is highly configurable. Whatever, there needs to be agreement on defaults for specifying the LRS, D.type and D.acceptability (via the LRS(s)) and a default D.languageCode (presumably *). However even for 'basic term searching' (given the use cases listed) it should be possible to over-ride/modify all of these, and the syntax needs to handle it. Once we've got through all this metadata, we'd then need to declare how characters in terms are actually indexed. If so, then there isn't much that won't be required in 'basic term searching' left over for any later iteration!
Ed