If your goal is to eventually build an ontology or software model, I'd separate the understanding of the concept from its implementation.
A good concept definition answers these questions:
1. Purpose
Why does this concept exist?
What role does it play in the domain?
Example:
A Research Project coordinates people, funding, publications, and experiments around a common scientific objective.
2. Identity
What makes one instance distinct from another?
When do we say two instances are different?
Example:
Two Research Projects are different if they pursue different objectives, even if they involve the same researchers.
3. Invariants
What is always true?
These become the semantic rules of the concept.
Example:
Every Research Project has an objective.
A Project may have zero or more participants.
A participant has a role.
4. Lifecycle
How does it come into existence and how can it change?
Example:
Created
Active
Completed
Archived
5. Relationships
How does it relate to other concepts?
Example:
Research Project contains Experiments.
Research Project is funded by Grants.
Research Project produces Publications.
6. Questions
What questions should the model answer?
Example:
Which projects involve Alice?
Which publications came from Project X?
Which grants fund projects on robotics?
If the model cannot answer these questions, it is incomplete.
7. Behavior
What can this concept do?
Instead of thinking in terms of fields, think in terms of messages.
Example:
A Project can:
AddParticipant
RemoveParticipant
PublishResult
Close
ReceiveFunding
This is closer to an object or actor model than a database schema.
8. Observable Properties
Finally, decide what information needs to be stored.
Example:
Title
Summary
Objective
Start date
End date
Status
Notice these come last. Most modeling efforts start here, which often leads to shallow schemas.
A template
Concept
Purpose
What is it?
Identity
What makes one unique?
Invariants
What must always be true?
Lifecycle
How does it evolve?
Relationships
How does it connect to other concepts?
Questions
What should users or agents be able to ask?
Behavior
What messages can it receive?
Properties
What information must be persisted?
I think this ordering aligns well with Seed Hypermedia's philosophy. Rather than beginning with tables or attributes, you begin with meaning, then behavior, and only then decide what state must be stored. The ontology becomes a description of a community's shared understanding, while the data model is simply one implementation of that understanding.
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime