Date: Fri, 29 Mar 2024 07:56:15 -0400 (EDT) Message-ID: <327825458.994.1711713375394@ip-10-208-27-219.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_993_1453918866.1711713375391" ------=_Part_993_1453918866.1711713375391 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
LexEVS 6.x Design Links to Include |
---|
The information below is provided for introductory purposes. A full desc= ription of all available model components is also available in the javadoc = distributed with the LexEVS installation package (see file breakdown in the= LexEVS 6.x Insta= llation Guide). Since the javadoc is automatically generated and synchr= onized during the build process, it is recommended as the primary reference= for use by LexEVS developers.
The LexGrid Model is Mayo Clinic's proposal for standard storage of cont= rolled vocabularies and ontologies. The LexGrid Model defines how vocabular= ies should be formatted and represented programmatically, and is intended t= o be flexible enough to accurately represent a wide variety of vocabularies= and other lexically-based resources. The model also defines several differ= ent server storage mechanisms and an XML format. This model provides the co= re representation for all data managed and retrieved through the LexEVS sys= tem, and is now rich enough to represent vocabularies provided in numerous = source formats such as OWL (NCI Thesaurus) and RRF (NCI MetaThesaurus).
Once the vocabulary information is represented in a standardized format,= it becomes possible to build common repositories to store vocabulary conte= nt and common programming interfaces and tools to access and manipulate tha= t content. The LexBIG API developed for caBIG=C2=AE is one such interface, = and is described in additional detail in LexEVS APIs.
The LexGrid model is mastered in XML schema. The LexEVS project currentl= y builds on the 2010 version of the LexGrid schema. A complete list of XML = schemas, XSLT converters, model in Enterprise Architect (EA) format are ava= ilable at LexGrid Mode= l and Schema.
Following are some of the higher-level objects incorporated into the mod= el definition:
Each service defined to the LexGrid model can encapsulate the definition= of one or more vocabularies. Each vocabulary is modeled as an individual c= ode system, known as a codingScheme. Each scheme tracks information used to= uniquely identify the code system, along with relevant metadata and is a h= igh level container for entities and relations. Each CodingScheme represent= s a unique code system or version in the LexEVS service. The collection of = all code systems defined to a service is encapsulated by a single codingSch= emes container.
A code system may define zero or more coded entities, encapsulated withi= n a single container. An entity represents a coded entity (identified in th= e model as a entity) within a particular domain of discourse. Each entity c= ould be of type 'concept', 'instance', 'association' etc., and is unique wi= thin the code system that defines it. To be valid, an entity must be qualif= ied by at least one designation, represented in the model as a property. Ea= ch property is an attribute, facet, or some other characteristic that may r= epresent or help define the intended meaning of the encapsulating entity. A= n entity may be the source for and/or the target of zero or more relationsh= ips. Relationships are described in more detail in a following section. The= collection of all coded entities defined with in a coding scheme is encaps= ulated by a single entities container.
Entity is a set of lexical assertions about the intended meaning of a pa= rticular entity code. Each entity represents a unique entity within the cod= e system, it could be of type 'concept', 'instance', 'association' etc., an= d can be further described by properties and its relation to other entities= through relations. The collection of all coded entities defined with in a = coding scheme is encapsulated by a single entities container.
Relations are used to define and qualify associations between entities. = Each code system may define one or more containers to encapsulate relations= hips between entities. Each named relationship (e.g. "hasSubtype" or "hasPa= rt") is represented as an association within the LexGrid model. Each relati= ons container must define one or more association. The association definiti= on may also further define the nature of the relationship in terms of trans= itivity, navigable, forward and inverse names, etc. Multiple instances of e= ach association can be defined, each of which provide a directed relationsh= ip between one source and one or more target entities.
Source and target entities may be contained in the same code system as t= he association or another if explicitly identified. By default, all source = and target entities are resolved from the code system defining the associat= ion. The code system can be overridden by each specific association, relati= on source (associationInstance), or relation target (associationTarget).
AssociationEntity is a subclass of an Entity with type as 'association'.= AssociationEntity basically defines the nature of the relationship in term= s of transitivity, navigable, forward and reverse names.
Value Set Definition with in the LexGrid logical model defines the conte= nts of a Value Set. The contents are coded entities defined in referencing = Code System. Value Set can contain coded entities from one or more Code Sys= tems.
Visit L= exEVS 6.x Value Set Detailed Design for detailed information about Valu= e Set Definition.
Pick List Definition with in the LexGrid logical model defines an ordere= d list of entity codes and corresponding presentations drawn from a resolve= d value set definition.
Visit L= exEVS 6.x Pick List Detailed Design for detailed information about Pick= List Definition.
These are the elements primarily used to define metadata for a coding sc= heme, value set and pick list definition, mapping locally used names to glo= bal references. Each naming elements are represented as SupportedXXX where = XXX could be language, property name, source, context etc., that are locall= y used in coding scheme, value set definition or pick list definition. It a= lso has an optional URI that can be used to find the exact definition and m= eaning of the local id. Note: the string portion of this entry can be used = to provide additional documentation or information, especially when a URI i= s not supplied.
These are the elements primarily used to author terminology elements.
System Release is a collection of coding schemes, value set definitions,= pick list definitions and/or revision records that are distributed as a un= it.
Versionable Entities are the resources that can undergo change over time= while maintaining its identity. All the LexGrid elements that can undergo = changes (like Entity, CodingScheme, ValueSetDefinition, property etc) are V= ersionable Entities.
Versioning are an ordered collection of state changes that define the tr= ansformation of a set of resources from one consistent state to another.
The following extensions to the LexGrid model were introduced in support= of caBIG=C2=AE requirements. As with the LexGrid model, this document prov= ides a summary of the most significant elements for consideration by LexBIG= programmers. The complete and current version of the model is available online .
The LexBIG logical model consists of following five XML schemas:
LexBIG Collection contains named sets of things.
Schema: Collection.xsd:
http://= lexgrid.org/LexGrid/downloads/LexBIG/schemas/2010/01/Collection.xsd
LexBIG core elements provide enhanced referencing and controlled resolut= ion of LexGrid model objects.
LexBIG Enums contains various enums available in LexBIG model.
Schema: Enums.xsd:
http://= lexgrid.org/LexGrid/downloads/LexBIG/schemas/2010/01/Enums.xsd
Defines metadata related to model objects required by the runtime.
Maintains a record of modifications made to a code system.