1 / 27

ADL / AOM Terminology binding

ADL / AOM Terminology binding. Types of terminology binding (Taken from Linda Bird’s Presentation ). Value binding References one or more values that may be used to populate the information model artefact Semantic binding

cicero
Télécharger la présentation

ADL / AOM Terminology binding

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. ADL / AOM Terminology binding

  2. Types of terminology binding(Taken from Linda Bird’s Presentation) • Value binding • References one or more values that may be used to populate the information model artefact • Semantic binding • Uses the terminology artefact to define the meaning of the information model artefact • Template binding • Indicates how values recorded in two or more fields may be combined to represent a composite meaning • Inter-field binding • Constrains the value of one data element based on the value of another, where at least one of these data elements is coded.

  3. Archetype Terminology Archetypes Use Terminology for: • (Object) Node Identifiers (Semantic Binding) • Permissible values (Value Binding) • Small sets (Enumerations) • Internal formal sets (Value sets) • External sets (Defined value sets) • Paths (Template / Inter-field)

  4. ADL 1.5 • renamed the 'ontology' section 'terminology’ • 'id-codes' are now a real thing - i.e. where we had CLUSTER [at0004] we would now have CLUSTER [id4] • 'at-codes' are used only for value terms, not for identifier 'terms’ • id-codes have their own id_definitions section in the archetype terminology • id-codes are mandatory on every node in an archetypeFor the moment, only paths have to be unique, not individual node ids. 

  5. Sample Archetype

  6. Object Node Identifiers

  7. Permissible Values(Small Sets)

  8. Permissible ValuesInternal Formal Sets

  9. Permissible ValuesExternal Sets

  10. CIMI Terminology • ADL / AOM pattern is good • ‘idn’ codes are ADL specific • Different forms work as well as well as identifiers are unique • Paths are arguably ADL specific as well • Other modeling forms have similar mechanisms in place that accomplish the same goal

  11. Identity in Terminology ‘id1’ in body temperature archetype vs. ‘id1’ in musical instrument archetype • Solution is scoping namespace (e.g. body temperature archetype) + name • Scoping namespace must be unique • Solution is scoping namespace for namespace… • Scoping namespaces of namespaces must be…

  12. Identity in CIMI terminology http://opencimi.org/archetype/body_temp_test/terminology/id1 Identifier Identifier Scoping Namespace Scoping Namespace Identifier Scoping Namespace Identifier

  13. Identity in CIMI TerminologyWhy “http”? Why “http” (vs. DCE UUID’s, ISO Object Identifiers, Digital Object Identifiers)? Answer: Because the “http” identifier scheme: • Is in place and works • Is (mostly) non-forgeable • Is distributed • Is federated • Has a reasonable pricing scheme • Is available to anyone with an internet connection

  14. Identity in CIMI TerminologyWhy “http”? Why “http” (vs. DCE UUID’s, ISO Object Identifiers, Digital Object Identifiers)? Answer: Because the “http” identifier scheme: • Is in place and works • Is (mostly) non-forgeable • Is distributed • Is federated • Has a reasonable pricing scheme • Is available to anyone with an internet connection … AND … • HTTP services are based on Resource Oriented Architecture

  15. Identity in CIMI TerminologyResource-Oriented Architecture “That's the Resource-Oriented Architecture. It's just four concepts: 1. Resources 2. Their names (URIs) 3. Their representations 4. The links between them and four properties: 1. Addressability 2. Statelessness 3. Connectedness 4. A uniform interface” 1 1 RESTFul Web Services – Richardson and Ruby, O’Reilly Media, 2007

  16. Using ROA What is the type resource that we are identifying? • How is it represented? (i.e. what are its properties?) • What are its ‘rigid’ properties (aka. Identity)? • What resources does it link to?

  17. A note on URI ‘semantics’ Competing goals • URI’s should be easy to create and manage • http://opencimi.org/models/archetype/body_temp_archetype • URI’s should be easy to read from a human perspective • URI’s cannot be “readable” from an automation perspective (!!!!!) • http://opencimi.org/models/archetype/X and http://opencimi.org/models/archetype/Y are no more or less similar than http://opencimi.org/models/archetype/X and http://www.w3.org/People/Berners-Lee/card • The only way software can determine relatedeness is by dereferencing both URI’s and decoding the underlying description. Note: (arguably) software can make inferences about things before the “?”…

  18. Identity and Versions “Dissimilarity of the Diverse” (John McTaggart): “if x and y are distinct then there is at least one property that x has and y does not, or vice versa.” (Lebiniz’s law of indiscernables) • This is the easy part. Version ‘1’ and Version ‘X’ are different because they came out on different dates, represent different things, etc… • The hard part: How do we assert that Version ‘1’ and Version ‘2’ are versions of the same thing? • We have 3 resources – v1 of X, v2 of X and… X!

  19. Correlary From the modeling perspective, to be considered a “resource” an element must: • Have a unique identity • Have at least one rigid property – a property that, if it changes you have a different resource • Things that lack this characteristic are probably parts of models (think ‘CLUSTER’) • Have at least one non-rigid property • Things that lack this characteristic are called “data types”

  20. Versions and URI Semantics http://id.who.int/icd/release/10/2008/C77.1 is something different than http://id.who.int/icd/release/10/2010/C77.1 • Humans can tell that there is (probably) a relationship • Machines cannot (or should not) • There are (at least) 3 resources here, but we’ve only got 2 identifiers

  21. Version and URI Semantics So do we need to dereference a URI to tell the difference? • A: No – it may not even be possible. What we do instead is recognize the (obvious) situation that there are several things. Using ICD-10 • The ICD-10 category, “Secondary and unspecified malignant neoplasm: Intrathoracic lymph nodes” • The ICD-10 identifier “C77.1” • The description of the identifier, “C77.1” that appeared in the 2008 release of ICD-10 • The description of the identifier, “C77.1” that appeared in the 2010 release of ICD-10 • ICD-10 itself (!)

  22. How do we identify each of these • The ICD-10 category, “Secondary and unspecified malignant neoplasm: Intrathoracic lymph nodes” – Out of scope (see ICD-11, however) • The ICD-10 identifier “C77.1” – //id.who.int/icd/10/C77.1 • The description of the identifier, “C77.1” that appeared in the 2008 release of ICD-10 - //id.who.int/icd/10/2008/C77.1 • The description of the identifier, “C77.1” that appeared in the 2010 release of ICD-10 - //id.who.int/icd/10/2010/C77.1 • ICD-10 itself (!) - //id.who.int/icd/10 , //id.who.int/icd/10/2008 //id.who.int/icd/2010

  23. Terminology and CIMI Resources include: • Archetype • Archetype version (‘version’ vs. ‘release’ have to be discussed) • Archetype Terminology (? – may not be necessary) • Archetype Object • Archetype Object Identifier (?) • Terminological description of archetype object • Value set • Internal value set definition • Internal value set code • Internal value set code description • External value set

  24. Proposed Model

  25. Terminology and CIMI Resources include: • Archetype http://opencimi.org/archetype/{id} • Archetype version http://opencimi.org/archetype/{id}/version/{id} • Archetype Terminology (? – may not be necessary) • Archetype Object http://opencimi.org/archetype/{id}/object/{id} • Archetype Object Identifier (?) • Terminological description of archetype object (LocalURI – CTS2 form) <service>/entity/{ns}:{id} or <service>/entitybyuri?uri=http://opencimi.org/archetype/{id}/object/{id} • Value set http://opencimi.org/archetype/{id}/valueset/{id} • Internal value set definition http://opencimi.org/archetype/{id}/valueset/{id}/definition • Internal value set code • Internal value set code description • External value set • Value Set resolution

  26. Identifier question • Each ADL object constraint has an identifier (e.g. ‘id1’, ‘id2’, etc.) • Scope can be at Archetype level, meaning that (almost) every node is uniquely identifiable by ‘<scoping archetype>:<id>’ • Specialization can be explicitly modeled: arch1:id17 specializedBy arch2:id42 • What of slots and proxies (where root is renamed, but internal nodes stay the same)?

More Related