|
User Guide
COBrA supports the browsing and editing of two ontologies, and allows
the user to manually create links between terms in two ontologies. For
example, links between tissues in an anatomy and the cell types of the
tissues can be recorded and stored: these links are referred to as mappings.
Mappings can make reference to a third resource - the reference ontology.
COBrA also allows ontologies to be translated, read, and written into
Semantic Web languages including OWL.
COBrA supports reading and writing files in the following formats:
Please note that to load a go-termdb file it is necessary to first run
this qname script over the file,
e.g. $./qname go_200311-termdb.xml ". See Note
1.
COBrA also supports the manipulation and analysis of ontologies, for
example:
- merging
- inference
- validation
these functions are based on the Jena RDF libraries.
Loading an Ontology
Ontologies are loaded via the 'File' menu or by clicking on the buttons
labelled 'Left', 'Right', 'Mapping Ontology or 'Reference Ontology'. See
below for more details on file formats.
Browsing: The Tree View and the Node View
On loading an ontology into the left panel, the ontology is viewed as a
tree on the left and the details of the selected node are displayed on
the right. Once a second ontology is loaded into the right panel, the
node or tree view is chosen using the tabs on the top of each panel.
Both tree and node views can be used for navigation - click on the
parent or child node of interest. The tree and node views are kept in
synchrony, even if one of the views is hidden. The four pre-defined
ontology relationship are represented by the following
icons:
Relationship
|
Icon
|
is_a / subClassOf
|
|
partOf
|
|
subEventOf
|
|
develops from / lineage
|
|
Editing
Editing can be performed either by drag-and-drop - by clicking on
nodes in the tree and dragging
them using the mouse - or by calling the Term Editor. Dragging a
node to a new position causes a copy to be made, the original is not
deleted. The full range of editing options can be selected from a menu
which pops-up on right-clickinga
term in the tree view (or
Apple-Key and click on a Mac). The menu offers:
- Create Term: create
a new term as a child of the selected term.
- Edit Term: edit the
selected term using the Term Editor.
- Delete Term: delete
the selected term and all references to it.
- Delete Sub-Tree:
delete the selected term and all child terms which are solely dependent
on that term. All references to deleted terms are removed.
- Copy: Copy the
term, including links to other terms.
- Paste: Paste a
copied term to a new location.
Single terms can be copied from one ontology to another by using the Copy function, as described above,
on the left ontology say, and selecting 'Copy from Left to Right'
on the 'Edit' menu on the top menu bar. The copied term will appear in
the right ontology at the currently highlighted position.
A new ontology can be created by selecting the 'Create New
Ontology' option from the File menu. Before doing so, the User
Profile should be edited such that the ID prefix does not clash with
that of other ontologies that have been created. The prefix+the
automatically generated number are assumed to be unique identifiers of
a concept. If the same ID occurs in several ontologies it is assumed to
refer to the same thing.
Mapping
Once two ontologies are loaded, mapping can begin. First a file must be
loaded to store the mappings as it is desirable to be able to record the
mappings without changing either original ontology. Once this is done,
the terms to be mapped are highlighted by clicking, and then the Annotate button
is clicked to call the mapping editor. A justification for the mapping
ought to be recorded. The author should also be recorded and this slot
can be filled automatically by filling-out the user profile - select the User Profile
option from the File
menu.
A more advanced mapping can be performed by loading a reference
ontology. In this case, each mapping must be accompanied by the
selection of one or more terms from the reference ontology. For example,
the tissues in the celegans
anatomy can be mapped to those in the drosophila
anatomy by making these the left and right ontologies, and loading the
OBO Cell Type ontology as the reference. Each
tissue-tissue mapping is made on the basis of shared cell types.
Formats and IDs
The User Profile allows the prefix for any new ID to be set. The new ID
will then be the next in the series, e.g. if the prefix is MAP, and the
current highest MAP ID is 0000002, and a zero padding of 7 is desired,
then the next ID is: MAP:0000003. This procedure applied to newly
created terms in the left or right ontology as well as mapping terms.
IDs are not editable by the user. The default namespace for new terms
can also be set in a similar fashion.
Format
|
Read
|
Write
|
File Extension
|
| GO Flat File Format |
yes
|
yes
|
.go
|
GO XML/RDF
|
yes
|
as RDF
|
.xml/.rdf
|
DAG Edit
|
yes |
no |
|
RDFS
|
yes
|
yes
|
.rdfs
|
OWL
|
yes
|
yes
|
.owl
|
The GO XML/RDF format follows the definition in the GO DTD which uses is_a and part_of but does not define their
meaning. GO XML/RDF ontologies are saved in RDF triple format.
The RDFS format is defined at http://www.xspan.org/obo.rdfs
and differs from GO RDF in the use of rdfs:subClassOf
for the subclass relation and the definitions given to term, part_of and the other GO RDF
relations (the relation names are unchanged).
The OWL format is defined at http://www.xspan.org/obo.owl
and differs from the RDFS format by the use of partOf and the use of the classes EventClass or ObjectClass for the type of terms. As
with RDFS, the definitions of the remaining GO relations are altered but
their names are unaltered.
Both the RDFS and OWL formats are created by 'coercing' the ontology
relations and types to conform to the ontology definition. This is
required as few ontologies are expressed in RDFS/OWL and therefore
existing ontologies need to be converted from a flat file or GO RDF
format. Conversion is achieved by reading from one format and saving-as another.
All RDF-based formats use the creator
and date relations from the
Dublin Core for recording author and date information.
The DAG Edit format is supported for reading only, and is as expressive
as the GO Flat File format, if a flat file format is desired. However,
textual information may be lost such as term definitions, author, date
etc by writing to a flat file format. The following DAG Edit relations
are recognised (based on a survey of current OBO ontologies):
@isa_a@ | @ISA@ ==> %
@part_of@ | @PARTOF@ ==> <
@develops_from@ | @DEVELOPSFROM@ ==> ~
Mappings between ontologies are encoded by introducing a concept for
the mapping, e.g. a mapping between adult midgut
and intestinal
epithelium might be called IntestinalEpithelium-MidgutHomology
and encoded as triples:
<adult midgut hasMapping IntestinalEpithelium-MidgutHomology>
<intestinal
epithelium hasMapping IntestinalEpithelium-MidgutHomology>
<absorbative_cell isReferenceForMapping IntestinalEpithelium-MidgutHomology>
in RDF
proper:
<rdf:Description
rdf:about="http://www.geneontology.org/go#FBbt.00003138">
<j.0:hasMapping
rdf:resource="http://www.geneontology.org/go#CL.0000007"/>
<j.0:name>adult
midgut</j.0:name>
</rdf:Description>
or in flat
file format:
%
IntestinalEpithelium-MidgutHomology ; CL:0000007
^ adult midgut ;
FBbt:00003138
^ intestinal
epithelium ; WBdag:0005792
# absorbative_cell
; CL:0000212
in this
example, absorbative_cell
is the reference of the mapping (i.e. the common cell type).
Tools
The Tools
menu offers a number of functions which make use of the methods provided
by the Jena 2.0 toolkit. Use of these functions requires some
understanding of Jena and RDF see jena.sourceforge.net
for more details. The options are:
- Merge Right Ontology into
Left - convert left and right ontologies into RDF graphs, and
merge the graphs. The result appears in the left tab pane. Note that
errors may occur if the root nodes have the same ID (PREFIX.number).
Note that merging does not perform any sophisticated ontology checks,
rather, it computes the set union of two RDF graphs.
- Apply Inference Rules to
Left - an window appears in which the rules to be applied should
be entered, then the RDF graph of the left ontology is extended by
applying the rules. This is done using the Generic Rule Reasoner of the
Jena reasoner. The result appears in the right tab pane. A forwards rule
defining is_a to be transitive
would be:
[rule1:(?a
http://www.geneontology.org/dtds/go.dtd#is_a ?b)
(?b
http://www.geneontology.org/dtds/go.dtd#is_a ?c)
->(?a
http://www.geneontology.org/dtds/go.dtd#is_a ?c)]
the effect
of this rule is to propagate the is_a
links. Forwards reasoning be be easily visualised, while backwards
reasoning can also be performed using Jena and would be more useful in a
query answering mode.
- Compare RDF Models
- both left and right ontologies are converted into RDF graphs and the
isomorphism/intersection/difference is calculated, then the triples in
which the models differ are listed. A new window appears to show the
results. The listing can be found in the file "./analysis.html".
- Validate Left/Right RDFS
Model - the left/right ontology is converted into RDFS and the
Jena validate method is called. Currently this only checks data types
(which is not very useful). Additional checks are then made on the
subclass hierarchy and equivalent classes are reported. Equivalence is
often due to a cycle in the class hierarchy. A similar analysis is
performed on the part_of relation. Domain/range checks are not yet
implemented. Finally, the graph is analysed for cycles. The graph may
be cyclical and the ontology may still be valid as the graph analysis
ignores the types of links between terms.
Procedures
The various features may be used in combination, some examples are:
Mapping
- load an ontololgy into the left tab, e.g. the mouse anatomy
- load an ontology into the right tab, e.g. the cell ontology
- edit the User Profile adding your name and setting the ID
prefix
- create a new mapping ontology, use the option under the
File menu
- click on nodes that are to be linked, click Annotate on the
top bar
- repeat 5
- save the mapping file, use Save Mapping Ontology As, save
in OWL, RDFS or RDF format only
Merging a Mapping File
- load an ontology for which mappings have been made into the
left tab
- load the mappings ontology into the right tab (e.g. the
result of Mapping)
- use the Merge Right Ontology into Left operation under Tools
- save the left ontology using save-as and save in OWL, RDFS
or RDF format
Propagating Mappings
- load a merged mappings file (i.e. the result of Merging)
- use the Apply Inference Rules option under the Tools menu,
and a rule set such as
[rule1:(?a http://www.geneontology.org/dtds/go.dtd#hasMapping ?b) (?a
http://www.geneontology.org/dtds/go.dtd#part_of ?c) -> (?c
http://www.geneontology.org/dtds/go.dtd#hasMapping ?b)]
in order to propagate mappings. Note that the rules
are applied to the RDF translation of the ontology, hence the use of the
GO namespace.
External Validation - validating an ontology using tools
available on the Web
- load the ontology that is to be validated externally, e.g.
using the OWL validator at
- use the Search and Replace Namespace option under the Edit
menu to set the URI for the ontology,
- e.g. http://www.aiai.ed.ac.uk/resources/go/cell.owl#
for a cell ontology cell.owl to be put on the web at
http://www.aiai.ed.ac.uk/resources/go/
- using a browser, go to the validator URL and enter the URI
of the ontology
Bugs and Problems
- loading GO termdb RDF/XML files in
the original XML syntax (e.g. after running qname over the file)
requires an internet connection to be available, else loading
will not complete. This is because the Jena parser tries to access the
GO DTD. Once such a file has been loaded, it can be saved in RDF, and
thereafter read/written without internet access as the saved format is
RDF triples. In general, loading and saving do not require a network
connection.
- very occasionally, on loading an ontology a tab frame will
freeze, the solution is to re-load the file (in the other frame).
|
