Re: Proposal to register rel="about"

["Erling Wegger Linde" <erlingwl@xxxxxxxxx>]

On Sun, Sep 14, 2008 at 1:26 PM, Aristotle Pagaltzis <pagaltzis@xxxxxx> wrote:
>
> * Herbert van de Sompel <hvdsomp@xxxxxxxxx> [2008-09-12 01:00]:
>> The ORE effort [1] that proposes a profile of Atom to meet its
>> requirements [2], has a need to express that an Atom Entry
>> provides information/metadata about some other resource.
>
> That's `rel="alternate"` – it states that the metadata in the
> Entry applies to the linked resource.

This is interesting. You are saying that rel="alternate" has the same
semantics as the proposed rel="about". That is, the atom:summary,
atom:author etc. applies to the resource referred to with an
atom:alternate link? E.g. if I say,

<atom:entry>
  <atom:summary type="text">A major bug...</summary>
  <atom:link rel="alternate" href="http://project1/issue1 />
</atom:entry>

The correct interpretation made by a client is that the summary "A
major bug.." is a property (summary) of the issue (which alternate
(for instance html) representation can be found at
http://project1/issue1). If this is so, I think I agree that we don't
need rel="about". But then again I don't understand why there was so
many people that reacted so strongly against Herberts proposition.
Looking forward to the follow up on this one =)

- Erling


>
>> The Atom use cases we refer to use Entries as containers to
>> provide "metadata" about some web resource other than the Entry
>> itself. For example, the GData Entry
>> <http://gdata.youtube.com/feeds/api/videos/S_bcAOlK0io > is
>> about the YouTube video by the Cribs <
>> http://www.youtube.com/watch?v=S_bcAOlK0io>: the atom:author,
>> atom:title, and atom:content elements are metadata about the
>> video. The same approach is used in Entries published by
>> academic publishers: the atom:author, atom:title, etc. elements
>> are metadata about a journal article that is described by the
>> Entry.
>
> An Entry can have more than one alternate representation.
>
>> This class of Atom use cases contrasts with cases in which Atom
>> Entries do not describe other resources, but are just ... err
>> ... themselves. This is the case with most blog entries, in
>> which e.g. atom:author is the creator of the Entry, atom:title
>> is a title for the Entry assigned by the creator, etc. This
>> metadata does pertain to the Entry itself, not to some external
>> resource.
>
> If you really need to provide metadata about the metadata, rather
> than metadata about the actual resource, wrap an Entry in an
> Entry. (Yes, `<content type="application/atom+xml;type=entry">`.)
>
> That isn't the case you have outlined in the rest of your entry
> however.
>
>> This class of Atom use cases contrasts with cases in which Atom
>> Entries do not describe other resources, but are just ... err
>> ... themselves. This is the case with most blog entries, in
>> which e.g. atom:author is the creator of the Entry, atom:title
>> is a title for the Entry assigned by the creator, etc. This
>> metadata does pertain to the Entry itself, not to some external
>> resource.
>
> External or not is a red herring. Either the metadata describes
> that other resource, in which case the Entry is an alternate
> representation, or it doesn't, and it's not, so the other
> resource is merely related.
>
> You can't use Atom elements in a single Entry to provide metadata
> about different resources anyway. To achieve that you would need
> extension elements, not a new link relation, otherwise documents
> you claim are Atom will actually be something very similar to
> Atom but not Atom, since 100% RFC 4287-compliant implementations
> will process such documents in an unintended manner.
>
>> We would very much appreciate your feedback, both regarding the
>> general idea of registering an "about" relationship, and
>> regarding the specifics of the interpretation of child elements
>> of atom:entry.
>
> I think it's unnecessary. Atom as specified can already express
> the relationships you want.
>
> Regards,
> --
> Aristotle Pagaltzis // <http://plasmasturm.org/>
>
>



-- 
Med vennlig hilsen
Erling Wegger Linde