UserPreferences

ConceptualModelRevisited


(Note: the revised conceptual model has been split off into the [Wiki]DocumentMode RevisedConceptualModel, leaving this page open for [Wiki]ThreadMode about arbitrary conceptual model revisions).

"In many ways, 'entry' appears to be an action or event that occurs to a resource more so than it is the resource itself." - WhatIsAnEntry

This points to the fact that the ConceptualModel--and the EntryModel in particular--is broken. Hence, for example, the RevisedConceptualModel. In the revised conceptual model, events are not entries, entries are very flexible in both what they represent and what they can take as properties, and everything is weblog agnostic.

Events are Not Entries!

A little more about the problem that started off the conceptual model revision proposal...

Since an entry can be published on more than one occasion, it is clear that a publication event is a property of the publishing forum, and not the entry itself.

For example, Bob writes an article about pigeons. He has a rough draft on his server at [WWW]http://example.org/pigeons. He then sends out the article for publication by super.blog and pigeonsweekly.blog. super.blog republishes his work as a page on their own site, and pigeonsweekly just point back to Bob's original content. That's quite a mess. Bob may have a feed on his weblog, as may super.blog and pigeonsweekly.blog.

Under the revised conceptual model, each weblog would have a publication event corresponding to when the weblog published Bob's article. super.blog might want to include the article in a content encoded element, whereas Bob and pigeonsweekly.blog might both want to point to bob's original.

One article, two publication locations, three publication events.

Comments

[BryantDurrell, RefactorOk] Seems like it complexifies matters from the user's point of view. In particular, GUID namespace problems loom larger. You can't just let your tools generate GUIDs anymore; you need to worry about manually setting GUIDs to account for republished articles, etc., etc. Also, parsing becomes slightly more complex in that you can't just chew through a feed. While it's true that the ConceptualModel as outlined is not general-purpose, the art of specification design is finding a balance between the particular needs of the practices one's trying to define and generality. This strikes me as too general.

[PhilWolff, RefactorOk] Is there room in this model for EntryLifeCycle attributes?


CategoryModel