org.coode.owlapi.obo.parser
Class DefaultNamespaceTagValueHandler

java.lang.Object
  org.coode.owlapi.obo.parser.AbstractTagValueHandler
      org.coode.owlapi.obo.parser.DefaultNamespaceTagValueHandler

All Implemented Interfaces:

TagValueHandler

public class DefaultNamespaceTagValueHandler
extends AbstractTagValueHandler

Author: Matthew Horridge
The University Of Manchester
Information Management Group
Date: 01-Sep-2008

OBO Namespaces are NOT like XML Namespaces. They are NOT used to form abbreviations for IRIs. The description below, taken from the OBOEdit manual, explains their provenance.

OBO Namespaces and Ontology Name (OBO Syntax and Semantics Document: Section 4.3)

Note that OBO namespaces are not the same as OWL namespaces - the analog of OWL namespaces are OBO ID spaces. OBO namespaces are semantics-free properties of a frame that allow partitioning of an ontology into sub-ontologies. For example, the GO is partitioned into 3 ontologies (3 OBO namespaces, 1 OWL namespace).

Every frame must have exactly one namespace. However, these do not need to be explicitly assigned. After parsing an OBO Document, any frame without a namespace is assigned the default-namespace, from the OBO Document header. If this is not specified, the Parser assigns a namespace arbitrarily. It is recommended this is equivalent to the URL or file path from which the document was retrieved.

Every OBODoc should have an "ontology" tag specified in the header. If this is not specified, then the parser should supply a default value. This value should be derived from the URL of the source of the ontology (typically using http or file schemes).

OBO Namespaces (From the OBOEdit Manual)

Namespaces

OBO files are designed to be easily merged and separated. Most tools that use OBO files can load many OBO files at once. If several ontologies have been loaded together and saved into a single file, it would be impossible to know which terms came from which file unless the origin of each term is indicated somehow. Namespaces are used to solve this problem by indicating a "logical ontology" to which every term, relation, instance OR relationship belongs, i.e., each entity is tagged with a Namespace that indicates which ontology it is part of.

Namespaces are user-definable. Every ontology object belongs to a single namespace. When terms from many ontologies have been loaded together, namespaces are used to break the merged ontology back into separate files.

Constructor Summary

DefaultNamespaceTagValueHandler(OBOConsumer consumer)

Method Summary

void	handle(String currentId, String value, String qualifierBlock, String comment) Handles a tag.

Methods inherited from class org.coode.owlapi.obo.parser.AbstractTagValueHandler

addAnnotation, applyChange, getAnnotationForTagValuePair, getBooleanConstant, getClassFromId, getConsumer, getCurrentClass, getDataFactory, getIRIFromOBOId, getOntology, getOWLClass, getOWLClassOrRestriction, getOWLObjectProperty, getOWLOntologyManager, getTagIRI, getTagIRI, getTagName, getUnquotedString

Methods inherited from class java.lang.Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

DefaultNamespaceTagValueHandler

public DefaultNamespaceTagValueHandler(OBOConsumer consumer)

Method Detail

handle

public void handle(String currentId,
                   String value,
                   String qualifierBlock,
                   String comment)

Description copied from interface: TagValueHandler

Handles a tag. This is called by the OBOConsumer during parsing to handle tags that match the value returned by the TagValueHandler.getTagName() method.

Parameters:

currentId - The id of the current frame.

value - The value of the tag

comment - The hidden comment. This is made up of any characters between ! and the end of line.