ROBOT can convert tables to OWL format using templates. See
template.csv for an example. The approach extends the QTT method described in Overcoming the ontology enrichment bottleneck with Quick Term Templates.
ROBOT can read comma-separated values (
.csv) or tab-separated values (
robot template --template template.csv \ --prefix "ex: http://example.com/" \ --ontology-iri "https://github.com/ontodev/robot/examples/template.owl" \ --output results/template.owl
Each template file must be set up in the following format:
template command accepts an optional input ontology, either using the
--input option or from the previous command in a chain. If an input ontology is given, its
rdfs:labels will be used when parsing the template. The
-t option specifies the CSV or TSV template file. Multiple templates are allowed, and the order of templates is significant. You can also specify the normal
--prefix options, the
--version-iri, and the usual
--output options. See Merging for the three different merge options, and details on how they control the output of the command.
A template may have multiple errors in different rows and columns. By default,
template will fail on the first error encountered. If you wish to proceed with errors, use
--force true. This will log all row parse errors to STDERR and attempt to create an ontology anyway. Be aware that the output ontology may be missing axioms.
ID: Every term must have an IRI to identify it. This can be specified with an
IDcolumn. Usually this will be a prefixed ID like
GO:12345. See the
--prefixoptions for details.
--inputontology, you can refer to it by
LABELinstead (see below).
LABELwill be skipped.
LABEL: a special keyword to specify an
rdfs:labelthat uniquely identifies the target term. This can be easier than the numeric IDs for human readers. Keep in mind:
LABELcolumn will create
rdfs:labelstring annotation for the entity
LABEL, be sure to include an
IDcolumn as well
TYPE: this is the
rdf:typefor the row. Because ROBOT is focused on ontology development, the default value is
owl:Classand this column is optional. When creating an OWLIndividual, specify the class to which it belongs in this column.
owl:NamedIndividual, or a defined class ID or label
Astring annotation: If the template string starts with an
Aand a space then it will be interpreted as a string annotation. The rest of the template string should be the label or compact IRI of an annotation property, e.g.
rdfs:label. The cell value will be the literal value of the annotation with type
xsd:string. Annotation property labels do not need to be wrapped in single quotes.
ATtyped annotation: If the template string starts with an
ATand a space then it will be interpreted as a typed annotation. The
^^characters must be used to separate the annotation property from the datatype, e.g.
rdfs:comment^^xsd:integer. The cell value will be the typed literal value of the annotation.
ALlanguage annotation: If the template string starts with an
ALand a space then it will be interpreted as a language annotation. The
@character must be used to separate the annotation property from the language code, e.g.
AIannotation IRI: If the template string starts with an
AIand a space, then the annotation will be made as with a string annotation, except that the cell value will be interpreted as an IRI.
>A(axiom annotations): ROBOT can also annotate logical and annotation axioms. The axiom annotation will be on the axiom created on the cell to the left of the
>A*template string. The
>symbol can be used in front of any valid annotation character (
Sometimes you want to include zero or more values in a single spreadsheet cell, for example when you want to allow for multiple annotations or have separate logical axioms. If a template string also contains
SPLIT=|, then ROBOT will use the
| character to split the contents of a cell in that column and add an annotation for each result (if there are any). Instead of
| you can specify a string of characters of your choice – other than pure whitespace – to split on (e.g.
DCfollowed by a space and the template string (e.g.
SC %) then it will be interpreted as a class expression. The value of the current cell will be substituted into the template, replacing all occurrences of the percent
%character. Then, the result will be parsed into an OWL class expression.
rdfs:label(enclosing in single quotes if it has a space in it).
SC %: the class will be asserted to be a subclass of the class expression in this column
EC %: the class will be asserted to be an equivalent class of the intersection of all
ECclass expressions in a row
DC %: the class will be asserted to be disjoint with the class expression in this column
C %: the class will be asserted as specified in the
CLASS_TYPE: an optional column that specifies the type for all
Ccolumns. This allows different rows to have different types of logical definitions. Valid values are:
subclass: the values of all
Ccolumns will be asserted as subclasses (this is the default)
equivalent: values of all
Ccolumns will be taken as an intersection and asserted to be an equivalent class
disjoint: the values of all
Ccolumns will be asserted as disjoint classes
CI template string tells ROBOT to read the cell value as an IRI and assert it as the
CLASS_TYPE. This is included for legacy support, and the other class template strings are preferred.)
|Label||Entity Type||Superclass||Disjoint Classes||Equivalent axioms|
|LABEL||TYPE||SC %||DC %||EC part_of some %|
|Class 2||class||Class 1|
|Class 3||class||Class 2|
|Class 4||class||equivalent||Class 3|
Class 2 will be a subclass of Class 1. Class 3 will be equivalent to
part_of some 'Class 2' and Class 4 will be disjoint with Class 3.
Manchester expressions can also be used within the cells. To avoid ambiguity, it’s best to enclose expressions in parentheses:
|Class 5||(part_of some ‘Class 4’)|
In this template, Class 5 would be a subclass of
part_of some 'Class 4'.
DOMAIN: The domain to a property is a class expression in Manchester Syntax (for object and data properties). For annotation properties, the domain must be a single class specified by label, CURIE, or IRI.
RANGE: The range to a property is either a class expression in Manchester Syntax (for object properties) or the name, CURIE, or IRI of a datatype (for annotation and data properties).
CHARACTERISTIC: for each row of data that has a
TYPEof object property or data property (not an annotation property), you can optionally specify a logical
CHARACTERISTICcolumn. The column can be split, e.g.
CHARACTERISTIC SPLIT=|, to specify multiple characteristics. Object properties can have any of the following characteristics, but only
functionalapplies to data properties:
functional: the created property will be functional, meaning each entity (subject) can have at most one value
inverse functional: the created object property will be inverse functional, meaning each value can have at most one subject
reflexive: the created object property will be reflexive, meaning each subject can also be a value
irreflexive: the created object property will be irreflexive, meaning the subject cannot also be the value
symmetric: the created object property will be symmetric, meaning the subject and value can be reversed
asymmetric: the created object property will be asymmetric, meaning the subject and value cannot be reversed
transitive: the created object property will be transitive, meaning the property can be chained
IPfollowed by a space and the template string (e.g.
SP %), then it will be interpreted as a property expression. The value of the current cell will be substituted into the template, replacing all occurrences of the
%character. Then the result will be parsed into an OWL property expression. ROBOT uses the same syntax for property expressions as Protégé: Manchester Syntax. If it does not recognize a name, ROBOT will assume that you’re trying to refer to an entity by its IRI or CURIE. This can lead to unexpected behavior, but it allows you to refer to entities without loading them into the input ontology.
SP %: the property will be asserted to be a subproperty of the property expression in the column
EP %: the property will be asserted to be equivalent with the property expression in the column
DP %: the property will be asserted to be disjoint with the property expression in the column
IP %: the property will be asserted to be the inverse of the property expression in the column (this can only be used with object properties)
P %: the property will be asserted as specified in the
PROPERTY_TYPE: an optional column that specifies the type for all
Pcolumns. This allows different rows to have different types of logical definitions. Valid values are:
subproperty: the values of all
Pcolumns will be asserted as subproperties (this is the default, annotation properties can only be subproperties)
equivalent: values of all
Ccolumns will be asserted as equivalent properties
disjoint: the values of all
Pcolumns will be asserted as disjoint properties
inverse: the values of all
Pcolumns will be asserted as inverse properties (only applies to object properties)
|ID||Entity Type||Characteristic||Super Property||Domain||Range|
|OP:1||owl:ObjectProperty||Property 1||Class 1||Class 2|
|DP:1||owl:DataProperty||functional||Property 2||Class 2||xsd:string|
TYPE is a defined class,
owl:NamedIndividual, an instance will be created. If the
TYPE does not include a defined class, that instance will have no class assertions. You may include a
TYPE if you wish to provide more than one class assertion for an individual.
I <property>: when creating an individual, replace property with an object property or data property to add assertions (either by label or CURIE). The value of each axiom will be the value of the cell in this column. For object property assertions, this is another individual. For data property assertions, this is a literal value. If using a property label here, do not wrap the label in single quotes.
SI %: the individual in the column will be asserted to be the same individual
DI %: the individual in the column will be asserted to be a different individual
|Label||Entity Type||Property Assertions||Different Individuals|
|LABEL||TYPE||I part_of||DI %|
|Individual 1||Class 1||Individual 2|
|Individual 2||Class 1||Individual 1|
template command has three options for merging, which are especially useful when chaining commands. First some terminology:
--inputoption, used to resolve terms in the template
The three options can differ in which ontology is saved for the
--output option and which is sent to the next command in the chain:
merge-before: the result ontology is merged into the input ontology immediately, so only the merged ontology will be output
--outputoptions apply to the result ontology, then result ontology is merged into the input ontology, and the output of the command is the merged ontology
These three options are particularly useful when chaining commands. For instance, the
merge-after option lets you save the result ontology separately, then send the merged ontology to the next command. See merge for more information on merge options, including
If the command includes
--ancestors, the result ontology will include the ancestors (from the input ontology) of the result ontology terms. Only the labels of the ancestors will be included.
Create an output ontology that includes the input ontology and the terms defined in the template:
robot template --merge-before --input edit.owl \ --template template.csv --output results/template.owl
robot template --merge-after \ --input edit.owl \ --template uberon_template.csv \ --output results/uberon_template.owl \ annotate --annotation rdfs:comment "UBERON with new terms" \ --output results/uberon_v2.owl
Create an output ontology that consists of the template terms plus their dependencies (
robot template --ancestors --input edit.owl \ --template uberon_template.csv \ --ontology-iri "https://github.com/ontodev/robot/examples/uberon_template_2.owl" \ --output results/uberon_template_2.owl
Create an output ontology that includes the input ontology and the terms defined in the template, but keep the import statements* (
robot template --merge-before \ --input test.owl \ --collapse-import-closure false \ --template uberon_template.csv \ --output results/test_template.owl
* NOTE: the imports would be merged into the output if
--collapse-import-closure true is included instead.
Further examples can be found in the OBI repository
Annotation properties should not have any value in the
CHARACTERISTIC column, if it exists. This type of logic for annotation properties is not supported in OWL.
The annotation property provided could not be resolved. Check your template to ensure the provided annotation property is in a correct IRI or CURIE format. For legibility, using CURIEs is recommended, but you must ensure that the prefix is defined.
A rdfs:label A http://www.w3.org/2000/01/rdf-schema#label
The only valid
PROPERTY_TYPE for an annotation property is
subproperty. Other types of logic for annotation properties are not supported in OWL. If this column is left blank, it will default to
An axiom annotation is an annotation on an axiom, either a class axiom or another annotation. Because of this, any time
>A is used, an annotation must be in the previous column. Any time
>C is used, a class expression must be in the previous column.
A rdfs:label,>A rdfs:comment C %,>C rdfs:comment
CLASS_TYPE values are:
A class row may only use one of:
disjoint. To add other types of axioms on an OWL class, use a separate row.
Each column that has a template string in row two must have a header string in row one. It is OK to have a header string with no template string.
The only valid
CHARACTERISTIC value for a data property is
functional. Other types of property characteristics for data properties are not supported in OWL.
The datatype provided in an
AT template string could not be resolved. Check your template to ensure the provided datatype is in a correct IRI or CURIE format. For legibility, using CURIEs is recommended, but you must ensure that the prefix is defined.
AT rdfs:label^^xsd:string AT rdfs:label^^http://www.w3.org/2001/XMLSchema#string
--template option accepts the following file types: CSV, TSV, or TAB.
Each template must have an ID column. Keep in mind that if the template has an ID column, but it is not filled in for a row, that row will be skipped.
INDIVIDUAL_TYPE values are:
An individual row may only use one of:
different. To add other types of axioms on an OWL individual, use a separate row.
The IRI provided as the value (in a row) to an
AI template string could not be resolved as an IRI. Check your template to ensure the provided value is in a correct IRI or CURIE format. If using CURIEs, remember to ensure the prefix is defined.
The template string for an
AL annotation must always include
The provided value cannot be parsed and may not be in proper Manchester syntax. See Manchester Syntax for more details. If you are using labels, make sure the labels are defined in the
--input ontology or using the
LABEL column. Also ensure that all properties use a label instead of a CURIE or IRI.
--merge-after cannot be used simultaneously.
You must specify at least one template with
--template to proceed.
CLASS_TYPE column is included, ROBOT will default to using
subclass. If a
CLASS_TYPE column is included, though, each row must include a specified class type. If the
CLASS_TYPE is left empty, this error message will be returned.
PROPERTY_TYPE column may include multiple types, only one of the logical types is allowed in each column:
disjoint, or (for object properties only)
inverse. To add other types of axioms on an OWL property, use a separate row.
An IRI cannot be created from the provided ID. This is most likely because the ID is not formatted properly, as an IRI or a CURIE.
PROPERTY_TYPE values are:
disjoint, and (for object properties only)
The template cannot be found in the current directory. Make sure the file exists and your path is correct.
The template string for an
AT annotation must always include
CHARACTERISTIC value was passed. If you are providing multiple characteristics, make sure to include
SPLIT= in your template string. Valid characteristics are:
Valid template strings are limited to the described above. If a different template string is provided, this error message will be returned.