Subject: Re: Q: modfied vs issued vs created

From: Graham Parks <[email-masked]>
Date: Sat, 03 Jul 2004 21:41:50 +0100

On Saturday, July 03, 2004, at 08:41PM, Asbjørn Ulsberg <[email-masked]> wrote:

>On Sat, 3 Jul 2004 14:49:09 -0400, Graham <[email-masked]> wrote:
>
>> You make a good point here, but go after the wrong solution. If an
>> article is reissued, <issued> no longer represents the creation date.
>
>Then we can't say that in the specification. Issued is issued, and never  
>'created', and they will never share any semantics, whatsoever. They are  
>of the same data type, but that's it.

Fair point.

>That's really of no interest to anyone. If someone would like to know when  
>an article was created, they SHOULD NOT be encouraged to look at the  
>'issued' date, if that date is bound to change every other minute.

Well I think I'm allowinf for that - I'm warning publishers of the assumptions consumers will make if metadata is ommitted. There might be a better way to word it.

>To take an example, Movable Type first creates an article, and then  
>publishes it first when the user hits [Save] with the status set to  
>'Publish'. I'm not sure how the internal structure of MT is, but there's  
>at least no problem with having the first created date saved somewhere.

Yes, but that's MT. The one date (and event) all systems publishing Atom will be able to record is the date that the content was actually issued.

>If it is how you say, that publishers tend to re-publish old entries, of  
>course it is interesting to know when the entry was first written. It is  
>about context. If you write something about the internet in 1996 and then  
>re-issue the same article in 2004, it would actually be nice to have some  
>idea of when the article was originally written. If the only date you  
>receive is '2004-07-03', the readers will look very skewed on it when they  
>read how you explain about great technology like «browsers», «HTML» and  
>the likes.

Well, it's up to the publisher to provide that information in those cirumstances. I don't think it matters which is most interesting, though, it's what publishers have and consumers need.

>However, if you edit the article, and publish it again, with a time span  
>of two weeks, the article should not get a new 'issued' date, but an  
>updated 'modified' date.

Why not? The intention of <issued> in PaceEntryDates is just that (provided the publisher actually wants to reissue the article, and wasn't just correcting a typo).

>Uhm. What is it that he reuses? The ID's of the entries, or the content?

He'd rather add something new to an old article, where most reissue the entry.

>> Why not just use the modified date? Because almost everyone else who
>> modifies old entries isn't trying to reissue them.
>
>I have no idea whatsoever you're trying to say here. Would you care to  
>elaborate a bit more, please?

In Blogger and propably MT and probably most other things, if I go and edit and old article, it *does not* jump back on to the front page. It's been <modified>, but it hasn't been <reissued>.

>I work in one of Norways largest news publishing corporations, and I will  
>make a very strong claim that it's a lot more important to be able to  
>modify an issued article, and reflect that in the Atom entry (but preserve  
>the original 'created' date), than to re-issue a really old article and  
>reflect that with an updated 'issued' date.

You're talking as if PaceEntryDates removes the <created> field. They're all still available. As I said before, issuing is the only event that all systems will have in common, and is therefore the only date that can be mandatory.

Graham Parks

---

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

On Sat, 03 Jul 2004 21:41:50 +0100, Graham Parks <[email-masked]> wrote:

> You're talking as if PaceEntryDates removes the <created> field.

No, not really. I'm more talking of that it's important that if <issued>  
is going to exist as an alternative for <created>, then <issued> MUST  
NEVER be updated, changed or fiddled with after it's first set.

> As I said before, issuing is the only event that all systems will
> have in common, and is therefore the only date that can be mandatory.

True, but I don't think it's a good idea to not only allow, but to  
encourage, publishers to update this field whenever they reissue the  
article. If so, we should have both <first-issued> and <last-issued>  
elements.

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

---

From: Walter Underwood <[email-masked]>
Date: Thu, 08 Jul 2004 09:00:24 -0700

> NEVER be updated, changed or fiddled with after it's first set.

Never? Even if there is a mistake in the issued date? The server is
required to send the wrong date forever?

I would prefer "published" instead of "issued" by the way. Blog
software mostly talks about publishing entries, not issuing them.

wunder
--
Walter Underwood
Principal Architect, Verity

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 08 Jul 2004 20:44:13 +0200

> required to send the wrong date forever?

Of course not. I'm sure you know what I'm talking about. The <issued> date  
should not change once it's first set (correctly).

> software mostly talks about publishing entries, not issuing them.

I know, but we're trying to be conformant with Dublin Core which uses the  
term 'issued'.

---

From: Graham <[email-masked]>
Date: Thu, 8 Jul 2004 17:28:58 -0400

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

> No, not really. I'm more talking of that it's important that if 
> <issued> is going to exist as an alternative for <created>, then 
> <issued> MUST NEVER be updated, changed or fiddled with after it's 
> first set.

Not necessarily. The other way to do it is to say that you must also 
supply a <created> date if you change <issued> - or in other words, 
<created> is required if it differs significantly from <issued>.

> article. If so, we should have both <first-issued> and <last-issued> 

I'd imagine <first-issued> ~= <created> would be true in most cases. 
And anyway, I don't think it's necessary for entries to include their 
full history - do they also have to supply details of older revisions?

Graham

---

From: Beecher Greenman <[email-masked]>
Date: Fri, 09 Jul 2004 07:59:44 -0400

Asbjørn Ulsberg wrote:

> 
> On Thu, 08 Jul 2004 09:00:24 -0700, Walter Underwood 
> <[email-masked]>  wrote:
> 
> Of course not. I'm sure you know what I'm talking about. The <issued> 
> date  should not change once it's first set (correctly).

Perhaps there should be some kind of clarification on when <issued> 
should change, in that case? The real-world issue date never changes; 
once you've done it, you've done it. The <atom:issued> date, therefore, 
should only change if the previous date was incorrect.

> I know, but we're trying to be conformant with Dublin Core which uses 
> the  term 'issued'.

Indeed. Although "published" is the established term in blog software, 
using it here when a more general term exists would move us back towards 
blog-centricity. As I understand it, that's something we're trying to avoid.

- Beecher Greenman

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 09 Jul 2004 15:31:47 +0200

On Fri, 09 Jul 2004 07:59:44 -0400, Beecher Greenman  
<[email-masked]> wrote:

> should change, in that case?

In my humble opinion, it should never change -- unless, of course -- the  
first time it's set incorrectly. That goes for 'atom:created' too; it  
shouldn't change once it's first set (correctly).

> The real-world issue date never changes; once you've done it, you've
> done it. The <atom:issued> date, therefore, should only change if
> the previous date was incorrect.

Bulls eye. :-)

> blog-centricity. As I understand it, that's something we're trying to  

Bulls eye again. I'm very satisfied with the term 'issued', and I'm one of  
the lonely developers on Atom that aren't going to (primarily) implement  
it in a blog, but rather on a pretty huge (in Norwegian scale ;) news  
publishing service.

---

From: "Roger B." <[email-masked]>
Date: Fri, 9 Jul 2004 10:07:45 -0500

> shouldn't change once it's first set (correctly).

Asbjørn: Issued is an end-user feature in most systems that implement it...
it can (and will) be changed as often as the user sees fit.

Created should generally be more static, since it's usually defined by the
system. Ditto for modified. So while it might be safe to make assumptions
about those two, issued is just user-defined metadata that isn't subject to
specification.

--
Roger Benningfield
JournURL: http://journurl.com/
blog: http://admin.support.journurl.com/

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 09 Jul 2004 17:33:40 +0200

On Fri, 9 Jul 2004 10:07:45 -0500, Roger B. <[email-masked]>  
wrote:

> Asbjørn: Issued is an end-user feature in most systems that implement  
> it... it can (and will) be changed as often as the user sees fit.

Then 'created' MUST be required, because knowing when an article about  
e.g. «The next big thing: CD's» is not only important, but vital to what  
the article means when read in 2004.

> Created should generally be more static, since it's usually defined by  
> the system.

It MUST be static and imho MUST be present, at least if 'issued' is a  
«whatever you feel like» date.

> Ditto for modified. So while it might be safe to make assumptions about
> those two, issued is just user-defined metadata that isn't subject to  
> specification.

Then 'issued' should really be the optional date, since that is the most  
bogus piece of information present in the whole Atom format. I wasn't  
aware of that until just now.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Fri, 09 Jul 2004 17:57:29 +0200

> <created> is required if it differs significantly from <issued>.

I could live with that.

> I'd imagine <first-issued> ~= <created> would be true in most cases.

Absolutely. Therefore it would be better to require 'created'. If it's so  
that the system doesn't distinguish between 'created' and 'issued', then  
just have them be the same in the Atom format. No one complains if they  
are the same, but I will comlain loudly if 'issued' isn't «first issued»  
and 'created' is missing from the entry. :-)

> full history

Full history is not necessary. I, for one, have absolutely no interest in  
when the entry was «last issued». When it was created and/or first issued,  
though, is of high interest to me (and should be to everyone else reading  
it).

> do they also have to supply details of older revisions?

No.

---

From: Antone Roundy <[email-masked]>
Date: Fri, 9 Jul 2004 10:41:44 -0600

I'm getting a little lost (okay, I've been speed reading, so it's my 
fault) with the different ideas for what each of the Date Constructs 
means, and why each is important.  Here's a sequence of events that I 
can image might occur in the creation and publishing of an entry.  The 
first number is a pseudo-timestamp.  That is followed by a description 
of what happened. Next, in square brackets, is a comment which begins 
with "created", "issued" or "modified" if one of those is applicable.

1000 - Author gets an idea for a blog entry, makes a brief 
note-to-self, and saves it as a draft [created & modified - Why does 
anyone but the author need to know this?  The author MAY wish to 
publish this to let people know how long they've been thinking about 
the idea, but this date doesn't exactly equal that, since they may have 
been thinking about it, or even typing it up, for some time before 
saving it as a draft]

1050 - Author adds a few more notes and saves as a draft again [ 
modified - there's even less need for anyone but perhaps the author to 
know this]

1100 - Author posts the entry, unmodified, to their blog [ issued - 
this date matters, does modified change? ]
OR
1100 - Author cleans up the draft and posts it to their blog [ modified 
& issued - this matters ]

1150 - Author decides they want to change the timestamp on the entry, 
either for "personal" reasons or because the clock on whichever 
computer initially set the date(s) was incorrect [ ? - are there any 
that they MUST NOT change? ]

1200 - Author udpates the entry and posts it to their blog [ modified - 
this matters ]

1300 - Author posts the same entry to another of their blogs without 
any changes--the id for the two entries is the same [ is issued now 
different in the two blogs? ]

1400 - Some aggregator sees the entries in the two blogs and puts one 
of them into a synthetic feed, smartly omitting the other since they 
have the same id [ IF issued is different in the two feeds, which one 
gets used? The earlier one probably makes more sense. ]

Additional comments and questions:
1) Are any of these dates set by the server, or does the client set all 
of them?
	1a) Are we going to specify that?
	1b) Are we going to provide suggestions on that?
2) I can't think of a reason to REQUIRE created.
3) Issued seems like it should be required, and modified, if later than 
(or different from?) issued.

Comments? Corrections?

Perhaps we should have an example timeline like this on the wiki where 
we could refer to it if there's confusion about what each date means 
and when it changes.

---

From: Jens Alfke <[email-masked]>
Date: Fri, 9 Jul 2004 10:19:02 -0700

Just to make things even more complicated, consider a feed that 
contains items with multiple access privileges. Depending on the 
credentials used to access the feed, different sets of items will be 
returned. (This is not hypothetical: this is how LiveJournal works. 
Posts can be "friends-only" so that only a specific set of LJ users can 
see them. A journal's feed's contents vary depending on what LJ user is 
fetching it.)

If I initially post an entry as friends-only, then at some later time 
make it public, what are the implications for its dates? I'm not sure 
of the answers, in fact I'm more unsure after reading this thread than 
I was before :) But it does seem like the Issued and Created dates 
shouldn't change.
_______________________________________
Jens Alfke — Atom/RSS Wrangler — Apple Computer
“Crow struggled, limply bedraggled his remnant.
He was his own leftover, the spat-out scrag.
He was what his brain could make nothing of.”
—Ted Hughes

---

From: Robert Sayre <[email-masked]>
Date: Fri, 09 Jul 2004 13:35:27 -0400

> I was before :) But it does seem like the Issued and Created dates 

I don't think dcterms:issued has anything to do with when the entry was 
published. That's dcterms:available.
dcterms:issued would seem to correspond to the date on a magazine. For 
example, I'm sure I can pick up the "August issue" of many magazines 
right now.

Can anyone tell me if this interpretation is correct?
http://dublincore.org/documents/2003/03/04/dcmi-terms/

Robert Sayre

---

From: "Bill Kearney" <[email-masked]>
Date: Fri, 9 Jul 2004 15:02:25 -0400

What's in control of distinguishing how the consumers can "tell" the
distribution scope?

In the context of a feed it seems entirely reasonable to think the item should
reflect some sort of modification time.  You did modfiy it, if only to change
the scope of who can consume it.  Now, do the users /care/ that you did this?
Should their reader program "do something" to bring this to their attention?
Should we spend any time whatsoever on crafting a mechanism for it?

You created the item at a fixed instant in time.  The server should need this to
remain unchanged if just for the sake of not wasting huge amounts of energies on
trying to maintain some sense of editing progression.  You offered it up for
consumption by others and this date should likewise remain fixed as the users
will likely depend on it.  You then altered the item and the system would
likewise probably want to keep track of this.  Did you change it "enough" for
the feed consuming programs to somehow present that?   Depends on how
"significantly" you want it to appear to the consuming audience.  Try screwing
around with it too much and you'll lose that audience (rightly so).

-Bill Kearney
Syndic8.com

---

From: "Bill Kearney" <[email-masked]>
Date: Fri, 9 Jul 2004 15:17:06 -0400

In the context of using Atom as a format for editing between a client-side
program and a server-side repository it seems entirely useful to have "real"
timestamps be employed.  If only to facilitate properly tracking changes.

In the context of the format being used to publish content intended for external
distribution there are other factors to consider.  A driving force behind
timestamps in items has been tracking read/unread status and avoiding
duplicates.  There have been any number of arguments and half-assed solutions
proposed and implemented.

The bottom line is different for each situation.

Back into the situation from the consuming reader's perspective.  What means can
be employed that effectively manage the detection of the uniqueness of an item
and tracking it?  Timestamps are one way, UIDs another.  For feed-like exchanges
either could be employed but without some consistency it's going to be a
hopeless mess.  For editing sessions it's hard to rationalize the against the
value of using multiple timestamps.

When dealing with calculations regarding the uniqueness of something it's
entirely reasonable to expect to see a creation date.  If the item is modified
it's likewise helpful to see both the original creation timestamp and the
modification.

"Vanity" timestamping is a quagmire.  Thus using some sort of publication or
issuance timestamps is often advisable.  But if people are going to ceaslessly
fuck around with the timestamps on their items they shouldn't be surprised when
the software fucks it up and the users complain.   Know that if you publish
something the users will make use of it based on the timestamps.  If you futz
around with those timestamps you will antagonize your audience.  Do so at your
peril but do not come crawling to the spec begging acceptance of bad habits.

Conflict resolution for uniqueness cannot rationally allow open-ended gobbling
of CPU just to accomodate stupidity or ludicrous edge-cases.

> anyone but the author need to know this?

For a feed?  No it's entirely reasonable to have the option to use 'publication'
oriented timestamps.  For editing sessions it's sort of crazy /not/ to use them.

> modified - there's even less need for anyone but perhaps the author to

But critical to whatever system the host might be using to deal with
syncronizing entries.

> & issued - this matters ]

Ah so, in a feed we're talking about:

    New item: [issued]
    Same item, edited somewhat [issued, modified]

> that they MUST NOT change? ]

Realizing, of course, that by doing so they'll be causing grief to their
audience.  They COULD change anything they liked.  But they probably SHOULD seek
to publish useful data and stick with it.

> different in the two blogs? ]

This being a place where conflict resolution starts getting messy.

Honestly, what are we trying to facilitate here?  There are going to be
situations where "a story" has some sort of on-going development.  Should it
only be published "once" and modified a bajillion times as it grows?  That seems
like a pretty bad idea.  But I can imagine some git with their
one-true-favorite-tool that they've only figured out how to use one way that
thinks it's a perfect FINE idea!   But for a feed driven publication method it
seems a lot more reasonable to look at the progression of the "story" as a
series of individual pieces that have some relation to each other.  Does this
"need" to be automated?  Not as many situations need this as some will doubtless
insist.

> have the same id

>[ IF issued is different in the two feeds, which one

How so?  I'd think it'd be more along the lines of seeing which one was modified
last and using that one.  In most situations "later" is usually what's intended
for consumption.

Likewise DC has means to indicate that an item is related to another.

-Bill Kearney