Abdera implementation strategy

[Ian Mayo <ia...@planetmayo.com>]

Hi all, I'm designing an AtomPub interface to a database storing
scientific observations, building on Abdera.

The context is that I have a database storing sensor observations,
thousands of them. The sensor observations have a natural grouping,
the datafile in which they were recorded.   These datafiles have
attributes such as the trial they were recorded under, and the
platform on which they were recorded.

I want to create an AtomPub interface to this database.  My
observations naturally translate into entries, and the datafiles
translate in to feeds/collections.  Also, the trial and platform
naturally translate into scheme-controlled app:categories.

Here's the trouble.  In my domain the categories apply to the
datafiles, not the observations.  Users filter the database by finding
datasets that match their analysis requirement - then download the
observations.  Thus the categories apply at the feed level.

Now, the Atom Syndication Format allows categories to be applied at
the feed level, but the Atompub protocol only allows the specification
of 'categories' elements at the collection level - thus the category
terms only apply to entries in that collection.

I appear to have a couple of choices, neither of which seem ideal:
- modify Abdera to allow categories elements to be applied at the
Workspace level, specifying the acceptable terms that may be applied
to the child collections (feeds)
- represent my individual datasets as entries within an 'all datasets'
feed.  An individual dataset entry would then have a linkage
(content-src) to a collection-type representation of that dataset
elsewhere in the workspace.  This compromises the 'true' link between
the dataset and it's data observations, and appears to introduce an
unnecessary level of abstraction.

Has anybody on the list solved/faced this before?

Is there a standard pattern for solving a problem like this?

cheers,
Ian.