Peter Keane wrote:
> What about the case of a Media Link Enty?
>
> This from AtomPub spec 9.6:
>
> "The Media Link Entry contains the metadata and IRI of the (perhaps
> non-textual) Media Resource. The Media Link Entry thus makes
> the metadata about the Media Resource separately available
> for retrieval and alteration."
>
> Isn't this a specified case in which the atom elements are
> describing the media resource and not the entry?
Either the relationships between the metadata, the content, and the entry is
ambiguous and application-dependent or the metadata has to describe the
entry. Those words from the AtomPub specification imply that the
relationships are ambiguous and so AtomPub has to clarify them for its
specific use of Atom. Following that, when you have an AtomPub MLE the
metadata describes the content, when you have inline content in an AtomPub
document the relationships are ambiguous, and when you are not using AtomPub
the relationships are ambiguous even with out-of-line content. That is, you
have basically the same problems as rel='about', but without the
explicitness of the rel='about' proposal (since you cannot easily tell
whether an entry is a media link entry or not in general).
I don't think that is a very useful approach because it means we have to
write extra specification text to clarify what metadata applies to what
under what circumstances, we have to write code for each special case, and
we have to write more tests to verify that we handle all the specific
scenarios correctly. The conclusion is that Atom's metadata is meaningless
without additional application-specific clarification, so we cannot write
tools that interpret metadata uniformly across applications. That is
completely at odds with the goals of Atom.
Instead, I prefer to think of AtomPub as a way of managing Atom entries
instead of a way of handling entries, media resources, and the media
metadata encoded as entries. Some of the entries might have out-of-line
content, and the protocol knows how to edit it, but the media resources are
always secondary to the entries. Thinking this way, there isn't a need to
have MLEs as a separate concept. Instead of regular entries vs. MLEs, we
have entries, some of which have "out-of-line content" while others have
inline content. This emphasizes that entries are all managed the same way,
that we should interpret entries' metadata uniformly, and that the entry is
the primary concept while the media resource is the secondary concept. This
fits with the way we manage media entries. An entry can exist without having
a media resource but a media resource cannot exist without a MLE. A media
resource is deleted when its MLE is deleted; the MLE isn't deleted when its
media resource is deleted (at least, that isn't required by the spec.). We
update app:edited whenever the entry changes; because the content is part of
the entry, whenever we update the content we have to update app:edited,
regardless of whether the content is inline or out-of-line.
Examples 1:
<entry ...>
<author><name>Brian</name></author>
<content src='something.html'/>
...
</entry>
Who is the author of the entry? Who is the author of something.html? Using
my way of thinking, Brian is the author of the entry and the author of the
content is unknown. Otherwise, everything is ambiguous; if the entry is part
of an AtomPub collection and the entry is a MLE then Brian is the author of
something.html and the author of the entry is unknown. But, if the entry
isn't a MLE entry then the authorship information is totally ambiguous.
Example 2:
<entry ...>
<id>urn:example:1</id>
<title>My brother's puppy</title>
<content src='http://example.org/puppy.jpg'/>
<app:edited>2008-01-01:01:01:01Z</app:edited>
<updated>2008-01-01:01:01:01Z</updated>
...
</entry>
<entry ...>
<id>urn:example:2</id>
<title>My puppy</title>
<content src='http://example.org/puppy.jpg'/>
<app:edited>2008-01-01:01:01:01Z</app:edited>
<updated>2008-01-01:01:01:01Z</updated>
...
</entry>
What is the title of the image? What is the title of entry urn:example:1?
What is the title of entry urn:example:2? Can an image have two different
titles at the same time? Using my way of thinking, each entry has the title
given and the title of the image is unspecified. Using the other way of
thinking, you have a mess.
Bonus: Given an entry (in a feed or standalone), how can you determine if it
is an AtomPub MLE so that you know what disambiguation rules to apply when
interpreting the AtomPub text above literally.
> I've struggled a bit in my own implementation with this exact
> issue, and wishing there was a switch that could be flipped
> to say "this is an MLE". I am not sure that in practice it
> matters all that much, since a specific use case will clearly
> suggest which you are talking about. I believe the challenge
> that Herbert is pointing to is that we need to be more
> precise is we are going to be deriving RDF from the Atom entry.
That is why I eventually settled on the approach that I described in my last
few messages to this list. It is simultaneously 100% unambiguous and the
simplest thing that could possibly work.
Regards,
Brian
