Re: Atom and Dublin Core

[Robert Sayre <mint@xxxxxxxxxxxxxxx>]

On 3/24/04 7:19 AM, "Norman Walsh" <ndw@xxxxxxxxxx> wrote:

> / Robert Sayre <mint@xxxxxxxxxxxxxxx> was heard to say:
> | Quoting Norman Walsh <ndw@xxxxxxxxxx>:
> |
> |> / "Danny Ayers" <danny666@xxxxxxxxxxx> was heard to say:
> |> | Ian Davis points out some obvious parallels, and makes an interesting
> |> | observation about Atom: "when you remove the overlap with Dublin Core
> |> what's
> |> | left is pure syndication".
> |> |
> |> | http://internetalchemy.org/2004/03/theNucleusOfAtom
> |> 
> |> It's an interesting observation. I was aware that there was some
> |> overlap, but I don't think I would have guessed there was that much.
> |> When I wrote about the three dates[1] that I decided I needed, I was
> |> struck by the fact that I wanted exactly dcterms:created,
> |> dcterms:modified, and dcterms:issued.
> |
> | My understanding of dc:issued is that it should never change. From
> |
> | "Term modified: The date of a specific version of a term declaration.
> | Term issued:   The date a term was first declared."[1]
> 
> I think the text you're quoting from [1] is describing the terms used
> by the DCMI board to describe the DCMI terms. Fair enough, after
> you've issued the term "foo", you can never issue it again.
> 
> The normative description of issued[2] says:
> 
> Term Name:  issued
>   Definition: Date of formal issuance (e.g., publication) of the resource.
> 
> And I think I'm satisfying that definition. The issued date changes if
> and only if I'm making a change to the resource that I want to
> identify by republication of the resource.
>

Although it's difficult to debate when phrased that way, I would say you're
extending that definition. Presumably, there's something about this change
that you're trying to communicate, other than the method by which you want
to identify it. 

In Dublin Core, a number of terms are provided that explicitly mention
changes to content, but 'issued' is not one of them. For example, there's
isVersionOf:

"The described resource is a version, edition, or adaptation of the
referenced resource. Changes in version imply substantive changes in content
rather than differences in format."

If atom:issued really means "when issued is updated, then substantive
changes have taken place to the entry", then it shouldn't be mapped to
Dublin Core, since it's actually a conflation of several different DC Terms.
 
> | PaceLinkConstruct defines link relations "replaces" and "replacedBy"
> | (dcterms:isReplacedBy, dcterms:replaces) for your use case.
> 
> Yes, I could have adopted the strategy that resources are absolutely
> immutable and that the only way to update http://example.com/foo was
> to publish http://example.com/bar and declare that one resource
> isReplacedBy/replaces the other.
> 
> In practical terms, I don't know how to apply the
> isReplacedBy/replaces logic without changing the URI and I am
> specifically choosing to update the document in place sometimes. It's
> a judgement call.
> 

I was not arguing that resources are immutable. There is an atom:modified
element. Why couldn't you add a replacedBy or hasVersion relation and update
atom:modified? Sounds reasonable solution for a syndication/interchange
format, and it provides a more complete history for clients joining your
feed after a number of significant edits. Also, note that there would be no
difference between the two strategies in a user interface.

Robert Sayre