The Napkin Representation (fwd)

[Doug Tody]

As noted earlier, it is fine to restrict the options for a particular
use-case, e.g., embedding time series datasets in a VOEvent.  One starts
with a general model, which can be used for many things, and restricts it
for a well defined use-case (hence for example we restrict the allowable
units when the Spectrum DM is used in a SSA query).

While it is true that a more custom solution might require less code,
code sharing can be much enhanced if a standard solution is adopted.
We were told earlier that the problem is not well constrained, and a
more general solution is required - arbitrary analysis may be required.
In this case the more standard solution with more re-use will win out.

	- Doug


On Thu, 5 Jul 2007, Steve Allen wrote:

> On Thu 2007-07-05T18:07:41 +0200, Frederic V. Hessman hath writ:
> > I'm no big fan of VOTable, but in this case, I have to agree: a
> > VOTable can easily do the same thing as <NapkinLightcurve> but is
> > already standardized and there are already parsers and tools.  The
> > only complaint can be that VOTable isn't just for lightcurves so one
> > has to check for the ucd's - so what, you'll have to do that anyway.
> 
> The Napkin severely restricted the number of options, far more so than
> VOTable with the availble UCDs.  So whereas it implies a new parser,
> the software support requirements for class libraries behind that
> parser might be much less than with VOTable.  That was part of the
> point of eschewing the complexity of STC which (perhaps along with the
> preprandial drinks) inspired the napkin.
> 
> --
> Steve Allen                 <sla at ucolick.org>                WGS-84 (GPS)
> UCO/Lick Observatory        Natural Sciences II, Room 165    Lat  +36.99855
> University of California    Voice: +1 831 459 3046           Lng -122.06015
> Santa Cruz, CA 95064        http://www.ucolick.org/~sla/     Hgt +250 m
>