content, format, ctype, or xtype ?
Arnold Rots
arots at head.cfa.harvard.edu
Mon May 4 12:47:58 PDT 2009
What I was getting at is this:
- TAP service is supposed to return its results in a VOTable
- VOTable has already a mechanism to include coordinate metadata in
its headers and associate it with the various columns
- TAP service knows (I would hope) what the coordinate metadata are
for its data
Then it would seem logical that the TAP service just fills it in in
the VOTable it generates - and we're all done: no new mechanism needed.
(It's unfortunate that VOTable does not know (unless it's in a new
version) the ISO-8601 datatime data type, but my recollection is that
the STC extension provides for it.)
Is there anything wrong with this procedure?
It seems to me like just following the standards that are already in
place.
- Arnold
Doug Tody wrote:
> Hi -
>
> Despite having just written a long email on UTYPEs, I suggest we are
> getting side-tracked. TAP and VOTable should support pass-through
> of UTYPE (and UCD), as these are important to be able to use TAP to
> access data which has an associated formal data model - SimDB, the
> generic dataset, etc. But this is largely not a TAP issue so long
> as the mechanism supports pass-through of the information. We might
> eventually want to be able to use UTYPE and UCD tags in queries but
> that can come later. We could get futher into UTYPE use cases but
> I suggest it suffices for now to state that we want TAP to support
> access to data containing UTYPEs.
>
> The immediate issue Francois raised is simpler. 1) Do we want to
> say something simple about the "format" of a single field/param
> of a votable, and 2) if so what do we call the attribute used for
> this purpose.
>
> 1) is still not clear although it appears that most feel this could
> be a useful feature to add.
>
> For 2), use of UTYPE is still not ruled out (as detailed in my other
> message), however if we really want this feature, an independent
> mechanism may be preferred, to avoid cases where UTYPE is already
> used by a larger data model.
>
> - Doug
>
>
>
> On Mon, 4 May 2009, Rob Seaman wrote:
>
> > Roy Williams wrote:
> >
> >> Can't we bring TAP back to its original limited purpose as an interface to
> >> a database?
> >
> > The nature of an interface is to tie two things together. In this case, Roy
> > reminds us that on one side lie tables in a DB. On the other side are VO
> > users. Presumably there is a list of table-access use cases that TAP is
> > intended to address?
> >
> > How will users benefit from having TAP? What specifically will applications
> > do with all these meta-metadata tags? Assume the DM and representational
> > hooks are indeed carried in some fashion from point A to point B. To what
> > purpose will they be put? Or rather, will most of the knowledge of the
> > underlying tables be built into the purpose-built applications anyway?
> >
> > For instance, a typical VOish answer might be that a meta^2data rich TAP will
> > permit joins between foreign tables created (very, very carefully created) by
> > different institutions for different purposes. Do we have specific such
> > examples in mind? How do such use cases flow down to the details of
> > specifying [c|x|u]types?
> >
> > Rob
> >
>
--------------------------------------------------------------------------
Arnold H. Rots Chandra X-ray Science Center
Smithsonian Astrophysical Observatory tel: +1 617 496 7701
60 Garden Street, MS 67 fax: +1 617 495 7356
Cambridge, MA 02138 arots at head.cfa.harvard.edu
USA http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------
More information about the dal
mailing list