Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Data analysis wikipedia , lookup
Information privacy law wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Business intelligence wikipedia , lookup
Forecasting wikipedia , lookup
Open data in the United Kingdom wikipedia , lookup
Operational transformation wikipedia , lookup
Relational model wikipedia , lookup
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 ?