Re: CML RSS

At 12:09 +0100 24/5/07, Jim Downing wrote:
>Hi all,
>
>I've been talking to Nick Day about the issues he's been having with CMLRSS, 
>i.e. the feed itself is problematically large.


the original intent was to provide  CML within the feed to provide 
metainformation
about the molecule and to allow eg visual display  (using  Jmol/JChemPaint)
and allow opportunities to filter the feeds according to eg  molecular formula,
or connectivity (which  Jmol implemented in part).
 Having to retrieve each entry as an enclosure would inhibit/
prevent such uses, particularly if there were many  (1000s)
of such enclosures.  Another intent of  CMLRSS is that it would in fact
be dynamically generated by eg a PHP/MySQL query, which would
restrict the answers returned. Obviously, if  CMLRSS is in fact a full
expression of a database containing  1M molecules, this would not
be practical.

Granted, if its used to provide a feed for  1000s of molecules or a smaller
number of very large molecules, the feed itself does get large.  However,
recollect that another use of  RSS is audio/video.  Here, one item may be
50-500 Mbytes in size.  Remember,  RSS is not designed as  "real time"
system, but designed to work automatically  "overnight".  Thus size
may not be a particular concern when machine is talking to machine.
Having one file containing eg 1000 molecules might be more efficient
than one file containing merely pointers to  1000 molecules, which
would require 1000 http requests.

RSS 1.0 which was used for  CMLRSS does not in fact support the concept
of an enclosure, for which RSS 2.0 was developed specifically. Atom
may also support  enclosure, but  as I understand it, only  RSS 1.0 allows
RDF to be delivered (neither  RSS 2.0 nor  Atom do this).  So
If we do go down this route, we might have to produce separate  RSS 1.0
and eg Atom  1.0 feeds.  I have not studied the specifications recently,
so I may well need to be corrected on this.  Part of the original intention
was that CMLRSS could be used to automatically populate an  RDF
triple store, so the loss of RDF would be missed.
-- 

Henry Rzepa.
+44 (020) 7594 5774 (Voice); +44 (0870) 132 3747 (eFax); 
rzepahs-ee4meeAH724@xxxxxxxxxxxxxxxx (iChat)
 http://www.ch.ic.ac.uk/rzepa/ Dept. Chemistry, Imperial College London, SW7  
2AZ, UK.

(Voracious anti-spam filter in operation for received email.
If expected reply not received, please phone/fax).