Re: Proposal to register rel="about"

["Peter Keane" <pkeane@xxxxxxxxxxxxxxx>]

I'd have to agree that atom:content/@src is the most appropriate place
to state what this entry is "about."  To me, the fact that
atom:link/@about breaks backwards compatibility strikes me as a
possible deal-killer. But Herbert's point that current implementations
are quite fuzzy on this point is well taken.  It strikes me as one of
those tricky spots that puts Atom's existentialist view of the world
at odds with a necessarily essentialist Semantic Web view of the
world.  There are, though, some compelling reasons for using
atom:content@src since that is exactly what the  AtomPub spec
describes for the Media Link Entry.   Were ORE to adopt this (using
atom:content@src to express what the entry is "about"), it would
simply be one more definitive precedent that this is how is "should be
done."  And in the spirit of Atom ("let's allow implementations to
establish best practices, etc."), it would be a step in the right
direction for making Atom more compatible with the Semantic Web.

--peter keane


On Sat, Sep 13, 2008 at 11:58 AM, Antone Roundy <electriceel@xxxxxxxxx> wrote:
>
> Erling Wegger Linde wrote:
>>
>> If you could use <link rel="about" href="htmlrepresentationofissue">
>> together with for instance <content type="application/rdf+xml">RDF
>> represenation here..</content>
>
> I think that's what link/@rel="alternative" is for.
>
>>>>>> 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
>>>>>> >
> ...
>>>>> My impression upon looking at the entry is that you could do this
>>>>> instead
>>>>> (and add an atom:summary element with textual content):
>>>>>
>>>>> <content src="http://www.youtube.com/watch?v=S_bcAOlK0io"; />
> ...
>>> What if you use Atom entries as wrappers for other resources?
>>> It seems to me that that's exactly what <content src="..." /> is for.
>>
>> No, I don't agree. What if you haven't got a proper "wrapper resource"
>> to refer to, how could you use <content src=".."> then? You couldn't
>> do that without creating a new resource right? And what if for
>> instance you want to let a client understand that the <summary>
>> element of an Atom entry is actually metadata about another resource?
>
> Once again, I think this is exactly what <content src="..." /> is for. For
> an Atom entry to have its own content that ISN'T simply an alternative
> representation of an external resource, and have entry/summary be a summary
> of anything other than entry/content is a corruption of Atom.
>
> I'm not sure what you mean by "wrapper resource" -- if you have an external
> resource which is what the entry metadata is about, then that external
> resource is the "content" of the entry.  If the entry contains additional
> content commenting on the external resource, then the entry's metadata
> should be about that additional content (and in THAT case, rel="about" might
> be an appropriate way to link to the external resource, but the entry
> metadata is still about the entry content).
>
> If the external resource is the content of the entry and you point to it
> with content/@src, then the summary is metadata about the external resource
> -- atom:summary is a summary of atom:content, whether the content is
> included inline or not.
>
>>> Allowing a link/@rel value to alter the
>>> meaning of core Atom elements would be dangerous, because implementations
>>> that don't understand the new @rel value (which they're not required to
>>> do,
>>> and we rejected the idea of creating any sort of "mustUnderstand"
>>> mechanism)
>>> would misinterpret the core Atom elements.
>>
>> Well, I can see your point. But from working with Semantic Web
>> technology together with AtomPub I think that adding a
>> link@rel="about" to the Atom format could make Atom(Pub) a bigger
>> player in the Semantic Web (which I hope is the future).
>
> I understand your point, but I think doing it the way you're wanting to
> would require redefining Atom in a way that's not backwards compatible with
> the existing RFC.
>
>> I'm not sure if this would be such a dangerous addon to Atom as you
>> indicate. I can't see why most clients can't keep on doing business as
>> usual.
>
> It goes back to this:
>
>> We understand that an RFC that specifies the proposed rel="about"
>> relationship would have to express which child elements of atom:entry
>> pertain to the resource described by the Entry, and which to the Entry
>> itself, whenever a rel="about" is present in an Entry.
> ...
>> (a) /entry/id, /entry/published, /entry/updated, /entry/rights,
>> /entry/link@rel="self", /entry/link@rel="license" pertain to the Entry
>> (b) all other child elements of /entry that are in the Atom namespace
>> pertain to the resource that is the target of the "about" relationship.
>
> Existing implementations expect entry/author, entry/category, entry/content,
> entry/contributor, entry/link (whatever the @rel value is), entry/source,
> entry/summary, and entry/title to be metadata about the entry. If the
> existence of rel="about" changes the interpretation of these elements,
> implementations that aren't aware of rel="about" won't interpret them as the
> publisher intended.
>
> Antone
>
>