[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: created, issued, modified [Re: comments on Atom 0.2]
> Both of those together lead me to believe that using these Dublin Core
> terms will lead to confusion. I'd rather have a spec that had hard and
> simple rules defining these values.
We do. Its called Dublin Core. We may need additional terms, and I'll get to
this in a moment, but the only problem I see with Dublin Core is that you
are so unwilling to use it that you write horseshit FUD like the quoted
pieces above.
Odd. The more things change, the more they stay the same. And the more they
stay the same, the more I find myself sounding like Bill K. I'm going to
have to watch that. :)
> I think we're getting somewhere, here. To my mind, Pepys' Diary is
> exactly the sort of problem we need to address, because it is the same
> problem as my going to the mountains for a week: there is more than one
> timestamp related to the post and both are vital for the purposes of
> displaying in an aggregator.
Actual, Pepys' Diary is STILL a remarkably different, but wholely
applicable, scenario. Pepys wasn't sitting in front of a laptop creating
Pie/Echo/Atom/Feedcast/whatever entries in a software application, unlike
the Mountain Man. Unless you are suggesting that Mountain Man was just
writing his text into notepad and then pasting the content into his CMS just
before publishing the content once he returned from the mountains, in which
case I wish you had said so. :) If so, I'll admit that his situation then
becomes like the Pepys scenario. The Pepys' Diary example is one of (what
I'll call) re-publishing, in this case the bringing of content from another
medium into the blogging world. True blog->blog syndication scenarios will
present a number of similar issues, and I do feel they are within scope of
the project, assuming that scope can be addressed without finding ourselves
on an overly slippery slope.
> Let me try to explain my thinking by way of an example.
-snip-
Evan - I have followed both of your examples without problem since they were
first presented. The problem still boils down to this:
1. You seem to want to use issued in a way much more suited to created
2. Even if you swapped your usage of the two you would still be in a
situation where human-oriented and machine-oriented metadata are getting
mixed up (and even I'll admit to falling into this trap when trying to find
useful ways to deal with the Pepys scenario without introducing additional
terms - something I think we may be faced with if we want to handle your
human-oriented desires as well as re-publishing and true syndication
scenarios)
> Now let's return to the Atom terms. We currently are tossing about
> three times, which have names that are similar to Dublin Core names
> but are apparently underspecified enough to cause confusion. (For
> example, the distinction between "time the entry was actually modified"
> and "time the modified entry was posted" mentioned above, while
> potentially interesting data, is not the sort of ambiguity we want in a
spec.)
Agreed.
> Now, to (finally :P) answer your question. In the LJ Atom implementation,
> which was based on reading the Wiki and MT implementation and from
> conversations with the validator authors, I am using these mappings:
> - issued -> write time
> - created -> post time
> - modified -> modify time
>
> If these DC terms are really as fuzzy as it seems to me, we might be
better
> off using different names.
Then the LJ Atom implementation still has issued and created backwards as
far as the DC definitions go, and the fuzziness is only as great as your
unwillingness to read the DC spec. Unless the wiki also has these backwards,
but from my recollection of it as well as other reminders recently posted to
this mailing list I don't think that is the case.
Look, to be clear, if I sound overly critical of your position, its because
you seem to have your eyes closed, your ears plugged with your fingers, and
your mind occupied with the humming of a random tune when it comes to the
definitions of the Dublin Core terms. Let's try to do two things:
1. Get you over that. Starting with the brutal clarity of DC's definition of
issued.
2. Determine whether or not there is still a need to:
2a) clarify the interpretation of the term "resource" as used by DC in
created and modified (as in abstract content vs.
Pie/Echo/Atom/Feedcast/whatever entry)
2b) add additional terms to handle re-publishing and syndication scenarios
2c) add an additional term to handle a 100% subjective human-oriented
machine-ignored date and/or time for entries
Jeremy Gray