xtype: similarity to VODataService's externalType
Douglas Tody
dtody at nrao.edu
Thu May 28 13:59:36 PDT 2009
The specific problem we are trying to solve here is how to specify
the TAP (ADQL), DBMS-oriented datatypes, for example when we upload a
table to TAP, or pass a table between two TAP services. In this case
there are a whole set of datatypes specific to DBMS type operations.
This has a mapping to the VOTable datatypes but is more DBMS oriented
(you can read about in the TAP_SCHEMA section of the TAP draft).
The cases of ISO8601 and STC-s are special, more limited but general
cases. While in principle xs:dateTime might help with ISO8601 it is
not going to give us a way to specify general ADQL datatypes for the
fields of a table encoded as VOTable, and preserve these across data
transfers encoded as VOTable.
The problem is that all the field attributes in VOTable are used up.
Either we add a new attribute (XType or whatever), or we overload an
existing one (UCD or UNIT). The consensus in the meeting today was
that it was better to have a "clean" solution to extend the datatype
specification, rather than overload an existing attribute.
Anyway, after thinking about this some more over dinner, I suggest we
might change the name of the new attribute to something like "xdatatype"
(extended datatype) to make it more clear that this is a type of
"datatype", rather than something that sounds similar to UTYPE.
- Doug
On Thu, 28 May 2009, Rob Seaman wrote:
> Does this discussion seem as inscrutable to people onsite? :-) Here
> is the only email I've found where dateTime is mentioned in a VO
> context:
>
> >> From: Arnold Rots <arots at head.cfa.harvard.edu>
> >> Date: April 20, 2006 10:53:03 AM GMT-07:00
> >> To: Rob Seaman <seaman at noao.edu>
> >> Cc: VOTable mailing list <votable at ivoa.net>, Mark Taylor <m.b.taylor at bristol.ac.uk
> >> >
> >> Subject: Re: String representations of numeric values
> >>
> >> ISO-8601 is not a problem; it can be handled through xs:dateTime.
> >>
> >> - Arnold
>
> Perhaps a pointer to some more extensive (VO) discussion about
> xs:dateTime? I presume we're meant to start somewhere like:
>
> http://www.w3.org/TR/xmlschema-2/#dateTime
>
> Meanwhile Doug's discussion seems just a teensie weensie itsy bitsy
> obscure...certainly we should expect none of our users to ever
> comprehend the difference between XTYPE and UTYPE.
>
> Combining the two, is it possible that xtype is a solution to a
> general class of problem that has already been solved in the w3
> context by particular structures like dateTime?
>
> Rob
> -----
>
> On May 28, 2009, at 12:21 PM, Arnold Rots wrote:
>
> > I probably should have reminded people, for the record, of something I
> > mentioned a long time ago: that the whole business of ISO-8601 time
> > stamps could be avoided if VOTable were to recognize the datatype
> > xs:datetime.
> >
> > - Arnold
> >
> > Douglas Tody wrote:
> >> Hi -
> >>
> >> As I mentioned in the VOTable session, we need to be very careful
> >> to distinguish XTYPE from UTYPE. So XTYPE is used to define a
> >> "custom type". But an "abstract type" sounds very similar, but can
> >> be an object or data model, which is where UTYPE is already used.
> >>
> >> The distinction should be that anything which has an XTYPE is an
> >> atomic type which could be used anywhere (not defined as an element
> >> of
> >> some data model), and which can be mapped to a primary type such as
> >> any VOTable datatype. Basically it is used to extend the "machine"
> >> level typing system to say things such as a primitive type of string
> >> contains a timestamp or STC-S region.
> >>
> >> We can probably ensure against semantic confusion by insisting that
> >> an
> >> XTYPE be storable in a single item of primitive type, and manipulated
> >> atomically as a primitive type would be, at the layer where the type
> >> is defined. It would be possible to abuse this simple concept by
> >> serializing an object as a string or blob, but if it can nonetheless
> >> be manipulated as an atomic object at the level where the datatype
> >> is defined (as in storing an object in a field of a table) this might
> >> still be ok.
> >>
> >> Hence a FIELD or PARAM (and maybe INFO for consistency although I
> >> would be happy with only having string there) can have an XTYPE,
> >> but GROUP should not, nor any higher level non-atomic construct
> >> which has some internal structure. If it can't have a "datatype",
> >> it can't have an XTYTPE. This is for VOTable, but if VODataService
> >> deals with this as well it should be consistent.
> >>
> >> - Doug
> >>
> >>
> >> On Thu, 28 May 2009, Ray Plante wrote:
> >>
> >>> Hi VOTablers,
> >>>
> >>> As discussed in the last VOTable session in Strasbourg, we are
> >>> considering
> >>> adding a new FIELD attribute called xtype (or exttype or
> >>> externalType).
> >>> As I mentioned, this is very similar to an attribute availble in
> >>> VODataService for describing a table column.
> >>>
> >>> For reference, here's how the VODataService Document
> >>> (http://www.ivoa.net/Documents/latest/VODataService.html) describes
> >>> them...
> >>>
> >>> More descriptive information about the type can be provided via
> >>> the
> >>> extendedType and extendedSchema, which provide an alternate data
> >>> type
> >>> name. It's expected that this name will only be understood by a
> >>> special
> >>> subset of applications. The name given in the element content,
> >>> then,
> >>> represents a more commonly understood "fall-back" type.
> >>>
> >>> extendedType Value type: string: xs:string.
> >>> Semantic Meaning: the data value represented by
> >>> this
> >>> type can be interpreted as of a
> >>> custom type identified by the
> >>> value
> >>> of this attribute.
> >>> Occurrences: optional
> >>> Comments: The name implies a particular
> >>> expected format for the data
> >>> value that can be parsed into a
> >>> value in memory.
> >>>
> >>> If an application does not
> >>> recognize
> >>> this extendedType, it should
> >>> attempt
> >>> to handle value assuming the
> >>> type
> >>> given by the element's value.
> >>> "string" (or its equivalent)
> >>> is a
> >>> recommended default type.
> >>>
> >>> This element may make use of
> >>> the
> >>> extendedSchema attribute and/
> >>> or any
> >>> arbitrary (qualified)
> >>> attribute to
> >>> refine the identification of
> >>> the
> >>> type.
> >>>
> >>> extendedSchema Value type: URI: xs:anyURI.
> >>> Semantic Meaning: An identifier for the schema
> >>> that
> >>> the value given by the extended
> >>> attribute is drawn from.
> >>> Occurrences: optional
> >>> Comments: This attribute is normally
> >>> ignored if
> >>> the extended element is not
> >>> present.
> >>>
> >>> hope this is helpful for reference.
> >>>
> >>> cheers,
> >>> Ray
> >>>
> >>
> > --------------------------------------------------------------------------
> > 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 votable
mailing list