Date: Thu, 28 Mar 2024 17:10:30 -0400 (EDT) Message-ID: <1530486486.808.1711660230031@ip-10-208-27-219.ec2.internal> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_807_82010600.1711660230024" ------=_Part_807_82010600.1711660230024 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
This document is a section of the Design and Architecture Gui= de.
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 LexBIG 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 LexBIG APIs.
To view the LexGrid 2010 Logical Model please visit the following: LexGrid 2010 Model= a>
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 informatio= n used to uniquely identify the code system, along with relevant metadata. = The collection of all code systems defined to a service is encapsulated by = a single codingSchemes container.
A code system may define zero or more coded concepts, encapsulated withi= n a single container. A concept represents a coded entity (identified in th= e model as a concept) within a particular domain of discourse. Eac= h concept is unique within the code system that defines it. To be valid, a = concept must be qualified by at least one designation, represented in the m= odel as a property. Each property is an attribute, facet, or some = other characteristic that may represent or help define the intended meaning= of the encapsulating concept. A concept may be the source for and/or the t= arget of zero or more relationships. Relationships are described in more de= tail in a following section.
Each code system may define one or more containers to encapsulate relati= onships between concepts. Each named relationship (e.g. "hasSubtype" or "ha= sPart") is represented as an association within the LexGrid model.= Each relations container must define one or more association. The associat= ion definition may also further define the nature of the relationship in te= rms of transitivity, symmetry, reflexivity, forward and inverse names, etc.= Multiple instances of each association can be defined, each of which provi= de a directed relationship between one source and one or more target concep= ts.
Source and target concepts may be contained in the same code system as t= he association or another if explicitly identified. By default, all source = and target concepts 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 (associati= onTarget).