Plow - Ontology package manager

Plow is package management solution for OWL ontologies, with support for specifying dependencies between packages via SemVer ranges.

Getting started - Installation

CLI

The CLI supports basic commands related to consuming and producing ontologies. It is suitable for both manual and automated workflows (e.g. metadata linting in CI)

To install our prebuilt binaries (available for Linux and macOS), run:

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/field33/plow/releases/download/plow_cli-v0.5.2/plow_cli-installer.sh | sh

You can also install from source via:

cargo install plow_cli

Prebuilt binaries are coming soon!

GUI

The plow_gui crate is obsolete and usage of it is discouraged.

A new ontology editor is in the works, and will be released as a separate project.

Basic usage

Login with Plow

The tooling currently expects you to be authenticated with the public plow registry (open issue). Please sign in, creating an account here and create a new api token in your account settings.

plow login <api-token>

Initialize workspace

Create the directory you want to organize your fields (= ontologies) in.

# Create workspace directory
mkdir example_workspace && cd example_workspace

# Crate your first field (.ttl file), or copy existing fields into the workspace
plow init --field @example_namespace/example_name

# To initialize a workspace run
plow init

Initialize a new field (= ontology)

Example 1

To create a new field with all the necessary metadata run:

plow init --field @example_namespace/example_name

Example 2

When run under an initialized workspace, this will create the relevant folder structure in the fields directory:

├── Plow.toml
└── fields
    └── @example_namespace
        └── example_fieldname.ttl

Example 3

If run outside of a workspace, it will create a new .ttl file in the current directory.

├── example_fieldname.ttl

Running plow init without the --field flag initializes a new workspace and if run after this, results would look like Example 1.

Open a field in protege

If you'd like to open an edit a field in protege, you may use the following command:

# Continuing with the upper example
plow protege example_fieldname.ttl

If you have protege installed in your system and if your field does not have parsing errors, this command will,

• Resolve the dependencies in your field if any dependencies are present.
• Inject them to your original field as owl:imports annotations.
• Make a protege_workspaces directory in ~/Documents/plow, copy your dependencies and hard link your field there.
• The changes to your field in protege will reflect to your original field permanently.

Submit a field to the registry

To prepare for submitting a new field run the following command:

# Public submission
plow submit <path-to-your-field> --dry-run

# Private submission
plow submit --private <path-to-your-field> --dry-run

The --dry-run flag will indicate our backend to go through the submission pipeline and pre-submission checks but not finalize the submission. If all checks pass you can omit the --dry-run flag and submit your field by running:

# Public submission
plow submit <path-to-your-field>

# Private submission
plow submit --private <path-to-your-field>

Repository contents

• plow_cli - CLI
• plow_gui - GUI
• plow_linter - Linter library (included in CLI/GUI)
• plow_package_management - Core logic of the package management
• plow_ontology - Representation of an ontology package and related helpers
• plow_graphify - Bridge to parse ontologies based on harriet
• plow_backend_reference - Reference implementation of the registry service

Reference implementation and registry.field33.com

We provide a reference implementation of the registry service under plow_backend_reference. The implementation documents and showcases all the REST API endpoints required for package management, but some of the functionality is only implemented in a limited fashio. E.g. it does not persist any data between process restarts, and doesn't include any authentication/authorization, making it unfit for production usage.

For production usage, we provide a hosted registry with a web UI at registry.field33.com. As the underlying codebase is strongly connected to other parts of our products, it is currently not viable for us to maintain the registry publicly, but that may change in the future.

Citing

If you use Plow in the context of a published academic piece of work, please consider citing:

@incollection{Plow,
  title = {Plow: A Novel Approach to Interlinking Modular Ontologies Based on Software Package Management},
  doi = {10.3233/ssw220015},
  url = {https://doi.org/10.3233/ssw220015},
  year = {2022},
  month = sep,
  publisher = {{IOS} Press},
  author = {Maximilian Goisser and Daniel Fiebig and Sebastian Wohlrapp and Georg Rehm},
  booktitle = {Towards a Knowledge-Aware {AI}}
}

Contributing

We are happy about any contributions!

To get started you can take a look at our Github issues.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed as below, without any additional terms or conditions.

License

Licensed under either of

• Apache License, Version 2.0, (LICENSE-APACHE or http://www.apache.org/licenses/LICENSE-2.0)
• MIT license (LICENSE-MIT or http://opensource.org/licenses/MIT)

lib.rs:

Package management

In our dependency management system, there are 4 main "artifacts"

• The input ontology file
• The ontology metadata (extracted from the ontology file), which includes among others:
  • The name of the ontology
  • The version of the ontology
  • The dependencies of the ontology (name + version specification of each)
• The dependency lockfile (generated from the metadata + data from the registry), which contains a set of resolved dependencies
• The materialized workspace (generated from lockfile + downloads from registry):
  • Modified input ontology file that contains OWL imports to the specified dependencies
  • Downloaded dependencies
  • Catalog file, that helps Protege to find the downloaded dependencies

Process

For a full documentation of the package management process see doc_process.