Skip to content
This repository was archived by the owner on Jan 8, 2026. It is now read-only.
Merged
Changes from all commits
Commits
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
18 changes: 18 additions & 0 deletions data-model-layer/data-model.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,6 +12,24 @@ While the Data Model describes these representations in the abstract,
additional optional tooling on top of the Data Model which can further refine,
describe, and constrain the range of acceptable data values.)

Motivation
----------

There is not **one** block format but **many** block formats widely used today in content
addressed data structures. We assume that we'll see more of these block formats in the
future and not less. It is quite clear then that a reasonable and more future proof approach
to using these data structures is to be block format agnostic.

The data model defines a common respresentation of basic types that **are easily representable
by common programming languages.** This provides the foundation for block format agnostic tools
to be built using familiar native types in a programmer's preferred language. As such, there
is an element of "lowest common denominator" to the IPLD Data Model in that it cannot support
some advanced features (like non-string keys for Maps) because support for such a feature
Copy link
Member

Choose a reason for hiding this comment

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

could also add "or unsigned integers" inside those parens to drive home the point

Copy link
Contributor Author

Choose a reason for hiding this comment

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

i’d rather not litigate that particular point in this PR :)

is not common enough among programming languages.

This does not mean that a block format could not support more advanced features than exist in the
data model, it just means that the common set of tools IPLD is building w/ its block format
agnostic approach cannot be easily leveraged to use those features.

Kinds
-----
Expand Down