| | |
|---|
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 LRSs that use the same Language tend to use 'Addition' - i.e. child LRS only includes additional acceptable terms, but can override the preferred term E.g. Regional LRS that adds local dialect to a National LRS E.g. Specialty-specific LRS E.g. Irish LRS that adds local preferences to the en-GB LRS
LRSs that define a translation to a different language tend to use 'Replacement' - i.e. child LRS replaces set of acceptable and preferred terms for any associated concept
|
Other topics | @Former user (Deleted) | |
Confirm next meeting date/time | @Former user (Deleted) | The next SLPG meeting will be held in 2 weeks at 20:00 UTC on Wednesday 5th June. |