Sam's [WWW]charge was to "Let everyone know what are essential requirements for your application." In other words generalize the concept of entry until it's ugly and overloaded, then trim it until it's elegant. In still other words, we're looking for the outer boundaries of what Entry is. Why do that? To reconcile as many applications as possible and to enable client software that can combine entries from many models and unify them in the user's experience.

We can take this further than to just model the WellFormedEntry:

See also: UseCases, ComponentBlog (making generalization commonplace)

Weblog interoperability

Goal: Provide data structure to support a wide range of weblog applications.

Task: Look for a complete description of an entry including optional data structures for prospective applications - the process so far in this wiki.

See eg RoadMap

Conversation app interoperability

Goal: Provide data structures will support a wide range of applications beyond weblogs - eg wiki page, email message, discussion board post ....

Task: Look at things similar to a log entry and make comparative analogies. If there is a reasonable mapping between two models, expand the notion of log entry to accept it.

See eg WikiPageAsEntry

Conversation app component interoperability

Goal: Agree on a high-level design of the entry's environment in order to expose common application structures.

Task: Look the other objects in the entry's environment and the relations among these objects. Generalize to define abstract base classes as a foundation for application components.

See Related, Containers

See also EntryChannels, SiteAndSyndication "internal vs external data model", WellFormedEntryModelDiscussion "associative model"

Pushing this entry-centric (nice ring!) approach leads to a conceptual design with

isn't the talk of controllers and views jumping into implementation details a little? This may be useful to help with descriptions, but the impression I get from the RoadMap is that we're meant to be looking at the model here

Agreed. MVC is for conceptual design to help compare various architectures. No implementation presumptions.

Note that the definition of entry/document in the RevisedConceptualModel is very broad; cf. [WWW]foaf:Document, [WWW]doc:Work.