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 all the concepts and their terms 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 Terms¶

An important characteristic of our Concept Vocabularies is how concepts relate to the actual words people 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 Terms associated with it—the actual words or phrases people use to refer to that concept
This is a one-to-many relationship: one concept, potentially many terms

Why Multiple Terms?¶

In a given context, people often use different words for the same thing:

Example: Hospital Context

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

"Patient" — medical staff terminology

"Client" — administrative perspective

"Customer" — billing department

"Visitor" — reception desk

All these terms refer to the same underlying concept in this hospital context, so they're grouped under one Concept identifier.

Context Matters¶

The same terms 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 terms that mean the same thing in your specific use case context.

Terms are reusable, Concepts are context-specific

The terms themselves (like "patient", "client") can be reused across many vocabularies and use cases. But the concept that groups those terms 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 terms mean the same things across different parts of the organization
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 Terms¶

Terms are part of concepts, which are part of vocabularies:

A Concept Vocabulary contains multiple Concepts
Each Concept has one or more Terms
Terms provide the actual labels and names 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 abstract idea or thing
The Concept has a one-to-many relationship with Terms
Terms are the actual manifestations—the words and phrases people use
A Concept can have multiple Terms, each representing different ways people refer to the same thing 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)
├── Term: "Patient" (medical staff usage)
├── Term: "Client" (administrative usage)
├── Term: "Customer" (billing department usage)
└── Term: "Visitor" (reception desk usage)

All these terms refer to the same underlying concept in this hospital use case's context. In other contexts, these same terms might mean completely different things and wouldn't be grouped together.

Key insight:

Concepts (the UUID identifier) are context-specific to the use case
Terms (the actual words) are reusable across many contexts
The Concept binds together all the terms that mean the same thing in your specific use case context

This separation allows:

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