Oh! on closer look at the spec I see that I had misunderstood the way
entries get posted to the collection.
I thought an entry gets returned in the body of the POST when posting
to entry collections. I now see that the POSTing part to both
collections is identical. In each case one gets returned the location
of the document one sent. It is in the reading of the collections
that the difference shows up. Reading entry collections, one gets a
list of one's entries as first order objects inside the feed; reading
media collections one gets a feed of entries that point to the
resources one created. So in media collections there is a level of
indirection between the URI returned and what appears in the feed
returned at the href of the collection.
I suppose it would make sense to return an entry when posting to the
media collection, since there is this indirection. This would give
the client a handle on the generated id, and other metadata.
Or perhaps one could just state that the id of that entry is the url
of the resource returned?
Henry
On 8 Mar 2006, at 20:50, Henry Story wrote:
So clearly this gives us a :Service, :Workspace, and :Collection
class. The relation between the :Collections of type :entry
and :media and the feeds they point to can be specified by the N3 rule
{ ?c a :Collection;
:href ?feedUrl;
:member-type :entry .
?feedUrl a atom:Feed;
atom:id ?feedId .
?feedId atom:update ?entry .
} => { ?entry atom:content [ a owl:unionOf ( atom:TextContent
atom:XHtmlContent ) ] } .
The above should say that for any collection of member-type entry
pointing to ?feedUrl with atom id ?feedId, all the entries on feeds
with that id will have contents of type text or xhtml.
I can see that the above is clearly wrong now.
Note: atom:update is the relation that a feed id has to all entries
that are part of feed documents with that id. In N3
{ ?feed a :Feed, :Version;
:id ?feedId;
:entry ?entry . } => { ?feedId :update ?entry } .
Anyway Here I am making 2 assumptions:
a1. that the linked list of feeds at ?feedUrl all have the same id
and that these are all the feeds with that id.
I suppose that is ok.
a2. that the content of those entries are limited to things of
mime type text/html, text/xhtml, text/plain.
that is wrong. And so is all the thinking below.
I wonder what people on this group think about assumption a1.
Thinking about it assumption a2 is very likely wrong. My guess is
that the difference between entry collections and media collections
is purely procedural, ie, how one interacts with them.
I suppose a test would be what your answer to the following
question would be: could it be that there is no syntactic way to
distinguish an entry collection and a media collection. For example
is it possible that someone could post some html to a media
collection?
POST /myblog/entry HTTP/1.1
Host: example.org
User-Agent: Thingio/1.0
Content-Type: text/html
Content-Length: nnnn
Title: Atom-Powered Robots run Amok
<html><body>Hello there</body></html>
Ok I suppose the entry created would then look something like this
<entry>
<title>Atom-Powered Robots run Amok</title>
<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
<updated>2003-12-13T18:30:02Z</updated>
<content src="http://eg.com/xxx.html";>
</entry>
Worry 1:
The fact that posting to a media collection does not return an
entry, even though requesting the feed for the collection returns a
feed of entries, worries me a little. It means that if one wanted
to find the id for the posted object one would have to scroll
through the feed to find it. Is that asymetry really necessary?
Well so that's probably enough for now. I have a couple of
questions, 2 assumptions and 1 worry.
Henry Story
[1] see presentation at http://bblfish.net/work/atom-owl/2006-03-02/
and ontology at http://bblfish.net/work/atom-owl/2005-10-23/
