Atom-OWL Ontology 22 June 2004

For an overview of my work see the parent directory.

titleA Atom in N3 example feed
created25 May 2004 08:10:00 GMT
authorHenry Story
bodyAn example of an Atom feed in N3. Conversation have been written by Henry Story. These did not take place but could have. (source code available in directory).
---- ----
entries
titleThe Link Class
created26 Jun 2004 09:35:00 GMT
authorHenry Story
bodyIn my last model I thought it would be nice to simply remove the link class. It did really clarify the UML diagram a lot. And it nearly works. It works for the current spec. But there is talk of adding other things to this link element, such as a descriptive text field for example. The text field is a nasty one for my simplification, because there really is no way to get around that. It has to be attached to a link object.

So Link Class is back in. The problem is that it seems to be sooo general. So many things could end up going through a Link Class that it would make UML diagrams completely meaningless. Luckily there is a standard way of dealing with this called an Association class (Fowler, 'UML Distilled, Second Edition', p.98). This allows me to annotate the properties on a Link without making the diagram unreadable. And the result is a readable UML diagram

---- ----
titleFeedisAEntry
created19 Jun 2004 18:20:00 GMT
authorHenry Story
bodyBy reconstructing the UML of Danny Ayers Atom in OWL model we can show that a feed is an Entry. This chimes with some other very interesting consequences of the REST architecture such as that described by Mark Baker. A fuller explanation of my original thinking with graphics can be found on this post of the Atom mailing list. The OWL model I have used is here. I have moved back to something a little closer to Danny Ayer's original model, by removing the State object, that I really only needed in my database representation. The model can be represent like this in UML
except that I have left out the EntryState object and merged it back into Entry as in Danny Ayers' original Atom OWL model.
---- ----
entries
titleInteresting idea.
created11 Jun 2004 21:20:00 GMT
authorDanny Ayers
bodyThat is an interesting idea. So you are saying that if I add an entry your post it is going to turn into a feed? Pretty neat :-)
---- ----
titleMapping to XML
created22 Jun 2004 07:13:00 GMT
authorAsbjorn Ulsberg
body Yes! Look at entry.2004-05-10.2020.n3 in this directory. It is a Feed and an Entry at the same time.
How are you going to map this into Atom XML?
---- ----
titlere: Mapping to XML
created22 Jun 2004 08:55:00 GMT
authorHenry Story
bodyI am trying to get the semantics right first of all. Since N3 can be mapped into XML in a number of ways, showing that this can be done in N3 shows that it can be done in XML. It is a further task to then work on the Atom XML syntax to make this work there too.
Noticed that your entry is entry.2004-05-21.0913.n3. It is not a feed. Just a plain entry. Though at any time it could turn into a feed, if someone responded to your post. It is interesting how this differs from OO programming like java where Objects cannot be cast down the class hierarchy once they have been instantiated. (except for Dynamic Proxies perhaps?)
---- ----
titleNot a good idea!
created22 Jun 2004 23:05:00 GMT
authorKen McLeod
bodyAfter a long conversation on #atom irc channel, with Henry I think we came to the conclusion that making a Feed a subclass of Entry is a bad idea. The following reasons make me think this would make the model unRESTful. The main problem is that by allowing any entry to be turned into a feed we make it reasonable for every entry on the system to be polled, since at any time that entry could turn into a new feed. This would if deployed widely massively increases the amount of requests going over the web, make the caching of entries meaningless, and thereby render meaningless the main reason of a feed's existence: the reduction in traffic it allows for by funnelling changes into one request.

So even though this model does seem equivalent to the original one proposed by Danny, and though it looks cleaner UML wise, it also potentially fails to preserve the main properties of a feed:

  • entries should not change
  • the head document of a feed should be the only thing that does change
Once a feed has reached a certain size its contents should be moved into a feed archive which should be fixed and unchanging.
---- ----
titleOther improvements
created24 Jun 2004 11:05:00 GMT
authorHenry Story
bodyI completely agree with bitsko's argument above. It took me some time to understand where he was going, but in the end it clicked.

In any case there are other ways of achieving similar simplifactions of Danny's original model that now come to my mind.

  • One of them is that the link object feels quite superfluous, especially in N3. In N3 every property is a link between two resources, so the idea of modeling a link object between resources feels redundant. Especially between the feed and its successor (next) and its predecessor (prev). In N3 it is clear that that should be simply replaced by a successor and predecessor property. Furthermore we can allready observe in the current example's archived feed that the start relation is redundant: An archive feed in N3 is simply a number of triples with as object the url of the main feed. This removes the relation we had between the Feed and the Link object in our original diagram.
  • The other simplification we can make to the orignal diagram is move the title and other info from the Feed class into the Entry class. Ie we can refactor our inheritance diagram with a containement relation between a feed and its header entry. A well known refactoring: 'Replace Inheritance with Delegation', p. 352, Refactoring, by Martin Fowler.
  • This makes the feed into a very specialised Entry container.
  • service.edit type links in RESTish world seem unecessary since that is just the url of the entry or feed itself.
  • service.post type links should just be a specialised relation between a feed and a resource. What type that resource has in OWL I don't yet know. It just seems a very general type of thing.
This leaves us then with the following diagram, which is even simpler that the one using inheritance I described previously.
So perhaps there is some more work to be done on the content object.
We do of course loose the threading ability that we see here, but that should be easy to reconsitute by adding a in-reply-to relation between entries. Oh heck. Let me add it right now...
---- ----
titleREST: the thesis
created23 May 2004 07:12:00 GMT
authorHenry Story
bodyThis thesis by Fielding is really worth reading! I think I read it too quickly to do it justice and will need to reread it carefully.
---- ----
titleMy third blog entry
created22 May 2004 08:10:00 GMT
authorHenry Story
bodyThis is the first entry of this example feed. To be precise this is the html representation of the entry. The n3 entry itself is editable by WebDav like methods. The feed still lacks many features. It should of course point to this piece of html. Some other things that could be added is an example of the entry pointing to its parent (or should that be its 'in-reply-to' feed/entry. Or should there be both?
You will notice that the feed can always be found at feed.bblfish.n3 in this directory. As new entries are added a link object will get created in that n3 file pointing to the older links. That will be another n3 file. You can find the first two blog entries by looking at the feed.
---- ----