OBO Flat File Format 1.4 Syntax and Semantics [WORKING DRAFT]

Editor's Draft: November 2011

This version:

http://purl.obolibrary.org/obo/oboformat/2011-11-29/doc/obo-syntax.html

Editor's version:

http://oboformat.googlecode.com/svn/trunk/doc/obo-syntax.html

Latest version:

http://purl.obolibrary.org/obo/oboformat/spec.html

Previous version:

http://purl.obolibrary.org/obo/oboformat/2011-08-28/doc/obo-syntax.html

Editors:

Chris Mungall, Lawrence Berkeley National Laboratory

Alan Ruttenberg, University at Buffalo

Ian Horrocks, University of Oxford

David Osumi-Sutherland, Cambridge University

Contributors:

Erick Antezana, Bayer CropScience

James Balhoff, National Evolutionary Synthesis Center

Melanie Courtot, British Columbia Cancer Research Center

Heiko Dietze, Lawrence Berkeley National Laboratory

John Day-Richter, Google

Amelia Ireland, The Jackson Laboratory

Suzanna Lewis, Lawrence Berkeley National Laboratory

Shahid Manzoor, Lawrence Berkeley National Laboratory

Syed Hamid Tirmizi, University of Texas

---

Abstract

1 Introduction

This document specifies the syntax and semantics of OBO Format (OBOF)

The first part of this specification describes the syntax and structure of OBO Format using BNF. This states how strings of characters in OBOF Files are parsed into abstract OBO documents, and describes constraints on the structure of these documents. The second part of this specification describes the semantics of an OBO document via a mapping to OWL2-DL and community metadata vocabularies.

1.1 Relationship to previous specifications and translations

This specification builds on previous attempts to specify the syntax and/or semantics of OBOF.

1.1.1 Golbreich and Horrocks translation

This document is derived from and indebted to a previous document by Ian Horrocks [OBO-OWL Horrocks], later described in an accompanying paper [OBO-OWL Golbreich]. This document provided a semantics for OBO Format in terms of OWL-DL and what was then called OWL1.1 (later to become OWL2). The syntax was underspecified and the mapping was incomplete as there was no treatment of annotation properties.

implementation: This mapping was implemented in the OWLAPI, and is consequently used by current versions of Protege4

1.1.2 OboInOwl

The OboInOwl mapping attempted to fill in the gaps in the Horrocks translation by providing a full translation of all of OBOF 1.2, including synonyms and definitions[OBO-OWL NCBO]. This mapping requires use of the n-ary relations pattern to represent OBO metadata in its entirety. This has undesirable side-effects, such as introducing modeling classes and individuals into an ontology, affecting both reasoning and usability.

implementation:This mapping was implemented via an XSLT translation from OBO-XML. All class and ontology URIs are of the form http://purl.org/obo/owl.

1.1.3. OBO Format 1.3 mapping

OBO Format 1.3 was accompanied by a grammar and mapping to FOL [Obolog]. This mapping was based on the 2005 version of the OBO Relation Ontology and OBOF1.3/Obolog attempted to do justice to dual instance/type level relations and ternary temporally-qualified instance-level relations. However, this introduced too large an impedance mismatch between OBOF and OWL, and as a consequence OBOF1.3 and Obolog have been deprecated.

implementation:Deprecated.

1.1.4 Tirmizi et al

More recent work by Tirmizi provides an implementation of a fully roundtrippable mapping between OBO to OWL and back [OBO-OWL SWAT4LS] [OBO-OWL JBMS]. This did not attempt to provide a full grammar, and implemented the same specification as 1.1.2

implementation:OBO-Edit 2.0 (removed from OBO-Edit-2.1)

1.1.5 OBO Format Guides

The OBO Format 1.2 guide is too loose to be regarded as a full specification. It served as a basis for (1.1.1).

The [OBO Format 1.4 guide] accompanies this document. It is intended as a guide, not a normative specification.

1.1.6 Normative mapping

This document supersedes previous efforts. The goal is to provide a complete, normative specification of both the syntax and semantics of OBOF1.4. The syntax and semantics specified here also hold for any OBOF1.2 document.

The mapping provided here is consistent with the original Golbreich/Horrocks translation (1.1.1). It improves on this translation by specifying the grammar in full, and by providing a full mapping of all OBOF constructs to OWL2, through a combined use of the Information Artefact Ontology (IAO) and the OboInOwl vocabulary.

This mapping uses a different means of translating OBOF terminological elements (synonyms, definitions, etc) to OWL2 than the one provided in 1.1.2. The n-ary relations pattern has been abandoned, and replaced by the use of OWL2 AxiomAnnotations. Many of the OboInOwl vocabulary elements have been replaced by IAO annotation properties. This mapping also uses a different URI scheme. In place of the deprecated http://purl.org/obo/owl URIs, the OBO Foundry standard http://purl.obolibrary/org/obo scheme is now used.

The semantics specified in this document are inconsistent with the abandoned OBOF1.3 specification 1.1.3, which is strongly deprecated.

This specification also introduces new constructs absent from previous versionsof OBOF, and clarifies many syntactic and semantic elements that were previously unclear.

implementation: the reference implementation of this ontology can be found at the oboformat site

1.2 Additional introductory material

More material can be found at the oboformat site

2 Preliminary Definitions

2.1 BNF Notation

OBO-Format 1.4 is defined using a standard BNF notation, which is summarized in the table below.

Because generic tag-value pairs occur in very many places in the syntax, to save space the grammar has meta-productions for basic tag-values and for the tags themselves:

<T>-TVP ::= '<T>:' {ws} UnquotedString <T>-BT ::= '<T>:' {ws} ( 'true' | 'false' ) <T>-Tag ::= '<T>:' {ws}

For example, property_value-Tag should be interpreted as: 'property_value:' { ws }

We provide an additional List meta-production, for comma-delimited lists

<NT>List ::= [<NT>: {',' {ws} <NT>: }]

For example, property_value-Tag should be interpreted as: 'property_value:' { ws }

Documents in the obo-format consist of sequences of Unicode characters [UNICODE] and are encoded in UTF-8 [RFC 3629]. TODO - language tags

2.2 Spacing Characters

WhiteSpaceChar ::= ' ' | \t | U+0020 | U+0009 ws ::= { WhiteSpaceChar } NewlineChar ::= \r | \n | U+000A | U+000C | U+000D nl ::= ws NewLineChar nl* ::= { nl } nl+ ::= nl { ws NewLineChar } OBOChar ::= '\' Letter | ( Char - (NewLineChar | '\') )

2.3 Line Termination

Each tag-value clause in OBOF is line separated. The line can optionally be ended by a comment, indicated by the ! character - this is ignored by the parser. Each clause can also have zero or more tag-value qualifiers.

EOL ::= ws* [ QualifierBlock ] ws* [ HiddenComment ] ws* NewLineChar QualifierBlock ::= '{' QualifierList } HiddenComment ::= '!' { ( Char - NewlineChar ) } QualifierList ::= Qualifier {',' {ws} Qualifier } Qualifier ::= Rel-ID '=' QuotedString

2.4 Tokens

QuotedString ::= DblQuote { ( OBOChar - DblQuote ) } DblQuote UnquotedString ::= { OBOChar }

2.5 Identifiers

NonWsChar ::= ( OBOChar - WhiteSpaceChar ) Class-ID ::= ID Rel-ID ::= ID Instance-ID ::= ID ID ::= Prefixed-ID | Unprefixed-ID | URL-as-ID URL-as-ID ::= ( http: | https: ) { NonWsChar } Unprefixed-ID ::= { ( NonWsChar - ':' ) } Prefixed-ID ::= Canonical-Prefixed-ID | NonCanonical-Prefixed-ID

Canonical-Prefixed-ID ::= Canonical-IDPrefix ':' Canonical-LocalID Alpha-Char ::= a |b |c |d |e |f |g |h |i |j |k |l |m |n |o |p |q |r |s |t |u |v |w |x |y |z | A |B |C |D |E |F |G |H |I |J |K |L |M |N |O |P |Q |R |S |T |U |V |W |X |Y |Z Digit ::= 0 |1 |2 |3 |4 |5 |6 |7 |8 |9 Canonical-IDPrefix ::= Alpha-Char { ( '_' | Alpha-Char ) } Canonical-LocalID ::= { Digit }

NonCanonical-Prefixed-ID ::= ( Any-IDPrefix ':' Any-LocalID ) - Canonical-Prefixed-ID Any-IDPrefix ::= { ( NonWsChar - ':' ) } ':' Any-LocalID ::= { NonWsChar }

2.6 Xref Lists

An XrefList is a comma-separated list of zero or more Xrefs inside square brackets (these are manditory). Each Xref is a string of characters, optionally followed by a auoted description. Note that commans in the xref need to be escaped. We include an extra production rule for when solitary Xrefs are provided (i.e. with the 'xref' tag) - in this case commas do not need to be escaped.

XrefList ::= '[' [ Xref { ',' {ws} XrefNoComma } ] ']' XrefNoComma ::= { ( NonWsChar - ',') } [ {ws} QuotedString ] Xref ::= ID [ {ws} QuotedString ]

3 OBO Grammar

3.1 OBO Document Structure

An OBO document consists of a series of header frame followed by zero or more entity frames. Each frame has a set of clauses, or <tag,value> pairs. A tag is a token which may be drawn from the set of defined OBOF tags. The value can be atomic or multi-values. In the OBO Abstract syntax a clause is written <Tag>(<V1>...<Vn>).

Each frame should by convention be separated by an empty line, but this is not enforced in the syntax

Note that the term "frame" replaces the previously used "stanza" in order to be more consistent with Manchester Syntax.

OBO-Doc := header-frame { entity-frame } nl*

3.2 OBO Headers

header-frame ::= { header-clause nl* } header-clause ::= format-version-TVP | ontology-TVP | data-version-TVP | date-Tag DD-MM-YYYY sp hh-mm | saved-by-TVP | auto-generated-by-TVP | import-Tag IRI | filepath | subsetdef-Tag ID sp QuotedString | synonymtypedef-Tag ID sp QuotedString [ SynonymScope ] | default-namespace-Tag OBONamespace | idspace-Tag IDPrefix sp IRI [ sp QuotedString ] | treat-xrefs-as-equivalent-Tag IDPrefix | treat-xrefs-as-genus-differentia-Tag IDPrefix ws Rel-ID ws Class-ID | treat-xrefs-as-reverse-genus-differentia-Tag IDPrefix ws Rel-ID ws Class-ID | treat-xrefs-as-relationship-Tag IDPrefix Rel-ID | treat-xrefs-as-is_a-Tag IDPrefix | treat-xrefs-as-has-subclass-Tag IDPrefix | remark-TVP | UnreservedToken ':' [ ws ] UnquotedString entity-frame ::= term-frame | typedef-frame | instance-frame

3.3 Term Frames

Term frames introduce and define the meaning of terms (AKA classes).

term-frame ::= nl* '[Term]' nl id-Tag Class-ID EOL { term-frame-clause EOL } term-frame-clause ::= is_anonymous-BT | name-TVP | namespace-Tag OBONamespace | alt_id-Tag ID | def-Tag QuotedString ws XrefList | comment-TVP | subset-Tag Subset-ID | synonym-Tag QuotedString ws SynonymScope [ ws SynonymType-ID ] XrefList | xref-Tag Xref | builtin-BT | property_value-Tag Relation-ID ( QuotedString XSD-Type | ID ) | is_a-Tag Class-ID | intersection_of-Tag Class-ID | intersection_of-Tag Relation-ID Class-ID | union_of-Tag Class-ID | equivalent_to-Tag Class-ID | disjoint_from-Tag Class-ID | relationship-Tag Relation-ID Class-ID | created_by-Tag Person-ID | creation_date-Tag ISO-8601-DateTime | is_obsolete-BT | replaced_by-Tag Class-ID | consider-Tag ID

3.4 Typedef Frames

Typedef frames introduce and define the meaning of relations (AKA properties).

typedef-frame ::= [ nl ] '[Typedef]' nl id-Tag Relation-ID EOL { typedef-frame-clause EOL } typedef-frame-clause ::= is_anonymous-BT | name-TVP | namespace-Tag OBONamespace | alt_id-Tag ID | def-Tag QuotedString ws XrefList | comment-TVP | subset-Tag Subset-ID | synonym-Tag QuotedString ws SynonymScope [ ws SynonymType-ID ] XrefList | xref-Tag Xref | property_value-Tag Relation-ID ( QuotedString XSD-Type | ID ) | domain-Tag Class-ID | range-Tag Class-ID | builtin-BT | is_anti_symmetric-BT | is_cyclic-BT | is_reflexive-BT | is_symmetric-BT | is_transitive-BT | is_functional-BT | is_inverse_functional-BT | is_a-Tag Rel-ID | intersection_of-Tag Rel-ID | union_of-Tag Rel-ID | equivalent_to-Tag Rel-ID | disjoint_from-Tag Rel-ID | inverse_of-Tag Rel-ID | transitive_over-Tag Relation-ID | holds_over_chain-Tag Relation-ID Relation-ID | equivalent_to_chain-Tag Relation-ID Relation-ID | disjoint_over-Tag Rel-ID | relationship-Tag Rel-ID Rel-ID | created_by-Tag Person-ID | creation_date-Tag ISO-8601-DateTime | is-obsolete-BT | replaced_by-Tag Rel-ID | consider-Tag ID | expand_assertion_to-Tag QuotedString ws XrefList | expand_expression_to-Tag QuotedString ws XrefList | is_metadata_tag-BT | is_class_level_tag-BT

3.5 Instance Frames

Instance frames introduce and define the meaning of instances (AKA individuals).

instance-frame ::= [ nl ] '[Instance]' nl id-Tag Relation-ID EOL { instance-frame-clause EOL } instance-frame-clause ::= is_anonymous-BT | name-TVP | namespace-Tag OBONamespace | alt_id-Tag ID | def-Tag QuotedString ws XrefList | comment-TVP | subset-Tag Subset-ID | synonym-Tag QuotedString ws SynonymScope [ ws SynonymType-ID ] XrefList | xref-Tag ID | property_value-Tag Relation-ID ID | instance_of-Tag Class-ID | PropertyValueTagValue | relationship-Tag Rel-ID ID | created_by-Tag Person-ID | creation_date-Tag ISO-8601-DateTime | is-obsolete-BT | replaced_by-Tag Rel-ID | consider-Tag ID

3.5 Synonym Scopes

SynonymScope ::= 'EXACT' | 'BROAD' | 'NARROW' | 'RELATED'

4 OBO Document Structure

This section defines structural constraints on an OBO Document. These structural constraints hold on an abstract OBO Document - the result of parsing a physical OBO document file.

4.1 Frame Identifiers

Each frame in an abstract OBO document can be accessed by its identifier - the value of the id tag. A frame can only of one type. A document containing two frames of different types with the same id is illegal.

4.1.1 Merging frames during parsing

Although it is strongly recommended that an OBOF document does not contain two frames with the same identifier, this is syntactically valid. If two frames have the same identifier, then they are combined. Only frames of the same type can be combined - if a document uses the same ID for two frames of different types, the document is structurally invalid.

When two frames F1 and F2 are combined, the new frame F3 has a set of tag-values consisting of the union of the set of tag-values from F1 and the set of tag-values from F2. If two tag-values are have identical tags and identical values, they are considered a single tag-value.

4.2 Typedef constraints

If a Typedef frame has a clause is_metadata_tag(true), then that Typedef id may never be used as a Rel-ID in an intersection_of clause.

4.3 OBO namespaces and ontology name

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).

4.4 Processing Header Macros

4.4.1 Implicit Header Macros

Every OBO-Doc is automatically populated with two header clauses:

• treat-xrefs-as-equivalent(RO)
• treat-xrefs-as-equivalent(BFO)

4.4.2 Header Macro Translation

The following table shows how header macros are used to insert new clauses into the ontology document. If the pre-condition is satisfied (middle column) and the header contains the specified macro (first column), then clauses are added to the ontology such that the post-condition is satisfied (right hand column). Note that the original xref tags are not replaced in the ontology.

These clauses are expanded into a fresh ontology, which can be optionally imported.

4.4 Tag Cardinality Constraints

Note that the id tag is not specified in this table. Each frame has exactly one id tag, and the id tag uniquely identifier the frame. These constrainst must hold after frames with identical ids have been combined (see above).

Any tag not mentioned has free cardinality (zero, one or many).

• If a frame with an intersection_of clause has exactly one intersection_of(Class-ID) clause, then the frame is said to have a genus-differentia definition

5 OBO Semantics : Mapping to OWL2-DL

On completions this section will define the semantics of the entirety of OBO via mappings to OWL2. The mappings could also be used to specify a translation procedure and/or an interface to OWL tools (such as OWL reasoners).

The translation is defined using a translation function T which translates (a fragment of) OBO into OWL DL. The definition of T is often recursive, but it will eventually "ground out" in (a fragment of) OWL DL.

5.0 Ontologies

An OBO-Doc translates to an owl Ontology. The Ontology IRI is generated by extracting the value of the "ontology" tag in the header frame

5.1 Declarations

5.2 Mapping Term Frames - Class Axioms

5.2.1 Class Axioms, Basic Table

Term frames are mapped to Class declarations and Class-level axioms. We list the translations that are specific to Term frames here - generic translations making annotation assertions are applied later on.

5.2.2 Treatment of gci_relation qualifier

5.3 Class Expressions

The relationship and intersection_of tags can take pairs of values; these pairs map to OWL Class Expressions according to the following table.

Mappings are listed in order of precedence - an expression cannot match more than one production rule, only the first match counts.

5.4 Property Axioms

Note that OWL2 does not have the ability to declare EquivalentProperties between a named object property and either an intersection or a union. We translate these OBO constructs to a weaker axiom and add an AnnotationAssertion - we will later provide an appendix for handling these in FOL. This is also true for equivalent_to_chain

Inferred Axioms

The OBO Format equivalent_to_chain clause can only be partially expressed in OWL2. We can do some inference as part of translation - see this prover9 file for a proof.

5.5 Individual Axioms

5.6 Common Elements to Annotation Properties

5.7 Translation of OBO Qualifiers to Annotations

The following qualifiers are not translated to annotations:

• cardinality
• maxCardinality
• maxCardinality
• gci_relation
• gci_filler

5.8 Translation of Annotation Vocabulary

Annotation properties are drawn from the followling vocabularies:

• IAO - http://purl.obolibrary.org/obo/IAO_
• oboInOwl - http://www.geneontology.org/formats/oboInOwl#
• rdfs - http://www.w3.org/2000/01/rdf-schema#
• dc - http://purl.org/dc/elements/1.1/

Note we have no cognate of IAO:definition_source - we would have a generic xref annotation on the definition annotation assertion

5.8.1 Semantics of synonyms

Mapping of OBO Format synonym clauses is described in 5.6. These map to annotation properties without any semantics in OWL. This section provides semantics external to OWL.

Informal Description (Informative)

In OBO Format, the term "synonym" is used loosely for any kind of alternative label for a class (the "name" tag is used for the community preferred label). A label is a synonym for a class if there exists some user or user community (existing or historic) for which this label unambiguously denotes the class.

Synonyms are always scoped into one of four disjoint categories: EXACT, BROAD, NARROW, RELATED. A synonym is EXACT if it is a "true" synonym - most members of the community served by the ontology regard the exact synonym as substitutable for the primary label. If an ontology contains two classes which share either primary label (name) or exact synonym, then these classes are equivalent. A synonym for a class C is BROAD if it denotes a broader class than C. Here, broader than is an informal notion that encompasses both subsumption and possibly mereological and temporal containment. For example, "skull" could conceivably be a BROAD synonym for the class cranium. Conversely a synonym for a class C is NARROW if C denotes a broader class than the synonym. If a synonym is neither EXACT, NARROW or BROAD, then it is RELATED.

Scoping of synonyms has proven extremely useful for OBO format ontologies - most ontologies use this feature. The ability to designate a synonym as EXACT, in particular, is very useful for introducing additional terminological precision and reducing ambiguity in ontologies. These have also proven useful for NLP purposes.

5.9 Translation of Identifiers

5.9.1. Pre-processing

Every OBO-Document is automatically populated with two clauses:

• idspace(RO "http://purl.obolibrary.org/obo/RO_")
• idspace(BFO "http://purl.obolibrary.org/obo/BFO_")

5.9.2. Translation of identifiers

The following table is used when translating an OBO identifier to an IRI

5.9.3. Special Rules for Relations

An exception is made to 5.9.2 for translating relation IDs:

• If an Unprefixed-ID is declared in a Typedef frame, and that Typedef frame has an xref clause, then the value of that xref clause is used in the translation.
• If there are multiple xref clauses in the Typedef frame, then precedence is as follows:
  • xrefs in the 'BFO' and 'RO' ID-space take priority over all others
  • xrefs for which there is a corresponding idspace declaration in the header of the same document take precedence over xrefs for which there is no such declaration
  If these rules produce no clear winner, the source document is invalid.

A side effect of this substitution is the generation of an annotatoion assertion that preserves the original shorthand relation: AnnotationAssertion(T(shorthand) T(Formal-ID) "Original-ID"^^xsd:string)

These rules are normative. An informative summary is provided in section 8.2.2.

Mapping ID Prefixes

• If the OBODoc header tag contains an idspace clause idspace(IDPrefix URIPrefix), then the value of T^prefix(IDPrefix) is URIPrefix
• If the OBODoc header tag contains no matching idspace clause then the value of of T^prefix(prefix) is 'http://purl.obolibrary.org/obo/'

Examples (informative)

5.10 Post-Processing OWL DL

5.11 OWL to OBO

Not every OWL ontology can be converted to OBO Format. This may be because the OWL ontology uses constructs that cannot be expressed directly in OBO, or it may be because the corresponding OBO ontology would violate OBO document structure constraints (see section 4.4).

• If a Frame has more than one name after translation, an arbitrary one is selected, and a warning is fired
• If a Frame has more than one comment after translation, the set of distinct comments for that frame is concatenated using the \n escape character
• If an expression cannot be translated, it is dropped OR converted into an OWL Macro, see below

Note that all classes in an OBO Document are assumed to satisfiable. Any axioms refering to owl:Thing should be removed. An ontology with unsatisfiable classes is not translateable.

6 OBO Sublanguages

We introduce the concept of an OBO sublanguage. This is similar to an OWL profile, but the goal is not to provide sublanguages for reasoning purposes. Sublanguages are intended for legacy applications that make unwarranted assumptions about OBO format. The assumptions do not hold about OBO documents as a whole, but they may hold for particular sublanguages.

At this time, only one sublanguage is specified - OBO basic. To define this sublanguage, we first introduce a number of sublanguage characteristics.

6.1 OBO Sublanguage Characteristics

6.1.1 DAG

An ontology is a DAG if the graph formed by its logical relationships does not contain any cycles. Formally: let V be a set of nodes corresponding to all Term frames in the ontology (OWL Classes). Let E be a set of edge pairs A,B where both A and B are in V and either

• A is_a B (i.e. SubClassOf(A B)) or
• relationship: R B (i.e. SubClassOf(A ObjectSomeValuesFrom(R B)))

The ontology is a DAG if the transitive closure of E contains no cycles.

6.1.2 Dangling Clauses

A dangling clause is an is_a, relationship, intersection_of, union_of, transitive_over, equivalent_to_chain, holds_over_chain, disjoint_from, domain or range clause in which any of the values is not declared in the ontology document. Here declaration means there exists a frame with the corresponding identifier.

We can define 3 sub-characteristics:

• Dangling Classes
• Dangling Relations
• Dangling Individuals

6.1.3 Unidirectional

An ontology is said to be multidirectional if it contains a class assertion involving property P and a class assertion involving property P', where P is the inverse of P'. An ontology is unidirectional if it is not multidirectional.

For example, if an ontology contains statements using both part_of and has_part properties, then the ontology is not unidirectional.

Note that multidirectional ontologies with frequently be non-DAGs, according to the definition above, but this need not hold.

6.1.4 Fully asserted

An ontology is fully asserted if the graph formed by is_a and relationship clauses (i.e. SubClassOf axioms) is not lacking any relationships that can be inferred from the full set of axioms in the ontology (e.g. EquivalentClasses axioms, or DisjointFrom Axioms).

More formally: O is an ontology, and O' is an ontology consisting only of is_a and relationship tags asserted in O. O is fully-asserted if there is no SubClassOf axiom that is entailed by O but not by O'.

If an ontology is fully asserted, then basic applications can use solely is_a and relationship tags for graph traversal. intersection_of tags can be removed with no loss of functionality in these basic applications. Ontology publishers may wish to keep two versions - an edit version, in which only minimal assertions are made, and a release version, which is fully asserted, with the assertions added by a reasoner.

6.1.5 Fully Labeled

An OBO ontology is fully labeled if and only if every frame has a "name" tag.

6.1.6 Uniquely Labeled

An OBO ontology is uniquely labeled if and only if there are no two entities share the same name, including both the source ontology and its full import closure.

6.1.7 Locally Uniquely Labeled

An OBO ontology is locally uniquely labeled if and only if there are no two entities share the same name, considering only the source ontology but not its import closure.

6.1.8 No equivalence axioms

An OBO document has no equivalence axioms if the OWL translation contains no EquivalentClasses axioms.

6.1.9 No obo-namespace crossing

An OBO document has no obo-namespace crossing if there are no is_a, relationship, intersection_of or union_of clauses that span two obo-namespaces. Note that an obo-namespace is not the same as an OWL namespace. It is specified by the namespace tag in OBOF. An example is found in the GO, which is a single ontology partitioned into 3 obo-namespaces. Some legacy software assumes no namespace crossings, so the basic version of the GO released by the GOC has no obo-namespace crossings.

6.2 OBO Basic

OBO Basic is a sub-language of OBO format (i.e. every OBO Basic document is automatically an OBO Document). It allows basic applications to continue to make certain simplifying assumptions; many of these simplifying assumptions were based on the initial version of the Gene Ontology, and have become enshrined in many popular and useful tools such as term enrichment tools.

Examples of such assumptions include: traversing the ontology graph ignoring relationship types using a naive algorithm will not lead to cycles (i.e. the ontology is a DAG); every referenced term is declared in the ontology (i.e. there are no dangling clauses).

An ontology is OBO Basic if and only if it has the following characteristics:

• DAG
• Unidirectional
• No Dangling Clauses
• Fully Asserted
• Fully Labeled
• No equivalence axioms

6.3 Conversion to sub-languages

In general translation to a sublanguage is lossy, but this is not always the case. An OBO-Dangling-Clause ontology can be converted to a semantically equivalent ontology with declarations for all undeclared referenced frames (note that this typically happens as a side-effect of obo-to-ow-to-obo roundtripping). Note that this means the target ontology is no longer OBO-Fully-Labeled.

7 OWL Macros

This section cab be considered an independent component that can be used for any OWL ontology. It may eventually form its own separate specification. It should be seen as informative for now.

Macros are specified as the range of an AnnotationAssertion on a property. They take the form of a string encoding either an OWL axiom or OWL expression in an extension Manchester Syntax format [BCP 47]. This extension allows the use of variable markers (written ?X or ?Y) in place of classes or class expressions. When these variable markers are replaced by actual OWL classes or expressions (again serialized in Manchester Syntax) as part of a Template Substitution Operation Subst, the resulting string must be valid Manchester Syntax.

Examples are provided in [OWL Macros].

7.1 Macro Annotation Assertions

Two IRIs are used to specify the two different types of macro expansion.

7.2 Macro Expansion and Replacement

7.3 Macro-based GCI Enhancement

An alternative strategy is to use the occurrence of macro relations to add General Class Inclusion (GCI) axioms to the ontology

7.4 Placement of Generated Axioms in External Ontologies

The behavior of a macro-expansion engine regarding whether to replace on add new GCIs is implementation-dependent, as this decision of whether to place generated axioms in a new ontology or the source ontology.

The recommended behavior is:

• The 2nd (GCI) table should be used.
• The source ontology should be left unmodified.
• GCIs generated from expand_expression_to templates and new axioms generated by expand_assertion_to should be placed in a separate ontology or ontologies. The recommended IRI of this ontology will be specified in the id-policy document.

8 Recommendations (informative)

8.1 Generating OBO Format Documents

These guidelines are provided to minimize character-level differences between OBO Documents generated by different procedures.

8.1.1 Whitespace

• For every tag-value line, the initial ':' character should be followed by a space character (' ').
• Every successive pair of frames should be seperated by a single empty line.
• The initial frame should be separated from the header block by a single empty line.
• Each document should have an ontology declaration in the header.
• The ontology id should be all lower case, and should match the primary ID space used in the ontology (for example: 'go', 'cl').

8.1.2 File Comments

• If a frame references an identifier, and that identifier is opaque (i.e. it conforms to the Canonical-Prefixed-ID production rule), then the generator should add commments, adding a label for every opaque identifier. For example:

  relationship: part_of ABC:1234567 ! hand
  relationship: R:9999999 ABC:1234567 ! part_of hand
                      

• All file comments should be preceded by a tag-value pair, and there should be exactly one space character on either side of the '!' character

8.1.3 Tag Ordering

See the serializer conventions in the OBO format guide

8.1.4 Escaping characters

When writing solitary 'xref' tags, the comma character should be escaped.

8.2 Identifiers

8.2.1 Class (Term) Identifiers

All class identifiers should follow OBO Foundry ID Policy. i.e. all ID-spaces must be registered and approved (email obo-admin at obofoundry.org to register), and the entire ID should consist of the ID space followed by ':' followed by a zero-padded numeric local identifer (a minimum of 7 digits is recommended).

8.2.2 Relation (Property) Identifiers

Relation identifiers should in follow the same guidelines as class identifiers. Note however that the use of symbolic identifiers such as 'part_of' is common in almost all OBO format ontologies, and has a precedent stretching back over ten years. A large body of software now expects symbolic identifiers for relations, and ontology maintainers are understandably reluctant to change these to numeric identifiers.

This specification provides a means of using numeric identifiers globally whilst retaining symbolic identifiers within the context of a single file. Refer to section 5.9.3 for details.

• Every symbolic relation identifier (e.g. 'part_of') should have an xref tag to a formal relation identifier. E.g.

  [Typedef]
  id: has_part
  name: has_part
  xref: BFO:0000051
  

• This xref should refer to either BFO (http://purl.obolibrary.org/obo/bfo.owl) or to RO (http://purl.obolibrary.org/obo/ro.owl
• According to the rules in section 5.9.3, the symbolic relation identifier can be used as a shorthand for the formal relation identifier.
• When roundtripping the OBO file, the symbolic identifiers should be preserved.

8.3 Individuals

Individuals are retained in OBOF1.4 for compatibility with previous versions of the format. OBOF is not a good choice for modeling using individuals. Ontologies should not contain individuals, and OBOF is not a good choice for knowledge bases that use individuals.

9 References

9.1 Normative References

[BCP 47]

BCP 47 - Tags for Identifying Languages. A. Phillips and M. Davis, eds. IETF, September 2006. http://www.rfc-editor.org/rfc/bcp/bcp47.txt

[OWL 2 Specification]

OWL 2 Web Ontology Language: Structural Specification and Functional-Style Syntax Boris Motik, Peter F. Patel-Schneider, Bijan Parsia, eds. W3C Recommendation, 27 October 2009, http://www.w3.org/TR/2009/REC-owl2-syntax-20091027/. Latest version available at http://www.w3.org/TR/owl2-syntax/.

[RDF Test Cases]

RDF Test Cases. Jan Grant and Dave Beckett, eds. W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-testcases-20040210/. Latest version available as http://www.w3.org/TR/rdf-testcases/.

[RFC 3629]

RFC 3629: UTF-8, a transformation format of ISO 10646. F. Yergeau. IETF, November 2003, http://www.ietf.org/rfc/rfc3629.txt

[RFC 3987]

RFC 3987: Internationalized Resource Identifiers (IRIs). M. Duerst and M. Suignard. IETF, January 2005, http://www.ietf.org/rfc/rfc3987.txt

[SPARQL]

SPARQL Query Language for RDF. Eric Prud'hommeaux and Andy Seaborne, eds. W3C Recommendation, 15 January 2008, http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/. Latest version available as http://www.w3.org/TR/rdf-sparql-query/.

[UNICODE]

The Unicode Standard. The Unicode Consortium, Version 5.1.0, ISBN 0-321-48091-0, as updated from time to time by the publication of new versions. (See http://www.unicode.org/unicode/standard/versions/ for the latest version and additional information on versions of the standard and of the Unicode Character Database).

8.2 Non-normative References

[OBO-OWL Horrocks]

OBO Flat File Format Syntax and Semantics and Mapping to OWL Web Ontology Language. Ian Horrocks, March 2007. http://www.cs.man.ac.uk/~horrocks/obo/

[OBO-OWL Golbreich]

The OBO to OWL mapping, GO to OWL 1.1. Christine Golbreich, Ian Horrocks, 2007. http://en.scientificcommons.org/43278282

[OBO-OWL NCBO]

NCBO Mapping OBO to OWL. Dilvan Moreira, John Day-Richter, Chris Mungall, Nigam H. Shah 2007, http://www.bioontology.org/wiki/index.php/OboInOwl:Main_Page

[Obolog]

Obolog specification. Chris Mungall. Aug 2008, http://oboedit.org/obolog/spec/obolog-spec.pdf

[OBO-OWL WG]

Working Group on OBO-OWL interconversion. http://www.obofoundry.org/wiki/index.php/Working_Group_on_OBO-OWL_interconversion

[OBO OWL JBMS]

Mapping between the OBO and OWL ontology languages.. Syed Hamid Tirmizi, Stuart Aitken, Dilvan Moreira, Chris Mungall, Juan Sequeda, Nigam H. Shah and Daniel P. Miranker. In: Proceedings of Semantic Web Applications and Tools for Life Sciences Workshop, Amsterdam, The Netherlands,

[OBO OWL SWAT4LS]

OBO & OWL: Roundtrip Ontology Transformations.. Syed Hamid Tirmizi, Stuart Aitken, Dilvan Moreira, Chris Mungall, Juan Sequeda, Nigam H. Shah and Daniel P. Miranker. In: Proceedings of Semantic Web Applications and Tools for Life Sciences Workshop, Amsterdam, The Netherlands,

[OBO Format 1.4 Guide]

OBO Format 1.4 Guide. Chris Mungall and John-Day Richter, August 2010, http://www.geneontology.org/GO.format.obo-1_4.shtml

[Manchester OWL DL Syntax]

OWL 2 Web Ontology Language Manchester Syntax. Matthew Horridge, Peter F. Patel-Schneider, October 2009, http://www.w3.org/TR/owl2-manchester-syntax/

[OWL Macros]

OWL 2 Macros. Chris Mungall, David Osumi-Sutherland, Alan Ruttenberg, June 2010, http://precedings.nature.com/documents/5292/version/1

[OWLDEF]

OWLDEF: Integrating OBO and OWL. R Hoehndorf, A Oellrich, M Dumontier, J Kelso, H Herre, http://leechuck.de/pub/or-sig.pdf

[Relational Patterns]

Relational patterns in OWL and their application to OBO. R Hoehndorf, A Oellrich, M Dumontier, J Kelso, H Herre, "http://www.webont.org/owled/2010/papers/owled2010_submission_3.pdf