Collection
Purpose
A Collection groups related data.
Collections provide a logical organization for data without changing the meaning of the data they contain.
The Canonical Data Model defines the structure of a Collection but does not define the available Collection types.
---
Structure
A Collection consists of:
type- Identifies the kind of Collection.content- Contains the data associated with that Collection.
The interpretation of content is determined by type.
---
Characteristics
- Collections are typed.
- Collections are independent.
- Collections may contain any valid data.
- Collections are immutable.
Examples of capability:
{
"collection": {
"id": "community",
"type": "allowed"
}
}
Meaning:
This object may participate in community collections.
Examples of an instance:
{
"collection": {
"id": "community:seattle-makers",
"type": "community",
"content": {
"role": "member"
}
}
}
Meaning:
This object participates in the Seattle Makers community.
Or:
{
"collection": {
"id": "favorites",
"type": "user",
"content": {
"owner": "person:alice"
}
}
}
id identifies the collection definition or instance.
type classifies the collection.
content contains collection-specific data.
The semantics—whether it's declaring an allowed collection type or describing a specific collection—are determined by the statement in which the structure appears, not by collection.json itself.
---
Recognized type: sequence
A sequence Collection asserts that its member Objects are ordered and form a related flow —
each Object still stands as an independent, addressable Object; sequence only groups them and
asserts their order.
content.order names the ordering basis, e.g. "chronological" (each member Object's own
timestamp determines position — no separate index field is required on the Collection or its
members).
sequence does not imply how a flow should be displayed. Whether consecutive members from the
same origin are visually grouped, how a flow is paginated, or any other presentation treatment is
a Runtime rendering decision made from the generic sequence type, not part of what a sequence
Collection asserts. This keeps sequence reusable for any ordered flow of Objects — a
conversation's replies, a message thread's messages, a document's revision history — without
tying the canonical type to any one domain's presentation needs.
Example of an instance:
{
"collection": {
"id": "collection:conversation:42:replies",
"type": "sequence",
"content": {
"order": "chronological",
"count": 3
}
}
}
Meaning:
This Collection's member Objects (referenced via the Collection's items) form a chronologically
ordered flow — for example, the replies in a conversation, in the order they were posted.
---
Recognized type: roster
A roster Collection asserts that its member Objects are people participating in a parent
Object — the participants of a conversation, the members of a community, the guests of an event.
Each member Object still stands as an independent, addressable Object; roster only groups them
and asserts that they are a participant list.
Each member Object's own content carries its participation detail (for example role, or an
event rsvp_status). roster does not define those fields — they belong to whichever Service
produced the Objects — and it does not imply how the list should be displayed: whether members are
grouped by role or RSVP status, how a long roster is truncated, or any other treatment is a Runtime
rendering decision made from the generic roster type, not part of what a roster Collection
asserts. This keeps roster reusable for any participant list without tying the canonical type to
one domain's model.
Example of an instance:
{
"collection": {
"id": "collection:event:88:roster",
"type": "roster",
"content": {
"count": 14
}
}
}
Meaning:
This Collection's member Objects (referenced via the Collection's items) are the people
participating in a parent Object — for example the guests of an event, each member Object carrying
its own role or RSVP status in its content.