The Lexical Grid (LexGrid) project is an on-going communitydriven initiative coordinated by the Mayo Clinic Division of Biomedical Statistics and Informatics (BSI). It provides a common terminology model to represent multiple vocabulary and ontology sources as well as a scalable and robust API for accessing such information. While successfully used and adopted in the biomedical and clinical community, an important requirement is to align the existing LexGrid model with emerging Semantic Web standards and speci¯cations. This paper introduces the LexRDF model, which maps the LexGrid model elements to corresponding constructs in W3C speci¯cations such as RDF, OWL, and SKOS. Our mapping speci¯cation successfully used W3C standards to represent most of the existing LexGrid components, and those that did not map point out issues in the existing speci¯cations that the W3C may want to consider in future work. With LexRDF, the terminological information represented in LexGrid can be translated to RDF triples, and therefore allowing LexGrid to leverage standard tools and technologies such as SPARQL and RDF triple stores.
The evolution of ontologies and vocabularies in the biomedical domain, across the spectrum of detailed nomenclatures and sophisticated classi¯cations, has accelerated dramatically over the last decade [1{3]. This coupled with the ability to access vast amounts of patient data in electronic medical records (EMR) provides the opportunity to build semantically interoperable healthcare applications and solutions for individualized and evidence-based medicine. However, in practice, the healthcare service providers and EMR system vendors alike confront the di±culties of incorporating elaborate ontologies and vocabularies into clinical workstations and data recording system clients in an intuitive, friendly, and responsive interface while preserving the expressive power and latent semantics of the ontologies. This can be primarily attributed to incompatible ontology representation formats, multiple ontology modeling languages, and the lack of appropriate tooling and programming interfaces which hinder the wide-scale adoption and usage of biomedical ontologies in a variety of application contexts.
To address these issues, the Mayo Clinic Division of Biomedical Statistics and
Informatics has been coordinating a community-wide initiative, called LexGrid,
that is aimed at developing a common terminology model and programming
interfaces for uniformly storing, representing, and querying biomedical ontologies
and vocabularies [
While successfully used and adopted in the biomedical and clinical
community (see Section 2.1 for details), the current LexGrid model has not yet been
formally aligned with the most recent Semantic Web (World Wide Web
Consortium; W3C) standards and speci¯cations [
We discuss the details of the mapping process in the remainder of this paper. Section 2 gives an overview of the LexGrid model and a brief introduction to the appropriate W3C standards. Section 3 discusses how we arrived at the LexRDF mapping speci¯cation. Section 4 discusses the issues we encountered, summarizes the extensions we will propose to the W3C community, and addresses the possible future directions. 2 2.1
The LexGrid project is an on-going community-driven initiative that builds upon a set of common tools, data formats, and read/update mechanisms for storing, representing and querying biomedical ontologies and vocabularies. The primary goal of LexGrid is to accommodate multiple vocabulary and ontology distribution formats and support of multiple data stores for federated vocabulary and ontology access. The LexGrid model is designed to be °exible enough to faithfully and accurately represent a wide variety of multilingual terminological resources. LexGrid provides a semantic foundation upon which multiple APIs can be developed that support consistent searching, navigation and cross terminology traversal. Existing API implementations include the LexEVS API (http://gforge.nci.nih.gov/projects/lexevs), a reference implementation of the HL7 Common Terminology Services (CTS), and the LexWiki model (https://cabig-kc.nci.nih.gov/Vocab/KC/index.php/LexWiki) for representing terminology within a semantic mediawiki. These open-source tools are used in a variety of projects both internal and external to the Mayo Clinic, including the NCI Cancer Biomedical Informatics Grid (caBIG; http://cabig.nci.nih.gov), the National Center for Biomedical Ontology (NCBO; http://www.bioontology.org), the Biomedical Grid Terminology project (http://www.biomedgt.org), and the World Health Organization International Classi¯cation of Diseases (ICD-11) development process (http://www.who.int/classi¯cations/icd/ICDRevision). LexGrid hosts a wide variety of terminologies and ontologies including ICD-9-CM (http://icd9cm.chrisendres.com/), the Gene Ontology (http://www.geneontology.org/), the HL7 Version 3 vocabulary, and SNOMED-CT. LexGrid can also represent complete NLM Uni¯ed Medical Language System (http://www.nlm.nih.gov/research/umls), which currently includes over 100 source terminologies. Our experience in developing and deploying the LexGrid technology provides an unparalleled basis for using ontologies to represent patient and clinical trial information, thereby enabling semantic information retrieval. 2.2
The World Wide Web Consortium (W3C) is the main international standards
organization for the World Wide Web. Its goal is to develop interoperable
technologies and tools as well as speci¯cations and guidelines to lead the Web to
its full potential. W3C recommendation has several maturity levels: Working
Draft, Candidate Recommendation, Proposed Recommendation, and W3C
Recommendation. The standard recommendations we evaluated and compared with
LexGrid , and included in our mapping are the followings. The Resource
Description Framework (RDF) [
Our primary task was to determine equivalent constructs or axioms in the W3C recommendations introduced in Section 2.2 for each LexGrid element. In the case where appropriate mapping is lacking from the W3C speci¯cations, we proposed new constructs in the LexRDF name space. These extensions will be proposed to appropriate W3C committee for future recommendation. 3.1
LexGrid comprises various lexical elements describing meta-data about an ontology. These include provenance (source (dc:source), copyright (dc:right ), version (owl:verionInfo)), name (dc:title, rdf:label ), URI, and language (dc:language). Table 1 shows the LexRDF mapping speci¯cation for ontology information. LexRDF successfully identi¯ed mappings for all the LexGrid ontologyinformation components except one: approxNumConcepts, which indicates the total number of ontological entities present in a given/loaded ontology. This attribute was intended as a hint to service components, especially for the largesize ontologies. Since this information can be inferred from the ontology itself, we chose to exclude it from this mapping. 3.2
A LexGrid entity represents any resource in a terminology or ontology. Figure 1 shows the syntax graph of the LexGrid entity components. A dashed arrow from element A to element B indicates that A is an instance of B. An arrow with a clear arrowhead from A to B indicates that A is a subclass of B. We use lg to represent the LexGrid name space. LexGrid has de¯ned lg:concept, lg:association, and lg:instance as subclasses of lg:entity. LexRDF maps lg:concept to owl:Class, meaning that lg:concept inherits the de¯nition of owl:Class |both an instance and a subclass of rdfs:Class. The lg:association element is equivalent to the union of owl:ObjectProperty and owl:DatatypeProperty, which are both instances of rdfs:Class and subclasses of rdf:Property. The lg:instance element is a general holder of OWL individuals which are instances of OWL classes. LexRDF uses owl:Thing to declare a LexGrid instance in RDF triple representation when no speci¯c type is de¯ned for an instance. LexRDF also maps lg:entity to skos:Concept, which is de¯ned as an instance of owl:Class. This mapping speci¯cation preserves the original LexGrid de¯nition without introducing any contradictions of de¯nition in the standard name spaces.
Table 2 speci¯es LexRDF mappings for the LexGrid components related to entities. In addition to the mapping speci¯cation discussed above, each entity has an entityCode which is used as the URI for the corresponding entity in LexRDF. The entityCodeNamespace is the xmlns in LexRDF. LexGrid represents the anonymous classes in OWL using anonymous concepts. In this case, the isAnonymous °ag is set to be true in the loaded code system. In all other cases, the isAnonymous °ag is false. We believe this information is implicitly expressed in OWL, therefore we did not specify a mapping for isAnonymous. LexGrid also de¯ned a isDe¯ned °ag (true means that the entity is considered to be completely de¯ned (i.e. necessary and su±cient) within the context of the containing code system; and false means that only the necessary components are present). We use LexRDF:isDe¯ned to represent this °ag. The domain of LexRDF:isDe¯ned is skos:Concept and the range is boolean values. 3.3
Every instance of a LexGrid entity is associated with a set of properties, which are analogous to annotation properties in OWL. Table 3 shows the LexRDF mapping speci¯cation for property information and Figure 2 shows the property de¯nition overview. Each lg:property could have an optional type (comment, presentation, or de¯nition). Each lg:presenation and lg:de¯nition has a isPreferred °ag which indicates whether it was \preferred" in the given language and context. When no type is speci¯ed, a lg:property is mapped to an owl:AnnotationProperty. The lg:comment is a super property of skos:changeNote, skos:editorialNote, skos:example, skos:historyNote, and skos:scopeNote. The lg:presentation is mapped to skos:prefLabel when the isPreferred °ag is set to true and to skos:altLabel otherwise. The LexGrid de¯nition element is mapped to skos:de¯nition. LexRDF uses a LexRDF:isPreferred construct to reify whether a de¯nition is preferred or not.
As an example, Figure 3 illustrates how LexRDF presents entity property and
property rei¯cation. Figure 3(a) shows the original representation of a sample
term in the OBO [
Entity Code:FAO:0000025 Entity Type:Concept Presentation:mid reproductive
Property Name:textualPresentation is Preferred:true Presentation:``principal growth stages 6.1-6.3''
Property Name:synonym is Preferred:false Definition:``middle stages of reproductive phase.''
Property Name:definition is Preferred:true Source:TAIR:lr
(c)
Subject Predicate Object 1 FAO:0000025 rdf:type owl:Class 2 FAO:0000025 skos:prefLabel mid reproductive 3 FAO:0000025 skos:altLabel \principal growth stages 6.1-6.3" 4 A1 rdf:type rdf:Statement 5 A1 rdf:subject FAO:0000025 6 A1 rdf:predicate skos:de¯nition 7 A1 rdf:object \middle stages of reproductive phase." 8 A1 dc:source TAIR:lr 9 A1 lexRDF:isPrefered true has a source \TAIR:lr" using the predicate dc:source. LexGrid also set this de¯nition as a preferred one by default. Therefore LexRDF rei¯ed A1 as a preferred de¯nition using predicate LexRDF:isPreferred as row 9 in Figure 3(c) shows.
LexGrid uses propertyLink to de¯ne relationships between two properties. LexRDF de¯ned a new annotation property, LexRDF:propertyLink. Each property link is de¯ned as an instance of owl:ObjectProperty and a sub-property of LexRDF:propertyLink. LexRDF uses RDF rei¯cation to de¯ne a link between two properties. Figure 4 shows an example. A concept A has a preferred presentation \FAO", and another presentation \Food and Agriculture Organization". The relation between the two presentations is that the former is an acronym of the latter. The LexRDF representation is as fellows. A1 and A2 are the two properties of concept A. The relationship between A1 and A2 is sns:acronymOf where sns represents the source name space. And sns:acronymOf is also de¯ned as a sub-property of LexRDF:propertyLink.
LexRDF also de¯ned three new annotation properties: LexRDF:degreeOfFidelity, LexRDF:matchIfNoContext, and LexRDF:representationalForm. The degree of ¯delity states how closely a term approximates the intended meaning of an entry code. The MatchIfNoContext °ag should be set to true when the entity <A1> rdf:type rdf:Statement; rdf:subject <A>;
rdf:predicate skos:prefLabel; rdf:object "FAO"; <A2> rdf:type rdf:Statement; rdf:subject <A>; rdf:predicate skos:altLabel; rdf:object "Food and Agriculture Organization"; <A1> sns:acronymOf <A2>; sns:acronymOf rdf:subProperty LexRDF:propertyLink; presentation is valid in a contextual setting. The representational form states how the term represents the concept (abbreviation, acronym, etc.). 3.4
LexGrid uses associations to represent relationships between entities. The association de¯nition may also further de¯ne the nature of the relationship such as forward and inverse names, transitivity, symmetry, re°exivity, and etc. Table 4 shows the LexRDF mapping speci¯cation for LexGrid association elements. LexRDF used OWL properties and assertions to represent all of them except reverseName and isAntiTransitive. LexRDF uses a new construct LexRDF:reverseName to represent the name of the association on the reverse direction when a target to source side of the association is meaningful. LexRDF:isAntiTransitive is used to represent a property that is not transitive. In addition, an association could be modi¯ed by using LexGrid associationQuali¯cation. For example, one can de¯ne Poland anomaly FHreAqSueCncLyI=NVIeCrAyLfrSeIqGueNnt Dextrocardia, where HAS CLINICAL SIGN is the association name, Poland anomaly is the association source and Dextrocardia is the association target. This association instance also has an association quali¯cation indicates how frequently the disease has the symptom. The association quali¯cation has a name Frequency and a value Very
Subject Predicate Object 1 Poland anomaly rdf:type owl:class 2 Dextrocardia rdf:type owl:class 3 Poland anomaly rdfs:subClassOf A1 4 A1 rdf:type owl:Restriction 5 A1 owl:onProperty HAS CLINICAL SIGN 6 A1 owl:someValuesFrom Dextrocardia 7 A1 sns:Frequency \Very frequent" 8 sns:Frequency rdf:subProperty lexRDF:associationQuali¯cation 9 HAS CLINICAL SIGN rdf:type owl:objectProperty
Table 5. RDF Triples for an Example of AssociationQuali¯er frequent. Table 5 shows how LexRDF represents this example. By default, LexRDF uses OWL someValuesFrom restriction to represent an association instance. LexRDF ¯rst declares an anonymous note A1 for the association instance (rows 3-6 in Table 5). For associationQuali¯cation, LexRDF de¯ned a new OWL annotation property, LexRDF:associationQuali¯cation. Every actual association quali¯er is de¯ned as a sub-property of LexRDF:associationQuali¯cation, and therefore is also an instance of OWL annotation property. Rows 7-8 show how LexRDF de¯nes and rei¯es association quali¯ers. 4
We discussed the LexRDF mapping speci¯cation with respective to ontology information, entity, property, and association. LexRDF has successfully mapped 37 out of 45 LexGrid elements, achieving a very high degree of reusability. We have also discovered some interesting issues where the W3C standard language cannot fully represent our needs in LexGrid.
Generic holder for properties and comments As Figure 2 shows, LexGrid has a common superclass lg:property for comments, presentations, and de¯nitions. In LexRDF, we use skos:prefLabel and skos:altLabel, both of which are sub-properties of rdfs:label, to represent lg:comment ; we use skos:de¯nition, which is an instance of owl:AnnotationProperty, to represent lg:de¯nition. The properties in the subset of skos:note which we use to represent lg:comment are also de¯ned as instances of owl:AnnotationProperty. SKOS provides skos:notes as a general superset for de¯nition, example, and a set of di®erent notes. But it does not de¯ne a common ancestor for labels, and notes. We cannot ¯nd an appropriate component to represent generic properties. We have a similar problem with lg:comment. Currently it is mapped to a set of sub-properties of skos:note, but a generic comment class is also preferred.
Preferred properties SKOS has de¯ned prefLabel and altLabel, but no such constructs are provided for "de¯nitions". Currently, we are using LexRDF:isPreferred as a tag to specify whether a de¯nition is preferred or not. Akin to prefLabel and altLabel, our objective is to propose prefDe¯nition and altDe¯nition to the SKOS committee to be introduced in the future speci¯cation.
Association Quali¯cation LexGrid provides an option for modifying an association instance by adding association quali¯ers. We have found this to be needed in the clinical domain and believe that it is an important requirement to be considered by the appropriate W3C standards group.
Relation among properties We have a requirement to describe relations among properties. SKOS provides skosxl:labelRelation that can represent relations between two labels. The property skosxl:labelRelation, however, is de¯ned as a symmetric property with domain and range as skosxl:Label. These limitations restrict us from using it for our LexGrid propertyLink. We proposed a more general property LexRDF:propertyLink which is a super-property of skosxl:labelRelation. By using LexRDF:propertyLink, we can de¯ne relations between any two LexGrid properties. For example, we can assert that a particular label is an acronym of another, or that a given de¯nition is a literal translation of the same de¯nition in another language.
Property groups LexGrid is represent in UML where each concept could have multiple attributes de¯ned. For example, The LexGrid property element has attributes name and value. Same as associationQuali¯cation. How to represent this situation was a challenge for us. Currently, LexRDF de¯nes each generic property or association quali¯cation using a new OWL annotation property with its name value as the URI (i.e., sns:Frequency ). These new properties are also de¯ned as sub-properties of either LexRDF:entityProperty or LexRDF:associationQuali¯cation. This approach brings new interoperability problems since many new annotation properties were being de¯ned. We need to design a mechanism which can be used to represent a group of properties (i.e, name and value), then use this group to reify other elements.
In addition, we encountered the similar issue with association quali¯cations. Sometimes one association might have multiple groups of quali¯ers. For example, in UMLS we can have an association C001 PAR C002, where PAR is the association, C001 is the source, and C002 is the target. This association has two groups of quali¯ers: fRela=sub Type, Sab=LNCg and fRela=is a, Sab=SNOMEDg. We should consider de¯ning a propertyGroup similar to owl:propertyChain where a group of properties can be de¯ned together.
Missing lexical constructs For some lexical information in LexGrid (e.g., degreeOfFidelity, representationalForm, isDe¯ned), we cannot specify mappings. Coding and tags for these properties are being developed in the ISO TC37 community (http://www.tc37sc4.org/index.php) which we believe should be merged into the W3C speci¯cations. We have initiated communication with the respective W3C working groups for their inclusion in appropriate speci¯cations.
In summary, this paper introduced our on-going work to map the elements from the HL7 and ISO compliant LexGrid model to various Semantic Web standards. Although mostly successful, we have identi¯ed several limitations of the existing W3C speci¯cations that warrant broader community engagement.
Several directions remain to be pursued. We are working on implementing
a \bridge" that can load the LexGrid content and transferred it to an RDF
triple store according to the LexRDF mapping speci¯cation. We would also like
to formalize the LexRDF mapping speci¯cation by using standards such as the
OMG Ontology De¯nition Metamodel (ODM) [