Containers (synonym: collection) are objects that hold multiple Entries for any purpose.

This draws on discussion in GeneralizingEntry, EntryChannels, SiteAndSyndication, Related, Categorization

For comparison, DublinCore suggests a different(?) model for "containers". Instead of thinking of "an entry is a container of other things", DublinCore treats all resources as "equals". "Containment", per se, is supported by relating an entry to other entries, including, depending on direction, 'isPartOf' or 'hasPart', and 'isReferencedBy' or 'references'.

Containers work the same way. A Container and Entry are peer resources. An Entry is Related to the Container; the relation is "containedBy".

Yes, an Entry can be a Container because it can be Related to multiple Entries, but that's not the goal here. Container is defined here only as a way to allow an Entry to relate indirectly to other Entries that share the same Container.

JasonHx In an Entry-based storage layer, Containers == functional axes in the application == Controllers in MVC terms. Keep in mind that some containers that people may be thinking of are artifacts of the capital-v View. All of the containers above are describable in XPath-like syntax from either the virtual root node of a collection or a given entry:

Example Containers

Container Use-cases Non-normative pseudocode containers
Current entry notices from one author, like a weblog feed*).since(time)
Current entries from one author, like a weblog front page
Archive entries from one author, like a weblog archive*).sincethrough(starttime, stoptime)
Current entries from several authors constituting a thread entry/#(*).recent(20)
An arbitrary group of related entries, like a list or outline. entry/#list
An export file for transferring entries to another host entry/*?style=csv.xsl

To generalize, other Containers aren't so obvious but fit the pattern

Container compared to EchoFeed

'Containers is a very simple abstraction: Entry is Related to Container. There's two important differences between the EchoFeed approach (reimplementing RSS) and the Related approach.


[Skware] +1 on this. This matches my thinking over the last few days it relegates the orginisation of the blog to the CMS, allowing things like date archives, heirarchical categorisation, ... to be used. This possibly combined with something similar to Related would easily allow a photoblog that shows multiple photos in a collection, but still allow comments / permalinks to individual entries. It matches human nature to be able to think of a photo album more conceptually than a particular photo. For instance: people remember that the photo they want is in the birthday party collection of photos, rather than remembering that it was the 6th photo taken on the 24th of June 2003.)

[MikeD] How does a 'container' differ from a 'collection'? What happens to each Entry within a Container when you delete the Container? Are there two kinds of Container resources - one that removes contained Entries and one that does not?

[PhilWolff] Can a container hold/cite things besides an Echo entry?

[BillSeitz] - for sites that don't end up with any feed (e.g. Blogger sites, Zeldman's?), would there be other things that would be helpful, like containing each item within "a name" tags?

[DannyAyers] I like the general idea of containers here, another kind that should be considered is for holding blogrolls (lists of feeds), similar to that done by OCS and OPML

CategoryArchitecture, CategoryModel