Download as a utype

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Document related concepts

Relational model wikipedia, lookup

Database model wikipedia, lookup

Entity–attribute–value model wikipedia, lookup

Business intelligence wikipedia, lookup

Open data in the United Kingdom wikipedia, lookup

Data vault modeling wikipedia, lookup

Data model wikipedia, lookup

Information privacy law wikipedia, lookup

Operational transformation wikipedia, lookup

Data analysis wikipedia, lookup

Forecasting wikipedia, lookup

Transcript
Utypes for Model Referencing
●
●
●
A data model can be seen as a structure
(class) containing elements (attributes)
These elements can be mapped into a
qualified name that is called a utype.
Examples:



Target.Name
TimeAxis.numBins
AstroCoords.Time.TimeInstant.ISOTime
Name space in Utypes
●
A qualified utype may be ambiguous (exist in
several data models  use name space:



●
cha: for Characterisation (dedicated note)
spec: for Spectrum data model
stc: proposed for Space-Time coordinates
(proposal of a STC-U complementary to STC-X
and STC-S)
Examples:


cha:TimeAxis.numBins
stc:AstroCoords.Time.TimeInstant.ISOTime
Utype syntax
prefix:element.element.element...
●
●
●
namespace-type prefix
dot-separated list of the elements in the
hierarchy of the data model
to be agreed across IVOA WGs
(was in preparation by JMD)
Utypes as URI ?
●
Extend name space conventions to utypes?
Proposed by N. Gray in an IVOA note


●
Pros: fully accurate, versioning available, may
link to documentation, shared semantics...
Cons: potential proliferation of private models?
Example:



xmlns:cha=”http://ivoa.net/utype/char/1.1/#”
utype=”cha:TimeAxis.numBins”
may find documentation from
http://ivoa.net/utype/char/1.1/#TimeAxis.numBins
Utypes vs UCDs
Example of a value named NAXIS1:
● as a ucd: instr.fov;instr.pixel -- or maybe just
a number !
● as a utype: fits:main.NAXIS1 is the
parameter which gives the dimension along
the X-axis as described by the FITS datamodel
complementary
Utypes in the VO
●
●
●
●
Was created for the DAL needs
Used in SSA
Used by Characterisation
Could be used in ADQL/VOQL
Utypes in VOTable
The tabular material serialized as a VOTable
may contain in its fields (columns) any kind
of data
● it is impossible to import into a VOTable
document all XML structures related to all
data models developed by the VO
VOTable document therefore refers to data
models without including them
●
Utypes in VOTable1.1
●
in VOTable schema: utype is a non-mandatory attribute of
any RESOURCE TABLE FIELD PARAM GROUP
 is an acceptable attribute wherever the ucd accepted
 contrary to the ucd, gives exact meaning
● ucd = broad semantics, typically used for data mining
● utype = detailed semantics, refers to a data model
 is only useful in relation with a data model
 with URI linking ?
Utypes role in VOTable
●
●
supplies an accurate meaning to applications
especially important for quantities (parameters and/or
fields) which exact meaning is crucial




systems of coordinates for spatial correlations: celestial,
terrestrial, solar, ... (connection with STC)
time definitions for time series (connection with STC)
photometric systems & filters
more generally any parameter part of a model, simulation...
VOTable-STC Connection
●
●
●
STC is an essential component to precise the
conventions of dates, locations, coordinate
systems – now an IVOA Recommendation
is of interest in most VO components
in VOTable: replaces (and deprecates) the
COOSYS convention
VOTable-STC connection
Among the different scenarios proposed, the
preference makes use of GROUPs of
parameters
● it was decided to write an IVOA note
dedicated to the VOTable-STC connection
 preliminary version circulated, finally close
to an agreement
● Will be included in VOTable1.2
●
Coordinate components
2 classes are required (STC nomenclature):
➔ the coordinate system = AstroCoordSystem
which will generally refer to standard systems
➔
the actual coordinates = AstroCoord
More generic CooSys and Coords may be used
for non-astronomical coordinate frame.
Detailed Coordinate Definition
Done in 2 groups:
➔ coordinate system group with attributes


➔
utype=”stc:AstroCoordSystem”
ID=”mySysID” for referencing
coordinate group



utype=”stc:AstroCoords”
ref=”mySysID” refers the coordinate system group
ID=”myCoords” for referencing
Actual coordinate values are stored in FIELDs
Coordinate components
Defined in FIELD with attributes:
● ref=”myCoords”
● utype=”stc:AstroCoords.type.rep.comp”



●
type = Position2D | Position3D | Time
rep = Value2 | Value3 | TimeInstant
comp = C1 | C2 | C3 | ISOTime | MJDTime
... plus other attributes ucd, datatype, width,
precision ...
<GROUP utype=”AstroCoordSystem”
ID=”myFrame” >
<PARAM name=”STC_ID”
utype=”stc:AstroCoordSystem.ID”
value=”UTC_ICRS_TOPO” ... />
...
</GROUP>
ID/ref
<GROUP ref=”myFrame”
CoordSystem ID=”myCoords” utype="AstroCoords">
<PARAM name=”epoch”
includes
utype=”stc:AstroCoords.SpaceFrame.
sub-groups
epoch” value=”1991.25” ... />
for time,
...
space,
</GROUP>
redshift...
<GROUP
utype=”AstroCoords”
ref=”myFrame” ID=”myCoords” >
<PARAM name=”epoch”
utype=”stc:AstroCoords.
SpaceFrame.epoch”
value=”1991.25” ... />
...
</GROUP>
ID/ref
<FIELD name=”RA” ref="myCoords"
utype=”AstroCoords.Position2D.Value2.C1”
... />
Examples
●
●
Example 1: excerpt of the Hipparcos
Catalog
Example 2: Ephemerid of a comet
(see the note_stc.html document)
Relations between tables (1)
●
●
●
●
One VOTable document may contain several
tables, meaning tables logically grouped.
In the relational model, relations between
tables are specified via the concept of keys
basic key definitions: primary key (non-null,
unique) and foreign key (must exist as
primary in the related table)
A simple solution: GROUPs
Relations between tables (2)
<GROUP name=”primaryKey”>
<FIELDref ref=”ClusterName”>
<FIELDref ref=”GalaxyName”>
</GROUP>
...
<FIELD ID=”ClusterName” .../>
<FIELD ID=”GalaxyName” .../>
Relations between tables (3)
<GROUP name=”foreignKey”
ref=”mainTable”>
<FIELDref ref=”ClusterName”>
<FIELDref ref=”GalaxyName”>
</GROUP>
...
<FIELD ID=”ClusterName” .../>
<FIELD ID=”GalaxyName” .../>
Relations between tables (4)
Other possible interesting details:
● order of the data, e.g. with
<GROUP name=”order” >
<PARAM name=”sequence” value=”increasing”>
<FIELDref ref=”ClusterName”>
<FIELDref ref=”GalaxyName”>
</GROUP>
Relations between tables (5)
●
not yet decided: what is better:


●
just a <GROUP> with a specific name ?
prefer the definition of some “relational” data
model and refer to these groups with utypes ?
to be included in VOTable1.2 ?
Future of VOTable
After VOTable 1.2
● To keep as a Working Group ?
● Need maintenance ? Volunteers ?