Re: a methodical approach to defining what date elements we need

[Antone Roundy <antone@xxxxxxxxxxxxxx>]

On Tuesday, July 13, 2004, at 03:49  PM, Sam Ruby wrote:
> > I'm now convinced that it would be better to use just two:
> > Issued = when I published the essay
> > Modified = when I last changed any of the bits in the entry.
> > If I make a "significant" change, I should
> > 1. Create a new entry with a new ID and new dates
> > 2. Indicate that this new entry dcterms:replaces the original.
> > 2. Update the original to say it's been dcterms:isReplacedBy the new 
> > one.
> > It's more work, but it'll make for a better historical record.
>
> It's not much more work for you, but it is much more work for 
> consumers.
>
> Consider that a typical aggregator polls for data.  If you replace an 
> entry twice, and the aggregator missed the first one, then it has an 
> incomplete history to reconcile.
This, and the fact that people ARE going to republish heavily modified 
entries without creating a new one are my big reasons for not favoring 
any kind of "replaces" system.  I'd prefer a modified (big 
change)/updated (small change) combo, which hopefully would be simple 
enough to create a UI for (like someone suggested, default to small 
change and have a checkbox to indicate a big change), and if so, would 
encourage people to differentiate between little fixes and big changes.

On the other hand, that same UI could control whether an entry is 
updated or replaced (though it's greater complexity might result in 
some developers not supporting it).

Anyway, to me, the benefit just doesn't outweigh the much greater 
complexity for the consumer.