Remove LDAP Implementation
The LDAP implementation of the LexGrid model is no longer being used. The LDAP specific elements in the LexGrid model should be removed, as they add a degree of complexity and confusion that is no longer justified.
There are several issues that have made the model difficult to explain, implement, and use. These issues include:
All text type fields need data types
We need the ability to add a data type (format) to the target of associations as well as the target of any property. Right now, it only applies to property
Changed builtins name to "tsAnType". Added an optional dataType attribute to the field. Changed the types of "text" and "entityDescription to "tsAnyType". Changed property and associationData to have a reference to an entity of type "text" rather than being a kind of "text"
Flexible Entity types
The 2008/01 model supports a fixed set of entity types - concept, relation and instance. While this aligns with OWL/DL, it doesn't account for (a) terminologies that haven't differentiated classes from individuals, (b) OWL Full, where an entity can be both a class and an individual and (c) other type systems, such as that supported by KTMI
Made "entity" a first class class, that included all properties and characteristics. Added an optional, repeating entityType field which allowed the entity to be classified, added supportedEntityType in the mappings to allow types to be customized, removed the fixed enumeration of types and added constraints that define "concept", "instance" and "relation" by the entityType field
LexGrid updates need to be communicated as sets of changes rather than complete sets of contents. The history mechanism needs to be extended so that a collection of changes can be communicated that will allow an existing system to be updated incrementally
Changed the definition of versionable, added entityState and revision model elements and changed the definition of systemRelease to carry a collection of revisions.
Refined History Model
LexGrid needs the ability to version and activate changes on the property, entity, association instance, pick list, pick list entry level in addition to the concept level. Each of these entities need to support a status, state (active or inactive) the date/time when the change is to become active, the data/time when it is to become inactive, and additional metadata about who, how and why the change should be applied.
Namespaces Aren't CodingSchemes
The namespace used to qualify the URI of a coded entity isn't necessarily the namespace of the coding scheme making an assertion about the entity. These two elements are convoluted in the current LexGrid model.
Added a new localId type, "NamespaceName" and a new mapping, "supportedNamespace". Changed the codingSchemeId attribute of "entity" to entityCodeNamespace, which references a supportedNamespace. If entityCodeNamespace is present, it references a supportedNamespace, which, in turn, has an attribute, "equivalentCodingScheme", which has the local name of the codingScheme that corresponds to the entityCodeNamespace
Revise Value Domains / Pick Lists
The value domain model needs to be extended to support the definitions represented in the IHC model. In addition, the model needs to support (a) HL7's value domain definition model and the sort of definitions that can be created through the DTS editor. The model of pick lists need to be extended accordingly to meet multiple GE/IHC requirements
Completely replaced the ValueDomains package to carry the new model.
Dual Type Properties
RDF based loaders transform triples into a combination of (a) first class attributes (e.g. entityDescription, copyRight, presentation, definition, ...) (b) generic lexical properties or (c) relations. Properties and relations preserve the original RDF type, but the first class attributes lose the information about where the resource was derived from. In addition, there is no way to assign status and provenance information to the first class attributes (see: Refined History Model)
Model philosophy was changed to have first class attributes represented in two forms: as an attribute and as a property that is identified as being an attribute. To do this, we added new attributes to property and propertyQualifier that, if non-blank, stated the first class entity that this property (or propertyQualifier) represented. As an example, the copyRight entity would also be represented as a property with a propertyType of "copyRight"
The LexBIG API history API goes directly against the NCI Cumulative History content and renders its output in terms of codingSchemeVersion, version and entity version. These elements need to be preserved in the new LexGrid model as deprecated elements that exist for backwards compatibility with the LexBIG API.
Preserved Version, Version Reference, representsVersion, entityVersion and codingSchemeVersion, but marked them as "deprecated"
Common Mappings Type
The 2008/01 model has two different "mappings" entities, one for codingScheme and one for valueDomain. Each has a different collection of supported, and the order of the entries are confusing and arbitrary. With the addition of another "mappings" entry for pick list, we suggest that the three mappings be consolidated into one type, and the contents be alphabetized. This will make code management and authoring easier. (second entry) It should be possible to enter a codingScheme, valueDomain or pickList without having any mappings entries and have the loader fill out the information of all of the localId's and, where possible, the URI's that they map to. This should not be the function of an editor or type transformation package
Created a new "mappings" entry in Naming package, removed the existing entries from codingScheme and valueDomain and pointed them at the new entry. Alphabetized the entries and made them all optional.
Agent Role on supportedSource
supportedSource has an agentRole field, but role is a property of the association of the source with the entity (e.g. the source may be author on one field, editor on another).
Removed agentRole from supportedSource
Assertions can be inferred, entities cannot
isInferred is listed as a property of a concept. DL can infer additional axioms about a concept, but they cannot infer the existence of a concept that isn't already specified.
Moved isInferred from concept to associatiableElement
PropertyLink.propertyLink is confusing
the link attribute in the propertyLink element was renamed to "propertyLink". This is confusing
(not fixed yet)
isTranslationAssociation is not a property of the association, but how it is used.
Association was made a first class entity in the 2008/01 model, meaning that all of the characteristics had to be properties of the association itself, not how it used in a particular relations collection. isTranslationAssociation is a property of use, yet is listed as a property of the association itself
Removed isTranslationAssociation from the model. No alternative available at the moment
targetCodingScheme is not a property of an association, but how it is used.
Association was made a first class entity in the 2008/01 model, meaning that all of the characteristics had to be properties of the association itself, not how it used in a particular relations collection. targetCodingScheme is a function of how it is used, not the association itself
Removed targetCodingScheme from the model, meaning that mappings across coding schemes will always have to provide the namespace id for the target element.
associationName is a localId, not an entityCode
Association was made a first class entity in the 2008/01 model, and associationName was removed anticipating that the entityCode and associationName would always be the same thing. This may not be the case, however, as an ontology may use, say "isA" as the name of an association, but define it as being the same as an entirely different concept in a different namespace.
Reintroduced associationName as a localId with the supportedAssociation mapping entries
Type is an attribute of entity, not usage. An entity can have multiple types
sourceEntityType and targetEntityType are incorrect in the associations package, as they assume that the type is part of an entity's identity (i.e. you can have two entities with the same URI, one of which is a class and one an individual).
sourceEntityType and targetEntityType were removed from the model
Need to select associations by context
IHC needs to be able to select associations based on a passed context
added usageContext attribute to associatableElement
Need instance identifiers on associations
You can assign an identifier to a DataProperty type association, but not to ObjectProperty type association. Both IHC and SNOMED-CT maintain unique identifiers on associations
Removed dataId from the associationData and created associationInstanceId in the associatableElement class. This field is optional, as dataId originally existed for LDAP compatibility.
Need to know whether an association participates in the definition of a concept
While OWL doesn't currently support this, it is useful to understand whether a assertion is considered to be part of the definition of an entity or simply an additional fact that is known about that entity.
Added isDefining attribute to the associatableElement class