Ontoshire

Imports & dependencies

How Ontoshire discovers an ontology’s owl:imports, resolves each target to a hosted version when one exists, and lets you download or reuse what it finds — across visibility boundaries, name collisions, and forks.

What counts as a dependency#

At ingestion time, alongside validating and storing your ontology, Ontoshire extracts three facts about the version: its own declared IRI (the owl:Ontology subject), its owl:versionIRI if it declares one, and every IRI-valued owl:imports target. (Blank-node import targets aren’t valid IRIs and are ignored.) These are stored as small, separate facts about the version — not part of your ontology’s own graph — and are what every dependency lookup on this page reads from.

Exact-IRI matching — deliberately no normalization#

An import target is resolved by exact string comparison against every published version’s declared IRI, per RDF’s own identity rule (two IRIs are the same resource only if they’re the same string). Ontoshire does not trim trailing slashes, add or strip fragments, or otherwise guess:

these are three different IRIs to Ontoshire
http://example.org/health
http://example.org/health/
http://example.org/health#

This is a deliberate trade-off, not an oversight: a fuzzy match that’s wrong would bundle the wrong file into someone’s download or silently point their import at the wrong ontology. A near-miss renders as external / unresolved (below) rather than a guessed match. If your ontology imports something and it’s not resolving, the first thing to check is that the IRI you wrote is byte-for-byte the IRI the target ontology actually declares.

Resolution and visibility#

Resolving a dependency is always done for a specific viewer, not globally — the same import can resolve differently depending on who’s looking:

  • A Public hosted version matching the IRI is visible to everyone.
  • A Private hosted version matching the IRI is visible only to its owner, signed in.
  • To anyone else, someone else’s private copy simply isn’t there — it renders identically to an IRI that isn’t hosted on Ontoshire at all (see External / unresolved below). This is intentional: a dependency graph must never be a way to detect that a stranger’s private ontology exists.

When more than one copy exists#

Ontology IRIs aren’t globally unique — anyone can publish a document claiming any IRI, so a fork, a mirror, or your own re-publish can all declare the same one. When an owl:imports target matches several copies hosted on Ontoshire, the Dependencies tab doesn’t silently pick one and hide the rest: it shows every copy you can access and lets you switch which one to follow.

  • In the tree, a dependency with more than one hosted copy carries a “2 copies” badge.
  • Selecting it opens the detail panel, which lists each copy under “N copies of this IRI hosted”. Your own copy is marked (yours), and every entry links to that copy’s version page.
  • The copy shown first — the default edge in the tree and the default download target — is deterministic: your own copy if you have one, otherwise the earliest-registered public copy. A version-IRI match is always preferred over a plain ontology-IRI match, regardless of registration date.

Selecting the imported node shows a panel like this:

Dependencies → detail panel
uberon                                   Public
http://purl.obolibrary.org/obo/uberon.owl
An integrated cross-species anatomy ontology.
12,043 classes · 209 properties
View this ontology →

2 copies of this IRI hosted
  obolibrary/uberon
  my-org/uberon-fork   (yours)
You only ever see copies you can access. The list is public copies plus your own private ones — someone else’s private copy never appears and never changes the count, so it can’t leak that it exists.

External / unresolved dependencies#

If no accessible hosted copy matches an import’s IRI, it renders as external / unresolved — a grey node you can inspect (the IRI itself) but not browse into or download from Ontoshire. This is the same rendering whether the IRI genuinely isn’t hosted anywhere, or it is, but it’s someone else’s private copy (see Resolution and visibility) — by design, the two cases must be indistinguishable.

Not the same as a manifest’s external reference. owl:imports targets are discovered automatically from your ontology’s own triples. A ontoshire.ttl manifest’s dcterms:requires is a separate, author-declared statement — for a dependency that isn’t (or can’t be) expressed as an owl:imports. See the manifest guide.

The Dependencies tab & graph#

The Dependencies tab renders the full transitive closure as an indented tree, starting from the version you’re viewing. It’s cycle-safe (an ontology that imports something that imports it back won’t loop forever) and diamond-deduplicated (if two branches both depend on the same hosted version, it appears once, cross-referenced, not duplicated). For very large transitive graphs it’s bounded — 12 levels deep, 200 nodes — with a visible notice when the tree was truncated, so a runaway import chain can’t hang the page or hide how much was cut off.

Downloading the dependency closure#

From the Dependencies tab, download the ontology alone or bundled with everything in its closure that you can access, as a zip — Turtle, RDF/XML, JSON-LD, or N-Triples. Requires signing in (free, but not anonymous — see below for why).

  • The zip contains one file per hosted dependency, plus a download-manifest.json describing what’s included and what was left external — never a single merged graph. Merging would silently reintroduce the collision problem above (whose “uberon” would win?), so each dependency stays its own file, addressable by its own coordinate. (This is a plain JSON index of the archive — unrelated to the RDF ontoshire.ttl manifest in Publishing.)
  • Access is re-checked at download time, not just when the page loaded — if a dependency’s visibility changed (or your session did) between opening the tab and clicking download, you get exactly what you’re currently allowed to see, not a stale snapshot.

Reusing an ontology — or being reused#

To depend on a hosted ontology, add an owl:imports statement to your own file pointing at its own declared IRI — not a Ontoshire URL. (The distinction between an ontology’s own IRI and the /o/owner/repo/version coordinate Ontoshire serves it at is explained in Resolvable URLs.) Once published, Ontoshire resolves that import to the hosted version automatically, the same way it resolves any other.

The reverse works the same way: to make your ontology importable by others, all it takes is declaring a real, stable owl:Ontology IRI. Anyone who imports that exact IRI — and can see your version’s visibility — resolves straight to your published version, with no coordination needed beyond publishing it.