Return-Path: Delivered-To: apmail-abdera-user-archive@www.apache.org Received: (qmail 76589 invoked from network); 17 Apr 2009 14:41:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 17 Apr 2009 14:41:00 -0000 Received: (qmail 71317 invoked by uid 500); 17 Apr 2009 14:41:00 -0000 Delivered-To: apmail-abdera-user-archive@abdera.apache.org Received: (qmail 71281 invoked by uid 500); 17 Apr 2009 14:41:00 -0000 Mailing-List: contact user-help@abdera.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@abdera.apache.org Delivered-To: mailing list user@abdera.apache.org Received: (qmail 71267 invoked by uid 99); 17 Apr 2009 14:41:00 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Apr 2009 14:41:00 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of ianmayo@gmail.com designates 209.85.219.161 as permitted sender) Received: from [209.85.219.161] (HELO mail-ew0-f161.google.com) (209.85.219.161) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 17 Apr 2009 14:40:53 +0000 Received: by ewy5 with SMTP id 5so873204ewy.15 for ; Fri, 17 Apr 2009 07:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=wTUTuBo5/H+VRam6AHuv9LYjWDT3qEHYKbu9AkRK4nU=; b=HCwwO8FM59UrUBP3BGhUH7wvMuTmJn4ovpEe0JjNiPCiYZ8yJ5lzsqlWZL1FgFaHqv hhjTl/mToEC1lDzev4m9/euuTvHjPGW62t5bh4BaYecV61Ny0zVk7rcpDB+YL+mK6ptL Dz11IyfIDKB22Ebrdf6Bqu3cZ+Nhqrgf7i0ys= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:content-transfer-encoding; b=nGjJCOBLSrGYmDMi9RyzuoZRodC52I8vuYGMnQzbybltmYEDAAjVtgsBipA/TLYf/t VIY/b0U4iWmNq5KT3GT/u4hXAtdOgGtFNFzF4V80fnzD3syEWJMz+A7GD3u56wfPO7BO XASOj5kja3EAzw6BuVgKfvbrIdPpN+vOaszgI= MIME-Version: 1.0 Sender: ianmayo@gmail.com Received: by 10.210.35.17 with SMTP id i17mr2825261ebi.28.1239979231934; Fri, 17 Apr 2009 07:40:31 -0700 (PDT) Date: Fri, 17 Apr 2009 15:40:31 +0100 X-Google-Sender-Auth: 7b0f21836b8eb129 Message-ID: Subject: Abdera implementation strategy From: Ian Mayo To: user@abdera.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org 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.