Subject: Re: Q: modfied vs issued vs created

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 11 Jul 2004 03:37:07 +0200

On Sat, 10 Jul 2004 14:07:41 +1000, Eric Scheid  
<[email-masked]> wrote:

>     As of 2pm two days ago,
>     the weather report for today is [blah].
>
>     As of 2pm today,
>     the weather report for today is [not blah]
>
> same entry

No, that's not the same entry. They both talk about different things.  
Someone might find a reason to use the same entry for both events and  
«stories», but that's abuse of the initial entry and not something Atom  
should either support or recommend.

> different issue dates

It should have been different entries as well.

> the latest is more interesting than the earliest.

That is something I can agree with. To take your example a little further:  
«Tomorrow will be a fun day» is _not_ the same entry as «Yesterday was a  
fun day».

-- 
Asbjørn Ulsberg         -=|=-        [email-masked]
«He's a loathsome offensive brute, yet I can't look away»

---

From: Eric Scheid <[email-masked]>
Date: Sun, 11 Jul 2004 12:00:06 +1000

On 11/7/04 11:37 AM, "Asbjørn Ulsberg" <[email-masked]> wrote:
> On Sat, 10 Jul 2004 14:07:41 +1000, Eric Scheid wrote:
>>     As of 2pm two days ago,

They are both talking about the same thing: the weather report for Sat, 10
Jul 2004. Typically, when a weather report is issued, it replaces the
previous report for that the date covered -- and I'm talking real-world
(non-atom) here. You thus wouldn't have a feed with two (differing) weather
reports for the same date.

Deleting the old one and inserting the new one will only annoy the user --
if the prognosis hasn't actually changed they will still be presented with a
"new, unread" weather report, and one which they can't compare to the old
(because it's been deleted).

e.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Sun, 11 Jul 2004 16:16:59 +0200

On Sun, 11 Jul 2004 12:00:06 +1000, Eric Scheid  
<[email-masked]> wrote:

> They are both talking about the same thing: the weather report for Sat,  
> 10 Jul 2004.

They have the same topic; yes, but they are two different stories. If you  
don't see that, I don't think we can ever reach any agreement on this  
matter.

> Typically, when a weather report is issued, it replaces the previous
> report for that the date covered -- and I'm talking real-world (non-atom)
> here.

I know that's how it seems like for the audience. But having worked with  
The Meteorological Institute in Norway (my company is a big client of  
their services) I know that their internal data model stores each of these  
events seperately (for how long, I'm not sure, but they do for at least a  
couple of days). A new forecast doesn't overwrite an old one, even if  
they're reporting the same weather at the same time at the same place.

> You thus wouldn't have a feed with two (differing) weather reports for
> the same date.

I agree that having two entries saying different things in the feed at the  
same time is confusing and shouldn't happen, but there's absolutely no  
fuzz with just removing the old weather report and inserting the new one  
-- effectively replacing it in the feed. The entry will have a new ID  
though, and it will have different dates.

> Deleting the old one and inserting the new one will only annoy the user

Why? Do you really think a user cares whether the ID has changed or not?  
If anything, the entries should be related (<link rel="related"> or  
something), but they are, and never will be, the same entry.

---

From: Eric Scheid <[email-masked]>
Date: Mon, 12 Jul 2004 02:14:11 +1000

> they're reporting the same weather at the same time at the same place.

(1) I did my uni time on VAX/VMS, complete with a versioning file system
(handy for all that COBOL programming I did ... saints preserve me!). A
database that retains a multiple number of older versions is not that
different. Consider too your typical wiki -- any given page can have
multiple versions held. In each of those three cases, we're talking about
the same "thing", they just happen to have multiple versions.

(2) "I know that's how it seems like for the audience". Isn't that what we
should be modelling for? The technical arcana inside the guts of the
publishers' system is of zero interest to most users, surely?

> something), but they are, and never will be, the same entry.

They would be annoyed because they would see a "new" entry (because it has a
new ID), even though it is actually a weather report for the same node in
4-space. Right now my aggregator of choice advises me of modifications to a
given entry in the same way it would of a new entry - the entry title
appears in blue and bold. I'm hanging out for a future version that
differentiates modifications of old entries from completely new entries.

e.

---

From: Walter Underwood <[email-masked]>
Date: Sun, 11 Jul 2004 14:24:40 -0700

--On Sunday, July 11, 2004 4:16 PM +0200 Asbjørn Ulsberg <[email-masked]> wrote:
> On Sun, 11 Jul 2004 12:00:06 +1000, Eric Scheid  <[email-masked]> wrote:
>
> They have the same topic; yes, but they are two different stories.
> If you  don't see that, I don't think we can ever reach any agreement
> on this  matter.

"Current weather" is a valid web resource. It might change every
second.

Whether that web resource is a good Atom entry is a different
question.

We still need to work on what kind of web resource an Atom entry is.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Ken MacLeod <[email-masked]>
Date: 11 Jul 2004 16:43:13 -0500

> We still need to work on what kind of web resource an Atom entry is.

There's been some work in that area in AtomTerminology,

    http://intertwingly.net/wiki/pie/AtomTerminology

The current definition (sans Atom implementation) of Entry reads,

     A principal published resource that is part of a set or series,
     such as would appear in a front page "news", a digest,
     hierarchical sitemap or index, or news box.

Please note well: I am *not* against having Atom <entry> elements, or
feeds for that matter, being used for things that work well in
aggregators.  I'm not particularly against using feeds/entries for
some things that don't work well in aggregators specifically, as long
as they're well marked.

The only thing I'm against is making feeds and entries completely
generic resource records, there are far better ways of doing that.

The definition above can be matched by similar definitions of other
things that can also be mapped to atom:entry, or maybe we can change
the above term for "entry" into, say, "Syndication entry" to indicate
the above usage, and reserve the unqualified "entry" for whatever we
determine atom:entry is.

  -- Ken

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 12 Jul 2004 00:37:51 +0200

> "Current weather" is a valid web resource. It might change every

Yes.

> Whether that web resource is a good Atom entry is a different

Each update of the resource is a valid and good Atom entry, but it's not  
the _same_ entry for each update.

> We still need to work on what kind of web resource an Atom entry is.

Feel free to edit AtomTerminology with what you think an Atom entry is or  
should be, but please tell the list if the changes you make are major.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 12 Jul 2004 06:26:37 +0200

On Mon, 12 Jul 2004 02:14:11 +1000, Eric Scheid  
<[email-masked]> wrote:

> (2) "I know that's how it seems like for the audience". Isn't that what  
> we should be modelling for? The technical arcana inside the guts of the

I don't know what other people's agenda is, but my goal is to influence  
Atom to be usable in some EU projects I, through my company, am involved  
in, as well as for the needs my company and myself have in regard to  
syndication of news. I'm also a notorious non-pragmatist and a Draconian  
bastard, and try to aim as high as possible and rather end on the second  
top shelf, instead of aiming at the middle and ending at the second  
lowest. :-)

PaceSupersede[1] has been created to accommodate some of my and other's  
needs in this regard.

> They would be annoyed because they would see a "new" entry (because it  
> has a new ID)

The new entry would supersede the old one, and thus leaving it up to the  
client what to do with this information. Also, I wouldn't be annoyed to  
get an update when the weather forecast changed from saying «at 18:00,  
there will be sun and great weather» to «at 18:00, there will be a deadly  
storm annihilating everything in its path».

> I'm hanging out for a future version that differentiates modifications
> of old entries from completely new entries.

Wouldn't it be better to differentiate between minor and major updates?  
You mostly don't care about typographical erratas, but if the entry has  
been completely rewritten, has become six sections longer and so on, you'd  
probably want to be notified.

Atom currently doesn't support «minor» and «major» changes; everything is  
just «changes» and all changes will (or at least should) update the  
'atom:modified' date.

____
[1] <url: http://intertwingly.net/wiki/pie/PaceSupersede>

---

From: Graham <[email-masked]>
Date: Mon, 12 Jul 2004 00:46:31 -0400

On 12 Jul 2004, at 12:26 am, Asbjørn Ulsberg wrote:

> PaceSupersede[1] has been created to accommodate some of my and 
> other's needs in this regard.

I agree with the idea of the Pace, but completely disagree with 
changing the atom:id of the entry. What is the point of the id if not 
to link different versions of the same entry? There's a 1:1 
relationship here. A major change should result in a new atom:issued 
under PaceEntryDates.

Secondly, the atom:supercedes element itself appears to point to only 
the previous version. What if two major changes happen between polls? 
The aggregator can't follow the thread. The solution here is to... have 
a single id that appears in all versions of the entry.

-1

Graham

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 12 Jul 2004 07:03:40 +0200

On Mon, 12 Jul 2004 00:46:31 -0400, Graham <[email-masked]> wrote:

> changing the atom:id of the entry.

You're not changing the ID of the entry. You're issuing a _new_ entry,  
with of course, a new ID.

> What is the point of the id if not to link different versions of
> the same entry?

Being able to identify an entry by its ID is totally orthogonal to being  
able to see different versions of the entry at the exact same ID. With  
PaceSupersede, entries will be related through the atom:supersedes  
element, and a superseding entry could be abstractly considered to be the  
same entry, in some sense.

> A major change should result in a new atom:issued under PaceEntryDates.

Oh god, no!

> the previous version. What if two major changes happen between polls?

Good question which I should look into.

---

From: Graham <[email-masked]>
Date: Mon, 12 Jul 2004 01:08:22 -0400

On 12 Jul 2004, at 1:03 am, Asbjørn Ulsberg wrote:

> Being able to identify an entry by its ID is totally orthogonal to 
> being able to see different versions of the entry at the exact same 
> ID. With PaceSupersede, entries will be related through the 
> atom:supersedes element, and a superseding entry could be abstractly 
> considered to be the same entry, in some sense.

What does supercedes offer that linking all major and minor versions by 
the same atom:id doesn't? Wouldn't a more direct approach to versioning 
be better - version ids or version numbers?

Graham

---

From: Eric Scheid <[email-masked]>
Date: Mon, 12 Jul 2004 17:49:50 +1000

> just «changes» and all changes will (or at least should) update the

Atom does support minor/major changes: if the modified date changes, but the
issued date doesn't, then it's a minor change. If the modified date changes,
and the issued date does too, then it's a major change. If the modified date
doesn't change, but the issued date does, then you can consider it
assertively no changes (but no longer old news).

(the fourth combination where neither changes means it's old news, caveat
emptor)

e.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 12 Jul 2004 12:14:03 +0200

On Mon, 12 Jul 2004 01:08:22 -0400, Graham <[email-masked]> wrote:

> the same atom:id doesn't?

«Linking these» ID's effectively overwrites old versions with new ones.  
Superseding them keeps every version intact.

> Wouldn't a more direct approach to versioning be better - version ids
> or version numbers?

Nah, too complicated. PaceSupersede isn't supposed to solve versioning,  
nonetheless.

---

From: "Arve Bersvendsen" <[email-masked]>
Date: Mon, 12 Jul 2004 15:07:19 +0200

On Mon, 12 Jul 2004 17:49:50 +1000, Eric Scheid  
<[email-masked]> wrote:

> Atom does support minor/major changes: if the modified date changes, but  
> the issued date doesn't, then it's a minor change. If the modified date  
> changes,and the issued date does too, then it's a major change. If the  
> modified date doesn't change, but the issued date does, then you can  
> consider it

The "issue" date is the date of "formal issuance" (e.g initial  
publication) and should _never ever change._ [1] If the issued date  
changes, it is no longer the same entry. Hence, a new ID and a superesede  
mechanism.

That the current blog-like CMSes doesn't handle this, should be no excuse  
for not adding such a mechanism.  Old systems, like MT, will happily go on  
working the way they do.

-- 
Arve Bersvendsen

http://www.virtuelvis.com
http://www.bersvendsen.com

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 12 Jul 2004 15:20:17 +0200

On Mon, 12 Jul 2004 17:49:50 +1000, Eric Scheid  
<[email-masked]> wrote:

> changes, and the issued date does too, then it's a major change.

atom:issued should _never_ change. Period. Alas, Atom does not have  
support for minor and major changes.

> If the modified date doesn't change, but the issued date does, then you
> can consider it assertively no changes (but no longer old news).

What's the use case for this? What you're really should be doing here is  
alter 'modified' and keep 'issued' the same. Then, it's up to the client  
to choose to show this modification or not. As we don't have a  
supersede-mechanism at the moment, there's no way to separate major  
changes from minor, so users  will either have to choose «show all  
changes» or «never show changes».

> (the fourth combination where neither changes means it's old news, caveat

If it's old news, would you ever find it in a feed? An archive feed,  
perhaps?

---

From: Robert Sayre <[email-masked]>
Date: Mon, 12 Jul 2004 09:27:55 -0400

Eric Scheid wrote:

>and the issued date does too, then it's a major change. 
>  
>

There is nothing in the spec to this effect, and that's not what 
dc:issued means.

Robert Sayre

---

From: Ken MacLeod <[email-masked]>
Date: 12 Jul 2004 08:36:56 -0500

Eric Scheid <[email-masked]> writes:

> Atom does support minor/major changes: if the modified date changes,
> but the issued date doesn't, then it's a minor change. If the
> modified date changes, and the issued date does too, then it's a
> major change. If the modified date doesn't change, but the issued
> date does, then you can consider it assertively no changes (but no
> longer old news).

This behavior is not described in the current spec or any proposals
that I'm aware of.  Are you proposing this behavior?

I'm -1 on any proposal for *core Atom* that seeks to propose
information that indicates "meaningful change".

"Meaningful change" can only be interpreted by a human, and this
particular informational indicator is one that requires a significant
amount of discipline to achieve.  The chances of this happening enough
in the general population of publishers is near nil, which makes it a
very unlikely feature to be supported by clients.

I would favor an "editing" extension (mod_editing) that provided terms
for the purpose of indicating "meaningful change", because the
likelyhood of someone adopting and using mod_editing significantly
increases the likelyhood that they have a "publishing process" (note,
not "system") that includes enough discipline to properly indicate
meaningful change.  That's something clients can depend on.

Note, mod_editing could also include the "supersedes" functionality
being described in another thread.

  -- Ken

---

From: Ken MacLeod <[email-masked]>
Date: 12 Jul 2004 11:04:26 -0500

Ken MacLeod <[email-masked]> writes:

> I would favor an "editing" extension (mod_editing) that provided
> terms for the purpose of indicating "meaningful change", because the
> increases the likelyhood that they have a "publishing process"
> (note, not "system") that includes enough discipline to properly
> indicate meaningful change.  That's something clients can depend on.

Another possible solution is a "date discipline" profile indicator.
Atom core would define the dates using the precisely imprecise Dublin
Core definitions, and a "date discipline" profile would indicate a
site's self-certification of conformance to a stricter profile.

<entry>
  <profile:date-discipline xmlns:profile="http://purl.org/atom/profile/date#"/>
  <title>Created will be present and will not change, etc.</title>
  <created>2004-03-11T12:13:14Z</created>
  ...
</entry>

  -- Ken

---

From: Eric Scheid <[email-masked]>
Date: Tue, 13 Jul 2004 02:30:09 +1000

> that I'm aware of.  Are you proposing this behavior?

Since the spec is silent w.r.t. interpreting various combinations of changes
in issued/modified, then yes, I am proposing this. Looks like I'm stuck with
being the one to write the pace.

> amount of discipline to achieve.

not to mention honesty and integrity. Anyhow, someone lacking in any of
those qualities could still push through a major change as a "minor change",
sneaking it under the radar. No system or process can stop that. Even the
Newspapers Of Record have a hard time guaranteeing that.

Bottom line - do we need a more complicated and more granular mechanism for
indicating change (assuming veracity)? I'd say no, not for _atom-core_. If
some environment needs more finesse, then they can use mod_editing or
similar. 

e.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 13 Jul 2004 02:30:06 +1000

On 12/7/04 11:20 PM, "Asbjørn Ulsberg" <[email-masked]> wrote:

> alter 'modified' and keep 'issued' the same.

then how would you distinguish that from a minor change, which has the same
pattern?

> Then, it's up to the client

we do if we use modified and issued as I've outlined. We've got expressions
of minor change, major change, no change, and old news confirmed to be
current news.

> If it's old news, would you ever find it in a feed? An archive feed,

There's more than a few rss/atom feeds I could point you to which have
entries from more than 48 hours ago. That's news old enough to wrap fish in.

e.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 12 Jul 2004 18:35:08 +0200

> site's self-certification of conformance to a stricter profile.

I'm not sure yet, but I think I like this proposal. I'll have to let it  
sink and digest some before I make up my mind, but I think it's the best  
solution to what we currently have, when I can't have «trustworthy»  
required data in the Atom Core.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 12 Jul 2004 19:21:45 +0200

On Tue, 13 Jul 2004 02:30:06 +1000, Eric Scheid  
<[email-masked]> wrote:

> then how would you distinguish that from a minor change, which has the  
> same pattern?

Exactly. You can't.

> we do if we use modified and issued as I've outlined.

That's not a good idea, imho, so I have to give a -1 to that proposal.

> We've got expressions of minor change, major change, no change, and old
> news confirmed to be current news.

To me, it's a lot more important to have «initial creation or publish  
date» than to be able to separate minor and major changes. Therefore, I'd  
rather see a static non-changed atom:issued than a dynamic «I'll change  
all the time»-atom:issued.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 13 Jul 2004 03:33:37 +1000

>> then how would you distinguish that from a minor change, which has the

Thank you, my point exactly. What you propose above doesn't let us
distinguish an interesting change from a trivial change, by smushing the two
together. I propose a means to differentiate the two types of changes, and
that is to our benefit.

> all the time»-atom:issued.

Then you'll need to write some spec text explaining what an aggregator
should do if it does happen to come across with an entry where <modified> is
after <issued>. 

I'm saying:

    <modified> changed = the entry has changed in some way
    <issued> changed = pay attention!

At the root of it all I'm just not convinced that <issued> shouldn't be
changeable. I can see however some utility in an optional <first-issued>.

e.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 13 Jul 2004 04:03:18 +1000

> should do if it does happen to come across with an entry where <modified> is

sorry - ignore this bit ... I wrote a longer paragraph to explain why that
would be necessary, thought better of it, deleted that paragraph, and left
this stupid bit in. sorry sorry sorry. It is (subjective time!) 04:00 here.

What an aggregator should do, in a world where entries are modified but
never re-issued, is simply mark the entry as modified. It would be up to the
user not to get annoyed at trudging through endless dreck of trivial
changes, instead being required to make that judgment call themselves every
time (despite the author's frustration in not being able to signal that with
a minor/major semantic). Bah, cranky eric needs sleep.

I can imagine an aggregator could present the user with general +
feed-specific preferences: show all changes, hide minor changes, hide all
changes. If the user doesn't trust a certain author's judgment as to what is
minor or major, then they wouldn't use that hide-minor preference.

e.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 12 Jul 2004 20:19:51 +0200

On Tue, 13 Jul 2004 03:33:37 +1000, Eric Scheid  
<[email-masked]> wrote:

> What you propose above doesn't let us distinguish an interesting
> change from a trivial change, by smushing the two together.

No, but what _does_ let us distinguish minor from major updates, is  
PaceSupersede. The current Atom model just can't provide the information  
needed to differ between minor and major updates.

> should do if it does happen to come across with an entry where  
> <modified> is after <issued>.

Uhm. Wouldn't that be the 99% use case? The user should be able to choose  
if she wants changes to have entries reappear in bold text or whatever her  
client does. If we support supersedes, though, a user can choose what to  
do with minor and major updates as well as still be able to find out when  
the entry she's looking at was (first) issued. She can then also in a  
relatively simple manner browse backwards in the history of that  
particular entry to see the individual updates of it.

> <modified> changed = the entry has changed in some way

Yup. This is what I'm saying as well.

> <issued> changed = pay attention!

<issued> should not change. Ever.

> I can see however some utility in an optional <first-issued>.

If someone just dies if they can't change their atom:issue date, I think  
we would need 'first-issued', yes.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 13 Jul 2004 04:39:47 +1000

On 13/7/04 4:19 AM, "Asbjørn Ulsberg" <[email-masked]> wrote:

> The current Atom model just can't provide the information

Only if we assume <issued> can't change.

If it can change, then we have all the information we need to communicate
minor change, major change, old news, and old news asserted to be still
valid. Pretty handy that.

e.

---

From: Ken MacLeod <[email-masked]>
Date: 12 Jul 2004 14:11:33 -0500

Eric Scheid <[email-masked]> writes:

> > The current Atom model just can't provide the information needed
> > to differ between minor and major updates.
> 
> If it can change, then we have all the information we need to
> communicate minor change, major change, old news, and old news
> asserted to be still valid. Pretty handy that.

Based on empirical evidence from wikis that implement that feature, I
would say that this would only work for a very few feeds from
individuals or groups that have a relatively high level of discipline.

I can see us specifying "reissued" would be a purpose for changing
<issued>, but I would still expect clients to provide the user the
option of selecting either of <issued>, <modified>, or <modified>+diff
for determining redisplay on a feed-by-feed basis.

Is this consistent with your proposal?

  -- Ken

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Mon, 12 Jul 2004 23:01:39 +0200

> Only if we assume <issued> can't change.

Why would one assume anything else? From where did the idea that  
atom:issued could be randomly updated, surface?

> valid. Pretty handy that.

We then loose a mechanism to tell when that particular entry was first  
issued. It's not all gain. With PaceSupersede, however, you get  
«everything» we've talked about in regard to minor and major changes, but  
don't redefine the DC dates (as specified in Atom, or in general) at all.

With PaceSupersede one could say that if you want to re-issue an entry,  
use the mechanisms described here. If you want to indicate that a major  
update has been done, use the mechanisms described here. If not, don't  
care about what is written here. Most users can ignore PaceSupersede.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 13 Jul 2004 13:14:47 +1000

On 13/7/04 5:11 AM, "Ken MacLeod" <[email-masked]> wrote:

> Based on empirical evidence from wikis that implement that feature

wikis are not the best example to model blogging behaviour.

That is to say, if blogging tools had a checkbox for "this is a minor
change" then I'd expect to see more accuracy than you would on a wiki.

Come to that, I'd expect to see more accuracy if the default was minor
change and the author had to select an option to "re-issue" it. That is, if
the option said "this is a major change" instead of "this is a trivial
change". Afterall, who wants to fuss with setting flags and stuff when
you're only doing a trivial change? Good defaults make good practice.

> for determining redisplay on a feed-by-feed basis.

what is <modified>+diff? oh ... you're talking about the feed-reading user
:-)

> Is this consistent with your proposal?

Yes. Similar to how the feed-reading user may want to select local-time vs
author-time for display on a feed-by-feed basis.

e.

---

From: Eric Scheid <[email-masked]>
Date: Tue, 13 Jul 2004 14:13:04 +1000

> atom:issued could be randomly updated, surface?

The spec was silent on the matter. It is observable practice (good or bad)
that people do "re-issue" entries with updated content. It is also
observable that most people don¹t ever re-issue the vast majority of their
entries, so the question is moot for most cases.

> We then lose a mechanism to tell when that particular entry was first
> issued.

If we need a tighter/narrower definition, then perhaps we need a new element
specifically for that purpose. It makes more sense to have a [generic]
<issued> and a [specific] <first-issued> than to have a [specific/narrow]
<issued> and a [wider] <latest-issued>.

Alternatively, we could simply have <issued>+ in the spec. That is, "one or
more", which shows not only the first issuance, but any subsequent major
re-publishings. When I look in the frontspiece of a dead-tree book I can
usually find a list of prior editions.

e.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 13 Jul 2004 21:25:10 +0200

On Tue, 13 Jul 2004 14:13:04 +1000, Eric Scheid  
<[email-masked]> wrote:

> The spec was silent on the matter. It is observable practice (good or  
> bad) that people do "re-issue" entries with updated content.

Okay.

> It is also observable that most people don¹t ever re-issue the vast
> majority of their entries, so the question is moot for most cases.

True.

> If we need a tighter/narrower definition, then perhaps we need a new  
> element specifically for that purpose. It makes more sense to have a
> [generic] <issued> and a [specific] <first-issued> than to have a
> [specific/narrow] <issued> and a [wider] <latest-issued>.

What I'm having just as much trouble with, is the idea that 'issued', no  
matter what the element is called, is a subjective date of issuance, when  
Dublin Core explicitly says it's the _formal_ date of issuance (or  
publication).

Note that «August issue» of «Sports Illustrated» is nothing but a title.  
'issued' is when it reaches your local store (approximately). Also note  
that 'issue' is a noun, while 'issued' is a verb describing an action. The  
noun and the verb, in metadata context, is not related.

> Alternatively, we could simply have <issued>+ in the spec.

Yes, I've thought about that as well. I think it's a good solution.

> When I look in the frontspiece of a dead-tree book I can usually find
> a list of prior editions.

Yup. That's why Dublin Core has a 'relation'[1] element, which is to be  
used for re-issues of a resource. It seems that none in the Atom community  
wants that though, because that forces one to change the ID of an entry  
when it has undergone «major changes» and is re-issued.

____
[1] <url: http://dublincore.org/documents/relation-element/>

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Tue, 13 Jul 2004 22:34:50 +0200

On Tue, 13 Jul 2004 13:14:47 +1000, Eric Scheid  
<[email-masked]> wrote:

> change and the author had to select an option to "re-issue" it. That is,  
> if the option said "this is a major change" instead of "this is a trivial
> change".

Absolutely. +1 on that. A re-issue should, however, not just update  
'issued', but truly re-issue the entry with a new ID and a <relation>  
element that has an attribute 'is-version-of' that points to the old  
version.