Subject: PaceLinkParent updated, tightened

From: Ken MacLeod <[email-masked]>
Date: 19 Jul 2004 14:19:50 -0500

I've updated PaceLinkParent with the following changes:

    * rename "parent" to "in-reply-to"

    * constrain defined behavior to "same feed", while leaving open
      future specification

    * remove description of linking to alternate media types

The proposal section now reads:

    Add the following to section to the protocol draft -00 section,
    3.4.1 rel:

    [[ note: link construct markup and location of normative
    specification (protocol or format) are currently under
    discussion. This proposal is written in the style of the -00
    drafts.]]

    [[ note to editor: the definition of this is adapted from RFC2882,
    sec 3.6.4]]

    in-reply-to

        The "in-reply-to" URI will contain the atom:id URI of the
        entry to which this one is a reply (the "parent entry"). An
        atom:entry MAY have one "in-reply-to" link, but MUST NOT have
        more than one. Clients MAY use this link to display nested
        entry threads.

        The "in-reply-to" URI can refer to an atom:entry or other
        resource that is not within the same atom:feed, however the
        mechanism for resolving these URIs is outside the scope of
        this document. An "in-reply-to" link that cannot be resolved
        SHOULD be considered as if the "in-reply-to" link were not
        present.

        For example, if this entry is a comment on a previous entry,
        the "href" attribute URI will be the atom:id URI of the
        previous entry. If this entry is a comment in reply to a
        previous comment (in a threaded comment system), the "href"
        attribute URI will be the URI of the previous comment.

This spec text constrains the defined behavior to what would work
within a minimum of a "local feed" as used in current practice
(including wfw:commentRss, atom:entry/atom:service.feed) and for
existing sites that provide nested comments, as linked from the Pace.

  -- Ken

PS.  I couldn't find who the author of this Pace was, so was not able
to coordinate this change with them following the discussion on the
list.  If the original author has a concern about how the discussion
was factored in, let me know and I'll revert it and create a new Pace.

---

From: Mark Pilgrim <[email-masked]>
Date: Mon, 19 Jul 2004 17:32:22 -0400

> was factored in, let me know and I'll revert it and create a new Pace.

That would be me, and your changes look good.

-- 
Cheers,
-Mark

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Wed, 21 Jul 2004 00:41:17 +0200

On 19 Jul 2004 14:19:50 -0500, Ken MacLeod <[email-masked]> wrote:

> I've updated PaceLinkParent [...]

Although I'm +1 on the idea the pace expresses, I do not agree with the  
concrete implementation. I think Atom should use the Dublin Core element  
<relation>, as its semantics is already defined there. <relation> also has  
the bonus that it defines other relation issues, like IsBasedOn  
(supersedes or «re-issuance» of resources) and such.

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

---

From: Ken MacLeod <[email-masked]>
Date: 20 Jul 2004 20:34:13 -0500

Asbjørn Ulsberg <[email-masked]> writes:

> Although I'm +1 on the idea the pace expresses, I do not agree with
> the concrete implementation. I think Atom should use the Dublin Core
> element <relation>, as its semantics is already defined
> there. <relation> also has the bonus that it defines other relation
> issues, like IsBasedOn (supersedes or «re-issuance» of resources)
> and such.

Logically,

    atom:in-reply-to
        the atom:id URI of the entry to which this one is a reply (the
        "parent entry")

is a refinement of

    dct:references
        The described resource references, cites, or otherwise points
        to the referenced resource.

which in turn is a refinement of

    dc:relation
        A reference to a related resource.

Thus, atom:in-reply-to *is* a dc:relation.  In the Dublic Core mapping
we can indicate that atom:in-reply-to can be interpreted as a
dct:references.

I think it would be bad practice to use a general term for a very
specific meaning.

  -- Ken

PS. Recall that the reason for changing "parent" to "in-reply-to" was
because "parent" was also too generic, almost equivalent to
dct:isPartOf, despite its common usage in the local context of a
message database where using "parent" to refer to the parent message
is easily understood.

---

From: Asbjørn Ulsberg <[email-masked]>
Date: Thu, 22 Jul 2004 01:42:28 +0200

>         A reference to a related resource.

True, +1, I agree and so on.

> I think it would be bad practice to use a general term for a very

Maybe. It wouldn't hurt to introduce more of the <relation> terms into  
Atom, though.