Clement Jonquet
email: jonquet@stanford.edu

Mark A Musen
email: musen@stanford.edu

Nigam H Shah

Help will be provided for this task: Ontology-Based Annotator Web Service

Keywords: ontologies, ontology-based/semantic annotation, web service, concept recognition, biomedical ontologies, semantic expansion, semantic web service, service-oriented architecture

Semantic annotation is part of the vision for the semantic web. Ontologies are required for this task, and although they are in common use, there is a lack of annotation tools for users that are convenient, simple to use and easily integrated into their processes. This paper presents an ontology-based annotator web service methodology that can annotate a piece of text with ontology concepts and return annotations in OWL. Currently, the annotation workflow is based on syntactic concept recognition (using concept names and synonyms) and on a set of semantic expansion algorithms that leverage the semantics in ontologies (e.g., is_a relations). The paper also describes an implementation of this service for life sciences and biomedicine. Our biomedical annotator service uses one of the largest available set of publicly available terminologies and ontologies. We used it to create an index of open biomedical resources. Both the deployed web service and a user interface can be accessed at (http://www.bioontology.org/tools.html).

Introduction

One of the requirements of the semantic web is that web content must be semantically described using ontologies. Since 2002, the call for papers for the International Semantic Web Conference has contained the following sentence: Authors of accepted papers will be required to provide semantic annotations for the abstract of their submission for the Semantic Web (prior to 2005, "mark up" was used instead of annotations). However, this sentence is followed by the following parenthetical remark: help will be provided for this task. This indicates that, in general, annotation is not an easy task. In the case of the ISWC call for papers, it needs to be done manually, with the contribution of the authors. It cannot be done entirely automatically when papers are submitted. The challenges posed by semantic annotation [START_REF]Annotation for the Semantic Web[END_REF] mean that today's web content is still mainly composed of unstructured text that is not re-usable by software agents or semantic engines.

Ontologies and terminologies already exist in several eScience domains and can be used to enrich the web content data description. As a result, semantically annotating web data using ontologies is becoming an important task. For example, in the biomedical domain, the variety of publicly available data is already enormous and is expanding very fast. This expansion means that researchers now face a hurdle to extracting the data they need from the large amount of data that is available. Biomedical researchers have turned to ontologies and terminologies to describe their data and turn it into structured and formalized knowledge [START_REF] Rubin | National Center for Biomedical Ontology: Advancing Biomedicine through Structured Organization of Scientific Knowledge[END_REF]. For instance, the Gene Ontology is widely used to describe the molecular functions, cellular locations, and biological processes of gene products. The Gene Ontology allows integrating these descriptions across several databases. As another example, when a new PubMed 1 citation is created, its title and abstract are indexed with MeSH 2 terms. However, besides Gene Ontology annotations and PubMed indexing most available biomedical data are unstructured and rarely described with ontology concepts.

In their study, Uren et al. define semantic annotation as the process that formally identifies concepts and relations between concepts in documents [START_REF] Uren | Semantic annotation for knowledge management: Requirements and a survey of the state of the art[END_REF]. In this paper, annotating refers to the process of describing data with ontology concepts; an annotation is a layer of meta-information on data that says: this data deals with this concept. Explicitly annotating data with ontology concepts is still not a common practice for several reasons:

• The numbers of relevant ontologies are increasing and getting access to all of them may become cumbersome because of different formats, locations or application programming interfaces (APIs); • Users do not always know the structure of an ontology's content or how to use it in order to do the annotation themselves; • Annotating data using ontologies is often a boring additional task without immediate reward for the user. Both inspired by the semantic web and the importance of service-oriented computing, we present a web service methodology that allows users to utilize available ontologies for annotating their data automatically. The Ontology-Based Annotator (OBA) web service automatically processes a piece of raw text to annotate (or tag) it with relevant ontology concepts and return the annotations. The OBA web service is an ontology-based service that uses ontologies to produce a new output. 3 Plus, the service delivers semantic web enabled results, because it creates annotations that are semantically described from raw text. The service workflow is composed of two main steps: (i) the concept recognition step that syntactically identifies concepts from their names or synonymous terms; 4 (ii) the semantic expansion step, where the first set of annotations is expanded using the 1 PubMed (www.ncbi.nlm.nih.gov/PubMed/) is the standard literature database of biomedicine. 2 MeSH (Medical Subject Headings) is a biomedical controlled vocabulary created and updated by the United States National Library of Medicine (NLM). 3 Ontology-based medical search engines are a good example of ontology-based services [START_REF] Kamel-Boulos | A first look at HealthCyberMap medical semantic subject search engine[END_REF][START_REF] Moskovitch | A Comparative Evaluation of Full-text, Concept-based, and Context-sensitive Search[END_REF][START_REF] Can | MedicoPort: A medical search engine for all[END_REF]. 4 A concept is unique in an ontology (class). A term is a particular string form that identifies a concept. Usually, a concept has several terms (e.g., name, synonyms, label). knowledge from one or several ontologies (e.g., is_a relations), to a larger set of annotations according to different expansion algorithms. The OBA web service distinguishes itself from what has been previously reported for several reasons:

1. It is an automatic web service that can be integrated in current workflow and used by software agents, 2. It leverages ontologies to create new annotations, 3. It is described by a specific service model ontology and returns annotations as an OWL ontology populated with annotations as instances, 4. It has access to multiple ontologies (biomedical ontologies in our application). We have deployed an application of the OBA web service for the biomedical domain. As stated above, the need for such a service in the life sciences and biomedicine is critical. Our previous experience [START_REF] Shah | Ontology-based Annotation and Query of Tissue Microarray Data[END_REF][START_REF] Marinelli | The Stanford Tissue Microarray Database[END_REF] has allowed us to identify appropriate use cases for our service such as annotating pathology samples, high-throughput datasets and clinical trial reports. Our prototype uses 47 publicly available terminologies and ontologies from the Unified Medical Language System (UMLS) and the National Center for Biomedical Ontology (NCBO) repository. It uses mgrep, a concept recognizer with a high degree of accuracy (>95%) in recognizing disease names [START_REF] Xuan | Interactive Medline Search Engine Utilizing Biomedical Concepts and Data Integration[END_REF]. The service is deployed as a SOAP (Simple Object Access Protocol) web service as well as a RESTful (REpresentational State Transfer) web service. An OWL (Web Ontology Language) ontology defines the service model. We have used the annotator service internally to process several biomedical resources and have constructed an ontology-based index that allows a user to search for biomedical data annotated with ontology concepts [START_REF] Jonquet | A System for Ontology-Based Annotation of Biomedical Data[END_REF].

Ontology-based annotator description and design

Automatically annotating a user's data for the semantic web poses technical challenges such as scalability, accuracy, and maintenance. For example, the number of ontologies available for use is large and, many ontologies change often and overlap as well. The ontologies are not in the same format and do not always provide APIs to query them. Users need services that abstract ontology formats or access mechanisms and matches with the service oriented computing principles [START_REF] Singh | Service-Oriented Computing, Semantics, Processes[END_REF]. The OBA is such a service. This section presents the ontology-based annotating workflow as well as the service model.

Ontology-based annotator web service workflow

Fig. 1 describes the OBA web service workflow, which is composed of two main steps. First, the user's text is given as input to a concept recognition tool along with a dictionary. The dictionary (or lexicon) is a list of strings that identifies ontology concepts. It is constructed by accessing several ontologies and dumping all concept names or other string forms, called terms, such as synonyms or labels that syntactically identify concepts. The choice of the set of ontologies used to create the dictionary depends of the domain for which the OBA web service is deployed. The tool recognizes concepts by using string matching and syntax based techniques such as stemming, spelling, or morphological forms. The output is a set of direct annotations. Fig. 1. OBA web service workflow. First, direct annotations are created from raw text according to a dictionary that use terms from a set of ontologies. Second, different components expand the first set of annotations using ontologies semantics.

Second, this primary set of annotations serves as input for the semantic expansion components. These components enhance the annotations extracted from the first step using the semantics of one or more ontologies. There may be different types of expansion components, such as:

• An is_a transitive closure component that traverses an ontology parent-child hierarchy up to the root to create new annotations with parent concepts. For instance, if a data is annotated with a concept from the National Cancer Institute Thesaurus (NCIT), 'melanoma,' the tool generates a new annotation with the concept 'neoplasm' because the NCIT provides the knowledge that 'melanoma' is_a 'neoplasm.' The component assumes that a document dealing with a child concept also deals with the parent concept(s). • A semantic distance component creates new annotations by obtaining related concepts according to a given semantic distance in an ontology [START_REF] Lee | Using Annotations from Controlled Vocabularies to Find Meaningful Associations[END_REF][START_REF] Caviedesa | Towards the development of a conceptual distance metric for the UMLS[END_REF]. For example, a semantic distance algorithm can evaluate at 1 the distance between siblings in an ontology and 4 the distance between cousins (i.e., child of parents sibling). A corresponding semantic distance component, configured to return all the concepts that are at the maximum distance 2 will return all the siblings of a concept but not the cousins. • An ontology mapping component creates new annotations based on existing mappings between different ontologies [START_REF] Euzenat | Ontology matching[END_REF]. The OBA web service is designed in manner that allows multiple semantic expansion components to be plugged-in, selected and parameterized by a user when requesting the service. These components may also be composed to create new component. The OBA service level agreement depends on the selected components as each consumes resources at a different level. For example, the is_a transitive closure takes a long time to process, even when using a pre-computed hierarchy table.

As an output of the second step, several sets of semantically expanded annotations are extracted and returned, along with direct annotations, to the user. The system may classify this final set of annotations by accounting for the frequency with which a concept has been identified directly by the concept recognizer (i.e., number of occurrence of a concept in a text) or by semantic expansion components (i.e., number of time an annotation was founded by expansion).5

Ontology-based annotator web service model

In this section we define the OBA web service model i.e., what the service returns to the user: the objects as well as their relations and the constraints that applies. Fig. 2 describes the OBA web service model as a Unified Modelling Language (UML) class diagram. The model is defined by a set of six objects:

• ResultBean is the main object returned by the OBA web service. It is a representation of an OBA result. text refers to the piece of text originally sent to the service, while name identifies the result. contextNb is a constant that defines the number of different types of context possible for this result (see below) i.e., the number (x) of components selected for the annotation, + 1 (for direct annotations). The properties annotations, dictionary, ontologies and statistics are defined hereafter. A ResultBean provides functions to export its content in different form for the user. These functions correspond to the four different calls a user can make via the OBA web service API. The toText(), toTabDelimited() and toXML() functions return the result content without any formal semantics. toOWL() returns the content in a structured and semantically rich form (see section 3). • AnnotationBean is a representation of one annotation. conceptID globally identifies (e.g., URI) the unique annotating concept that forms the annotation. conceptTerms specifies all the possible terms for the annotating concept that have been used in the dictionary. context asserts the context information for the annotation. • ContextBean has information about the context in which an annotation was created.

For example, it could be a direct annotation or could have been made by a semantic expansion component. contextName is a keyword (e.g., DIRECT, ISA_CLOSURE) which identifies the type of annotation. conceptID identifies the concept from which an annotation with a particular context was derived. For instance, if the annotation was produced by the is_a transitive closure component, name is ISA_CLOSURE and conceptID identifies the child concept from which the is_a relation was used to produce this annotation. ContextBean objects are strongly related to semantic expansion components in the sense that they specify from which component an annotation has been produced. Therefore, they may be adapted to fit with specific components added to the OBA web service workflow. • DictionaryBean contains the metadata (not the content) of the dictionary used for a result. version, name, and date identify the dictionary on the server side and give information about its content. nbConcept and nbTerm represent the number of concepts and terms in a dictionary and ontologies specifies the set of ontologies used in it. Dictionary versioning is strongly linked to the evolution of the ontologies used. Each time ontologies change, the dictionary is updated. All the dictionary information may be useful for comparing results of the OBA web service on time. • OntologyBean is a representation of an ontology. To keep the model simple, we provide only two key pieces of information: ontologyID and name. If the ontology was specifically involved in creating annotations returned as a result of an OBA web service call, the ontologies is associated to a result.

• StatisticsBean contains information on the number of annotations done for a given context. The contextName keyword identifies the type of context and nbAnnotation is the number of annotations of this type. The model introduced in this section presents the simple semantics of the OBA web service. Most of the constraints can be represented by beans in a Web Services Description Language (WSDL) description. For example, data types used and most of the cardinalities are straightforward and can be expressed through a WSDL description. However, some aspects of the model semantics cannot be expressed by a simple WSDL description. Data type restrictions are an example, as when version must be a positive integer, and conceptID must be an URI. Similarly, it is not simple to express that an ontology involved in a specific result must be part of the ontologies that form the dictionary of this result. There is also the question of how to represent different ContextBean (or OntologyBean) objects with inheritance. These examples require a higher semantic description for the OBA web service to allow users and software agents to manipulate service results.

Semantically described results

The OBA web service provides a semantic layer that allows a formal description of the service model and results. We have developed an OWL ontology that formalizes the OBA web service model (section 2.2) and implements constraints and restrictions on it. For example, the fact that an ontology involved in a result must be part of the ontologies that form the result's dictionary can easily be expressed by a SWRL rule (Semantic Web Rule Language) [START_REF] O'connor | Supporting Rule System Interoperability on the Semantic Web with SWRL[END_REF]: The OBA web service ontology uses OWL to semantically define objects returned by the service. When the OBA server compiles a result for a user, it populates its ontology with instances and directly returns the description or its URI location, and the instances as a specific OWL file. The couple ontology/instances works well for this type of application as it allows a clean separation of the data and the semantics defining the data. For example, the following annotation states that the concept PATO:0000051 (morphology), from the Unit ontology, is an annotation included in the result OBA_RESULTBEAN_d45dc8. It is an ISA_CLOSURE annotation derived from the concept PATO:0000918 (i.e., the Unit ontology provides the knowledge PATO:0000918 is_a PATO:0000051). The OWL representation of this annotation is: <AnnotationBean rdf:about="#OBA_AnnotationBean_624"> <conceptID rdf:datatype="http://www.w3...#string"> Unit:::PATO:0000051 </conceptID> <conceptTerms rdf:datatype="http://www.w3...#string"> morphology </conceptTerms> <result rdf:resource="#OBA_RESULTBEAN_d45dc8"/> <context> <ContextBean rdf:about="#OBA_ContextBean_624"> <contextName rdf:datatype="http://www.w3...#string"> ISA_CLOSURE </contextName> <conceptID rdf:datatype="http://www.w3...#string"> Unit:::PATO:0000918 </conceptID> <annotation rdf:resource="#OBA_AnnotationBean_624"/> </ContextBean> </context> </AnnotationBean> Parsing the OWL file with an OWL enabled API such as Jena (http://jena.sourceforge.net/) or the Protégé-OWL API (http://protege.stanford.edu/) enables a human user or a software agent to fully utilize the content of the OBA web service result and eventually integrate several results together. In addition, the entire semantic web technology stack (SPARQL, RDF tools, etc.) can be used to process the result as it is returned in a standard format. For example, a user can query OWL results to get all annotations done directly with or derived from one conceptID.

ResultBean(?

Application: a biomedical annotator service

The emergence of information and communication technologies has drastically changed biomedical research processes. Experimental data and results are easy to share and repurpose thanks to web APIs enabling connections to large databases. As a consequence, the biomedical data available in the public domain is now diverse and growing rapidly. This expansion has motivated research on data integration, and the research community agrees that ontologies are essential for data integration to occur [START_REF] Wache | Ontology-Based Integration of Information -A Survey of Existing Approaches[END_REF][START_REF] Aronson | Effective mapping of biomedical text to the UMLS Metathesaurus: the MetaMap program[END_REF][START_REF] Bodenreider | Bio-ontologies: Current Trends and Future Directions[END_REF][START_REF] Smith | The OBO Foundry: coordinated evolution of ontologies to support biomedical data integration[END_REF][START_REF] Bao | A Tool for Collaborative Construction of Large Biological Ontologies[END_REF]. However, although the variety of biomedical data is very large (from experimental data sets in repositories, to records of disease associations of gene products in mutation databases, to entries of clinical-trial descriptions, to published papers, and so on), it often contains free text meta-data information entered by the researcher who created it. This situation creates a challenge of producing consistent terminology or ontology labels for each element in the public biomedical resources. Such labels would enable the identification of all related elements at a given level of granularity. One mechanism of achieving consistency would be to map text metadata describing the resource element to ontology concepts allowing formulation of refined or coarse search criteria. Creating ontology-based annotations from this metadata will enable users to formulate flexible searches for biomedical data [START_REF] Spasic | Text mining and ontologies in biomedicine: making sense of raw text[END_REF][START_REF] Moskovitch | A Comparative Evaluation of Full-text, Concept-based, and Context-sensitive Search[END_REF][START_REF] Shah | Ontology-based Annotation and Query of Tissue Microarray Data[END_REF]. In this section, we present a prototype of the OBA web service that can address some of the biomedical community needs.

Implemented prototype

The National Center for Biomedical Ontology (NCBO) [START_REF] Rubin | National Center for Biomedical Ontology: Advancing Biomedicine through Structured Organization of Scientific Knowledge[END_REF] maintains BioPortal, a web application for accessing biomedical ontologies. BioPortal contains a large collection of ontologies, such as Gene Ontology, the National Cancer Institute Thesaurus, and the International Classification of Diseases, in different formats (OBO, OWL, etc.). Users can browse and search this repository of ontologies both online and via a web services API. BioPortal ontologies along with the Unified Medical Language System (UMLS) 6terminologies provide a key element for our biomedical annotator service: one of the largest set of biomedical terminologies and ontologies publicly available for our dictionary.

The complex task in building the dictionary is mainly the access to the ontologies. As previously stated, ontologies are spread all over the web and are defined with different languages that use different conventions. For example, the Open-Biomedical Ontology (OBO) format provides a specific field for synonyms facilitating the dumping of all the terms that define a concept. This is not the case for OWL ontologies for which a specialist has to decide the relevant property (e.g., rdfs:label, skos:prefLabel, skos:altLabel) that represent a term for a concept. Additionally, the dictionary is a representation of the content of several ontologies at a given time. It has to follow the ontologies evolution. For instance, if a concept is removed from an ontology, the corresponding terms in the dictionary needs also to be removed. In our prototype the complexity of accessing ontologies to create and update the dictionary is significantly reduced by the use of BioPortal and UMLS APIs. Both APIs provide means to help us construct the list of terms that identify concepts in their ontologies. The dictionary is automatically (re)built by accessing these APIs.

In the first step of the workflow presented in section 2.1, our biomedical annotator service uses a selection of 47 biomedical ontologies that give a dictionary of 793,681 unique concepts and 2130700 terms. The current prototype uses mgrep, a concept recognizer developed by the National Center for Integrative Biomedical Informatics. Mgrep is a tool that implements a novel radix tree based data-structure that enables fast and efficient matching of text against a set of dictionary terms. Mgrep was parameterized to match all the possible concepts. 7 This tool recently reported a degree of accuracy >95% in recognizing disease names [START_REF] Xuan | Interactive Medline Search Engine Utilizing Biomedical Concepts and Data Integration[END_REF]. We have conducted [START_REF] Bhatia | Comparing Concept Recognizers for Ontology-Based Indexing: MGREP vs. MetaMap[END_REF] a comparative evaluation of this tool with the gold standard in the biomedical community, MetaMap [START_REF] Aronson | Effective mapping of biomedical text to the UMLS Metathesaurus: the MetaMap program[END_REF]. Mgrep is more precise at recognizing concepts, is more scalable, and can be configured to use third party dictionaries. As a result, unlike MetaMap, mgrep is not tied to the UMLS structure. Note that the prototype is designed to allow us to plug-in other concept recognizers. In the second step of the workflow, the biomedical annotator uses only an is_a transitive closure component to expand the annotations created by mgrep. Both BioPortal and UMLS APIs provide a function to get is_a hierarchy relations (i.e., for a given concept, which are the parents concepts) allowing us to pre-compute a hierarchy table. 8The service is deployed as a SOAP web service as well as a RESTful web service. The current WSDL and OWL ontology of the biomedical annotator service are available online (http://www.bioontology.org/tools.html) and the prototype can be accessed programmatically. A user friendly web interface is also provided. Current response times are ~20-25 seconds for 500 words. Nevertheless, some technical improvements are being considered: (i) keeping the dictionary loaded into memory between service calls (mgrep constraint); (ii) loading the pre-computed hierarchy table into memory.

We evaluated our biomedical annotator for the purpose of annotating a wide range of public biomedical datasets. For example, we annotated a set of 1,050,000 PubMed citations (title, abstract and other metadata), creating 174,840,027 annotations (18% DIRECT, 82% ISA_CLOSURE). By considering only one unique annotation done in several contexts of the same citation (e.g., if an annotation was found both in the title and in the abstract, we count just one), we obtained an average of 160 annotating concepts by citation. Approximately 99% of our test set was annotated (with at least 1 concept), demonstrating the service's utility.

In the current prototype, conceptIDs and ontologyIDs are ad-hoc usable identifiers rather than URIs. In this implementation, we have to abstract on both BioPortal and UMLS APIs that do not have the same representation and constraints for a concept. For example, in UMLS a concept may exist in several terminologies while this is not allowed in BioPortal where ontology mappings are encouraged. In the future, BioPortal will integrate all the UMLS ontologies and provide URIs for concepts and ontologies.

Use cases enabled and potential impact of the biomedical annotator service

In a recent study, we described the prototype implementation of OBR, an open biomedical resources index. OBR index was constructed using the our annotator service workflow and is directly queriable in the NCBO BioPortal [START_REF] Jonquet | A System for Ontology-Based Annotation of Biomedical Data[END_REF]. OBR's objective is to perform offline annotation of a large number of biomedical resources and to provide an up-to-date index of annotated resource elements. There are five biomedical resources in the current prototype. The OBR index keeps track of the structures of elements it has annotated i.e., from which part of the element (e.g., title, description) an annotation has been produced. The system allows a user to search for various biomedical data related to a specific ontology concept (in one place) greatly enhancing the value of the ontology repository. For example, searching for "melanoma" in BioPortal returns, among others the concept DOID:1909 from the human disease ontology. A user can access the 13 ArrayExpress experiments, the 673 clinical trials, the 960 articles in PubMed, or the 10 Gene Expression Omnibus datasets related to that concept that have been annotated in the OBR index. The OBR and OBA together create a system that allows a user to make a request of the annotator and get back the biomedical data related to a piece of text. The system may be useful, for example, when a researcher is writing a paper. He can annotate his article abstract and then use the system to find PubMed citations related to it.

They are many use cases for the annotator service we propose. For example, the Stanford Tissue Microarray Database (STMD), annotates the tissue samples in the database with concepts from the National Cancer Institute Thesaurus [START_REF] Marinelli | The Stanford Tissue Microarray Database[END_REF]. STMD designers are potential users of the OBA web service for the following reasons: (i) annotating with ontologies is not their domain of expertise, (ii) integrating an ad-hoc annotation tool into STMD processes is not a good software practice, nor it is a stable and scalable solution over time, (iii) STMD designers may be interested by annotating their samples with more than one terminology. As a second example, NCBO collaborators from Univ. of California, San Francisco have to create annotations for HIV/AIDS clinical trials in order to provide an ontology-driven web application for visualizing, understanding, and analyzing the trials. As a third example, within the context of the Ontology Development Information Extraction project, biomedical informaticians led by a group at the Univ. of Pittsburgh are developing a set of tools to assist researchers with 'extracting meaning and codifying medical documents.' These groups are potential users of the annotator service.

Discussion and related work

Semantic annotation is an important research topic [START_REF]Annotation for the Semantic Web[END_REF]. Tools vary along with the types of documents to annotate (e.g., image [START_REF] Hollink | Semantic Annotation of Image Collections[END_REF]). For an overview and comparison of semantic annotation tools the reader may refer to the study of Uren et al. [START_REF] Uren | Semantic annotation for knowledge management: Requirements and a survey of the state of the art[END_REF]. The authors compare a large number of tools and the two main annotation frameworks Annotea [START_REF] Kahan | Annotea: an open RDF infrastructure for shared Web annotations[END_REF] and CREAM [START_REF] Handschuh | Leveraging Metadata Creation for the Semantic Web with CREAM[END_REF] with seven requirements. They show that these requirements are hardly addressed by current solutions. The requirements and how the OBA web service is compatible with them are as follows:

Standard formats. Using standard formats is preferred, wherever possible. The OBA web service returns OWL data.

User centered/collaborative design. To provide knowledge workers with easy to use interfaces that simplify the annotation process and place it in the context of their everyday work. The choice of a service-oriented architecture fulfills this requirement.

Ontology support (multiple ontologies and evolution). Annotation tools need to be able to support multiple ontologies. Systems will have to cope with changes made to ontologies over time. Our biomedical annotator supports multiple ontology formats (OBO, OWL, UMLS) and provides a means for versioning the dictionary (as explained before). This characteristic supports ontology evolution.

Support of heterogeneous document formats. Dealing with multiple document formats is a prerequisite for integrating annotation into existing work practices. The OBA web service deals with the most basic format available: free text. Most documents can be converted into free text (or have free text extracted from them). For the moment, it is up to the user to keep track of the part of the document from where an annotation has been derived, as we are doing in our OBR project. In the future, the OBA web service should be able to process directly structured documents.

The two following requirements do not apply to the OBA web service: Document evolution (document and annotation consistency). What should happen to the annotations on a document when it is revised.

Annotation storage. The semantic web model assumes that annotations will be stored separately from the original document. As a service, the OBA stores neither annotations nor annotated text. OBA users have to manage this information. Note that in our OBR index, we have implemented wrappers that automatically keep resource contents (i.e., documents) and annotations up-to-date. They are stored separately.

Automation. This requirement intrinsically fulfilled by the OBA web service.

The OBR-OBA use case presented before is similar to the approach of the SemanticHacker project (http://semantichacker.com). SemanticHacker enables 'semantic discovery' by providing users with a 'semantic signature,' which is a weighted representation of the concepts contained in a piece of text. It is based on Wikipedia content and links back to the related Wikipedia articles. The OBA web service differs principally from SemanticHacker in that it uses biomedical ontologies.

In the biomedical domain, automatic annotation or indexing of biomedical resources is an important topic. A number of publicly available concept recognizers identify concepts from ontologies or terminologies in a piece of text. For examples, see IndexFinder [START_REF] Zou | IndexFinder: A Method of Extracting Key Concepts from Clinical Texts for Indexing[END_REF], MetaMap [START_REF] Aronson | Effective mapping of biomedical text to the UMLS Metathesaurus: the MetaMap program[END_REF], SAPHIRE [START_REF] Hersh | SAPHIRE -an information retrieval system featuring concept matching, automatic indexing, probabilistic retrieval, and hierarchical relationships[END_REF], and mgrep [START_REF] Xuan | Interactive Medline Search Engine Utilizing Biomedical Concepts and Data Integration[END_REF]. MetaMap is the gold standard for evaluating these tools. The main challenges for these tools are openness to various terminologies or ontologies, accuracy, and scalability. Most of the time, they deal only with UMLS. Our choice of mgrep was motivated by its high accuracy and its facility to consume a simple text based dictionary. The fact that it is not tied to a particular ontology structure was beneficial [START_REF] Bhatia | Comparing Concept Recognizers for Ontology-Based Indexing: MGREP vs. MetaMap[END_REF].

More similarly, CONANN [START_REF] Reeve | CONANN: An Online Biomedical Concept Annotator[END_REF] is an online biomedical concept annotator. It takes a source phrase, identifies potential matching concepts and phrases in a domain-specific thesaurus (UMLS), uses an incremental filter to remove candidate phrases using a variation of inverse document frequency, and maps the source phrase to the best matching concepts. CONANN provides a speed advantage and a better recognition precision when compared to MetaMap. CONANN aims to identify the best possible matches, whereas mgrep in the OBA web service identifies the greatest number of concepts. Maximizing the number of annotations for the OBR index enables the extraction of new knowledge. For example, it enables data-driven ontology alignment by mapping annotations together e.g., if a large number of resource elements have been annotated with two concepts it may means that this two concepts are related [START_REF] Shah | Ontology-based Annotation and Query of Tissue Microarray Data[END_REF]. One feature of CONANN not currently implemented in the OBA web service is the use of term frequency to order/filter results. Note that if CONANN becomes freely available, and open to third party dictionaries, we can also use it for the concept recognition step fairly easily.

Many research projects leverage ontology annotations such as biomedical data search engines. MedicoPort [START_REF] Can | MedicoPort: A medical search engine for all[END_REF] uses UMLS semantics to expand user queries. Moskovitch et al. [START_REF] Moskovitch | A Comparative Evaluation of Full-text, Concept-based, and Context-sensitive Search[END_REF] use ontologies for annotation (concept based search) and demonstrate the importance of the context (context-sensitive search) when annotating structured documents. They use UMLS based is_a relations for their semantic expansion. HealthCyberMap [START_REF] Kamel-Boulos | A first look at HealthCyberMap medical semantic subject search engine[END_REF] uses ontologies and semantic distances for visualizing biomedical resources information. Finally, Essie [START_REF] Reeve | CONANN: An Online Biomedical Concept Annotator[END_REF] shows that a judicious combination of exploiting document structure, phrase searching, and concept based query expansion is a useful approach for information retrieval. Essie also leverages context and frequency of occurrence. Most of these tools are limited to UMLS. This limitation gives our biomedical annotator a significant advantage.

Khelif et al. [START_REF] Khelif | An ontology-based approach to support text mining and information retrieval in the biological domain[END_REF] present a similar work to the OBR project. They have annotated the GeneRIF resource using GATE [START_REF] Cunningham | GATE: A framework and graphical development environment for robust NLP tools and applications[END_REF], a natural language processing framework, for concept recognition. They used UMLS and Galen as ontologies. GATE allows them to extract not only concepts from text, but also relations. Their system returns and stores annotations in RDF and uses a software based on conceptual graphs, called Corese [START_REF] Corby | Searching the Semantic Web: Approximate Query Processing Based on Ontologies[END_REF], to do semantic expansion (is-a relation, external rules, reasoning, and views on the annotations). The OBR index contains more content (resources annotated and ontologies used) but it may be useful in the future to see how to reuse GATE to extract relations and Corese as a semantic expansion component.

In contrast with classic web service, semantic web services (SWS) [START_REF] Cabral | Approaches to Semantic Web services: an overview and comparisons[END_REF] are semantically described with ontologies. They use ontologies to create a knowledge-level model of information describing and supporting what the service accepts, does and returns. They also enable automated understanding of their functionalities. More generally, the semantic layer helps service discovery, invocation, composition, or interoperation. It enables reasoning about services, planning compositions of services, and automating their use by software agents. For example, web service discovery should be based on the semantic match between a description of a service demand, and a description of a service offer both available in a semantically competent platform/registry [START_REF] Crubezy | Configuring online problem-solving resources with the Internet Reasoning Service[END_REF]. The two main current frameworks for SWS development are proposed by the OWL-based Web Service Ontology, (OWLS) [START_REF] Martin | Bringing semantics to Web services: The OWL-S approach[END_REF] and Web Service Modeling Ontology (WSMO) [START_REF] Roman | Web Service Modeling Ontology[END_REF] working groups. The semantic description of 'what is returned by the service' is the first step to deploying the OBA web service as SWS. It does not yet provide a semantic description of what the service does using a framework such as OWL-S or WSMO.

Conclusion and future work

Annotations play a crucial role in the emergence of the semantic web. The need to switch from the current web to semantically rich content annotated using ontologies has been clearly identified. Meeting this need requires services (usable by humans and agents) that can be integrated into web processes. We have presented a service for semantic annotation. Our service methodology leverages ontologies to create annotations of raw text and returns them using semantic web standards. We have also described an implementation of this model for the biomedical domain. Our biomedical annotator is distinguished from previous work in the biomedical domain because (i) it is clearly positioned as a service-oriented tool; and (ii) it has access to a large dictionary, which is composed of UMLS and NCBO ontologies. Evaluation has demonstrated accuracy (>95% for the concept recognizer) and utility (160 annotating concepts for one PubMed citation). The service workflow is currently involved in a project within NCBO to annotate a large number of open biomedical resources. The comparison, done in section 5, with the requirements of [START_REF] Uren | Semantic annotation for knowledge management: Requirements and a survey of the state of the art[END_REF] shows that our semantic service-oriented approach makes sense and distinguishes our tool from what exists or is currently proposed in the community. Future work will concentrate on three main issues that will determine the OBA web service success in processing annotations:

• Concept recognition. The choice of the mgrep tool is not fixed. Better concept recognizers can easily be plugged-in. It would be interesting to recognize more than concept from text, but also relations [START_REF] Bundschus | Extraction of semantic biomedical relations from text using conditional random fields[END_REF][START_REF] Kim | Corpus annotation for mining biomedical events from literature[END_REF]. • Ontologies. We wish to allow users to choose (and eventually propose) any ontology desired for the annotation process (i.e., customize the dictionary on demand). We will also propose a set of 'topic oriented' dictionaries which will simplify the use of the service and will abstract on the ontology layer. • Semantic expansion components. We are currently working on a semantic distance component [START_REF] Lee | Comparison of Ontology-based Semantic-Similarity Measures[END_REF] and a component that will extract concept similarity based on the current version of the OBR index (data-driven ontology alignment). Plus, in the future, we want to develop and re-use other components and still allow the user to select and parameter the one(s) to use when querying the service. The OBA web service also has role as a testbed for evaluating semantic web services for NCBO. The evaluation of the OBA web service semantic approach (i.e., the couple ontology/instances) may enable more semantics for NCBO services as it may be a solution to add a semantic layer to the current NCBO SOAP and RESTful services.

Fig. 2 .

 2 Fig. 2. OBA web service UML model.

Information retrieval techniques (frequency, inverse document frequency) can also be used here.

UMLS (http://umlsinfo.nlm.nih.gov/) is a reference in biomedicine for controlled vocabularies. In our prototype, UMLS is available as a local database.

If a text contains the string "cutaneous melanoma," two annotations are generated: one with 'melanoma' one with 'cutaneous melanoma' because the dictionary contains the two terms.

The is_a transitive closure component can also be parameterized to return detailed results (i.e., track of the concept from which an ISA_CLOSURE annotation has been derived).

Acknowledgements

This work is supported by the National Center for Biomedical Computing (NCBC)/ National Institute of Health roadmap initiative; NIH grant U54 HG004028. We also acknowledge the assistance of Manhong Dai and Fan Meng at University of Michigan.


Ontrez Project Report

National Center for Biomedical Ontology, November, 2007 Nigam H. Shah, Clement Jonquet

Executive summary

Currently, genomics data and data repositories in the public domain are expanding at an explosive pace. 1 The wealth of publicly accessible data is beginning to enable cross-cutting integrative translational bioinformatics studies [START_REF] Butte | Creation and implications of a phenome-genome network[END_REF]. However, translational discoveries that could be made by mining such public resources are hampered if they lack standard terminologies to describe diagnoses, diseases, and experimental conditions. For discovery to proceed in the eras of e-science, researchers need tools to enable them to find all the data sets relevant to their area of study-spanning the biological scales from molecular studies to clinical medicine-and bridging the research modalities from high-throughput experiments to clinical trials and medical imaging. For example, a researcher studying the allelic variations in a gene would want to know all the pathways that are affected by that gene, the drugs whose effects could be modulated by the allelic variations in the gene, and any disease that could be caused by the gene, and the clinical trials that have studied drugs or diseases related to that gene. The knowledge needed to study such questions is available in public data sets; the challenge is finding that information.

The key challenge common to all the needs outlined above is to annotate the various resource elements consistently to identify the biomedical concepts to which they relate. These resource elements range from experimental data sets in public repositories, to records of disease associations of gene products in mutation databases, to entries of clinical-trial descriptions. Creating ontology-based annotations from the metadata in biomedical resources and identifying diagnoses, pathological states, and experimental agents contained in those resources allows indexing of the resources, enabling end users to formulate flexible searches for biomedical data [START_REF] Spasic | Text mining and ontologies in biomedicine: making sense of raw text[END_REF][START_REF] Moskovitch | A Comparative Evaluation of Full-text, Concept-based, and Context-sensitive Search[END_REF][START_REF] Sneiderman | Knowledge-based Methods to Help Clinicians Find Answers in MEDLINE[END_REF][START_REF] Shah | Ontology-based Annotation and Query of Tissue Microarray Data[END_REF][START_REF] Shah | Ontology-driven Indexing of Public datasets for Translational Bioinformatics[END_REF].

In the past two months, we have been developing a system that is integrated with BioPortal known as Ontrez. 2 Ontrez enables researchers to search for biomedical data (such as genomic data sets, medical images, clinical trials and published papers). Ontrez promotes translational research by enabling researchers to locate relevant biological data sets and to integrate them with clinical data to bridge the bench-to-bedside gap.

Ontrez processes the metadata-annotations of gene expression data sets, descriptions of radiology images, clinical-trial reports, as well as abstracts of Pubmed articles to annotate (or tag) them with terms from appropriate ontologies.

While BioPortal addresses the ontological content need of the biomedical community, Ontrez meets the data access and data discovery need of researchers, meeting many of the specific aims outlined in Core 2 of the NCBO grant. In fact, we envision a tight integration of BioPortal and Ontrez as we originally proposed (Figure 1). This tight integration of ontology access and ontology-based applications is essential to enable the capabilities that we present in our Ontrez use cases. In this report, we outline our methodology as well as the current status of the project.

Use cases enabled by Ontrez

One of the key aims for NCBO is to build resources and methods to help biomedical investigators store, view, and compare annotations of biomedical research data and to develop a query interface for the underlying data sets. Below we list the kinds of uses cases enabled by Ontrez. In this view of the NCI Thesaurus, the user can select an ontology element (in this case, Hepatocellular carcinoma) and see immediately a number of online resources that relate directly to that term (and the terms that is subsumes). Ontrez allows the user to link directly to the 29 articles in a small subset of PubMed that deal with Hepatocellular carcinoma and its subtypes. The user also can link to any of the eight DNA microarray datasets related to hepatocellular carcinoma in ArrayExpress or to any of the 206 clinical trials for hepatocellular carcinoma in ClinicalTrials.gov. Figure 6, on page 9, points out the various features of the interface with call outs.

1.

Querying and finding data sets

Ontrez enables researchers to find biomedical datasets by expanding their searchers using ontologies. For example, if a protein expression study is labeled with a term from the NCI thesaurus (such as pheochromocytoma), then a researcher can query for retroperitoneal tumors and find data sets related to pheochromocytoma (the NCI Thesaurus will provide the knowledge that pheochromocytoma is_a retroperitoneal tumor). This use case is similar, in principle, to query expansion at Entrez; however, Entrez does not use ontologies, such as the NCI thesaurus or SNOMED-CT for this purpose. There are pheochromocytoma data sets in GEO, but none show up on searching for retroperitoneal neoplasms in Entrez. In Ontrez, however, a researcher could search for "retroperitoneal neoplasms" and find the relevant samples [START_REF] Butte | Finding disease-related genomic experiments within an international repository: first steps in translational bioinformatics[END_REF].

Ontrez currently enables such querying across both the Gene-Expression Ombibus (GEO) and ArrayExpress.

Integrating gene and protein expression data sets

Researchers who seek to identify biomarkers for stratifying cancers currently need to search for each of the different types of cancers within different databases-GEO and the Tissue Micro-Array Database (TMAD), for example. Using Ontrez, a researcher can locate all the relevant data sets across a diversity of biomedical resources; for example, the researcher could locate data sets for breast cancer across GEO and TMAD, enabling integrative studies, such as those by Quong et al., which correlate protein-expression changes with gene-expression changes [START_REF] Quong | Correlation of protein and gene expression for the stratification of breast cancer patients[END_REF][START_REF] Basik | Integration of genomic technologies for accelerated cancer drug development[END_REF].

Integrative analysis of imaging and genomic data sets

Researchers recently demonstrated that imaging biomarkers of hepatocellular carcinoma can be identified by integrating gene-expression data and CT-scan imaging data. The authors correlated gene-expression profiles for hepatocellular carcinoma with features extracted from the original CT scan images [START_REF] Segal | Decoding global gene expression programs in liver cancer by noninvasive imaging[END_REF]. Finding the data sets needed for such analyses is challenging. Discovering these data for such novel studies is readily enabled by Ontrez, which allows researchers to seamlessly search both GEO and the Goldminer repositories.

Searching clinical trials

Currently, Ontrez contains ontology-based annotations of all the clinical-trial descriptions in clinicaltrials.gov. In addition to indexing the trial description, we intend to augment Ontrez by processing the text describing the eligibility criteria of clinical trials from the clinicaltrials.gov resource. Once these clinical-trial eligibility criteria are annotated using ontologies, Ontrez will enable users to compute the semantic distance [START_REF] Caviedes | Towards the development of a conceptual distance metric for the UMLS[END_REF] between specific clinical trials and the medical-record data for individual patients who are candidates for those trials, using technology being developed for the AppliMatch project. (AppliMatch is an ongoing project in collaboration with Ida Sim's group, which is developing methods to identify clinical trials whose eligibility criteria are semantically close to the data in a particular patient's electronic medical record.)

Functional Specification

Figure 2 summarizes the functional specification of the Ontrez system. The key functionality of Ontrez is to provide a service that will enable users to locate biomedical data resources related to their search for particular ontology terms.

Ontrez-Annotations

Ontrez

Ontrez-Annotations

The current Ontrez prototype has the following two main functional components: (1) an indexcreation component and (2) a user-query component.

The process of index creation involves the following three steps: 1. Accessing a set of resources 2. Processing metadata annotations 3. Building the index

The query component involves the following two steps: 1. Semantic query expansion 2. Interaction and results display Figures 3 and4 show an example of the Ontrez system in action, processing a specific GEO element. Note that each GEO element, in this case a dataset, has a title and a description field that contain free text entered by the person creating the data set. Moreover, GEO datasets can have an additional 24 descriptors (such as agent, cell line, and species) along with their subset descriptions. We retrieve these descriptors, either by accessing the resource over the Web. we have dealt only with element titles and descriptions to validate the notion of context awareness. Later, we will process the more of the metadata structure to enable a finer grained level of detail.) The display within BioPortal allows the user to view the original data set with a single click.

Design specification

Figure 5 shows the design of Ontrez, with different architectural levels that map into these five functional steps. The software components corresponding to each of these steps are described in detail in the Appendix and we summarize them here.

Components in the Resource level are concerned with accessing resource elements (such as experiment descriptions in GEO) both via remote access (e.g., Web services) and local access (e.g., a downloaded local copy). Components in the Annotation level create a dictionary of relevant ontology terms from both Bioportal and UMLS ontologies and create annotation tables by recognizing concepts in the metadata. The component performing the concept recognition is a tool called mgrep developed by The National Center for Integrative Biomedical Informatics (NCIBI). The design of the annotation level allows us to plug-in other concept recognizers as needed.

The Index Level computes what elements are annotated with a particular ontology term. The Ontology level provides the terms to use in annotation as well as performs semantic query expansion of user provided search terms.

The User level components integrate the annotations created by Ontrez with Bioportal's ontology search. For example a user can search for "melanoma" and get links to related resource elements (such as datasets, publications, and clinical trials).

Results and current status

In our work to develop the Ontrez prototype, we have processed (1) metadata annotations of high-throughput gene-expression data in repositories such as GEO and Array Express, (2) clinical-trial descriptions in repositories such as clinicaltrials.gov, (3) annotations of images in repositories such as Goldminer, and (4) abstracts of articles published in Pubmed. For a quick summary of the project status:

• Figure 6 shows a snapshot of the current resources annotated in Ontrez and available for search via Bioportal. • Table 1 shows the current number of elements annotated from each resource that we have processed. Our prototype uses 2,010,533 terms from 50 different ontologies (listed in the appendix) to index the resource elements shown in Table 1.

Figure 5. Ontrez design levels

The figure shows an overview of the five primary design components of Ontrez. The Resource level components are concerned with accessing resource elements (such as experiment descriptions in GEO) both via remote access (e.g., Web services) and local access (e.g., a downloaded local copy). The Annotation level components create a dictionary of relevant ontology terms and also create the annotation tables. The Index Level computes what elements are annotated with a particular ontology term. The Ontology level provides the terms used in annotation as well as semantic query expansion. The User level component integrates the Ontrez annotations with Bioportal's ontology search. For example a user can search for "melanoma" and get links to related resource elements (such as datasets, publications, and clinical trials). Ontrez implements ontology-based search, which is an area of active research in the computerscience community [START_REF] Moskovitch | A Comparative Evaluation of Full-text, Concept-based, and Context-sensitive Search[END_REF][START_REF] Sneiderman | Knowledge-based Methods to Help Clinicians Find Answers in MEDLINE[END_REF]. There are potential problems that we may encounter in scaling up the prototype to production use. However, we believe that these problems are addressable in the amount of time that we have left in the project.

The issues that we have identified are:

1. Success of processing the metadata depends on the ability to identify accurately concepts such as diseases, drugs, anatomical parts, and so on in the free-text annotation.

-In our preliminary studies, we have very encouraging results for identifying disease names in GEO text annotations. We rely on the mgrep tool developed by NCIBI, which has a very high degree of accuracy (over 95%) in recognizing disease names. We have not yet conducted an evaluation of the precision and recall of mgrep in recognizing concepts of different types, such as diseases, drugs, and anatomical parts, however. We are aware that NCIBI is developing entity recognizers for tagging entities such as cytobands and microsatellite markers, and we hope to utilize these new tools in our future work.

-Relationships are very hard to identify in free text. Therefore, we will focus initially on the entities that are relevant to the data source (e.g., disease names for GEO), rather than on the relations.

2. Success of processing the metadata-annotations depends on the ability to access the public data resources. Currently, we have processed GEO, ArrayExpress, PubMed, Clinicaltrials.gov, and a subset of Goldminer. We have access to the Stanford Tissue Micro-Array Database (which will soon be available publicly) as well as to the public data sets in the Stanford Microarray Database (SMD). We will decide on the inclusion of new resources for indexing based on their value to the community and will ask for feedback from the Bioportal User Group when prioritizing the resources to include in our work.

3. The quality of the search results depends on the quality of query expansion that we can achieve. In our preliminary results, we have been able to identify relevant data sets across GEO and TMAD with approximately 77% accuracy [START_REF] Shah | Ontology-driven Indexing of Public datasets for Translational Bioinformatics[END_REF]. We note published results from Moskovitch et al. [START_REF] Moskovitch | A Comparative Evaluation of Full-text, Concept-based, and Context-sensitive Search[END_REF], which demonstrate that concept-based searches outperform keyword queries and that search results improve monotonically as additional concepts are included in the search.

Summary

Our preliminary results demonstrate that the metadata available in public biomedical data can be processed automatically by computer programs, and that the resulting annotations can enable several diverse use cases. Ontrez can process metadata-annotations of gene-expression data sets, descriptions of radiology images, clinical-trial reports, as well as abstracts of PubMed articles to annotate them automatically with terms from appropriate ontologies. Ontrez enables researchers to search biomedical data (such as genomic data sets, images, clinical trials, and published papers) in an ontology-driven manner from within BioPortal. We believe that, as we expand Ontrez with additional ontologies and process additional biomedical resources, we will serve an even wider user population, broadening the reach and impact of the NCBO in enabling translational research.

Annotation level -Processing the metadata-annotations

The annotation level processes the metadata corresponding to each element from an online data resource to assign ontology terms to that element; Ontrez stores these assignments in annotation tables. The annotation of elements with ontology terms is performed using a dictionary that provides the set of terms to identify in the metadata. The annotation process is context aware, meaning that we keep track of the context (such as title, description) in each element's metadata where the annotation was derived. The resulting annotation table associates each resource-element identifier with terms belonging to the ontologies in BioPortal.

The annotation table contains information such as "Element E was annotated with term T in context C".

Note: The actual concept recognition step in a particular context (the title or description) is done using the mgrep tool developed by The National Center for Integrative Biomedical Informatics (NCIBI). The design of the annotation level components is such that we can plug-in other concept recognizers.

Index level -Building the index

At the Index level, a global index is constructed that indexes annotations according to dictionary terms from the ontologies in BioPortal. The index contains information such as: "term T annotates elements E1, E2 … in resource R1". We also perform a transitive closure. That is, for each annotation found in the annotation table, we assign additional terms to annotate that element based on the parent-child relationships subsumed by the original term.

Ontology level -Semantic query expansion

The Ontology level provides access to the ontology content used for creating the dictionary and for computing transitive closure. The ontologies are also used for semantic query expansion. For example, when a user issues a query with a term such as "skin neoplasm", ontologies may be used to expand the query by adding more specific terms to the query (e.g., specializations of skin neoplasm, such as malignant melanoma), as well as by adding terms from other ontologies that are "semantically close" to the query terms or explicitly mapped to them. We have an active research project to evaluate alternative semantic-distance measures that we may use in Ontrez for query expansion.

User level -Interaction and results display

At the User level, Ontrez provides a user who is searching for a specific ontology term (e.g., Hepatocellular carcinoma) with resource elements that have are found directly in the Ontrez index or via the semantic query expansion. The search service is provided directly through the existing Bioportal user interface. Ontrez results are displayed inside Bioportal and a Web link is available to each of the online data elements (see Figure 6).

List of Ontologies used in Indexing

Bioportal Ontologies UMLS Ontologies

Biological imaging methods SNOMED Clinical Terms, 2007_01_31

Dictyostelium discoideum anatomy RxNorm Vocabulary, 07AA_070503F

Figure 1 .

 1 Figure1. The integration of Ontrez into BioPortal. In this view of the NCI Thesaurus, the user can select an ontology element (in this case, Hepatocellular carcinoma) and see immediately a number of online resources that relate directly to that term (and the terms that is subsumes). Ontrez allows the user to link directly to the 29 articles in a small subset of PubMed that deal with Hepatocellular carcinoma and its subtypes. The user also can link to any of the eight DNA microarray datasets related to hepatocellular carcinoma in ArrayExpress or to any of the 206 clinical trials for hepatocellular carcinoma in ClinicalTrials.gov. Figure6, on page 9, points out the various features of the interface with call outs.

Figure 2 :

 2 Figure 2: Ontrez functional specification. (Top panel)We retrieve the metadata from data resources such as GEO (A), and tag them with ontology terms using the library of ontologies in BioPortal (B). The result is stored as annotations of these data sources in Ontrez. (Bottom panel) User queries are formulated as a set of terms[START_REF] Butte | Creation and implications of a phenome-genome network[END_REF]. We use the BioPortal index to convert the query to ontology terms. We use the subsumption relations in the ontologies and the mappings in BioPortal to expand the query. We then query the annotations of data sources in Ontrez with the expanded set of terms (2). The user receives the result (3) in terms of references to the original data sources.

3

 3 Figures3 and 4show an example of the Ontrez system in action, processing a specific GEO element. Note that each GEO element, in this case a dataset, has a title and a description field that contain free text entered by the person creating the data set. Moreover, GEO datasets can have an additional 24 descriptors (such as agent, cell line, and species) along with their subset descriptions. We retrieve these descriptors, either by accessing the resource over the Web.3

Figure 3 .

 3 Figure3. Indexing an element from GEO. The GEO element GDS1989 is annotated according to its title and its description, as well as by the ontology elements that comprise the transitive closure over the parent-child relationships subsumed by the direct annotations.

Figure 4 .

 4 Figure 4. Performing a search of GEO using Ontrez. A user searching for "melanoma" in Bioportal is able to view the set of online data resources that have been annotated with the ontology terms related to this query. The GEO element "melanoma progression" is returned as a pertinent element for this search. (Note: In the current version,

Figure 6 .

 6 Figure 6. The figure shows a snapshot of the Ontrez user interface within BioPortal, where the user has selected the term 'Hepatocellular Carcinoma' and then navigated to the 'Resources' tab. The call outs point to and describe the different features of the interface.

Table 1 .

 1 The current number of elements annotated from each resource that we have processed.

Resource Number of elements Resource file size (Kb) Number of direct annotations Number of closure annotations Total number of 'useful' 4 annotations PubMed subset

		10164	13461	187686	681973	857459
	ArrayExpress	2751	2880	143134	484758	619133
	ClinicalTrials.gov	43918	8379	1206939	6792430	5217115
	Gene Expression Omnibus	546	163	16494	100984	116234
	ARRS GoldMiner	1155	494	53082	290935	340915
	TOTAL	58534	25377	1607335	8351080	7150856

For example, the Gene Expression Omnibus (GEO) had 369 data sets in February

2007; in the March release, the number of data sets increased to about 1500. Since its inception, GEO has been gaining data at the rate of about 300% per year.[START_REF] Spasic | Text mining and ontologies in biomedicine: making sense of raw text[END_REF] Ontrez (Ontology aware Entrez) is named after the popular search engine Entrez at NCBI for database search across 30 NCBI resources.

In case of GEO we use the E-Util programs, specifically the eSearch and eSummary.

To prevent redundant annotation entries, we do not add those terms in the closure annotations for which the element was already annotated directly.

Appendix

Description of Ontrez design levels Figure 5 showed the design of Ontrez, with different architectural levels that provide the five functional steps for annotating resources. The software components corresponding to each of these steps were summarized in the main text and are described in detail here.

The resource level -Accessing resources

The resource level comprises biomedical data sets, repositories, and databases, and provides a Web interface to query those resources. Resources are composed of elements (such as GEO data sets) that represent an abstraction for the unit of storage in theses databases. An element is identifiable and can be linked by a specific URL/URI. An element is associated with structured metadata for the element (title, description, abstract, and so on). In order to annotate these resource elements, Ontrez either can download a local copy of the resource elements or can access them directly online (preferred) through a public interface, such as Web services. Processing online resources and keeping the set of annotated elements up to date is done by a resource-specific access tool.