Page tree

Date & Time

20:00 UTC Wednesday 30th January 2019

Teleconference Details

To join the meeting please go to https://snomed.zoom.us/j/471420169

Further information can be found at SLPG meeting information

Goals

  • Consider proposal to change language syntax from ABNF to ANTLR
  • Recap ECL transitivity/role chain proposal, and consider implementation support
  • Summarize 2019 work items, including:
    • Proposed new ECL language features
    • Updates to URI standard
    • Enhancement to template language
    • Draft Query Language

Agenda and Meeting Notes

Description
Owner
Notes

Welcome and apologies


Proposal to move from ABNF to ANTLRDaniel Karlsson

For discussion: Daniel has proposed to change the primary syntax representation for all languages from ABNF to ANTLR.

  • Auto-translation from ABNF to ANTLR difficult
  • ABNF grammar represents the byte representation of UTF-8 / Needs to be updated to include a range of UTF characters (not the byte representation)
  • ABNF is a tool-independent language for defining syntaxes / ANTLR is a tool for defining parsers (and dependent on versions)
  • Proposal - Continue to use ABNF as the standard, with a hand-crafted ANTLR as the authoratative ANTLR reference implementation
  • Alternate representations, e.g. JSON, would be useful (e.g. for templates)
  • Actions
    • Post authoratative ANTLR syntax used by SNOMED International
    • Update ABNF with additional UTF characters

Transitivity, Reflexivity &
Role chaining

Proposed extension to ECL to support transitive relationships and role chaining (to align with new enhanced DL axioms)

  • Example 1
    • Direct relationship
        • < |Body structure|: << 774081006 |Proper part of| = << 51185008 |Chest|
    • Transitive relationship
        • < |Body structure|: << 774081006 |Proper part of|* = << 51185008 |Chest|
        • <<(< |Body structure|: << 774081006 |Proper part of| = << 51185008 |Chest|)
  • Example 2
    • Direct relationship
        • < 71388002 ||: 363701004 |Direct substance| = 372687004 |Amoxicillin|
    • Role chained relationship (via 738774007 |is modification of|)
        • < 71388002 ||: 363701004 |Direct substance|* = 372687004 |Amoxicillin|
        • <<(< 71388002 ||: 363701004 |Direct substance| = 372687004 |Amoxicillin|)

What implementation support will be required? Should we provide easy access to those relationships that can be inferred by transitivity and role chains (note: These will be excluded from the inferred relationship file as they are redundant). If so, then what format should be used - for example, a TSV file with the following columns:

    • sourceId
    • destinationId
    • typeId
    • relationshipGroup
END OF MEETING
Executing maps

Proposed extension to ECL to support the execution of maps (focusing on the resolution of historical refsets)

  • The specific use-case here comes initially from Jeremy and relates to being able to work with inactive concepts via the historical association maps. For example, given an ECL expression that identifies a set of concepts 'c' to be used for retrieving patient records, you probably also want to retrieve records for sameAs (c) and replacedWith (c)
    • Example:
      • (< 72704001 |Fracture| AND ^ 900000000000527005 |SAME AS association reference set|) . 900000000000533001 |Association target component|
Template SyntaxLinda Bird

New requirements

  • 2 slots must have the same value
  • 2 slots must have different values
  • The value of 1 slot must subsume the value of another
  • Default value for slots
URI StandardLinda Bird
  • Finalize and publish language and language instance URIs
Query Language
- Summary from previous meetings




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.type = "FSN"
    • D.type = "fullySpecifiedName"
    • D.type = "synonym"
    • D.type = "textDefinition"
  • D.acceptabilityId
    • D.acceptabilityId = 900000000000549004 |acceptable|
    • D.acceptabilityId = 900000000000548007 |preferred|
  • D.acceptability
    • D.acceptability = "acceptable"
    • D.acceptability = "preferred"

Additional Syntactic Sugar

  • FSN
    • FSN = "*heart"
      • D.term = "*heart", D.type = "FSN"
      • D.term = "*heart", D.typeId = 900000000000003001 |fully specified name|
    • FSN = "*heart" LANGUAGE X
      • D.term = "*heart", D.type = "FSN", D.acceptability = * LANGUAGE X
      • D.term = "*heart", D.typeId = 900000000000003001 |fully specified name|, acceptabilityId = * LANGUAGE X
  • synonym
    • synonym = "*heart"
      • D.term = "*heart", D.type = "synonym"
      • D.term = "*heart", D.typeId = 900000000000013009 |synonym|
    • synonym = "*heart" LANGUAGE X
      • D.term = "*heart", D.type = "synonym", D.acceptability = * LANGUAGE X
      • D.term = "*heart", D.typeId = 900000000000013009 |synonym|, (D.acceptabilityId = 900000000000549004 |acceptable| OR D.acceptabilityId = 900000000000548007 |preferred|) LANGUAGE X
  • synonymOrFSN
    • synonymOrFSN = "*heart"
      • synonym = "*heart" OR FSN = "*heart"
      • D.term = "*heart", (D.type = "synonym" OR D.type = "fullySpecifiedName")
    • synonymOrFSN = "*heart" LANGUAGE X
      • synonym = "*heart" OR FSN = "*heart" LANGUAGE X
      • D.term = "*heart", (D.type = "synonym" OR D.type = "fullySpecifiedName"), D.acceptability = * LANGUAGE X
  • textDefinition
    • textDefinition = "*heart"
      • D.term = "*heart", D.type = "definition"
      • D.term = "*heart", D.typeId = 900000000000550004 |definition|
    • textDefinition = "*heart" LANGUAGE X
      • D.term = "*heart", D.type = "definition", D.acceptability = * LANGUAGE X
      • D.term = "*heart", D.typeId = 900000000000550004 |definition|, D.acceptabilityId = * LANGUAGE X
  • Unacceptable Terms
    • (D.term = "*heart") MINUS (D.term = "*heart", D.acceptability = * LANGUAGE X)

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

      • 99999900 |Irish language reference set| PLUS |GB English reference set|

  • 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

    • E.g. Danish LRS that does a partial translation of the International Release

      • 999999 |Danish language reference set| ELSE |GB English reference set|

Other topics
  • Any other topics?
Confirm next meeting date/time

The next SLPG meeting will be held in 2 weeks at 20:00 UTC on Wednesday 6th February.

No files shared here yet.


  • No labels

2 Comments

  1. Concerning item 3, example 1, the only transitive relationship types in SNOMED CT (Jan 2019) are the "...part of" relationship types and the "is modification of" relationship type. Perhaps this doesn't matter if we're not going to implement this change, but if needed we should have another example.

    /Daniel

    1. Thanks Daniel! I have changed this example to a |Proper part of| query instead.