Abstract
Define a Date Construct to hold a publisher-selected date which is the date of the subject of the entry. This date is not tied to an event in the publishing process.
While inspired in part by PaceDateSubjective, this pace has been more refined, and the definition and use-case semantics narrowed.
Status
Open
Supporters
Rationale
-
For some purposes, it is desirable to be able to specify a date connected to the subject of an entry, rather than to an event in the process of publishing that entry.
-
There are objections to duplicating dates from dcterms in the Atom core. dcterms does not have anything that matches this element.
-
This element is optional, which means for those entries which don't have a clear subject date it can be left out entirely.
-
While much use of Atom will be for publishing blog-centric content, the charter allows for publishing of other content, and thus content which is not strongly tied to a date in publishing process but more identifiable with some other date.
-
Example uses include:
-
a feed of 'on this day' notes
-
a weather feed, where each entry is specific to a given day
-
a feed of upcoming birthdays, which is something the various social networking services could provide
-
a feed of deadlines for a project
-
historical journals, such as samuel pepys' diary, wherein entries are about what happens each day
-
a travel diary, published after the fact (no wifi on the beach!)
-
a series of essays regarding significant dates
-
a retrospective timeline for a given subject (eg. Israel/Palestine conflict)
-
The other date elements for Atom are meant to be objective, and related to events in the publishing process. It is argued that without an outlet for a subjective date element then these other objective dates would be hijacked, thus diminishing their usefulness.
-
This element provides enough to get a simple and useful job done - to allow human beings to sort and filter on the subject date.
-
Not all use cases will have appropriate extension modules available, let alone be supported by aggregators, or worth the effort for just a quick note. This element provides the basic functionality, and provides it in a way all aggregators can support without having to provide support for all manner of various extensions.
-
Note though that extension modules are not ruled out. No. If more complete information is required which is best suited to a more comprehensive extension, then extensions can still be used. If all you want in the feed is the subject date, then that is better satisfied with an in-core subject-date element ... that way every aggregator only has to look for the one element to find the general 'date of the subject' date.
-
Putting the subject-date inline in the entry is preferable to referring to an external calendar resource, otherwise a simple operation of sorting by subject-date would require fetching the calendar resource for every entry.
-
While this date element is of a subjective nature, it is more narrowly defined than that of PaceDateSubjective. The subject-date element is to be used for the date of the subject of the entry, and not just any damn date the publisher wants to associate with the entry. With a little imagination, you can see this rules out all sorts of subjective semantics: the date i first heard about this, the date i fact checked it, the birthdate of whichever historically notable philosopher i'm dedicating this entry to, date i told my mom about this ... and so on. None of those semantics are appropriate to subject-date.
(see also the References section below)
Proposal
Insert the following after section 5.6 "atom:updated" Element (draft-ietf-atompub-format-02.txt)
=== 5.x "atom:subject-date" Element === The "atom:subject-date" element is a Date Construct indicating the date and time of the subject of the entry. It is not directly related to events in the publishing process. For example, atom:subject-date might be used to express the date which a journal entry describes, although that entry might have been written at a later date. Other example uses of this element include: * web publication of a diary from the past (eg: Pepys' Diary) * a weather feed, where each entry is specific to a given day * entries in a feed of upcoming birthdays * a series of essays regarding significant dates * a feed of 'on this day' notes & trivia * a retrospective timeline for a given subject * a simple list of upcoming events at some venue * a feed of deadlines or other event dates for a project atom:entry elements MAY contain an atom:subject-date element but MUST NOT contain more than one. The content of this element MUST conform to the Date and Time format defined in RFC 3339.
Impacts
If there is no subjective date element, then publishers will be forced to hijack some other date field for their purposes (eg. date-updated). Thus, date-subject is a good escape valve, protecting the objective date fields (particularly date-published, which has been strongly argued for no-changes-ever).
References
Here are some snippets from discussion of PaceDateSubjective, a predecessor to PaceDateOfSubject. PaceDateSubjective was criticised as being vague and ambiguous, with bad example uses. This pace hopefully corrects those shortcomings...
-
I'm not wanting to model [events]; I'm wanting to talk about them. -- JamesAylett http://www.imc.org/atom-syntax/mail-archive/msg10074.html
-
[storing the date an entry discusses] is a function that users have demanded from me when wearing my Publisher Hat (I still get complaints that old versions of the app have fixed dates), and I've never encountered a problem when consuming similar feeds while wearing my Aggregator Hat. So from where I'm standing, it's beyond useful and practical... it's a necessity. -- RogerBennigfield http://www.imc.org/atom-syntax/mail-archive/msg10087.html
-
Someone keeping a diary doesn't care about "published", "modified", or whatever else... she cares about the timeline of her life. It doesn't matter that Entry #1234 was entered into the system four days after Entry #1233. What matters is that Entry #1234 describes the events of her birthday party on 2004-08-10, and Entry #1233 describes her hangover on 2004-08-11. (Said hangover being the reason she couldn't post about her party for a few days.) -- RogerBennigfield http://imc.org/atom-syntax/mail-archive/msg10085.html
-
When I got back from my Florida vacation, it took me several months to go through hours of occasionally mis- or unlabeled DV tape, extract stills, and begin posting entries to my travelblog. As a result, one day I was posting an entry about what I did on 2003-03-18, and the next day I would find a cache of footage from 2003-03-12. And the next day, poof, there was the missing footage from 2003-03-14! -- RogerBennigfield http://imc.org/atom-syntax/mail-archive/msg10085.html
-
The reason I support this element is that we fully expect Atom to be used in non-blog environments where the date in the contents is much more important than the date the entry is created or modified. -- PaulHoffman http://www.imc.org/atom-syntax/mail-archive/msg09833.html
-
I can see being useful for situations where PaceDateSubjective refers to the actual date the content occured (such as pictures of 9/11) that are now recently published. This is a more generalized view of the linked content other than the "blog centric" view. -- Brett Lindsley, Motorola Labs. http://imc.org/atom-syntax/mail-archive/msg10082.html
-
I'm +1 to it because for the cases when people want to use it there is no alternative in dcterms. It seems natural to let the author of an article express a date that they want associated with it. -- DavidPowell http://www.imc.org/atom-syntax/mail-archive/msg09889.html
Notes
rejected names for this element include:
-
atom:date -- too generic, especially considering we have other date elements
-
atom:content-date -- not clear the date is regarding the subject of the content, as distinct from the content element itself (eg. could be confused with atom:modified)
-
atom:dateline-date -- derived from NewsML, has formatting issues (note though that there is no conflict of date-of-subject and date-piece-authored, as it is the former which actually goes into dateline)
-
atom:timeline-date -- too narrow/specific and an ill fit for things like birthday feeds, weather feeds
date ranges are not covered by this pace (yet - suggestions welcome)
Doesn't mean someone couldn't write an entry about the start of Six Day War and put the starting date into subject-date. If however someone wants to write about this particular six day date range in 1967 then the use of subject-date would be inappropriate.
We explicitly disallow the model of {0,*} instances of atom:subject-date in atom:entry because the theoretical utility is undermined by the practical difficulty of coding support for the elements under that semantic.