Journal:ROBOT: A Tool for Automating Ontology Workflows - Revision history

Shawndouglas: Fixed citation issue

2021-09-19T20:40:32Z

Fixed citation issue

← Older revision		Revision as of 20:40, 19 September 2021
Line 175:		Line 175:

	===The Ontology Development Kit===		===The Ontology Development Kit===
	Creating a Makefile to coordinate all these steps can be challenging. We make this easier for ontology developers by providing an Ontology Development Kit (ODK).<ref name="GitHubODK">{{cite web \|url=https://github.com/INCATools/ontology-development-kit/ \|title=INCATools / ontology-development-kit \|work=GitHub \|accessdate=09 October 2018}}</ref> This can be used to create a GitHub repository following a standard layout, with a standard Makefile following the workflow detailed above. The resulting GitHub repository will also be automatically configured to run the validation steps (such as <tt>report</tt>) of the workflow via Travis CI.<ref name="TravisCI" /> The workflow can also be executed using Docker with ODK containers released on DockerHub.<ref name="DHObolibrary">{{cite web \|url=https://hub.docker.com/u/obolibrary \|title=obolibrary \|work=DockerHub \|accessdate=09 October 2018}}</ref> This allows easy execution of workflows on either the local computer of an ontology developer, with Travis CI, or through scalable-build tools such as Jenkins.<ref name="~~GitHubODK~~">{{cite web \|url=https://jenkins.io/ \|title=Jenkins \|work=jenkins.io \|accessdate=21 May 2019}}</ref>		Creating a Makefile to coordinate all these steps can be challenging. We make this easier for ontology developers by providing an Ontology Development Kit (ODK).<ref name="GitHubODK">{{cite web \|url=https://github.com/INCATools/ontology-development-kit/ \|title=INCATools / ontology-development-kit \|work=GitHub \|accessdate=09 October 2018}}</ref> This can be used to create a GitHub repository following a standard layout, with a standard Makefile following the workflow detailed above. The resulting GitHub repository will also be automatically configured to run the validation steps (such as <tt>report</tt>) of the workflow via Travis CI.<ref name="TravisCI" /> The workflow can also be executed using Docker with ODK containers released on DockerHub.<ref name="DHObolibrary">{{cite web \|url=https://hub.docker.com/u/obolibrary \|title=obolibrary \|work=DockerHub \|accessdate=09 October 2018}}</ref> This allows easy execution of workflows on either the local computer of an ontology developer, with Travis CI, or through scalable-build tools such as Jenkins.<ref name="JenkinsHome">{{cite web \|url=https://jenkins.io/ \|title=Jenkins \|work=jenkins.io \|accessdate=21 May 2019}}</ref>

	ODK builds on ROBOT and demonstrates ROBOT’s utility, but a full discussion is beyond the scope of this article.		ODK builds on ROBOT and demonstrates ROBOT’s utility, but a full discussion is beyond the scope of this article.

Shawndouglas: /* Notes */

2020-02-17T22:21:08Z

Notes

← Older revision		Revision as of 22:21, 17 February 2020
Line 286:		Line 286:

	==Notes==		==Notes==
	This presentation is faithful to the original, with only a few minor changes to presentation, spelling, and grammar. We also added PMCID and DOI when they were missing from the original reference.		This presentation is faithful to the original, with only a few minor changes to presentation, spelling, and grammar. We also added PMCID and DOI when they were missing from the original reference. A few citations were turned into simple inline links to content, where appropriate.

	<!--Place all category tags here-->		<!--Place all category tags here-->

Shawndouglas: Finished adding rest of content.

2020-02-17T22:01:23Z

Finished adding rest of content.

Show changes

Shawndouglas: Saving and adding more.

2020-02-17T21:20:59Z

Saving and adding more.

← Older revision		Revision as of 21:20, 17 February 2020
Line 38:		Line 38:

	==Background==		==Background==
	[[Ontology (information science)\|Ontologies]] are vital parts of the [[Informatics (academic field)\|informatics]] ecosystem, supporting life science research, enabling analysis of high-throughput datasets, data standardization and integration, search, and discovery. However, there is a lack of tools supporting the complete ontology development lifecycle, especially when compared with the [[Systems development life cycle\|software development lifecycle]]. This has resulted in many groups developing their own ''ad hoc'' ontology development ~~workflows~~, often with time-consuming and inefficient manual steps. In some cases, groups release ontologies without any kind of systematic workflow or [[quality control]] process, which can result in errors or problems with downstream applications or [[Data analysis\|analyses]].		[[Ontology (information science)\|Ontologies]] are vital parts of the [[Informatics (academic field)\|informatics]] ecosystem, supporting life science research, enabling analysis of high-throughput datasets, data standardization and integration, search, and discovery. However, there is a lack of tools supporting the complete ontology development lifecycle, especially when compared with the [[Systems development life cycle\|software development lifecycle]]. This has resulted in many groups developing their own ''ad hoc'' ontology development [[workflow]]s, often with time-consuming and inefficient manual steps. In some cases, groups release ontologies without any kind of systematic workflow or [[quality control]] process, which can result in errors or problems with downstream applications or [[Data analysis\|analyses]].

	Noy ''et al.'' (2010) describe a general ontology lifecycle, with a focus on bio-ontologies.<ref name="NoyTheOnt10">{{cite journal \|title=The ontology life cycle: Integrated tools for editing, publishing, peer review, and evolution of ontologies \|journal=AMIA Annual Symposium Proceedings \|author=Noy, N.; Tudorache, T.; Nyulas, C. et al. \|volume=2010 \|pages=552–6 \|year=2010 \|pmid=21347039 \|pmc=PMC3041389}}</ref> First, requirements for the ontology are gathered. Then, the ontology is collaboratively developed in an ontology editor such as Protégé.<ref name="HorridgeSupport06">{{cite journal \|title=Supporting early adoption of OWL 1.1 with Protégé-OWL and FaCT++ \|journal=OWL: Experiences and Directions 2006 \|author=Horridge, M.; Tsarkov, D. \|pages=1–7 \|year=2006 \|url=http://webont.org/owled/2006/accepted06.html}}</ref> Once the requirements have been fulfilled, the ontology is published and feedback is solicited from the community. Feedback is integrated back into development, and the ontology is continuously updated and released. At any point after the initial publication, the ontology may be deployed in other applications.		Noy ''et al.'' (2010) describe a general ontology lifecycle, with a focus on bio-ontologies.<ref name="NoyTheOnt10">{{cite journal \|title=The ontology life cycle: Integrated tools for editing, publishing, peer review, and evolution of ontologies \|journal=AMIA Annual Symposium Proceedings \|author=Noy, N.; Tudorache, T.; Nyulas, C. et al. \|volume=2010 \|pages=552–6 \|year=2010 \|pmid=21347039 \|pmc=PMC3041389}}</ref> First, requirements for the ontology are gathered. Then, the ontology is collaboratively developed in an ontology editor such as Protégé.<ref name="HorridgeSupport06">{{cite journal \|title=Supporting early adoption of OWL 1.1 with Protégé-OWL and FaCT++ \|journal=OWL: Experiences and Directions 2006 \|author=Horridge, M.; Tsarkov, D. \|pages=1–7 \|year=2006 \|url=http://webont.org/owled/2006/accepted06.html}}</ref> Once the requirements have been fulfilled, the ontology is published and feedback is solicited from the community. Feedback is integrated back into development, and the ontology is continuously updated and released. At any point after the initial publication, the ontology may be deployed in other applications.
Line 115:		Line 115:
	Ontology workflows typically include query operations over the ontology, producing reports which may be informative for both editors and users of the ontology, e.g., a table of all classes plus their textual definitions. Query operations can also be used for validation checks. The SPARQL query language provides a universal and declarative way for ontology maintainers to create ontology reports and validation checks.<ref name="HarrisSPARQL13">{{cite web \|url=https://www.w3.org/TR/sparql11-query/ \|title=SPARQL 1.1 Query Language \|editor=Harris, S.; Seaborne, A.; Prud'hommeaux, E. \|work=w3.org \|date=21 March 2013 \|accessdate=23 May 2019}}</ref> ROBOT provides a convenient way to perform queries with the <tt>query</tt> command, or validation checks using <tt>verify</tt>. Additionally, the <tt>report</tt> command includes a configurable package of standard queries for OBO projects that can be used in any ontology workflow, without requiring the maintainer to be familiar with SPARQL.		Ontology workflows typically include query operations over the ontology, producing reports which may be informative for both editors and users of the ontology, e.g., a table of all classes plus their textual definitions. Query operations can also be used for validation checks. The SPARQL query language provides a universal and declarative way for ontology maintainers to create ontology reports and validation checks.<ref name="HarrisSPARQL13">{{cite web \|url=https://www.w3.org/TR/sparql11-query/ \|title=SPARQL 1.1 Query Language \|editor=Harris, S.; Seaborne, A.; Prud'hommeaux, E. \|work=w3.org \|date=21 March 2013 \|accessdate=23 May 2019}}</ref> ROBOT provides a convenient way to perform queries with the <tt>query</tt> command, or validation checks using <tt>verify</tt>. Additionally, the <tt>report</tt> command includes a configurable package of standard queries for OBO projects that can be used in any ontology workflow, without requiring the maintainer to be familiar with SPARQL.

			====Querying====
			ROBOT’s <tt>query</tt> command runs SPARQL queries on ontologies or other RDF resources. This can be used by an ontology maintainer to either perform interactive queries, or more typically to include standard queries into an ontology workflow. The <tt>query</tt> command wraps one of the few operations that uses Apache Jena<ref name="CarrollJena04" />, rather than OWL API. The Jena API allows ROBOT to load an ontology as a collection of triples contained by an RDF Model object. It provides a SPARQL query engine for those models, which we use to run all queries.

			‘SPARQL SELECT’ queries produce a comma- or tab-separated table of results. ASK queries produce a file with a Boolean value. ‘SPARQL CONSTRUCT’ queries produce an RDF file, which can be further processed by ROBOT or merged back into the loaded ontology. ‘CONSTRUCT’s provide a convenient way of performing “macro” style expansion.<ref name="MungallTaking11">{{cite journal \|title=Taking shortcuts with OWL using safe macros \|journal=Nature Precedings \|author=Mungall, C.; Ruttenberg, A.; Osumi-Sutherland, D. \|year=2011 \|doi=10.1038/npre.2011.5292.2}}</ref ‘SPARQL UPDATE’ queries insert and/or remove data directly in an ontology (as an RDF Model). ROBOT converts the updated RDF Model back to an OWL API ontology object to be saved in any of the supported syntaxes.

			The <tt>query</tt> command supports an option to load imported ontologies as named graphs with the <tt>--use-graphs</tt> option. If this is set to <tt>true</tt>, the imports can be queried as named graphs (the name being that ontology’s IRI) and the default graph is a union of all graphs. Using the default graph is similar to conducting a <tt>merge</tt> of all the imports prior to querying, but the distinction between imports would be lost in a <tt>merge</tt>.

			====Verification====
			The <tt>verify</tt> command is a variation on the ‘SPARQL SELECT’ execution. The queries are used to ensure that an ontology conforms to a predetermined set of conditions, by, for example, ensuring that no class has multiple textual definitions. Given a SELECT query, <tt>verify</tt> will succeed (i.e., exit with status code 0) if no results are returned. It will fail (i.e., exit with a non-zero status code) if any results are return from the query. So, given a SPARQL query that SELECTs for invalid data, the <tt>verify</tt> command will verify that the ontology (or other resource) does not contain any such invalid data.

			====Reporting====
			The <tt>report</tt> command is an extension of <tt>query</tt> and <tt>verify</tt> that provides a series of configurable quality control (QC) checks for an ontology and returns a spreadsheet or YAML output of the violations. The spreadsheet is output in either comma- or tab-separated format and easy for a user to read, while the YAML output can be easily parsed by other programs.

			The QC checks include annotation checks, logical checks, and metadata checks. Annotations are important to facilitate human comprehension, so the <tt>report</tt> command finds cases where missing or duplicate annotations could cause problems. Logical checks look at the structural coherency and consistency of the ontology. Finally, <tt>report</tt> identifies missing ontology metadata, as specified by OBO Foundry recommendations.

			There are three levels of violations that are reported: ERROR, WARN, and INFO. An ERROR is the most severe, such as a missing or duplicate label. By default, the <tt>report</tt> command fails if there are any ERROR-level violations, halting any automated build processes. These types of violations must be fixed before publishing an ontology. WARN-level violations should be fixed as soon as possible, e.g., inferred one-to-one class equivalencies, which are typically unintended in OBO projects. INFO is for recommended fixes that help maintain consistency across OBO Foundry ontologies, such as beginning a definition with an uppercase letter and ending with a period. <tt>report</tt> can be configured with a command-line option to fail on a different violation level or to never fail, regardless of any violations. We document each QC check with a suggestion for a manual fix that the user can apply.

			A default “profile” with report levels for each QC check is provided by ROBOT, but users are also able to create their own profiles. In these profiles, they can change the violation levels of individual checks, choose to exclude certain checks, and add their own checks as SPARQL queries. For example, some ontologies may categorize a class lacking a textual definition as an error, while others may categorize this as a warning. One of our goals is to converge on a standard profile that is maximally useful for the set of all ontologies in the OBO library, encouraging adoption of common quality control checks.

			====Repairs====
			Although most problems raised by <tt>validate</tt> and <tt>report</tt> must be fixed manually, ROBOT also provides a <tt>repair</tt> command that can automatically fix certain problems. The current implementation will merge annotations on duplicate axioms and update references to deprecated classes when they are annotated with a suggested replacement. We intend to extend <tt>repair</tt> to a wider range of common problems for which the correct fix is clear.

			===Templated ontology development===
			ROBOT provides a template-driven ontology term generation system. Users also have the option to plug other term generation systems such as Dead Simple OWL Design Patterns (DOS-DPs)<ref name="Osumi-SutherlandDead17">{{cite journal \|title=Dead simple OWL design pattern \|journal=Journal of Biomedical Semantics \|author=Osumi-Sutherland, D.; Courtot, M.; Balhoff, J.P. et al. \|volume=8 \|issue=1 \|at=18 \|year=2017 \|doi=10.1186/s13326-017-0126-0 \|pmid=28583177 \|pmc=PMC5460348}}</ref> into their workflow.

			A huge amount of data is stored in spreadsheets and databases, and tabular formats are well suited to many sorts of data. ROBOT’s <tt>template</tt> command allows users to convert tabular data into RDF/OWL format. A ROBOT template is simply a tab-separated values (TSV) or comma-separated values (CSV) file with some special conventions, which are outlined in the ROBOT <tt>template</tt> [http://robot.obolibrary.org/template documentation].

			These templates can be used for modular ontology development. The template spreadsheets may be maintained as part of the ontology’s source code repository, and instead of directly editing the ontology file, developers edit rows in the spreadsheet which correspond to terms in the ontology. The <tt>template</tt> command is then used to generate a module of the ontology, which is included as an import statement in the editors’ version of the ontology and merged during the release process.

			===Workflows===
			A workflow consists of a set of tasks coordinated by some workflow system. Ontology workflows consist of tasks such as executing QC checks, building import modules, reasoning over ontologies, and generating various ontology release products.

			ROBOT itself is not a workflow manager, although it allows multiple commands to be chained together into one long command. When chaining ROBOT commands, the output ontology from one command is passed directly as the input to the next command. For example, chaining may be used to replace two commands that merge ontologies and then reason over the merged product:

			* <tt>robot merge --input ont-1.owl --input ont-2.owl --output merged.owl</tt>
			* <tt>robot reason --input merged.owl --output reasoned.owl</tt>

			Instead of creating the merged product and running <tt>reason</tt> over that, it can be done in one command:

			* <tt>robot merge --input ont-1.owl --input ont-2.owl reason --output reasoned.owl</tt>

			The key advantage to chaining is that ontologies do not have to be serialized and parsed between each step; the same OWL API ontology object is maintained in memory and passed through the chain of ROBOT commands. For large ontologies, chaining can vastly improve ROBOT’s performance.

			Because ROBOT commands can be executed on the command line, a number of different workflow systems can be used. We highlight the use of GNU Make<ref name="GNUMake">{{cite web \|url=https://www.gnu.org/software/make/ \|title=GNU Make \|work=GNU - Software \|accessdate=21 May 2019}}</ref>, which is typically used to compile software. A Makefile consists of a set of rules used to make “targets.” In ontology development, the Makefile is used for automated tasks such as preparing an ontology for release. In this case, the targets are usually ontology files. The “recipes” for the rules are Unix-style system commands, carried out by the <tt>make</tt> command.

			ROBOT commands can be used as the “recipes” to make the “targets.” A typical workflow will not use all 19 of the ROBOT commands. For example, not all ontology projects may use ROBOT templates and therefore not all release workflows need to include the <tt>template</tt> command. Ontology developers can decide which commands are needed to perform the release and build a workflow around those commands. Figure 1 shows a standard way in which a selection of ROBOT commands is combined for a release workflow.


			[[File:Fig1 Jackson BMCBioinformatics2019 20.png\|600px]]
			{{clear}}
			{\|
			\| STYLE="vertical-align:top;"\|
			{\| border="0" cellpadding="5" cellspacing="0" width="600px"
			\|-
			\| style="background-color:white; padding-left:10px; padding-right:10px;"\| <blockquote>'''Figure 1.''' The ROBOT release workflow. A typical release workflow using ROBOT. The ontology edit file ONT-edit.owl is first verified as a quality control check with ROBOT <tt>verify</tt>. Then, text files containing lists of external ontology terms in the imports directory are used to regenerate import modules using <tt>extract</tt>, ensuring that the imports are up-to-date. ONT-edit.owl is then passed through a series of ROBOT commands (<tt>reason</tt>, <tt>relax</tt>, <tt>reduce</tt>, and <tt>annotate</tt>) to generate the release, ONT.owl. Finally, ONT.owl is converted to OBO format.</blockquote>
			\|-
			\|}
			\|}

			First, quality control checks are run over the editors’ version of the ontology with <tt>report</tt> or <tt>verify</tt>. These look for equivalent classes, trailing whitespace in annotations, self-references, incorrect cross-reference syntax, and missing labels. The results are saved to a specified "reports/" directory. If there are any ERROR-level violations, the task will fail and write the violations to a table so that they can be easily identified. This step allows developers to quickly see if new changes have introduced any problems within the ontology and fix them before releasing.

			Assuming the initial QC check step has completed successfully, the next step is to create the import modules. The ROBOT <tt>extract</tt> is run for each entry in a list of imports, which have corresponding term files (for the seed set) in the "imports/" directory. This creates all the import modules in the same "imports/" directory. This ensures that when an ontology is released with external terms, all external terms are up-to-date with the released versions of the source ontologies. Releasing out-of-date external terms can cause confusion, as the term will show both the old and new details in ontology search services like Ontobee<ref name="XiangOntobee11" /> and the Ontology Lookup Service.<ref name="CôtéTheOnt10">{{cite journal \|title=The Ontology Lookup Service: Bigger and better \|journal=Nucleic Acids Research \|author=Côté, R.; Reisinger, F.; Martens, L. et al. \|volume=38 \|issue=WSI \|at=W155-60 \|year=2010 \|doi=10.1093/nar/gkq331 \|pmid=20460452 \|pmc=PMC2896109}}</ref> Additional QC checks can be run over the full ontology with imports using the <tt>verify</tt> command or by running <tt>report</tt> again.

			Last, the main release products are created: the OWL file and the OBO file. To create the OWL release, the editors’ file is passed through a series of chained ROBOT commands: <tt>reason</tt>, <tt>relax</tt>, <tt>reduce</tt>, and <tt>annotate</tt>. This series of commands helps to ensure that the released ontology is both easy to browse and understand, as well as free of any redundant axioms. If any of these commands fail, the Make process will terminate with the corresponding error message. For example, if an ontology is incoherent the <tt>reason</tt> step will fail. Finally, the </tt>annotate</tt> command adds the version IRI to the ontology metadata. This OWL file is then converted to OBO format, at which point all targets are copied to a dated release directory.

			===The Ontology Development Kit===

Shawndouglas: Saving and adding more.

2020-02-17T20:35:41Z

Saving and adding more.

← Older revision		Revision as of 20:35, 17 February 2020
Line 100:		Line 100:
	In order to support ontology term provenance, the <tt>extract</tt> command has an <tt>--annotate-with-source true</tt> option that will annotate each extracted term with the URL of the source ontology that it is extracted from.		In order to support ontology term provenance, the <tt>extract</tt> command has an <tt>--annotate-with-source true</tt> option that will annotate each extracted term with the URL of the source ontology that it is extracted from.

			====Removal and filtration====
			The <tt>remove</tt> and <tt>filter</tt> commands are used for fine-grained operations on OWL axioms. <tt>remove</tt> allows users to choose which sets of axioms they wish to remove from a target ontology. <tt>filter</tt> does the opposite, so that only selected axioms are copied from the input into a new output ontology.

			These two commands work by starting with a seed set of entities, then applying various selectors to find related entities, and finally selecting which axiom types to remove or filter. We expect only a small number of “power users” to use this feature directly, but these commands will eventually provide a foundation for other higher-level commands.

			These commands can be used to generate ontology subsets based on annotations by either filtering for or removing entities with the specified annotation. OBO Foundry ontologies often annotate classes with the ‘in subset’ property to specify where a class might be used. The annotation selector allows a user to provide a full annotation value or a pattern to match using regular expression.

			====Merging====
			The <tt>merge</tt> command combines two or more separate input ontologies into a single ontology. It also provides the ability to merge all imported ontologies of a single input ontology into one main ontology, which is often used when creating a release.

			Merging imported ontologies (specified by import statements) into the input ontology is performed automatically so that the user does not need to list each imported ontology as an input. We offer the option (<tt>--collapse-import-closure false<tt>) to turn this feature off, supporting cases in which users may merge multiple input ontologies that have import statements but want to keep their imports separate.

			===Querying and reporting===
			Ontology workflows typically include query operations over the ontology, producing reports which may be informative for both editors and users of the ontology, e.g., a table of all classes plus their textual definitions. Query operations can also be used for validation checks. The SPARQL query language provides a universal and declarative way for ontology maintainers to create ontology reports and validation checks.<ref name="HarrisSPARQL13">{{cite web \|url=https://www.w3.org/TR/sparql11-query/ \|title=SPARQL 1.1 Query Language \|editor=Harris, S.; Seaborne, A.; Prud'hommeaux, E. \|work=w3.org \|date=21 March 2013 \|accessdate=23 May 2019}}</ref> ROBOT provides a convenient way to perform queries with the <tt>query</tt> command, or validation checks using <tt>verify</tt>. Additionally, the <tt>report</tt> command includes a configurable package of standard queries for OBO projects that can be used in any ontology workflow, without requiring the maintainer to be familiar with SPARQL.


	~~====Extraction====~~

Shawndouglas: Saving and adding more.

2020-02-17T20:28:03Z

Saving and adding more.

← Older revision		Revision as of 20:28, 17 February 2020
Line 78:		Line 78:
	Reasoning is one of the most important operations in ROBOT. The <tt>reason</tt> command covers two uses: logical validation of an ontology and automatic classification. In both cases, users can choose their preferred reasoner, which is used to perform inference. Large ontologies such as the Gene Ontology typically use ELK<ref name="KazakovTheIncr13">{{cite journal \|title=The Incredible ELK \|journal=Journal of Automated Reasoning \|author=Kazakov, Y.; Krötzsch, M.; Simančík, F. \|volume=53 \|pages=1–61 \|year=2014 \|doi=10.1007/s10817-013-9296-3}}</ref>, which performs reasoning quickly using the OWL EL profile. Smaller ontologies with richer axiomatization, such as the Relations Ontology, typically use a complete OWL DL reasoner such as HermiT.<ref name="ShearerHermit08">{{cite journal \|title=HermiT: A Highly-Efficient OWL Reasoner \|journal=OWL: Experiences and Directions 2008 \|author=Shearer, R.; Motik, B.; Horrocks, I. \|pages=1–10 \|year=2008 \|url=http://ceur-ws.org/Vol-432/}}</ref>		Reasoning is one of the most important operations in ROBOT. The <tt>reason</tt> command covers two uses: logical validation of an ontology and automatic classification. In both cases, users can choose their preferred reasoner, which is used to perform inference. Large ontologies such as the Gene Ontology typically use ELK<ref name="KazakovTheIncr13">{{cite journal \|title=The Incredible ELK \|journal=Journal of Automated Reasoning \|author=Kazakov, Y.; Krötzsch, M.; Simančík, F. \|volume=53 \|pages=1–61 \|year=2014 \|doi=10.1007/s10817-013-9296-3}}</ref>, which performs reasoning quickly using the OWL EL profile. Smaller ontologies with richer axiomatization, such as the Relations Ontology, typically use a complete OWL DL reasoner such as HermiT.<ref name="ShearerHermit08">{{cite journal \|title=HermiT: A Highly-Efficient OWL Reasoner \|journal=OWL: Experiences and Directions 2008 \|author=Shearer, R.; Motik, B.; Horrocks, I. \|pages=1–10 \|year=2008 \|url=http://ceur-ws.org/Vol-432/}}</ref>

			When the <tt>reason</tt> command is invoked on an input ontology, ROBOT will initiate a reasoner using the OWL API Reasoner interface. The resulting inferences are checked to ensure the ontology is logically coherent: the ontology must be consistent and have no unsatisfiable classes (i.e., classes that cannot be instantiated without introducing an inconsistency). If the ontology is incoherent, this is reported and execution halts. ROBOT can optionally perform additional checks, such as ensuring that no two classes are inferred to be equivalent post-reasoning.

			If the ontology is consistent, ROBOT will perform automatic classification. All direct inferred ‘subClassOf’ axioms are added to the ontology. Generation of other types of axioms can be configured.

			The assertion of all inferred axioms is often a fundamental step in the release process for biomedical ontologies. Many of these ontology classes only assert a single named superclass (‘A subClassOf B’, where B is another class in the ontology), and zero or more anonymous superclasses and/or anonymous equivalent classes (‘A subClassOf/equivalentTo (R some B)’, where R is an object property). These anonymous classes allow the reasoner to make inferences, which are then asserted. Therefore, in the release version of an ontology, a class may have more than one named superclass.

			The <tt>reason</tt> command has additional “helper” commands. The <tt>relax</tt> command asserts entailed subClassOf axioms according to a simple structural rule: an expression ‘A equivalentTo (R some B) and …’ entails ‘A subClassOf R some B’. This can be useful as consumers of bio-ontologies often expect to navigate these expressions, e.g., partonomy in GO and Uberon. The <tt>relax</tt> command relieves the ontology developer from the need to assert these in addition to the equivalence axioms, and as such it is also often included in release workflows. Finally, the <tt>reduce</tt> command removes redundant ‘subClassOf’ axioms, and can be used after <tt>relax</tt> to remove duplicate axioms that were asserted in that step.

			The <tt>materialize</tt> command uses the Expression Materializing Reasoner (EMR) extension to assert inferred expressions of the form ‘A subClassOf R some B’.<ref name="GitHubEMR">{{cite web \|url=https://github.com/owlcollab/expression-materializing-reasoner \|title=owlcollab / expression-materializing-reasoner \|work=GitHub \|accessdate=09 October 2018}}</ref> Where the <tt>reason</tt> command asserts inferred named superclasses, <tt>materialize</tt> asserts anonymous superclasses. This is not part of the standard release cycle but can be beneficial for creating complete ontology subsets.

			===Working with external ontologies===
			The OBO Foundry aims to coordinate ontologies in a modular fashion, such that parts of some ontologies can be used as building blocks for other ontologies. For example, the ChEBI chemical entities ontology<ref name="HastingsTheChe13">{{cite journal \|title=The ChEBI reference database and ontology for biologically relevant chemistry: Enhancements for 2013 \|journal=Nucleic Acids Research \|author=Hastings, J.; de Matos, P.; Dekker, A. et al. \|volume=41 \|issue=DB1 \|pages=D456-63 \|year=2013 \|doi=10.1093/nar/gks1146 \|pmid=23180789 \|pmc=PMC3531142}}</ref> is used to construct OWL definitions for metabolic processes and activities in the Gene Ontology.<ref name="HillDove13">{{cite journal \|title=Dovetailing biology and chemistry: Integrating the Gene Ontology with the ChEBI chemical ontology \|journal=BMC Genomics \|author=Hill, D.P.; Adams, N.; Bada, M.A. et al. \|volume=14 \|at=513 \|year=2013 \|doi=10.1186/1471-2164-14-513 \|pmid=23895341 \|pmc=PMC3733925}}</ref> There are a variety of different strategies for leveraging external ontologies and managing dependencies between ontologies, depending on the use case.

			====Extractions====
			The <tt>extract</tt> command creates a module based on a set of entities to extract (the “seed”). There are four different extraction methods (as specified by the <tt>--method</tt> option): MIREOT, TOP, BOT, and STAR.

			ROBOT’s MIREOT extraction method is based on the principle of the same name<ref name="CourtotMIREOT11" /> and requires that one or more “bottom” entities are specified. Optionally, one or more “top” entities can also be specified. The command extracts all the “bottom” level entities and their ancestors up to the “top” level from the input ontology. If no “top” entities are provided, ancestors up to the top-level entity (‘owl: Thing’) are included.

			The TOP, BOT, and STAR methods make use of the OWL API Syntactic Locality Module Extraction (SLME) implementation, which is guaranteed to capture all [[information]] logically relevant to the seed set.<ref name="GrauModular08">{{cite journal \|title=Modular Reuse of Ontologies: Theory and Practice \|journal=Journal of Artificial Intelligence Research \|author=Grau, B.C.; Horrocks, I.; Kazakov, Y. et al. \|volume=31 \|pages=273–318 \|year=2008 \|doi=10.1613/jair.2375}}</ref> The BOT method (“bottom”) includes all relationships between the input entities and their ancestors. The TOP method includes all relationships between the input entities and their descendants. Finally, the STAR method only includes all relationships between input entities. The STAR method produces the smallest outputs, while the TOP method typically produces the largest outputs.

			In order to support ontology term provenance, the <tt>extract</tt> command has an <tt>--annotate-with-source true</tt> option that will annotate each extracted term with the URL of the source ontology that it is extracted from.



			====Extraction====

Shawndouglas: Saving and adding more.

2020-02-17T19:29:58Z

Saving and adding more.

← Older revision		Revision as of 19:29, 17 February 2020
Line 58:		Line 58:
	==Implementation==		==Implementation==
	===Overview===		===Overview===
	ROBOT provides a standardized yet configurable way to support the ontology development lifecycle via a library of common high-level functionality and a command-line interface. ROBOT builds on OWL API and is compatible with all ontology syntaxes that OWL API supports: RDF/XML, OWL/XML, Turtle, OWL Functional Syntax, OWL Manchester Syntax, and OBO format. The source code is written in Java and is available from our GitHub repository<ref name="GitHubROBOT">{{cite web \|url=https://github.com/ontodev/robot \|title=ontodev / robot \|work=GitHub \|accessdate=09 October 2018}}</ref> under an open source (BSD 3) license. It is also released as a Java library on Maven Central. ROBOT code can be used from any programming language that runs on the Java Virtual Machine (JVM). The command-line tool is packaged as a JAR file that can be run on Unix (including macOS and Linux), Windows, and other platforms supported by the JVM. This JAR file is available for download from the ROBOT GitHub site<ref name="~~GitHubRobot~~" />, along with platform-specific scripts for using ROBOT from the command line. Installation instructions and documentation are available from the [http://robot.obolibrary.org/ OBO Library].		ROBOT provides a standardized yet configurable way to support the ontology development lifecycle via a library of common high-level functionality and a command-line interface. ROBOT builds on OWL API and is compatible with all ontology syntaxes that OWL API supports: RDF/XML, OWL/XML, Turtle, OWL Functional Syntax, OWL Manchester Syntax, and OBO format. The source code is written in Java and is available from our GitHub repository<ref name="GitHubROBOT">{{cite web \|url=https://github.com/ontodev/robot \|title=ontodev / robot \|work=GitHub \|accessdate=09 October 2018}}</ref> under an open source (BSD 3) license. It is also released as a Java library on Maven Central. ROBOT code can be used from any programming language that runs on the Java Virtual Machine (JVM). The command-line tool is packaged as a JAR file that can be run on Unix (including macOS and Linux), Windows, and other platforms supported by the JVM. This JAR file is available for download from the ROBOT GitHub site<ref name="GitHubROBOT" />, along with platform-specific scripts for using ROBOT from the command line. Installation instructions and documentation are available from the [http://robot.obolibrary.org/ OBO Library].

	===Architecture===		===Architecture===
Line 66:		Line 66:

	Most ROBOT operations package low-level functionality provided by OWL API into high-level functionality common to ontology development workflows in the OBO community. For best compatibility, we aim to match the exact version of OWL API used by ROBOT with the exact version used by the latest Protégé release. Some operations use Apache Jena.<ref name="CarrollJena04">{{cite journal \|title=Jena: Implementing the semantic web recommendations \|journal=WWW Alt. '04: Proceedings of the 13th international World Wide Web conference on Alternate track papers & posters \|author=Carroll, J.J.; Dickinson. I.; Dollin, C. et al. \|pages=74–83 \|year=2004 \|doi=10.1145/1013367.1013381}}</ref> Each operation works with Java objects that represent OWL ontologies, OWL reasoners, OWL classes, etc., while each command works with command-line option strings and files. The commands also perform various conversion and validation steps. The command-line interface uses the Apache Commons CLI library<ref name="ApacheCommons">{{cite web \|url=https://commons.apache.org/proper/commons-cli/ \|title=Commons CLI \|work=Apache Commons \|accessdate=23 May 2019}}</ref> for parsing commands.		Most ROBOT operations package low-level functionality provided by OWL API into high-level functionality common to ontology development workflows in the OBO community. For best compatibility, we aim to match the exact version of OWL API used by ROBOT with the exact version used by the latest Protégé release. Some operations use Apache Jena.<ref name="CarrollJena04">{{cite journal \|title=Jena: Implementing the semantic web recommendations \|journal=WWW Alt. '04: Proceedings of the 13th international World Wide Web conference on Alternate track papers & posters \|author=Carroll, J.J.; Dickinson. I.; Dollin, C. et al. \|pages=74–83 \|year=2004 \|doi=10.1145/1013367.1013381}}</ref> Each operation works with Java objects that represent OWL ontologies, OWL reasoners, OWL classes, etc., while each command works with command-line option strings and files. The commands also perform various conversion and validation steps. The command-line interface uses the Apache Commons CLI library<ref name="ApacheCommons">{{cite web \|url=https://commons.apache.org/proper/commons-cli/ \|title=Commons CLI \|work=Apache Commons \|accessdate=23 May 2019}}</ref> for parsing commands.

			Each operation has a set of unit tests, built with JUnit<ref name="JUnit">{{cite web \|url=https://junit.org/junit4/ \|title=JUnit \|work=junit.org \|accessdate=21 May 2019}}</ref>, that are executed each time the final product (the JAR file) is generated. Each command in ROBOT is documented in its own web page (e.g., [http://robot.obolibrary.org/reason http://robot.obolibrary.org/reason]). The web pages are authored in Markdown format and contain embedded command-line examples that are parsed and executed as part of our integration tests, with the results compared against a “gold standard” set of outputs. ROBOT’s ‘diff’ functionality is used when comparing ontology files, otherwise standard file comparison is used. This helps ensure correctness and consistency of documentation and code. The unit tests and integration tests are executed on any pull request onto the codebase via Travis continuous integration (Travis CI)<ref name="TravisCI">{{cite web \|url=https://travis-ci.org/ \|title=Travis CI \|publisher=Travis CI, GmbH \|accessdate=21 May 2019}}</ref> so that contributions to the codebase are verified.

			===Commands and operations===
			ROBOT currently provides 15 operations (in the ‘robot-core’ library) and 19 commands (for the command-line interface). Some commands are quite specialized, and most ontology projects will not make use of all of them. Here we provide an overview of the most common and general commands. In each case, the core functionality is supported by operations in the ‘robot-core’ library, that can be used independently of the command-line interface from any programming language that runs on the JVM.

			====Conversion====
			A variety of OWL ontology formats are supported, including RDF/XML, Turtle, Manchester, OBO format, and more. To enable further interoperability, ROBOT includes a <tt>convert</tt> command to change between supported ontology formats. A complete list of supported formats can be found in the <tt>convert</tt> [http://robot.obolibrary.org/convert documentation].

			====Reasoning====
			Reasoning is one of the most important operations in ROBOT. The <tt>reason</tt> command covers two uses: logical validation of an ontology and automatic classification. In both cases, users can choose their preferred reasoner, which is used to perform inference. Large ontologies such as the Gene Ontology typically use ELK<ref name="KazakovTheIncr13">{{cite journal \|title=The Incredible ELK \|journal=Journal of Automated Reasoning \|author=Kazakov, Y.; Krötzsch, M.; Simančík, F. \|volume=53 \|pages=1–61 \|year=2014 \|doi=10.1007/s10817-013-9296-3}}</ref>, which performs reasoning quickly using the OWL EL profile. Smaller ontologies with richer axiomatization, such as the Relations Ontology, typically use a complete OWL DL reasoner such as HermiT.<ref name="ShearerHermit08">{{cite journal \|title=HermiT: A Highly-Efficient OWL Reasoner \|journal=OWL: Experiences and Directions 2008 \|author=Shearer, R.; Motik, B.; Horrocks, I. \|pages=1–10 \|year=2008 \|url=http://ceur-ws.org/Vol-432/}}</ref>

Shawndouglas: Saving and adding more.

2020-02-17T19:05:52Z

Saving and adding more.

← Older revision		Revision as of 19:05, 17 February 2020
Line 52:		Line 52:
	Slimmer<ref name="GitHubSlimmer">{{cite web \|url=https://github.com/enanomapper/slimmer/ \|title=enanomapper / slimmer \|work=GitHub \|accessdate=21 May 2019}}</ref>, created as part of the eNanoMapper ontology project<ref name="HastingsEnano15">{{cite journal \|title=eNanoMapper: harnessing ontologies to enable data integration for nanomaterial risk assessment \|journal=Journal of Biomedical Semantics \|author=Hastings, J.; Jeliazkova, N.; Owen, G. et al. \|volume=6 \|at=10 \|year=2015 \|doi=10.1186/s13326-015-0005-5 \|pmid=25815161 \|pmc=PMC4374589}}</ref>, uses OWL API to create ontology subsets (also known as “slims”). A configuration file allows the user to specify which terms to include and which annotations to include on those terms. OntoPilot<ref name="StuckyOnto17">{{cite journal \|title=OntoPilot: New Software to Simplify and Accelerate Ontology Development and Deployment \|journal=Biodiversity Information Science and Standards \|author=Stucky, B.J.; Luc, A. \|volume=1 \|at=e20192 \|year=2017 \|doi=10.3897/tdwgproceedings.1.20192}}</ref>, developed for the Plant Phenotype Ontology, uses OWL API via Jython (a version of Python that runs on the Java Virtual Machine) to provide an integrated ontology development framework, including term imports, term creation, releases, and documentation.		Slimmer<ref name="GitHubSlimmer">{{cite web \|url=https://github.com/enanomapper/slimmer/ \|title=enanomapper / slimmer \|work=GitHub \|accessdate=21 May 2019}}</ref>, created as part of the eNanoMapper ontology project<ref name="HastingsEnano15">{{cite journal \|title=eNanoMapper: harnessing ontologies to enable data integration for nanomaterial risk assessment \|journal=Journal of Biomedical Semantics \|author=Hastings, J.; Jeliazkova, N.; Owen, G. et al. \|volume=6 \|at=10 \|year=2015 \|doi=10.1186/s13326-015-0005-5 \|pmid=25815161 \|pmc=PMC4374589}}</ref>, uses OWL API to create ontology subsets (also known as “slims”). A configuration file allows the user to specify which terms to include and which annotations to include on those terms. OntoPilot<ref name="StuckyOnto17">{{cite journal \|title=OntoPilot: New Software to Simplify and Accelerate Ontology Development and Deployment \|journal=Biodiversity Information Science and Standards \|author=Stucky, B.J.; Luc, A. \|volume=1 \|at=e20192 \|year=2017 \|doi=10.3897/tdwgproceedings.1.20192}}</ref>, developed for the Plant Phenotype Ontology, uses OWL API via Jython (a version of Python that runs on the Java Virtual Machine) to provide an integrated ontology development framework, including term imports, term creation, releases, and documentation.

	The lack of automation seen circa 2010 led directly to a lack of standardization, with each ontology editor or group adopting a slightly different approach to manual editing in Protégé. This diversity of practices, even within the OBO community, made it a challenge to develop tools to serve multiple ontology projects. OWLTools<ref name="GitHubOwlTools">{{cite web \|url=https://github.com/owlcollab/owltools \|title=owlcollab / owltools \|work=GitHub \|accessdate=21 May 2019}}</ref> was designed for use by multiple OBO ontology projects, providing convenience methods on top of the OWL API. OWLTools includes the OBO Ontology Release Tool (OORT)<ref name="GitHubOwlTools">{{cite web \|url=https://github.com/owlcollab/owltools/wiki/Oort-Intro \|title=owlcollab / owltools : Oort Intro \|work=GitHub \|accessdate=21 May 2019}}</ref>, a command-line tool to release OWL- and OBO-format ontologies. OORT provides a series of basic commands to create a release pipeline for an ontology, including module extraction with MIREOT, support for multiple input ontologies, reasoning, and creation of "main" and "simple" release products.		The lack of automation seen circa 2010 led directly to a lack of standardization, with each ontology editor or group adopting a slightly different approach to manual editing in Protégé. This diversity of practices, even within the OBO community, made it a challenge to develop tools to serve multiple ontology projects. OWLTools<ref name="GitHubOwlTools">{{cite web \|url=https://github.com/owlcollab/owltools \|title=owlcollab / owltools \|work=GitHub \|accessdate=21 May 2019}}</ref> was designed for use by multiple OBO ontology projects, providing convenience methods on top of the OWL API. OWLTools includes the OBO Ontology Release Tool (OORT)<ref name="GitHubOwlTools-Oort">{{cite web \|url=https://github.com/owlcollab/owltools/wiki/Oort-Intro \|title=owlcollab / owltools : Oort Intro \|work=GitHub \|accessdate=21 May 2019}}</ref>, a command-line tool to release OWL- and OBO-format ontologies. OORT provides a series of basic commands to create a release pipeline for an ontology, including module extraction with MIREOT, support for multiple input ontologies, reasoning, and creation of "main" and "simple" release products.

	ROBOT (a recursive acronym for “ROBOT is an OBO Tool”) was developed to replace OWLTools and OORT with a more modular and maintainable code base. It builds on previous experience to include a comprehensive set of automation capabilities to support an even wider range of OBO projects. Development began in 2015 and continues today, with more than 1000 commits from a dozen contributors. ROBOT is freely available open-source software. Although we do not track our users, a recent GitHub search shows that at least 26 ontology projects in the OBO community have adopted ROBOT.		ROBOT (a recursive acronym for “ROBOT is an OBO Tool”) was developed to replace OWLTools and OORT with a more modular and maintainable code base. It builds on previous experience to include a comprehensive set of automation capabilities to support an even wider range of OBO projects. Development began in 2015 and continues today, with more than 1000 commits from a dozen contributors. ROBOT is freely available open-source software. Although we do not track our users, a recent GitHub search shows that at least 26 ontology projects in the OBO community have adopted ROBOT.
Line 58:		Line 58:
	==Implementation==		==Implementation==
	===Overview===		===Overview===
			ROBOT provides a standardized yet configurable way to support the ontology development lifecycle via a library of common high-level functionality and a command-line interface. ROBOT builds on OWL API and is compatible with all ontology syntaxes that OWL API supports: RDF/XML, OWL/XML, Turtle, OWL Functional Syntax, OWL Manchester Syntax, and OBO format. The source code is written in Java and is available from our GitHub repository<ref name="GitHubROBOT">{{cite web \|url=https://github.com/ontodev/robot \|title=ontodev / robot \|work=GitHub \|accessdate=09 October 2018}}</ref> under an open source (BSD 3) license. It is also released as a Java library on Maven Central. ROBOT code can be used from any programming language that runs on the Java Virtual Machine (JVM). The command-line tool is packaged as a JAR file that can be run on Unix (including macOS and Linux), Windows, and other platforms supported by the JVM. This JAR file is available for download from the ROBOT GitHub site<ref name="GitHubRobot" />, along with platform-specific scripts for using ROBOT from the command line. Installation instructions and documentation are available from the [http://robot.obolibrary.org/ OBO Library].

			===Architecture===
			We previously described the basic architecture of the tool<ref name="OvertonROBOT15">{{cite journal \|title=ROBOT: A command-line tool for ontology development \|journal=Proceedings of the 2015 International Conference on Biomedical Ontology \|author=Overton, J.A.; Dietze, H.; Essaid, S. et al. \|pages=1–2 \|year=2015 \|url=http://ceur-ws.org/Vol-1515/}}</ref>, which we summarize here.

			The ROBOT source code consists of two parts: ‘robot-core’ and ‘robot-command.’ ‘robot-core’ is a library supporting common ontology development tasks, which we call “operations.” ‘robot-command’ provides a command-line interface divided into “commands,” each of which wraps a ‘robot-core’ operation.

			Most ROBOT operations package low-level functionality provided by OWL API into high-level functionality common to ontology development workflows in the OBO community. For best compatibility, we aim to match the exact version of OWL API used by ROBOT with the exact version used by the latest Protégé release. Some operations use Apache Jena.<ref name="CarrollJena04">{{cite journal \|title=Jena: Implementing the semantic web recommendations \|journal=WWW Alt. '04: Proceedings of the 13th international World Wide Web conference on Alternate track papers & posters \|author=Carroll, J.J.; Dickinson. I.; Dollin, C. et al. \|pages=74–83 \|year=2004 \|doi=10.1145/1013367.1013381}}</ref> Each operation works with Java objects that represent OWL ontologies, OWL reasoners, OWL classes, etc., while each command works with command-line option strings and files. The commands also perform various conversion and validation steps. The command-line interface uses the Apache Commons CLI library<ref name="ApacheCommons">{{cite web \|url=https://commons.apache.org/proper/commons-cli/ \|title=Commons CLI \|work=Apache Commons \|accessdate=23 May 2019}}</ref> for parsing commands.




	==References==		==References==

Shawndouglas: Saving and adding more.

2020-02-17T18:21:02Z

Saving and adding more.

← Older revision		Revision as of 18:21, 17 February 2020
Line 52:		Line 52:
	Slimmer<ref name="GitHubSlimmer">{{cite web \|url=https://github.com/enanomapper/slimmer/ \|title=enanomapper / slimmer \|work=GitHub \|accessdate=21 May 2019}}</ref>, created as part of the eNanoMapper ontology project<ref name="HastingsEnano15">{{cite journal \|title=eNanoMapper: harnessing ontologies to enable data integration for nanomaterial risk assessment \|journal=Journal of Biomedical Semantics \|author=Hastings, J.; Jeliazkova, N.; Owen, G. et al. \|volume=6 \|at=10 \|year=2015 \|doi=10.1186/s13326-015-0005-5 \|pmid=25815161 \|pmc=PMC4374589}}</ref>, uses OWL API to create ontology subsets (also known as “slims”). A configuration file allows the user to specify which terms to include and which annotations to include on those terms. OntoPilot<ref name="StuckyOnto17">{{cite journal \|title=OntoPilot: New Software to Simplify and Accelerate Ontology Development and Deployment \|journal=Biodiversity Information Science and Standards \|author=Stucky, B.J.; Luc, A. \|volume=1 \|at=e20192 \|year=2017 \|doi=10.3897/tdwgproceedings.1.20192}}</ref>, developed for the Plant Phenotype Ontology, uses OWL API via Jython (a version of Python that runs on the Java Virtual Machine) to provide an integrated ontology development framework, including term imports, term creation, releases, and documentation.		Slimmer<ref name="GitHubSlimmer">{{cite web \|url=https://github.com/enanomapper/slimmer/ \|title=enanomapper / slimmer \|work=GitHub \|accessdate=21 May 2019}}</ref>, created as part of the eNanoMapper ontology project<ref name="HastingsEnano15">{{cite journal \|title=eNanoMapper: harnessing ontologies to enable data integration for nanomaterial risk assessment \|journal=Journal of Biomedical Semantics \|author=Hastings, J.; Jeliazkova, N.; Owen, G. et al. \|volume=6 \|at=10 \|year=2015 \|doi=10.1186/s13326-015-0005-5 \|pmid=25815161 \|pmc=PMC4374589}}</ref>, uses OWL API to create ontology subsets (also known as “slims”). A configuration file allows the user to specify which terms to include and which annotations to include on those terms. OntoPilot<ref name="StuckyOnto17">{{cite journal \|title=OntoPilot: New Software to Simplify and Accelerate Ontology Development and Deployment \|journal=Biodiversity Information Science and Standards \|author=Stucky, B.J.; Luc, A. \|volume=1 \|at=e20192 \|year=2017 \|doi=10.3897/tdwgproceedings.1.20192}}</ref>, developed for the Plant Phenotype Ontology, uses OWL API via Jython (a version of Python that runs on the Java Virtual Machine) to provide an integrated ontology development framework, including term imports, term creation, releases, and documentation.

			The lack of automation seen circa 2010 led directly to a lack of standardization, with each ontology editor or group adopting a slightly different approach to manual editing in Protégé. This diversity of practices, even within the OBO community, made it a challenge to develop tools to serve multiple ontology projects. OWLTools<ref name="GitHubOwlTools">{{cite web \|url=https://github.com/owlcollab/owltools \|title=owlcollab / owltools \|work=GitHub \|accessdate=21 May 2019}}</ref> was designed for use by multiple OBO ontology projects, providing convenience methods on top of the OWL API. OWLTools includes the OBO Ontology Release Tool (OORT)<ref name="GitHubOwlTools">{{cite web \|url=https://github.com/owlcollab/owltools/wiki/Oort-Intro \|title=owlcollab / owltools : Oort Intro \|work=GitHub \|accessdate=21 May 2019}}</ref>, a command-line tool to release OWL- and OBO-format ontologies. OORT provides a series of basic commands to create a release pipeline for an ontology, including module extraction with MIREOT, support for multiple input ontologies, reasoning, and creation of "main" and "simple" release products.

			ROBOT (a recursive acronym for “ROBOT is an OBO Tool”) was developed to replace OWLTools and OORT with a more modular and maintainable code base. It builds on previous experience to include a comprehensive set of automation capabilities to support an even wider range of OBO projects. Development began in 2015 and continues today, with more than 1000 commits from a dozen contributors. ROBOT is freely available open-source software. Although we do not track our users, a recent GitHub search shows that at least 26 ontology projects in the OBO community have adopted ROBOT.

			==Implementation==
			===Overview===

	==References==		==References==

Shawndouglas: Saving and adding more.

2020-02-17T18:15:44Z

Saving and adding more.

← Older revision		Revision as of 18:15, 17 February 2020
Line 45:		Line 45:

	Other than Protégé, the most prominent suite of tools used by the OBO community has been the Onto-animal suite, developed by the He Group<ref name="HeOnto-Animal15">{{cite journal \|title=Onto-animal tools for reusing ontologies, generating and editing ontology terms, and dereferencing ontology terms \|journal=Proceedings of the 2015 International Conference on Biomedical Ontology \|author=He, Y.; Zheng, J.; Lin, Y. \|pages=1–2 \|year=2015 \|url=http://ceur-ws.org/Vol-1515/}}</ref>, which includes Ontobee<ref name="XiangOntobee11">{{cite journal \|title=Ontobee: A Linked Data Server and Browser for Ontology Terms \|journal=Proceedings of the Second International Conference on Biomedical Ontology \|author=Xiang, Z.; Mungall, C.; Ruttenberg, A. et al. \|pages=279–81 \|year=2012 \|url=http://ceur-ws.org/Vol-833/}}</ref>, Ontofox<ref name="XiangOntoFox10">{{cite journal \|title=OntoFox: Web-based support for ontology reuse \|journal=BMC Research Notes \|author=Xiang, Z.; Courtot, M.; Brinkman, R.R. et al. \|volume=3 \|at=175 \|year=2010 \|doi=10.1186/1756-0500-3-175 \|pmid=20569493 \|pmc=PMC2911465}}</ref>, and Ontorat.<ref name="XiangOntoRat15">{{cite journal \|title=Ontorat: Automatic generation of new ontology terms, annotations, and axioms based on ontology design patterns \|journal=Journal of Biomedical Semantics \|author=Xiang, Z.; Zheng, J.; Lin. Y. et al. \|volume=6 \|at=4 \|year=2015 \|doi=10.1186/2041-1480-6-4 \|pmid=25785185 \|pmc=PMC4362828}}</ref> These tools are free web services backed by a Virtuoso [[wikipedia:Triplestore\|triplestore]] loaded with the latest version of all available OBO community ontologies, as well as some other ontologies. Ontobee is an ontology term browser. Ontofox implements the MIREOT term extraction method.<ref name="CourtotMIREOT11">{{cite journal \|title=MIREOT: The minimum information to reference an external ontology term \|journal=Applied Ontology \|author=Courtot, M.; Gibson, F.; Lister, A. L. et al. \|volume=6 \|issue=1 \|pages=23–33 \|year=2011 \|doi=10.3233/AO-2011-0087}}</ref> Ontorat implements template-based ontology term creation. Together with a few other tools, these support an extensible ontology development strategy<ref name="HeTheExt18">{{cite journal \|title=The eXtensible ontology development (XOD) principles and tool implementation to support ontology interoperabilitye \|journal=Journal of Biomedical Semantics \|author=He, Y.; Xiang, Z.; Zheng, J. et al. \|volume=9 \|at=3 \|year=2018 \|doi=10.1186/s13326-017-0169-2}}</ref> covering a range of ontology development tasks, many of which can combined and automated using a sequence of web-based [[application programming interface]] (API) calls.		Other than Protégé, the most prominent suite of tools used by the OBO community has been the Onto-animal suite, developed by the He Group<ref name="HeOnto-Animal15">{{cite journal \|title=Onto-animal tools for reusing ontologies, generating and editing ontology terms, and dereferencing ontology terms \|journal=Proceedings of the 2015 International Conference on Biomedical Ontology \|author=He, Y.; Zheng, J.; Lin, Y. \|pages=1–2 \|year=2015 \|url=http://ceur-ws.org/Vol-1515/}}</ref>, which includes Ontobee<ref name="XiangOntobee11">{{cite journal \|title=Ontobee: A Linked Data Server and Browser for Ontology Terms \|journal=Proceedings of the Second International Conference on Biomedical Ontology \|author=Xiang, Z.; Mungall, C.; Ruttenberg, A. et al. \|pages=279–81 \|year=2012 \|url=http://ceur-ws.org/Vol-833/}}</ref>, Ontofox<ref name="XiangOntoFox10">{{cite journal \|title=OntoFox: Web-based support for ontology reuse \|journal=BMC Research Notes \|author=Xiang, Z.; Courtot, M.; Brinkman, R.R. et al. \|volume=3 \|at=175 \|year=2010 \|doi=10.1186/1756-0500-3-175 \|pmid=20569493 \|pmc=PMC2911465}}</ref>, and Ontorat.<ref name="XiangOntoRat15">{{cite journal \|title=Ontorat: Automatic generation of new ontology terms, annotations, and axioms based on ontology design patterns \|journal=Journal of Biomedical Semantics \|author=Xiang, Z.; Zheng, J.; Lin. Y. et al. \|volume=6 \|at=4 \|year=2015 \|doi=10.1186/2041-1480-6-4 \|pmid=25785185 \|pmc=PMC4362828}}</ref> These tools are free web services backed by a Virtuoso [[wikipedia:Triplestore\|triplestore]] loaded with the latest version of all available OBO community ontologies, as well as some other ontologies. Ontobee is an ontology term browser. Ontofox implements the MIREOT term extraction method.<ref name="CourtotMIREOT11">{{cite journal \|title=MIREOT: The minimum information to reference an external ontology term \|journal=Applied Ontology \|author=Courtot, M.; Gibson, F.; Lister, A. L. et al. \|volume=6 \|issue=1 \|pages=23–33 \|year=2011 \|doi=10.3233/AO-2011-0087}}</ref> Ontorat implements template-based ontology term creation. Together with a few other tools, these support an extensible ontology development strategy<ref name="HeTheExt18">{{cite journal \|title=The eXtensible ontology development (XOD) principles and tool implementation to support ontology interoperabilitye \|journal=Journal of Biomedical Semantics \|author=He, Y.; Xiang, Z.; Zheng, J. et al. \|volume=9 \|at=3 \|year=2018 \|doi=10.1186/s13326-017-0169-2}}</ref> covering a range of ontology development tasks, many of which can combined and automated using a sequence of web-based [[application programming interface]] (API) calls.

			The core operations of the Onto-Animal suite are driven by SPARQL queries against the centralized triplestore. This results in a number of limitations. First, only the specific version of each ontology loaded into that triplestore can be used. This is a particularly severe limitation during ontology development. Second, processing is done on the centralized server, limiting the processing power available to any user. Third, SPARQL has limited utility when working with OWL logical axioms.

			These limitations are mitigated by running software locally, loading the desired versions of the desired ontologies, and using OWL API<ref name="HorridgeIgnit07">{{cite journal \|title=Igniting the OWL 1.1 Touch Paper: The OWL API \|journal=OWL: Experiences and Directions 2007 \|author=Horridge, M.; Bechhofer, S.; Noppens, O. \|pages=1–9 \|year=2007 \|url=http://webont.org/owled/2007/Proceedings.html}}</ref> for OWL-native processing. A number of tools used in the OBO community have done precisely this. We have seen a spectrum of development, from tools that are focused on a single project, to tools used by a dozen related projects, to the current push for tools that are shared across the OBO community.

			Slimmer<ref name="GitHubSlimmer">{{cite web \|url=https://github.com/enanomapper/slimmer/ \|title=enanomapper / slimmer \|work=GitHub \|accessdate=21 May 2019}}</ref>, created as part of the eNanoMapper ontology project<ref name="HastingsEnano15">{{cite journal \|title=eNanoMapper: harnessing ontologies to enable data integration for nanomaterial risk assessment \|journal=Journal of Biomedical Semantics \|author=Hastings, J.; Jeliazkova, N.; Owen, G. et al. \|volume=6 \|at=10 \|year=2015 \|doi=10.1186/s13326-015-0005-5 \|pmid=25815161 \|pmc=PMC4374589}}</ref>, uses OWL API to create ontology subsets (also known as “slims”). A configuration file allows the user to specify which terms to include and which annotations to include on those terms. OntoPilot<ref name="StuckyOnto17">{{cite journal \|title=OntoPilot: New Software to Simplify and Accelerate Ontology Development and Deployment \|journal=Biodiversity Information Science and Standards \|author=Stucky, B.J.; Luc, A. \|volume=1 \|at=e20192 \|year=2017 \|doi=10.3897/tdwgproceedings.1.20192}}</ref>, developed for the Plant Phenotype Ontology, uses OWL API via Jython (a version of Python that runs on the Java Virtual Machine) to provide an integrated ontology development framework, including term imports, term creation, releases, and documentation.