ontology-design

Guides design of OWL ontologies and SKOS vocabularies with Turtle templates and validation rules.

Updated May 12, 2026
One-click install
npx skills add https://github.com/angelo-v/pi-kit --skill ontology-design-angelo-v
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: ontology-design
Source: https://github.com/angelo-v/pi-kit/tree/main/packages/linked-data/skills/ontology-design
Command: npx skills add https://github.com/angelo-v/pi-kit --skill ontology-design-angelo-v

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Designing OWL ontologies and SKOS controlled vocabularies involves many subtle rules — inverse properties, disjoint classes, label cardinality, hierarchy cycles — that are easy to get wrong. This Skill walks an agent through a structured workflow from domain clarification to validated Turtle output, preventing common modelling mistakes. ## Core Features & Use Cases - Structured Design Workflow: Clarify the domain, draft the ontology header, declare classes and properties top-down, then add individuals or concepts. - OWL and SKOS Guidance: Covers class axioms, property types and characteristics, concept schemes, labels, hierarchies, and cross-vocabulary mappings, with rules for combining both vocabularies. - Mistake Prevention: Enforces key rules such as one skos:prefLabel per language, bidirectional owl:inverseOf, mandatory skos:inScheme, and no skos:broader cycles. - Use Case: A knowledge engineer needs to model an organisational domain. The Skill guides them to declare an owl:Ontology header, build an Employee/Organisation class hierarchy with inverse object properties, and attach a SKOS concept scheme for job titles — all written as valid Turtle via rdf_write and checked with sparql_query_files. ## Quick Start Ask the agent to design an OWL ontology or SKOS vocabulary for your domain, stating the main entities, relationships, and base URI.

Frequently Asked Questions about ontology-design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I design an OWL ontology from scratch?▼

Start by clarifying the domain entities, relationships, and base URI, then draft an owl:Ontology header with metadata. Declare classes and properties top-down — superclasses before subclasses, domains before ranges — and add individuals only after the schema is stable.

Should I use OWL or SKOS for my vocabulary?▼

Use OWL when you need a formal domain model with typed individuals, constraints, and reasoning; use SKOS when you need a navigable taxonomy or thesaurus. They are complementary — applying skos:prefLabel and skos:definition to OWL classes is normal and encouraged.

What are the most common OWL ontology mistakes?▼

Common mistakes include mixing owl:ObjectProperty and owl:DatatypeProperty on the same URI, declaring owl:inverseOf in only one direction, and omitting the owl:Ontology declaration. Every class and property should also carry rdfs:label and rdfs:comment.

Why does my SKOS hierarchy have problems?▼

SKOS issues usually come from cycles in skos:broader, missing skos:inScheme on concepts, or multiple skos:prefLabel values in the same language. Assert skos:broader only on the narrower concept and run a cycle audit query to verify.

Can I reuse existing vocabularies instead of inventing new terms?▼

Yes, reusing established vocabularies such as foaf:, schema:, dct:, and prov: is preferred over inventing new terms. For cross-vocabulary links, SKOS provides skos:exactMatch, skos:closeMatch, and broader or narrower match properties.