Bridging the Semantic and Lexical Webs:Concept-Validating and Hypothesis-Exploring Ontologies

for the Nexus-PORTAL-DOORS SystemAdam Craig, Seung-Ho Bae and Carl Taswell

Brain Health Alliance, Ladera Ranch, CA 92694, USA

ABSTRACTThe Nexus-PORTAL-DOORS System (NPDS) hasbeen designed with the Hierarchically Distributed Mo-bile Metadata (HDMM) architectural style to pro-vide an infrastructure system for managing both lex-ical and semantic metadata about both virtual andphysical entities. We describe here how compatibil-ity between version 0.9 of the NPDS schema, the newNPDS-interfacing ontologies, and the domain-specificconcept-validating hypothesis-exploring ontologies al-lows NPDS to bootstrap the semantic web onto themore developed lexical web. We then describe howthis system will serve as the foundation of a plannedplatform for automated meta-analysis.

Keywords: Nexus-PORTAL-DOORS System,concept-validating ontology, hypothesis-exploring on-tology, semantic web, message exchange, metadatamanagement.

1 NEXUS-PORTAL-DOORSSYSTEM

The Nexus-PORTAL-DOORS System (NPDS)offersan approach by which individuals and organizationscan manage their own repositories of semantic andlexical metadata about a problem domain of interestand share metadata records via a common messageexchange format [18]. It consists of a metadata modelschema, messaging specification, and network archi-tecture for servers that distribute metadata aboutonline and offline resources. NPDS includes fourtypes of servers: The PORTAL registry is a registryfor resource representations that include URI iden-tifiers, names, text descriptions, keyword tags, con-trolled vocabulary term labels, and cross-references.The DOORS directory is a directory for lookup ofURI identifiers for resources with online and offlinelocations via their associated RDF descriptions. TheNexus diristry is a PORTAL registry and DOORSdirectory combined in a single server. The NPDScomponents server is a collection for meta-data about

NPDS services. Analogous to the Internet RegistryInformation Service (IRIS) and Domain Name Sys-tem (DNS) protocols, NPDS implements the Hierar-chically Distributed Mobile Metadata (HDMM) ar-chitectural style to deliver accurate information withlow latency [15]. Servers of the same type can forma hierarchy with primary servers that maintain mas-ter copies of records and that distribute them to sec-ondary and caching servers. Components of the NPDScan communicate with each other and with web ap-plications that retrieve records from them via a con-sistent RESTful web service API. The NPDS specifi-cation does not include the registrars through whichhuman users or automated agents may register newresources with a PORTAL registry. We have createdan example registrar service, Scribe, exposing a read-write REST web service API.

2 PRIOR WORKThe first published description of the PORTAL-DOORS System introduced the PORTAL andDOORS servers in order to promote synergy be-tween lexical and semantic meta-data [18]. Ver-sion 0.6 introduced the Nexus server as a com-bined registry, directory, and registrar to simplifyimplementation and use by combining all function-ality into a single server for simpler implementation[15]. Since then, we have worked with example im-plementations hosted at http://npds.portaldoors.net/, http://npds.telegenetics.net/, and http://npds.brainhealthalliance.net/ to better under-stand the strengths and weaknesses of our approachin realistic usage scenarios [19], [16], [13]. In the pre-vious iteration, version 0.8, we introduced a stream-lined read-only RESTful NPDS API for PORTAL reg-istries, DOORS directories, and Nexus diristires anda separate RESTful read-write API for Scribe regis-trars, simplifying development for client applicationsthat only need to retrieve records [5]. By assigningeach resource description a unique URI with resolv-able URL from which it can be retrieved, using this

Figure 1: Example of typical work-flow in NPDS manual curation web application.

and other URLs for cross-references between records,and delivering records using open web standards suchas XML and JSON, NPDS offers a more concrete andstructured realization of the ideals described in thelinked-data principles [1]. We hope that NPDS as adistributed system will play a complementary role inthe linked data ecosystem interfacing with those sys-tems that operate as centralized repositories such asWikidata [11] and domain-specific search of arbitrar-ily structured data such as DARPA’s Memex projects[21]. In parallel with development of the NPDS spec-ification itself, the example implementation of NPDShas followed a step-by-step development process inwhich each iteration has made fuller use of the sys-tem’s potential:

v0.5 First production code implementation of partialPORTAL server functionality, partial DOORSserver functionality, and AJAX-enabled web ap-plication for record curation. Version 0.5.4 wasthe last 0.5.* version published on 3/29/2009[18].

v0.6 Implementation with ASP.net of RESTful webservice API and AJAX-enabled curation appli-cation [15] (Figure 1).

v0.7 Implementation of lexical PORTAL and seman-tic DOORS functionality and interoperabilitywith MeSH contolled vocabulary [19].

v0.8 Implementation of lexical-semantic Nexusdiristries and streamlined RESTful read-onlyNPDS API and separate RESTful read-writeScribe API [5].

3 NPD ONTOLOGIESThe Nexus, PORTAL, and DOORS (NPD) ontologiesbridge the gap between lexical metadata and seman-tic descriptions. Each server type is defined by anauthoritative XML Schema Description (XSD) thatdescribes the required fields each server must includein the records published through it and the optionalfields for which NPDS client applications should check(Table 1). For each XML schema, we derived a cor-responding formal ontology representing the elementsof a Nexus, PORTAL, or DOORS record and the rela-tionships among them in such a way that it is straight-forward to convert key lexical metadata fields into asemantic description of the resource. While the XMLsemantics reuse paradigm informed our choice of for-malisms, we chose not to algorithmically convert ev-ery defined XSD type to a corresponding OWL class[7]. Instead, we selected the elements with informationthat would serve key functions for client applications,such as determining record provenance and currencyand identifying different semantic descriptions on sep-arate servers as describing alternate features of thesame entity. Where appropriate, the NPD ontolo-

gies reference other widely used ontologies and mapterms to equivalent terms in those ontologies. Forexample, the resource types in the Bibliographic On-tology (BIBO) are either equivalent to or subclasses ofsubclasses of the NPD resource type class, ET_Typebased on the enumerated type of the same name inthe XML schema [6].

4 CONCEPT-VALIDATINGONTOLOGIES

Large encyclopedic reference ontologies can be cum-bersome for both users and developers. For users, es-pecially those not versed in predicate logic, searchingthrough a large tree of classes and examining theirproperties takes time and effort, especially when theontology does not include the exact concept for whichone is looking or a direct relationship between twoconcepts of interest, thus requiring that the user cob-ble together a more complex query from the existingclasses and properties. For developers, updating nodesin an ontology with hundreds or thousands of classesand properties may introduce inconsistencies that aredifficult to resolve, making large ontologies more diffi-cult to maintain. Organizing the encyclopedia of con-cepts into smaller, modular ontologies that cover thelexicons of special topics makes both issues more man-ageable. A user can focus on searching for classes andproperties within a module of interest, and a developercan work on a module with less danger of introducingerrors in other modules. This mode of thought hasdriven the development of the original ManRay ontol-ogy [20] and many other ontologies including the OBOFoundry ontologies, the Gene Ontology and Founda-tional Model of Anatomy, some of the most matureand widely-used ontologies in the biomedical field [14].

Concurrently with the Nexus-PORTAL-DOORSSystem, Brain Health Alliance has been developinga collection of concept-validating ontologies foundedon this same principle. Early examples include theManRay ontology of nuclear medicine and diagnos-tic radiotracers [20] and the CTGaming ontology ofclinical telegaming [16]. Each such ontology definessufficient and necessary sets of concepts to which aknowledge resource must relate in order to fall withinthe scope of a particular problem domain. To addconcept-validating constraints to an NPDS server, adomain expert takes URIs or plain text terms fromthe ontology and groups them into expressions in con-junctive normal form, e.g. (sensory OR language ORmotor OR behavior) AND (onset) AND (neurodegen-erative OR dementia) [13]. A record must feature atleast one item from each group. A server can use mul-tiple tests with different types of tags or labels, inwhich case the record need only pass one of the tests

to be valid [17].

5 HYPOTHESIS-EXPLORINGONTOLOGIES

More recently, Brain Health Alliance has taken thisstrategy a step further by introducing the hypothesis-exploring ontology, a compact ontology that includesonly those concepts needed to describe the space of hy-potheses regarding a well-defined scientific question.The initial example of the hypothesis-exploring on-tology is the Sensory-Onset, Language-Onset, Motor-ONset (SOLOMON) ontology, which includes con-cepts needed to describe hypotheses on the relation-ships between onset type, disease progression, genes,brain regions, and proteinopathies in neurodegener-ative diseases leading to cognitive decline and de-mentia [13]. As SOLOMON and ManRay illustrate,unlike OBO Foundry ontologies, NPDS-interfacingontologies, whether only concept-validating or alsohypothesis-exploring, can overlap with each other.The use of a canonical label as a unique identifiermakes it clear whether two descriptions are of thesame resource, even when they describe it using differ-ent ontologies. However, to avoid redundancy where itserves no purpose, we include as modules within theNPD ontologies terms of shared use to all concept-validating and hypothesis-exploring ontologies, suchas Hypothesis, DependentVariable, and Independent-Variable. We also map these terms to concepts in theSWAN Biomedical Discourse Ontology [3].

6 USE-CASE EXAMPLE:META-ANALYSIS

A Google Scholar search for “nucleus accumbens” re-turned 19,200 results published since 2011. Read-ing through the abstracts alone would take weeks ormonths. Furthermore, 70% of results from such asearch are typically irrelevant, and 70% of relevantresults missing [12]. The herculean task of siftingthrough these results often falls to the authors of lit-erature review articles, valuable works that give read-ers new to a topic an overview of the current stateof a problem domain. A particularly valuable typeof literature review is the meta-analysis, which ag-gregates the effect sizes from numerous primary re-search articles testing the same hypothesis in orderto achieve greater statistical power than any one pri-mary study achieves alone [4]. The lengthy processof finding all the potentially relevant articles, select-ing which ones are of sufficient novelty and qualityto merit inclusion, and synthesizing their results intoa coherent set of conclusions is often a difficult task

Figure 2: Flow of information between components in the proposed system for automated meta-analaysis

that takes time away from the authors’ own origi-nal research. In the field of cognitive neuroscience,the greater statistical power meta-analysis can achievetakes on special importance, because human subjectsare both the most difficult to obtain in large numberand the most variable in behavior. Although animalmodels can help to uncover the low-level mechanismsof neuronal function and even of collective behaviorat the tissue scale, the human brain is unique in theanimal kingdom, and an understanding of the relation-ship between genotype, gene expression, biochemistry,anatomy, and behavior in the human brain requiresthe study of human beings. Brain Health Allianceis currently working to build a system for automatedmeta-analysis atop the NPDS infrastructure. In ad-dition to the NPDS and Scribe services themselves,this system will consist of six components (Figure 2).Web applications enabling curation of metadata pro-vide a human-friendly user interface for the Scriberegistrars. Focused web crawlers retrieve informationabout knowledge resources relevant to a problem do-main from databases, search engines, and other re-sources [2]. Such programs can aid human curatorsin populating NPDS servers with metadata. Naturallanguage processors translate natural language ques-tions into SPARQL queries and output from statis-tical analysis packages into natural language answers

[9]. Hypothesis-exploring ontologies allow for moredirect translation of questions from domain expertsinto SPARQL queries by providing a compact set ofthe most relevant concepts and relationships referenc-ing more comprehensive foundational and domain on-tologies to allow for query expansion [13]. Inferenceengines will expand queries and extract the relevantinformation from semantic descriptions of resourcesin DOORS or Nexus records [10]. Statistical analy-sis packages will compute aggregate effect sizes andconfidence intervals from the retrieved data [8].

7 CONCLUSIONSimilar to previous versions of the Nexus-PORTAL-DOORS System, NPDS v0.9 provides an infrastruc-ture system for the semantic web hybridized withthe lexical web. This current iteration brings NPDSanother step closer to bridging successfully the gapbetween the lexical and semantic webs by interfac-ing with the NPD ontologies, which in turn interfacewith domain-specific concept-validating hypothesis-exploring ontologies. These compact and easily up-dated ontologies will be instrumental in developingapplications that perform semantic search for re-sources registered with NPDS, including applicationsfor automated meta-analysis.

REFERENCES[1] Tim Berners-Lee. Linked data. 2006.[2] Soumen Chakrabarti, Martin Van den Berg,

and Byron Dom. “Focused crawling: a new ap-proach to topic-specific Web resource discovery”.In: Computer networks 31.11 (1999), pp. 1623–1640.

[3] Paolo Ciccarese, Elizabeth Wu, Gwen Wong,et al. “The SWAN biomedical discourse ontol-ogy”. In: Journal of Biomedical Informatics 41.5(2008), pp. 739–751. issn: 1532-0464.

[4] Harris Cooper, Larry V Hedges, and JeffreyC Valentine. The handbook of research synthe-sis and meta-analysis. Russell Sage Foundation,2009.

[5] Adam Craig, Seung-Ho Bae, Teja Veeramach-eneni, et al. “Web Service APIs for Scribe Regis-trars, Nexus Diristries, PORTAL Registries andDOORS Directories in the NPD System”. In:Proceedings of the 9th International SWAT4LSConference. Amsterdam, Netherlands, 2016.url: http://ceur-ws.org/Vol-1795/paper4.pdf.

[6] Bruce D’Arcus and Frédérick Giasson. Biblio-graphic ontology specification. 2009.

[7] Roberto Garcı́a González. A semantic web ap-proach to digital rights management. UniversitatPompeu Fabra, 2007.

[8] Robert J Grissom and John J Kim. Effect sizesfor research: Univariate and multivariate appli-cations. Routledge, 2012.

[9] Esther Kaufmann and Abraham Bernstein.“How useful are natural language interfaces tothe semantic web for casual end-users?” In: TheSemantic Web. Springer, 2007, pp. 281–294.

[10] James Mayfield and Tim Finin. “Information re-trieval on the Semantic Web: Integrating infer-ence and retrieval”. In: Proceedings of the SIGIRWorkshop on the Semantic Web. 2003.

[11] Elvira Mitraka, Andra Waagmeester, SebastianBurgstaller-Muehlbacher, et al. “Wikidata: Aplatform for data integration and disseminationfor the life sciences and beyond”. In: bioRxiv(2015), p. 031971.

[12] Andrey Rzhetsky, Michael Seringhaus, andMark Gerstein. “Seeking a New Biology throughText Mining”. In: Cell 134.1 (2008), pp. 9–13.issn: 0092-8674.

[13] Martin Skarzynski, Adam Craig, and CarlTaswell. “SOLOMON: An Ontology forSensory-Onset, Language-Onset and Motor-Onset Dementias”. In: Bioinformatics andBiomedicine (BIBM), 2015 IEEE InternationalConference on. IEEE. 2015, pp. 969–972.

[14] Barry Smith, Michael Ashburner, CorneliusRosse, et al. “The OBO Foundry: coordinatedevolution of ontologies to support biomedi-cal data integration.” In: Nat Biotechnol 25.11(2007), pp. 1251–1255.

[15] Carl Taswell. “A Distributed Infrastructure forMetadata about Metadata: The HDMM Archi-tectural Style and PORTAL-DOORS System”.In: Future Internet 2.2 (2010). In Special Is-sue on Metadata and Markup., pp. 156–189.issn: 1999-5903. doi: 10.3390/fi2020156. url:http://www.mdpi.com/1999-5903/2/2/156/.

[16] Carl Taswell. “A New PDS PORTAL for Clin-ical TeleGaming Rehabilitation and Interven-tion”. In: Proceedings of 2010 IEEE Inter-national Conference on Bioinformatics andBiomedicine (BIBM10). 2010.

[17] Carl Taswell. “Concept Validating Methods forMaintaining the Integrity of Problem OrientedDomains in the PORTAL-DOORS System”. In:IDAMAP 2010: Intelligent Data Analysis inBiomedicine and Pharmacology. Ed. by StephenSwift and Kirk Phillips.

[18] Carl Taswell. “DOORS to the Semantic Weband Grid with a PORTAL for Biomedical Com-puting”. In: IEEE Trans Inf Technol Biomed12.2 (2 Mar. 2008). In the Special Section onBio-Grid, pp. 191–204. issn: 1089-7771. doi: 10.1109/titb.2007.905861.

[19] Carl Taswell. “Use of the MeSH Thesaurus inthe PORTAL-DOORS System”. In: ProceedingsAMIA 2010 Symposium on Clinical Research In-formatics, San Francisco CA. 2010, AMIA-033-C2010.

[20] Carl Taswell, Benjamin Franc, and RandallHawkins. “The ManRay Project: Initial Devel-opment of a Web-Enabled Ontology for NuclearMedicine”. In: Proceedings of the 53rd AnnualMeeting of the Society of Nuclear Medicine, SanDiego, CA. June 2006, p. 1431.

[21] BD Wilson, LJ McGibbney, CA Mattmann, etal. “MemexGATE: Unearthing Latent ContentFeatures for Improved Search and RelevancyRanking Across Scientific Literature”. In: AGUFall Meeting Abstracts. 2015.

Schema/Ontology Class NPDS Message Element side level req. FunctionCT_ResourceRepresentationPortal ResourceRepresentation PORTAL N/A yes lexical metadata

except locationCT_ResourceRepresentationDoors ResourceRepresentation DOORS N/A yes location and seman-

tic descriptionCT_ResourceRepresentationNexus ResourceRepresentation Nexus N/A yes both lexical and se-

mantic informationCT_EntityLevel1Metadata EntityMetadata PORTAL entity yes description of the

resourceCT_Name Name all entity no plain text nameCT_Nature Nature all entity no plain text descrip-

tionCT_EntityCanonicalLabel CanonicalLabel all entity yes main NPDS URICT_EntityAliasLabel_Set AliasLabels PORTAL entity no alternate NPDS

URIsST_PrincipalTag PrincipalTag PORTAL entity no plain-text unique

identifierCT_SupportingTag_Set SupportingTags PORTAL entity no relevant plain-text

tagsCT_SupportingLabel_Set SupportingLabels PORTAL entity no relevant controlled

vocabulary IRIsCT_CrossReference_Set CrossReferences PORTAL entity no related NPDS

record URIsCT_OtherEntityLabel OtherEntity PORTAL entity no any non-NPDS IRI

identifierCT_OtherMetadata_Set OtherMetadata PORTAL entity no any other metadata

CT_ContactLabel Contact PORTAL entity no IRI of person tocontact about en-tity

CT_OwnerLabel Owner PORTAL entity no IRI of entity ownerCT_Location_Set Locations DOORS entity yes physical or on-line

locations of entityCT_Description_Set Descriptions DOORS entity no set of RDF descrip-

tionsCT_RecordLevel2Metadata ResourceRepresentation PORTAL record yes description of the

NPD recordCT_PersonLabel CreatedBy all record no IRI of record cre-

atorxsd:dateTime CreatedOn all record no date-time record

createdCT_PersonLabel UpdatedBy all record no IRI of last updating

userxsd:dateTime UpdatedOn all record no date-time last up-

datedCT_PersonLabel ManagedBy all record no IRI of user manag-

ing the recordCT_DirectoryLabel Directory PORTAL record no DOORS URLCT_RegistryLabel Registry DOORS record no PORTAL URL

CT_InfosetLevel3MetadataPortal InfosetMetadata PORTAL infoset yes record validationstatus

CT_InfosetValidation PortalValidation PORTAL infoset yes validation vs POR-TAL constraints

CT_InfosetValidation DoorsValidation DOORS infoset yes validation vsDOORS con-straints

Table 1: Key elements of Nexus, PORTAL, and DOORS resource representations