Ontology Pipeline StudioA framework for building knowledge infrastructures

saved

Contents Your pipeline

The six stages of the pipeline, in the book's order. Each one unlocks the next.

"Each stage of the Ontology Pipeline prepares us for the next stage of building and provides a repeatable and measurable process for organizing information and knowledge."

Chapters

About this pipeline name, domain, purpose, who stewards it

Stage 1 Controlled vocabulary

Say what the vocabulary is for, list where the words come from, then add terms: one preferred term per concept, its alternatives, and a definition.

"A controlled vocabulary deliberately stays small and pragmatic: it is the approved set of words and the governance that keeps them stable."

1Purpose and scope

2Sources where the words come from

Style guide optional Β· how terms are written

3Terms

Add a candidate term.

The stage's checklist

Not run yet.

Stage 2 Metadata application profile

Choose the Dublin Core elements every record needs, and say for each whether it is required, how many times it may appear, and how it is written.

"A metadata application profile (MAP) is, at its core, a declaration of the metadata terms an organization uses, how it uses them, and the constraints that apply in specific contexts."

1Profile record

2Elements

Systems and crosswalk optional Β· which field holds each element in each system

The stage's checklist

Not run yet.

Stage 3 Taxonomy

Write down what the taxonomy is for, make a scheme, place your approved terms in it, and give each one its parent. Every parent must pass the Is-a test.

"Metadata schemas serve as architectural blueprints for the taxonomy, while controlled vocabularies provide the material from which we construct it."

1Use cases

Coverage model optional Β· what the taxonomy must cover

2Schemes and hierarchy

Add a scheme, then place terms in it.

The stage's checklist

Not run yet.

Stage 4 Thesaurus

Pick a concept and add what the taxonomy could not say: related concepts, a scope note, a mapping to an outside vocabulary.

"Beyond the taxonomic structure, a thesaurus adds skos:related (associative), and joins across concept schemes through the mapping properties."

1Concepts

Pick a concept.
Collections optional Β· groups for display, never hierarchy

The stage's checklist

Not run yet.

Stage 5 Ontology CBox β†’ TBox β†’ ABox β†’ Check

Three boxes in order. CBox: questions, namespaces and the ontology's record. TBox: classes, then properties. ABox: test individuals. Then Check.

"The CBox comes first, which surprises most people who expect to start with classes and properties. The CBox is the administrative and governance layer."

1Competency questions what the ontology must answer

2Namespaces and the ontology record

The record also declares owl:imports for SKOS and for each standard switched on in the survey that publishes an OWL file.

3Concept schemes from stages 3 and 4

What SKOS is used in each box, and how concepts cross into the TBox and ABox
"Build the CBox first, keep it intact, and integrate into the TBox and ABox only what needs the inferential machinery of RDFS and OWL. The CBox does not disappear when the ontology is built."
"The label and comment are written before the axiomsβ€”if a definition cannot be stated clearly, the concept boundary is not yet understood well enough to model."

1Standards to reuse before defining your own terms

2Classes the hierarchy first

Add a class, or promote a concept.

3Properties how classes relate

Add a property.

4Constraints SHACL shapes: the rules the thin OWL frame cannot state

The workflow ontology's own comment on requiresHumanApproval: "when true, the step's assigned Role must be filled by a ntwf:HumanAgent. All ntwf:ApprovalGate instances carry this as true."
A class or a property cannot state that rule; a shape can. A shape picks a class, optionally a condition (a property of the focus node with a value), and then a path of one or two properties whose values must be of a class or carry a value, at least and at most so many times. The Check applies every shape to the test ABox and reports each individual that breaks one.
Add a shape, or pick one.

5Metadata from the profile which records carry it

"Before deploying an ontology, build a representative set of ABox instances that exercises every class, every property, and every constraint available in the TBox."

1Individuals

Create an individual of a class.
"To manage these types of errors, populate a test ABox early, and run an RDFS-aware inference engine over it before you ever introduce OWL axioms. The errors that surface at the RDFS level are the cheapest to fix."

The three-box validation

Not run yet.
All findings every error and warning, by box
Not run yet.

Inferred triples what a reasoner adds, with the rule

Not run yet.

Stage 6 Knowledge graph Query Β· Graph

What the five stages before it built, as one graph. Ask it a question in SPARQL, or look at it. Your competency questions are the first queries, and any query's answer can be drawn.

"A competency question is a natural-language question that the knowledge graph must be able to answer. It is not a vague business objective or a KPI. It is a question with a definite answer that the graph either can or cannot return."
SELECT queries with OPTIONAL, FILTER, property paths (+ and *), ORDER BY, LIMIT and COUNT. Runs in the browser.
Drag to arrange, scroll to zoom, click a node to inspect it. Solid arrows are hierarchy: rdfs:subClassOf, skos:broader, and rdf:type from a thing to its class; dashed arrows are properties; the faintest dotted lines are membership (a concept in its scheme) and definition (a term in its ontology). Pick a query under Draw to see only what it answers, and the edges among those things.

The stage's checklist

Not run yet.

RDF See the RDF

Everything the pipeline has produced so far, as Turtle. Pick a layer, read it, copy it, or export it. It changes as you work, so come back after any stage.

"We will use the Turtle serialization format for all RDF examples. Turtle is the most human-readable RDF syntax and the one encountered most commonly in SKOS work. If you can read a spreadsheet, you can read Turtle."

  

Ontology Pipeline Studio

Your place in the pipeline is kept. Go back to it with the button, or open one of the two projects below.

The six stages of the book's pipeline as a tool. Each stage produces what the next one needs, and the next stays locked until this one is far enough along. The vocabulary is RDF, RDFS, SKOS, SKOS-XL and Dublin Core Terms, with the book's thin OWL frame in stage 5 and the standards it reuses: PROV-O, FOAF, Schema.org and DCAT.

1 Β· VocabularyPurpose and scope, sources, style guide, terms with provenance and genus-differentia definitions.
2 Β· MetadataAn application profile: Dublin Core elements with obligation, occurrence, encoding, guidelines, and a crosswalk to the systems.
3 Β· TaxonomyUse cases, a coverage model, concept schemes, and a hierarchy that passes the Is-a test.
4 Β· ThesaurusRelated terms, scope notes, mappings to outside vocabularies, collections, notation, SKOS-XL labels.
5 Β· OntologyCompetency questions, then CBox, TBox, ABox, and an RDFS check.
6 Β· Knowledge graphThe questions as SPARQL over everything, the graph drawn whole or one answer at a time, and the checks that it answers what it must.

Two projects are built in, complete through all six stages. Open one, read it stage by stage, change it, run the checks, ask it questions in the knowledge graph, and read the RDF it produces.

From the bookThe Special Solutions workflow

Chapter 5's NTWF ontology, taken back through chapters 1 to 4: the vocabulary, the record profile, four schemes, the thesaurus, then the ontology with its competency questions and test individuals. This is the book's own material.

Another domainMusic tourism: venues and events

The same method applied to a subject that is not in the book: a visitor choosing events and venues in the harbour city of Marlow Bay. Six schemes, a profile crosswalked to a listings system and a ticketing platform, Schema.org reused, six questions answered.

How to use the studio

  1. Go in order. The pipeline bar at the top lists the six stages, and Contents shows how far the open project has come. A later stage stays locked, its panels dimmed, until the earlier one is far enough along; the lock message says what is still needed and takes you there.
  2. Read each stage the way the chapter goes. A stage opens with a line from the book, then a Next box that says what to do now, then the panels where the work is done. The foot of every stage has Run the checklist, the book's checks for that stage, and a Continue button to the next.
  3. Stage 5 has four tabs, in the book's order. CBox: the questions, the namespaces, the ontology's record and the schemes. TBox: standards to reuse, classes, properties, SHACL constraints and the profile's metadata. ABox: the test individuals. Check: an RDFS-aware check, with inference, over the test set.
  4. Stage 6 asks the graph questions. Query runs SPARQL over all that the five stages built, with the competency questions and a set of ready queries; under any result, See these results as a graph draws that answer. Graph draws the whole project: drag, zoom, click a node to inspect it.
  5. See the RDF, in the pipeline bar and at the foot of every stage, shows the Turtle each layer produces, with Copy and export as Turtle, N-Triples, JSON-LD or the book's spreadsheet.
  6. Change anything. Every field can be edited: + Add buttons add to a list, remove links take away, Show and Hide open and close the folded sections. The checks report what a change broke, by name, and the ontology's Check applies the SHACL shapes to the test individuals.
  7. Your changes stay in this browser, in the project you made them in, until a new version of that project ships and replaces the copy here. Switch projects at any time from the Projects menu; a project always opens at its Contents page. This guide is one click away, at ? Guide.