Quickstart: publish & discover

Go from an ontology sitting in a GitHub repo to a searchable, citeable, reusable entry in the registry — in a few minutes. No SHACL shapes and no client install required for this path; that’s a separate, optional concern (see Quickstart: validate data).

1. Prepare an ontology#

Any repo with an ontology file works. This example deliberately imports something not hosted on Ontoshire, so you can also see what an unresolved dependency looks like later:

@prefix owl:  <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix ex:   <http://example.org/people#> .

<http://example.org/people> a owl:Ontology ;
    owl:imports <http://xmlns.com/foaf/0.1/> .

ex:Person a owl:Class ;
    rdfs:label "Person" ;
    rdfs:comment "A human being." .

Commit it to a GitHub repo.

2. Tag and push#

Ontoshire only ever ingests tags — never branch pushes, never HEAD. The tag name becomes the version:

git tag v1.0.0
git push origin v1.0.0

3. Register the repo#

Go to My Repositories → + Register repo and pick it. This links the repo and installs a webhook — it publishes nothing by itself.

4. Publish the version#

The Publish a version dialog opens right after registering: pick the v1.0.0 tag, choose Public or Private (Private needs Pro), and watch live progress (fetching → validating → writing → indexing) until it’s live. It reopens any time from My Repositories → Publish version.

From here on, new tags publish automatically — each repo has an auto-publish switch, on by default. See Publishing for the full mechanics, including multi-file ontologies and SHACL shapes.

5. Find it#

Head to the ontologies list and search for your repo name — the search bar in the header matches both ontologies and individual terms (classes/properties) across the whole public registry.

6. Explore it#

Open the version page. Alongside the metadata, it’s organised into tabs:

• Classes and Properties — browse the model, with annotations (labels, comments) for anything you select.
• Viz — the class structure as an interactive graph.
• Dependencies — the owl:imports tree. Since this example imports FOAF, which isn’t hosted on Ontoshire, you’ll see it rendered as an external / unresolved node rather than a broken link. See Imports & dependencies for the full resolution model — including what happens when the import target is hosted on Ontoshire.
• SPARQL — query the version directly from the browser.

Full tour in Browsing an ontology.

7. Cite and reuse it#

The metadata card surfaces a Public URL — a permanent, content-negotiated citation for this exact version:

https://ontoshire.com/o/your-org/people/v1.0.0

That’s what you cite, link to, or point a colleague’s owl:imports at — see Resolvable URLs for how it behaves for humans vs. machines. Anyone can also download the ontology (or its full dependency closure, once signed in) as Turtle, RDF/XML, JSON-LD, or N-Triples from the Dependencies tab.

From the other side: once someone else’s ontology imports http://example.org/people (this example’s IRI), Ontoshire resolves it back to your published version automatically — the same mechanism, run in reverse.

If something goes wrong#

• Repo doesn’t appear in the register picker — you need admin access on GitHub for that repo (webhook installation requires it). Org repos may also need the Ontoshire GitHub App approved by an org owner.
• “No tags found” in the publish dialog — Ontoshire only lists Git tags. Push one (step 2) and it’ll appear.
• Wrong file picked as the ontology — with no manifest, Ontoshire picks the first root-level RDF file by convention. For multiple files or a non-standard layout, add a ontoshire.ttl manifest — see the manifest guide (there’s an in-app generator under My Repositories → Manifest).