Skip to content

feat: updated user ontology #939

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
coodos merged 1 commit into from
Apr 3, 2026
Merged

feat: updated user ontology #939

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
44 changes: 44 additions & 0 deletions services/ontology/schemas/user.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -17,6 +17,50 @@
"type": "string",
"description": "The user's display name or full name"
},
"givenName": {
"type": "string",
"description": "The user's given name"
},
"familyName": {
"type": "string",
"description": "The user's family name"
},
"email": {
"type": "string",
"format": "email",
"description": "The user's email address"
},
"telephone": {
"type": "string",
"description": "The user's telephone number"
},
"address": {
"type": "object",
"description": "The user's postal address",
"properties": {
"streetAddress": {
"type": "string",
"description": "The street address"
},
"postalCode": {
"type": "string",
"description": "The postal code"
},
"addressLocality": {
"type": "string",
"description": "The locality or city"
},
"addressCountry": {
"type": "string",
"description": "The country"
}
},
"additionalProperties": false
},
Comment on lines +37 to +59
Copy link
Copy Markdown
Contributor

@coodos coodos Apr 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably a good idea to make this a seperate ontology called address (a person may have work address and a home address or own many homes) and make it a 1:n relation from user's perspective

Copy link
Copy Markdown
Contributor Author

@dima4914 dima4914 Apr 3, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We’ve reviewed the current model and believe that, within eVault, moving toward treating address as a first-class ontological entity is the right direction. In a proper, fully developed architecture, an address should not be just a string inside a user object — it should be a standalone entity with its own lifecycle, reusable across contexts, and capable of participating in relationships. This naturally leads to a many-to-many model: a user can have multiple addresses, and the same address can belong to multiple users. Moreover, for this to work correctly and avoid inconsistencies, it ideally requires a centralized source of truth — for example, a government-backed address registry with stable unique identifiers.

At the same time, we believe that implementing this model at the MVP stage introduces significant complexity. First, there is the problem of mapping between local and global identifiers: without a unified registry, there is no reliable way to match addresses, which quickly leads to duplication and inconsistency. Second, synchronization across platforms becomes non-trivial, as different systems may support different models (some allow only a single address, others multiple), and it becomes unclear how to interpret updates — whether a change represents an update to an existing address or the creation of a new one. Third, the many-to-many model itself requires careful handling of relationships: when multiple users are linked to the same address, or a user has multiple addresses, any change can affect multiple entities and their connections. Fourth, without a normalized source of addresses, duplicate records are inevitable — the same physical address may appear multiple times as separate entities. Additionally, update semantics become ambiguous: when a user enters a “new” address, it is unclear whether it should replace an existing one, be added as a new entry, or be matched against an existing record. Altogether, this makes the system significantly more complex and fragile, especially at the prototype stage.

For these reasons, while we fully support the long-term direction of modeling address as a separate entity with many-to-many relationships and integration with a centralized registry, we believe this is too heavy for the current MVP scope. As a pragmatic step, we propose simplifying the model for now and using a single address embedded directly within the user entity, without introducing a separate ontological entity or supporting multiple addresses. This approach avoids the mapping, duplication, and synchronization issues described above, simplifies integrations, and allows us to move faster toward a working MVP. At the same time, we see this as a temporary simplification, and we can later evolve the model toward a fully normalized solution with standalone address entities, many-to-many relationships, and integration with an external address registry.

"inLanguage": {
"type": "string",
"description": "The language associated with the user profile"
},
"bio": {
"type": "string",
"description": "The user's biography or description"
Expand Down
Loading