Quick id

Contributing authors: Frank Gibson, Dirk Derom

'This document is in flux and will evolve we are not soliciting feedback as yet. However, if you want to comment on a document that may change rapidly please use the Discussion option for this page  Status: Document in progress' About this document This document gives both the rationale and instructions on how to add quick terms to the OBI. A step by step guide should allow anyone to add terms to the OBI, and limited knowledge about the OBI is required. Nevertheless it is strongly recommended to get familiar with ontology design before adding terms to the OBI.

How to use this document?
This page is created both to explain the actual procedure of adding terms to OBI, as it is a description of the idea behind the Quick ID procedure. It is subdivided into different sections, so one can choose to  Simply learn how to add terms The section 'Submit a term to OBI ' describes the procedure on adding terms to OBI. Useful for those who are familiar with OBI and need a simple tutorial on how to add terms. Get familiar with the Quick ID procedure All other sections are created to help you understand the procedure. This includes:  Introduction to the QUICK ID A short introduction to Quick ID to get you going. Glossary of common terminology This glossary will explain frequently used terms, which hopefully helps to understand this procedure. This glossary is a guide explaining these terms, and refers to those documents with detailed explanation of the particular concept. Mailinglistfor Quick ID's If you have further questions, you can always contact us using [the Quick ID mailinglist]. (read this document on how to use a mailinglist).   

Introduction to the Quick ID?
This section is both an introduction to the Quick ID'' procedure. Read through this section if you are not (really) familiar with the Quick ID procedure.''

Quick ID's refers to a procedure developed to quickly add terms to the OBI (ID's in "Quick ID's" refer to ID's given to the terms when added to the OBI repository). Quick ID's therefore refers to the process of quickly adding terms to the OBI, without the necessity of being a core developer of OBI. The Quick ID process is a process to allow those individuals who might not be strongly involved in the design of OBI, to add terms to the OBI repository.

Quick Id's are created for those who want to contribute/support to the OBI targeting those individuals who are not directly involved or familiar with ontology design. Adding terms through the procedure of Quick ID, allows for fast additions with a minimal learning curve. It's procedure is despite it (relatively) simplicity, nevertheless very powerful. It's combination of curation and openness enables a fast growing ontology created by and for the community. The benefits of the Quick ID procedure for OBI are:  Direct input from the scientific community</li> Input from various fields using a single procedure</li> Curate the OBI and maintain influx from the community</li> Reduced load on curation through expert input</li> </ul> Contributors through the Quick ID benefit from:  Small load on contribution</li> Hands on control of the OBI and their domain specific ontology (terminology)</li> More robust ontology integration by shared expertise</li> Improved speed for the construction and extension of OBI and the domain specific ontology</li> </ul>

Quick Terms hold a special position within OBI. It is fully part of the OBI, however needs to be curated before being submitted to the OBI. This curation process normally has a small load, and enables the development of a well-structured OBI. Initially, a Quick Term has the status of uncurated. This means that these terms are not (yet) part of what you could call the core OBI. A developer of OBI then checks the submitted term and adds it to the OBI. Normally, when the Quick Term is added according the following instructions, this process is semi-automatic. For a Quick Term to be added quickly to the OBI, it is therefore important to follow the instructions.

Quick ID is created for all who want to add terms to the OBI. The goal of OBI is to create an integrated ontology for the description of life-science and clinical investigations. Anyone involved in the life-sciences or clinical investigations is welcomed to contribute to OBI. The power of OBI is driven by the input of these various fields. The Quick ID process is an expression of this emphasis on open access and development. Any questions regarding the Quick ID's can be asked [here ?mailinglist for Quick ID?].

BFO, OBI and Quick ID
In short Quick ID's is a file within'' OBI, and OBI uses BFO as an upper ontology. The Quick ID file allows to add terms into OBI, but needs to be curated before being added to the 'core' OBI repository.'' BFO ''The following information is gathered from BFO and is a (very short) summary which hopefully allows to grasp the basics of the BFO. For a full description of Basic Formal ontology (BFO), go to the BFO website. '' An ontology tries to represent the reality creating a controlled value list (different terms) to describe ('represent') the reality of the domain. A scientific ontology tries to represent the reality investigated by the sciences. But representing such a reality must be valid across various domains in order to exchange our data easily. Constructing specific ontologies only applicable to a specific domain is not very useful since it still does not allow to integrate the data from those fields. BFO is a framework that allows those various domains to be connected using the BFO framework. Therefore the BFO is a top-level (or upper or formal) ontology. It's main characteristics are:  top-level As mentioned before it is the overall framework designed to integrate domain ontologies.</li> Holds categories containing or representing universals primarily The goal of BFO is not to develop ontologies as such, but to organize domain ontologies (e.g. an ontology for the neurosciences, the genetic ontology...). Universals are the 'abstract' or 'general' structure (e.g. "human", "mammal" or "feline"). These universals are the focus of BFO.</li> Uses perspectivalism Many different representations that are equally good (good in the sense of being true) precisely in that they capture different and important features of one and the same reality (different 'perspectives' enhance our understanding of the studied subject).</li> It's extended downward When the BFO will be extended (cf. 'capture' more and more domains and thus studied subjects) this will be done through its domain ontologies. It is believed that the BFO holds the classes needed for the construction and development of detailed domain ontologies. As such, this framework is thought to be stable and extensive.</li> </ul> To sum it up: BFO is a top-level (dealing with only universals, say working on an 'abstract level') ontology (cf. the attempt to describe or represent reality) which allows domain specific ontologies (such as OBI) to describe reality by differentiating between the characteristics (e.g. 'is this a process or not') of the particular element (e.g. 'a heart') one wants to describe. OBI The Ontology for Biomedical Investigations project (cf. OBI) is developing an integrated ontology for the description of biological and clinical investigations (and therefore is a domain specific ontology in contrast with the top-level ontology BFO). This includes a set of 'universal' terms, that are applicable across various biological and technological domains (originating from BFO), and domain-specific terms relevant only to a given domain (OBI specific terms). This ontology will support the consistent annotation of biomedical investigations, regardless of the particular field of study. The ontology will represent the design of an investigation, the protocols and instrumentation used, the material used, the data generated and the type analysis performed on it. In other words: OBI uses the 'framework' of BFO and builds an ontology within this framework which allows to connect data from different fields. Quick Terms The Quick ID file (cf. obi-quick-id.owl) is a specific file within OBI, which (since being part of the OBI) also uses the BFO. It's a protocol developed for those who have values they think are part of the OBI domain specific ontology, but are not core developers of OBI as such. This protocol allows those individuals to add terms in an easy manner. The Quick ID procedure is built around the obi-quick-id.owl file. It's basically a file within the OBI ontology which holds all newly added terms. Adding a term through the Quick ID adds those terms to the Quick ID file (within OBI). This file is different from other OBI files, due to the fact that all terms initially are 'uncurated'. Though it's part of the OBI, the terms added through Quick ID are not immediately part of the core OBI, but need curation before added to the core OBI. When terms are added correctly this is a semi-automatic process.

Additional Information
When you start out with OBI, it is not surprising that the specific terminology is confusing. Therefore we provide a short glossary of terms used in BFO, OBI and Quick ID. It's gives both a short description as (if applicable) where to find additional information. If this document nevertheless does not answer all your questions, you can join our mailinglist for Quick ID.

The process for quickly allocating OBI ids for accepted simple cross product terms can be found here along with some  examples.

Before you start...
When you want to add terms through the Quick ID procedure, it is assumed that you:  You know how to use the specific software to add the terms to OBI. Quick ID (and OBI in general) uses Protege, and we recommend that you download and install Protege 3.4</li> You have checked out the latest version of the OBI repository using subversion via the command line or via a SVN client from the OBI subversion repository </li> <li>Know how to use the Quick ID file locally following these instructions</li> <li>Know how to use Protege with OBI. </li> <li>Are aware of the OBI Minimal metadata</li> <li>Are aware of the OBO Foundry naming conventions. </li> </ul>

Determine the node of the Basic Formal Ontology
The following instructions will help you determine where under BFO your term should go and therefore how to describe and annotate it for inclusion within OBI. When submitting a term to OBI consideration should be given as to which node of BFO the term should be inferred under. This section allows you to determine whether the term you would like to add is a <ul> <li>process</li> <li>material entity</li> <li>information that describes an entity</li> </ul> Using the definition of process, material entity or information that describes an entitiy (which are all BFO classes), one can determine under which class the particular term should go to. Each term should fit in one of these classes. Therefore, you should start with process and move on untill you found the class appropriate for your Quick Term. It is always a good idea to read through all the classes, even if you 'are sure' which class it should go under. Use the following table to determine the class. In the first column you find the actual BFO class and in the second the definition and explanation of the particlar class. Examples are used to further assist you in determining the class. Once you decided which class corresponds to your term, click on the class which brings you to the next step.

Define the newly created class
Next you need to define the properties of your newly created class. Read through this section and go to the examples to get a better idea on what is expexted. Fill in a single value for each of these properties (e.g. only 1 definition, 1 reference...). If you need/have multiple values for your class, use the option of adding an extra field (see "Add extra fields" at the end of this table on how to do that). This means that if you have multiple references for your definition (e.g. a wikipage and a book which are the sources of your definition), than add as many additional "definition source" as required. Follow the OBI minimum metadata guidelines for your values.

<ul> <li>Define your definition</li> <ul> <li>Double click in the Value field</li> <li>If it's a process, use the following structure: "A [term] is a process that [description of what the process does] and has the input [material entity / information] and utilizes the function of a [material entity/device]. The output of the process is [material entity / information]. "</li> <li>If it's a material entity, use the following structure: "A [term] is a material entity that [description of material]." If appropriate also add the following: "The [term] is manufactured by [organization or person], has function [function], has supplier [organization or person]."</li> </ul> </ul>
 * Define the property "definition editor"
 * Double click in Value field
 * Fill in your name (since you are the editor of this term)
 * Define the property "definition source"
 * Double click in Value field
 * Fill in the source of the term's definition. This can be a wikipedia page, a book reference... Be precise in your reference.

Examples on how to define your term
The best way of getting an idea on how it's supposed to be done, is to browse the OBI repository (which you checked out using SVN). However, for you convenience we provide some examples of Protege both from Quick Terms as from OBI core terms. This will give an insight in how a Quick Term could look like and how a core term of OBI in its final form looks like. They main difference between such Quick Term and a core OBI term is the status of being uncurated as a Quick Term. The following terms are snapshots and possibly due for change. The following term descriptions therefore are not necessarily the latest versions of the term within OBI. As said, for the latest versions do use Protege itself. They are merely provided as an easily accessible 'first glance' of the terms. The terms are sorted according to the BFO class. The decision to rank them in e specific class are not describes in these examples. Such an explanation can be found in the explanation of the BFO classes. Hence we end up with the following structure:
 * Process
 * visual fixation: example of a Quick Term using the Quick ID procedure
 * DNA sequence variation detection: example of core OBI
 * storage: example of core OBI
 * Material Entity
 * face: example of a Quick Term using the Quick ID procedure
 * rat: example of a Quick Term using the Quick ID procedure
 * word: example of a Quick Term using the Quick ID procedure
 * cell culture supernatant: example of core OBI
 * physical document: example of core OBI

 Visual Fixation  Can be found in the OBI at
 * entity
 * &lfloor; occurent
 * &lfloor; processual entity
 * &lfloor; process
 * &lfloor; visual fixation

Properties and Values

 DNA sequence variation detection  Can be found in the OBI at
 * entity
 * &lfloor; occurent
 * &lfloor; processual entity
 * &lfloor; process
 * &lfloor; DNA sequence variation detection

Properties and Values

 Storage  Can be found in the OBI at
 * entity
 * &lfloor; occurent
 * &lfloor; processual entity
 * &lfloor; process
 * &lfloor; storage

Properties and Values

 Face  Can be found in the OBI at
 * entity
 * &lfloor; continuant
 * &lfloor; independent continuant
 * &lfloor; material entity
 * &lfloor; face

Properties and Values

 Rat  Can be found in the OBI at
 * entity
 * &lfloor; continuant
 * &lfloor; independent continuant
 * &lfloor; material entity
 * &lfloor; rat

Properties and Values

 Word  Can be found in the OBI at
 * entity
 * &lfloor; continuant
 * &lfloor; independent continuant
 * &lfloor; material entity
 * &lfloor; word

Properties and Values

 Cell Culture Supernatant  Can be found in the OBI at
 * entity
 * &lfloor; continuant
 * &lfloor; independent continuant
 * &lfloor; material entity
 * &lfloor; cell culture supernatant

Properties and Values

 Physical Document  Can be found in the OBI at
 * entity
 * &lfloor; continuant
 * &lfloor; independent continuant
 * &lfloor; material entity
 * &lfloor; physical document

Properties and Values