Concept Vocabulary¶

A collection of related concepts that share a common context or domain, enabling reuse and consistency across use cases

Business & Management AudienceVocabulary ManagementRelationshipsOntology

What Is a Concept Vocabulary?¶

A Concept Vocabulary is a collection of related Concepts that share a common context or domain. Think of it as a dictionary or glossary specific to a particular area of your business. It groups together concepts and their manifestations that make sense to use together.

Just as you might have a "Finance Vocabulary" or a "Product Management Vocabulary" in your organization, the Use Case Tree Method organizes concepts into vocabularies to keep things clear and reusable.

How concepts work with manifestations¶

An important characteristic of our Concept Vocabularies is how concepts relate to the actual words and technical forms people and systems use:

A Concept in our model is essentially just a unique identifier (a random UUID) that represents an idea or thing in your domain
This concept can have multiple manifestations associated with it, such as business words, abbreviations, API parameters, query variables, ontology classes, shapes, and source occurrences
This is a one-to-many relationship: one concept, potentially many manifestations

Why multiple manifestations?¶

In a given context, people often use different words for the same thing, and systems often use different identifiers for it:

Example: Hospital Context

In a hospital use case, the concept of "a person receiving care" might have multiple manifestations:

"Patient" — medical staff terminology

"Client" — administrative perspective

"Customer" — billing department

"Visitor" — reception desk

All these manifestations refer to the same underlying Concept in this hospital context, so they are grouped under one Concept identifier.

Context Matters¶

The same manifestation value might mean completely different things in other contexts:

"Patient" in a hospital means something different than "patient" in a legal context (someone waiting)
"Client" in a hospital is different from "client" in a law firm
Each use case defines its own concepts that make sense in its context

The Concept (the UUID) ties together all the manifestations that mean the same thing in your specific use case context.

Manifestations can repeat, Concepts are contextual

The manifestation values themselves, such as "patient", "client", ?patient, or patient_id, can appear in many vocabularies and systems. The Concept that groups them together is specific to the use case's context and meaning.

Why Use Concept Vocabularies?¶

Concept Vocabularies serve several important purposes:

Organization — Keeps related concepts together in meaningful groupings
Reuse — Allows multiple use cases to share the same vocabulary without duplicating concepts
Consistency — Ensures that the same manifestation values can be interpreted in the right context
Ownership — Clarifies who is responsible for defining and maintaining concepts in each domain

One vocabulary, many use cases

A well-defined vocabulary can serve multiple use cases. For example, a "Customer Vocabulary" might be used by Customer Service, Sales, Marketing, and Analytics use cases.

Ownership and Inheritance¶

Every Concept Vocabulary is owned by exactly one Use Case. However, vocabularies are automatically inherited by all descendant Use Cases in the Use Case Tree:

Own vocabularies — Vocabularies owned by the current Use Case. The owning Use Case can add, modify, or remove Concepts in these vocabularies.
Inherited vocabularies — Vocabularies owned by ancestor Use Cases. These are available read-only to descendant Use Cases — they can use the Concepts but cannot change them.

This means broadly applicable vocabularies should be defined at higher levels of the Use Case Tree, where they benefit the most Use Cases.

Example:

The top-level "Customer Management" Use Case owns a "Customer Vocabulary." All child Use Cases — "Onboarding," "Service," "Billing" — automatically inherit this vocabulary and can reference its Concepts in their Stories. The "KYC Verification" Use Case (a child of Onboarding) also defines its own "KYC Vocabulary" with specialized Concepts like "Beneficial Owner" and "Sanctions List."

When to Create a New Vocabulary¶

Create a new Concept Vocabulary when:

New domain — You're working in a domain that doesn't have existing vocabularies
Unique terminology — Your use case needs concepts that don't exist elsewhere
Evolution needed — Existing vocabularies don't quite fit and you need flexibility to evolve
Experimentation — You're exploring new concepts before proposing them for wider use

When to Reference an Existing Vocabulary¶

Reference an existing Concept Vocabulary when:

Standard concepts — The concepts you need are already defined
Consistency matters — You want to ensure alignment with other use cases
Proven vocabulary — An established vocabulary meets your needs
Integration — You need to integrate with systems using that vocabulary

Evolution Path¶

Many vocabularies start as private and evolve to become shared:

Start private — Create a vocabulary specific to your use case
Prove value — Demonstrate that the concepts are useful and well-defined
Generalize — Remove use case-specific details and make concepts more generally applicable
Share — Publish the vocabulary for other use cases to reference
Maintain — Establish governance for the shared vocabulary

Governance¶

Each Concept Vocabulary should have clear governance:

Ownership¶

Owner — Who is responsible for the vocabulary?
Maintainers — Who can make changes?
Stakeholders — Who should be consulted for major changes?

Versioning¶

Vocabularies should be versioned
Changes should be tracked and communicated
Backward compatibility should be considered
Deprecation policies should be defined

Documentation¶

Each vocabulary should have clear purpose and scope
Concepts should be well-defined
Examples should be provided
Usage guidelines should be documented

Discovery and Reuse¶

To maximize reuse, vocabularies should be:

Discoverable — Listed in a central catalog
Searchable — Easy to find by topic or term
Well-described — With clear purpose and scope
Example-rich — Showing real usage

Vocabulary Catalog

Organizations should maintain a catalog of available vocabularies to promote discovery and reuse. This can be as simple as a wiki page or as sophisticated as a dedicated vocabulary management system.

Quality Criteria¶

A good Concept Vocabulary:

Focused — Has a clear, well-defined scope
Cohesive — Contains related concepts that belong together
Complete — Includes all concepts needed for its domain
Consistent — Uses terminology consistently throughout
Clear — Has unambiguous definitions
Useful — Serves actual use case needs

Antipatterns to Avoid¶

The Mega-Vocabulary¶

Problem: Trying to put all concepts in one massive vocabulary

Solution: Break into focused, domain-specific vocabularies

The Ghost Vocabulary¶

Problem: Creating vocabularies that nobody actually uses

Solution: Build vocabularies from real use case needs, not speculation

The Orphan Vocabulary¶

Problem: Vocabularies with no clear owner or maintainer

Solution: Assign ownership and maintenance responsibilities

The Frozen Vocabulary¶

Problem: Vocabularies that can't evolve with changing needs

Solution: Establish change management processes that balance stability with evolution

Relationship to Concepts¶

Concepts are the members of a Concept Vocabulary. Using the SKOS (Simple Knowledge Organization System) standard:

A Concept Vocabulary is a skos:ConceptScheme
A Concept is a skos:Concept
Concepts belong to a vocabulary via skos:inScheme

This follows established W3C standards for organizing concepts.

Relationship to Use Cases¶

Each Concept Vocabulary is owned by exactly one Use Case. A Use Case can own zero or more Concept Vocabularies.

Inheritance through the Use Case Tree¶

Concept Vocabularies are inherited down the Use Case Tree. When a Story in a child Use Case needs to reference Concepts, it can draw from:

Own vocabularies — Concept Vocabularies owned by the Story's own Use Case (read-write)
Ancestor vocabularies — Concept Vocabularies owned by any ancestor Use Case in the tree (read-only)

This inheritance mechanism means that broadly applicable vocabularies can be defined at higher levels of the Use Case Tree and reused by all descendant Use Cases without duplication.

Practical example¶

Enterprise Use Case Tree
└── Customer Management          ← owns "Customer Vocabulary"
    ├── Customer Onboarding      ← inherits "Customer Vocabulary"
    │   └── KYC Verification     ← inherits "Customer Vocabulary"
    │       ← owns "KYC Vocabulary"
    └── Customer Service         ← inherits "Customer Vocabulary"

In this example, "KYC Verification" can pick Concepts from both its own "KYC Vocabulary" and the inherited "Customer Vocabulary" from its ancestor.

Relationship to Stories¶

Stories use Concepts from vocabularies through Story/Concept Relationships. When associating Concepts to a Story as InputConcept, OutputConcept, or DependentConcept, the available Concepts come from:

Concept Vocabularies owned by the Story's own Use Case
Concept Vocabularies inherited from any ancestor Use Case in the tree (read-only)

A Story may reference Concepts from multiple vocabularies.

Relationship to manifestations¶

Concept Manifestations are attached to concepts, which are part of vocabularies:

A Concept Vocabulary contains multiple Concepts
Each Concept can have zero or more manifestations
Manifestations provide the labels, names, variables, schema resources, shapes, and source occurrences used in different contexts

Facts¶

About these facts

We're not prescribing a full OWL ontology here. These are minimal facts you can use to build your own ontology, schema, or graph model.

Technical Model¶

A Concept Vocabulary is a container for related concepts:

Extension of SKOS¶

While a Concept Vocabulary is technically a skos:ConceptScheme following W3C SKOS standards, we extend the model in an important way:

Standard SKOS:

A skos:Concept has labels directly attached (skos:prefLabel, skos:altLabel)
Labels are properties of the concept itself

Use Case Tree Method Extension:

A Concept is essentially just a universally unique identifier (UUID)
The Concept identifier represents the local linking pin
The Concept has a one-to-many relationship with Concept Manifestations
Manifestations are the observable forms: words, phrases, code identifiers, schema resources, shapes, and source occurrences
A Concept can have multiple manifestations, each representing a different way the same meaning appears in a given context

Why this matters:

In a given use case context, people often use multiple words for the same concept:

Concept: urn:uuid:a1b2c3d4-... (hospital visitor concept)
├── BusinessTerm: "Patient" (medical staff usage)
├── BusinessTerm: "Client" (administrative usage)
├── URIParameterManifestation: "patient-id"
└── OWLClassManifestation: hospital:Patient

All these manifestations refer to the same underlying Concept in this hospital use case's context. In other contexts, these same values might mean different things and would not be grouped together.

Key insight:

Concepts are context-specific linking pins
Manifestation values can recur across many contexts
The Concept binds together all manifestations that mean the same thing in your specific use case context

This separation allows:

Different use cases to use the same values with different meanings
One use case to group multiple manifestations under one Concept
Clear traceability of which manifestations are considered equivalent in which contexts