Mango10RFC < IVOA

IVOA Web>Mango10RFC (2026-01-29, LaurentMichel) (raw view)
---+ MANGO 1.0: Proposed Recommendation: Request for Comments

<br />%TOC{depth="2"}%

In the VO world, there is a paradox: source data, which represent the basic building blocks of astronomers' work, is not modeled.<br />Astronomical sources and their measured data, the key to astronomers' work, have no dedicated IVOA data models yet.<br />This paradox can be explained by the multifaceted nature of observed source objects.<br />&#x2028;Generally, the way features of source data are described and organized depends on the targeted scientific objective.<br />Principal investigators and archive designers set up the data profile, structuring it according to their goals, which vary from one project to another.<br />Therefore, a single static data model cannot serve this diversity by describing a source item for all possible cases.<br />&#x2028;A global source model would lead to an overly complex and impractical solution.<br />This standard proposes overcoming this paradox by presenting a template model that gathers independent components embedded in a container on demand.<br />MANGO is not designed to describe what a source is, but rather to help clients discover and understand the quantities available for each source instance in a catalog.<br /><br />In a list of sources — typically a catalog — each column has a meaning that can be associated with a property covered by MANGO.<br />Thus, MANGO helps build an upper description level for tabular query responses and homogenizes descriptions of relevant quantities.<br />The metadata already present in the table columns can be annotated using MIVOT to facilitate catalog comparison, discovery, and analysis.

Latest version of IVOASTANDARD can be found at:
   * [[https://ivoa.net/documents/MANGO/20250620/index.html][IVOA-DOC]]

---++ Reference Interoperable Implementations

The project contains 4 static files, shown as working examples located in _PROJECT_HOME/implementations._ <br />They cover most of the model features (see coverage <a href="https://github.com/ivoa-std/MANGO/blob/pr-1.0/implementations/README.md" target="_blank" title="table">table</a>). In addition to this, we have 2 services (Vizier, XMM) providing annotated data compliant to MANGO DM.

The term "reference implementation" has never been clearly defined in the context of a model. In the case of MANGO, whose purpose is to restore complex quantities from tabular data, we provide static or dynamic VOtables, whose data are mapped onto MANGO using the Mivot schema. Additionally, we consider the Pyvo Mivot API to be another type of implementation.
---+++ Static Files

4 references files implementing most of the model features are provided within the _implementations_ [[https://github.com/ivoa-std/MANGO/blob/pr-1.0/implementations][folder]] in the Git repository. The detail of the covered properties is givel by this <a href="https://github.com/ivoa-std/MANGO/blob/pr-1.0/implementations/README.md" target="_blank" title="table">table</a>.

<ul dir="auto"> <li> <p dir="auto"> *xtapdb*:TAP query response on the 4XMMdr14 slim catalog. The VOTable has been annotated on the flight by the server. <br />A link binding the postion with a quality flag has been added by hand.</p> <ul dir="auto"> <li> *file*: xtapdb.xml</li> <li> *service*: https://xcatdb.unistra.fr/xtapdb</li> <li> *query*: SELECT TOP1 * FROM "public".mergedentry</li> <li> *format*: application/x-votable+xml;content=mivot</li> </ul></li> <li> <p dir="auto"> *Gaia*:Vizier query response on the GAIA DR3 catalog. The VOTable has been annotated on by hand with the Pyvo MIVOT API.</p> <ul dir="auto"> <li> *file*: gaia_with_mivot.xml</li> <li> *service*: https://vizier.cds.unistra.fr/viz-bin/votable</li> <li> *query*: see the mango:origin.QueryOrigin instance</li> </ul></li> <li> <p dir="auto"> *datalink*:Query on an Obscore table made to exercise the mapping on both Footprint and Datalink classes. The VOTable has been annotated on by hand on the project purpose.</p> <ul dir="auto"> <li> *file*: datalink.xml</li> <li> *service*: https://ws.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/argus</li> <li> *query*: SELECT TOP 1 ivoa.ObsCore.obs_id,ivoa.ObsCore.s_region,ivoa.ObsCore.access_url FROM ivoa.ObsCore</li> </ul></li> <li> <p dir="auto"> *vizier_cs_I_239*:Cone search response on the I/239 Vizier table. The VOTable has been annotated on the flight by the server.</p> <ul dir="auto"> <li> *file*: vizier_cs_I_239.xml</li> <li> *service*: https://cds/viz-bin/conesearch/V1.5/I/239/hip_main</li> <li> *query*: RA=0&DEC=0&SR=0.5</li> </ul></li> </ul>
The detail of the covered properties is given in the README file.
---+++ Services

There are two services in operation and serving data mapped on MANGO.
---++++ XTapDB (HE Data and Photometry)

A TAP service serving XMM catalogue (<a href="https://xcatdb.unistra.fr/xtapdb/" target="_blank">https://xcatdb.unistra.fr/xtapdb/</a>) data (table _mergedentry_) has been deployed.

This service demonstrates the ability of MANGO to properly describe the following quantities
   * Coordinate systems (space, time imported from Coords DM)
   * Position at a given epoch
   * Photometric filters and calibration (imported from Phot DM)
   * Fluxes and hardness ratio
   * Quality flags
Only quiered quantities are annoated.

The service can be connected with <a href="https://saada.unistra.fr/taphandle?url=https%3A//xcatdb.unistra.fr/xtapdb/" target="_blank">Taphandle</a> or by using curl (or any other client enable to set a specific format)):<b><br /><br /></b>
   * *url:* _https://xcatdb.unistra.fr/xtapdb/sync?LANG=ADQL&REQUEST=doQuery&QUERY=[QUERY]&FORMAT=application%2Fx-votable%2Bxml%3Bcontent%3Dmivot_
   * *query*: SELECT TOP1 * FROM "public".mergedentry
   * *format*: application/x-votable+xml;content=mivot
   * <b>example: </b>copy this [[https://xcatdb.unistra.fr/xtapdb/sync?LANG=ADQL&REQUEST=doQuery&QUERY=SELECT%20TOP%201%20%2A%20FROM%20%22public%22.mergedentry&FORMAT=application%2Fx-votable%2Bxml%3Bcontent%3Dmivot][URL]] in your clipboard.
---++++ Vizier Endpoints

There are 2 Vizier services returning VOtable partially mapped on the EpochPosition MANGO property.

   * ConseSearch: Vizier deployed a cone search service that returns VOtable partially mapped on MANGO
      * URL: <a href="https://vizier.cds.unistra.fr/viz-bin/conesearch/V1.5/TABLE_ID" target="_blank">https://vizier.cds.unistra.fr/viz-bin/conesearch/V1.5/TABLE_ID</a>
      * Example _curl "https://vizier.cds.unistra.fr/viz-bin/conesearch/V1.5/I/329/urat1?RA=52.26708&DEC=59.94027&SR=0.05"_
   * ASU: proprietary URL based protocol to query catalogs.
      * URL: [[https://vizier.cds.unistra.fr/viz-bin/votable/V1.5?-source=I/239/hip_main&-out.max=10][https://vizier.cds.unistra.fr/viz-bin/votable/V1.5?-source=TABLE_ID&-out.max=10]]
      * Example: _curl https://vizier.cds.unistra.fr/viz-bin/votable/V1.5?-so urce=I/239/hip_main&-out.max=10_
These services have been officially [[https://cds.unistra.fr/news][released]] in May 2025.
---++++ Simbad Endpoints

The Simbad cone search can return data mapped to MANGO on demand. To access this data, append <i>RESPONSEFORMAT=mivo</i>t to the query URL.<br /><br />
   * Example: https://simbad.cds.unistra.fr/cone/?RA=269.4521&DEC=4.693365&SR=0.01&VERB=2&MAXREC=1&ORDER_BY=distance&RESPONSEFORMAT=mivot

Each table row is mapped to one _MangoObject_ instance, the available properties of which depend on the verbosity level (_VERB_ parameter).<br /><br />
   * _VERB=1:_
      * The MANGO object is identified by the main Simbad ID
      * It contains 2 properties:
         * an _EpochPosition_ instance mapping the position only
         * A _Label_ mapping the object main type
   * _VERB=2 (and 3):_
      * The MANGO object is identified by the main Simbad ID
      * It contains 4 properties:
         * an _EpochPosition_ instance mapping the position, the proper motion, the parallax and the velocity all with their errors.
         * _Label_ instances mapping the object type, the spectral type and the mophology type
The Pyvo code able to process this output will be included in the next release.<br /><br />

The extension has been released on October 2025.
---+++ Python API

An important new module is being added to Pyvo. This module's purpose is to write and read Mivot annotations, with a particular focus on MANGO (see the [[https://pyvo.readthedocs.io/en/latest/mivot/index.html][doc]]).
   * *Reader* (since PyVO 1.6):
      * Mivot annotations are rendered as dynamic Python objects that obey the model structure. This allows data to be explored through the model view.
      * If the data id mapped onto the EpochPosition property, this API can automatically extract SkyCoord instance.
   * <b>Generic writer (</b>since PyVO 1.6):
      * Allows to build Mivot annotation element per element (attribute, instance, collection...). This API has been made for developpers to build mode user-friendly functionalities.
   * *Mango writer* (since PyVO 1.7)
      * Write coordinate frames (space, time ang photmétric calibration) that are part of Mago instances
      * Map data on _EpochPosition_, _Brightness_ and _Color_ properties. This is faciltated by a meta-data analizer included in the code.
---+++ Implementations Validator

VOTable whose data are mapped onto MANGO can be validated with _mivot-validator:_
   * Package on [[https://pypi.org/project/mivot-validator/][Pypi]]
   * Doc on [[https://app.readthedocs.org/projects/mivot-validator/][readthedocs]]

The validator operates at 3 levels

   * Validation against the VOTable schema
   * Validation against the Mivot schema
   * Validation of the annoatation agans the models they refer to

---++ Note on the Repository

The process of building the document is very specific to the project. he workflow has been set up to make sure the diagrams keep in sync with the specified model.

   * The project is hosted by <a href="https://github.com/ivoa-std/MANGO" target="_blank">GitHub</a> as a regular _ivoa-std_ project
   * The working draft <a href="https://github.com/ivoa-std/MANGO/releases" target="_blank">PDF</a> is regularly udpdated
   * The descriptions of the model elements are stored in individual files located in _PROJECT_HOME/vo-dml/desc_. <br />This allows for an easy update. It also delegates the latex escape character handling to the builder tool.
   * The table of content of the normative sections is given by _PROJECT_HOME/utils/toc.json_
   * The document is built by the _PROJECT_HOME/utils/buildDoc.bash_ script:
      * Insert the description of all model elements in<i> mango.vo-dml.xml</i> and store the result in __desc.mango.vo-dml.xml__ which is the *model reference file.*
      * Escape some characters to please to latex
      * Build the _PROJECT_HOME/doc/model.tex_ file which contains the Latex of the model description (section 4). <br />This step is achieved by the XSLT developed by M. Cresitello Dittmar.
      * Update the publication date
      * Build the pdf with the _ivoatex_ tools
   * The <i>PROJECT_HOME/mivot </i>folder contains MIVOT snippets for the main classes. <br />This allows contributors to figure out what the MIVOT annotation for MANGO could look like.<br />These snippets have been generated with the _mivot-validator_ package (available on pip)
<b>Contributor Watchout: </b>If you want to open a PR, please *do not edit _PROJECT_HOME/doc/model.tex_* but the snippet files in __PROJECT_HOME/vo-dml/desc__ and then run __PROJECT_HOME/utils/buildDoc.bash__.

A brief &lt;a href="https://wiki.ivoa.net/twiki/bin/edit/Href=Https://github/com/ivoa-std/MANGO/blob/wd-v1/0/utils/README/Md?topicparent=IVOA.MANGO-1_0;nowysiwyg=0" rel="nofollow" title="note (this topic does not yet exist; you can create it)"&gt;note&lt;/a&gt; details the process.
---++ Comments from the IVOA Community during RFC/TCG review period: 2025-06-30 - 2025-08-2

The comments from the TCG members during the RFC/TCG review should be included in the next section.

In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your Wiki Name so that authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment.

Additional discussion about any of the comments or responses can be conducted on the WG mailing list. However, please be sure to enter your initial comments here for full consideration in any future revisions of this document

   * Sample comment by TWiki.WikiName
      * Response (by TWiki.WikiName)

---
---

---++ Comments from TCG member during the RFC/TCG Review Period: 2025-06-30 - 2025-08-02

WG chairs or vice chairs must read the Document, provide comments if any (including on topics not directly linked to the Group matters) or indicate that they have no comment.

IG chairs or vice chairs are also encouraged to do the same, althought their inputs are not compulsory.

---+++ TCG Chair & Vice Chair

---+++ [[IvoaApplications][Applications Working Group]]

In a few places, the document states that MANGO is used to reconstruct tabular data from columns. I think this is wrong. MANGO is used to represent multi attribute properties and the correlations that exists between them but the actual linking of columns in tabular data is done by MIVOT. I’ve highlighted a few instances, but if agreed, this needs to be corrected through the document.

2,1 “add an upper description level” -&gt; “add a higher level description layer”

2.1.1 "GAIA mission is producing the largest and *more* precise” -&gt; "GAIA mission is producing the largest and *most* precise”

2.1.7 "This document does not recommend one approach over another. This is a matter for the data providers to decide.” - not sure what this refers to or if it’s needed especially in this section

2.2 “ - MANGO must be able to provide an accurate description of properties which attributes are spread out on multiple columns (e.g. positions, errors).” I would say that MANGO needs to provide accurate description of multi-attribute properties. Whether these are stored in separate columns and need to be linked back is an implementation detail that it’s being taken care by MIVOT.

“ - MANGO must be able to setup links between different properties”. Is that different from “-MANGO must be able to set up correlation links between properties” above?

2.3.1 "MANGO is primarily used to organise tabular data provided by TAP services”. Again, I think this is wrong. MANGO is used to represent catalogue data. MIVOT provides the linking of tabular data with a model, in this case MANGO.

3.1.3 - I’m not sure I understand, especially the second option: "Scattered Independent Quantities: Each table row is considered as collection of independent quantities.”

4.3: "constraint

detail: Property.One association at the time” - formatting error. Not sure what the meaning is either.

4.3.1 "This means that for concepts from the core vocabulary, the value in the semantics fieldz always starts with a hash. (datalink1.1).”. fieldz-&gt;fields. Also, hash missing in datalink example?

5 "The emergence of missions such as Gaia (Gaia Collaboration and Brown et al., 2018), which are capable of observing objects over long periods of time with very high astrometric accuracy, combined with great spectroscopic capabilities, making it possible to link star 3D positions with 3D velocities, thus defining a 6-dimensional astrometric solution, tagged with the epoch when the parameters were set.” Doesn’t make sense. I suggest breaking it in shorter phrases.

5.1.4-5.1.6 - For clarity, I would start with the description first and then mention that they are coords clones.

5.1.8: Why “_applied” instead of “Applied”?

6.4: Formatting problems

8.5: Missing description

11.2 This is not clear to me how it could work so I would remove it.

All points have been addressed by the PR https://github.com/ivoa-std/MANGO/pull/101

<ul dir="auto" style="padding-left: 30px;"> <li>There is one commit per comment, each one referring the concerned section</li> <li>A few other changes have been committed.</li> </ul><p dir="auto" style="padding-left: 30px;">The requested changes that concerned the model itself have been merged with the DataTime representation suggested by DCP. This is due to the fact the the modeling tool (Modelio) does not support versionning.</p> <ul dir="auto" style="padding-left: 30px;"> <li>The updated PDF can be accessed [[https://github.com/lmichel/MANGO/releases/download/auto-pdf-preview/MANGO-draft.pdf][here]]</li> <li>The updated VO-DML can be accessed [[https://github.com/lmichel/MANGO/blob/draft-0.1/vo-dml/desc.mango.vo-dml.xml][here]].</li> </ul>

---+++ [[IvoaDAL][Data Access Layer Working Group]]

In short, in its current state, I don't see anything blocking or conflicting with DAL. It has been proven by some client and server implementations that it can work nicely, especially from the perspective of DAL protocols (mostly SCS and TAP).

Below are my detailed comments about MANGO-1.0, based on the branch [[https://github.com/lmichel/MANGO/tree/apps-review][apps-review]] (taking into account comments done by the Apps WG):

First, here are some minor comments (mostly typos):
   * Be careful to the writing of !VizieR. Only the first and last letters are in upper-case. Here are some places I have noticed it, but there may be more:
      * §2.1.6: "MANGO is not meant to replace the current management of the Vi<strong>Z</strong>ie<strong>r</strong> metadata"
         * "Vi<strong style="background-color: transparent;">z</strong>ie<strong style="background-color: transparent;">R</strong>"
      * §3.1.3: "is based on a Vizie<strong>r</strong> SCS"
         * "Vizie<strong style="background-color: transparent;">R</strong>"
   * §4.3: "for a flavor of property<strong style="background-color: transparent;">' ie</strong>"
   * §6.1:
      * "The time coordinate system is imported from coords:<strong style="background-color: transparent;">s</strong>imeSys." -&gt; coords:<strong style="background-color: transparent;">t</strong>imeSys
      * "I this case, it cannot be stored" -&gt; I<strong style="background-color: transparent;">n</strong> this case, ...
      * "but as an E<strong style="background-color: transparent;">P</strong>ochPosition attribute" -&gt; E<strong style="background-color: transparent;">p</strong>ochPosition
<b><i>A: All the issues above have been addressed</i></b><br /><br />Finally, here are some comments about the text itself:
   * §1: In the Architecture diagram (figure 1), there is a mention of ADQL and TAP, but none for SCS and STC-S (although still a WD, so maybe it should not be here anyway) which are mentioned several times in the document. Why just TAP (along with ADQL and UWS which are just its clear dependencies) is there? If standards to include are just one that can provide MANGO description, then, theoretically, any DAL protocol (e.g. SCS, SIA, SSA) should be here too. I think that this is not needed. So, either TAP is on the diagram with other DAL protocols (at least SCS) or, and this would be perfectly acceptable, no DAL protocol, except !DataLink, should be on the diagram. After all, MANGO does not use/rely on TAP and ADQL ; if they disappear, it will never impact MANGO. However, since there is a clear dependence with !DataLink, it makes perfectly sense to keep this one. I am no expert about this Architecture diagram, so my comment can be perfectly taken as a misunderstanding on this diagram. So, feel free, to take this comment into account or not.
<i><b>A: TAP, OBSCORE, UWS, DatasetDM and ADQL have been removed from the diagram because (as you said) none of those are directly conneted with MANGO</b></i><br /><br />
   * §1.1: "Implementations can use the TAP protocol and distribute data model instances in VOTable."
      * I'd rather say: "Implementations can use DAL protocols (e.g. TAP, Simple Cone Search) ..."
   * §3: Make a clear reference to the Figure 2 inside the text of this section. Because of !LaTeX which likes moving figures in funky places, it is sometimes hard to see when to look at the figure that we see above or below the corresponding text.
<b><i>A: Both issues above have been addressed<br /><br /></i></b>
   * §3.1:
      * According to the figure 3, all fields are required in !EpochPosition. Is it always possible to have all these information (e.g. parallax)?
      * Is it normal that all possible !DataLink fields are not represented in the !DataLink Property object? Could they be optionally added in an implementation?
*A1: The mandatory fields are those required to provide a full description of the property. For example, the EpochPosition requires a position to locate an object in the sky, but not semantics. However, this does not mean that all mandatory fields must be included in a serialisation for it to be valid.*

__A2: The datalink class is a subset of Datalink standard. It's a trade-off between the desciprion completness and the simplicity. It is technically possible to add extra fields in the serialisation, but this would prevent it from validating against the model.__

   * §4.3.1: "relative URIs (Berners-Lee and Fielding et al., 2005) are completed using the base URI of the core !DataLink vocabulary, http://www.ivoa.net/rdf/datalink/core."
      * I don't understand this sentence and the reference to the RDF description of !DataLink.
<b>A: section rephrased with reference to the UAT vocabulary<br /><br /></b>
   * §5.4: Should it be limited to a specific ISO version? Like _ISO 8601_, as usually used in IVOA standards (e.g. UWS, DALI).&lt;&gt;&gt;<br /><br /><i><b>A: Change to explicitely use ISO 8601, as usually</b></i><br />.
   * §9.6:
      * "STC-S: vodml-id: !FootprintSerialization.STC-S [...] SMOC should be in equatorial ICRS. [...] spaceSys can be ignored."
         * The end of the description for STC-S serialization is a copy-paste of SMOC and must be removed.
      * STC-S is a Working Draft for 12 years, and will apparently stay like this for years (probably forever). As such, it should not be referenced as a standard serialization in a document that will become a Recommendation. However, I know it keeps being used in some places for years while waiting for a good replacement (presumably DALI when more complete). So, if there is a strong reason to have it included in MANGO, it MUST be explicitly explained in this document.
__A: The STC-S section has been corrected, and its support is justified.__

__The corrected document is available [[https://github.com/ivoa-std/MANGO/releases/tag/auto-pdf-preview][here]] as a PDF preview .__

-- GregoryMantelet - 2025-12-18
---+++ [[IvoaDataModel][Data Model Working Group]]

This model provides some much needed functionality in the IVOA. With its emphasis on annotating Data (e.g. return from Catalog query) in terms of physical concepts, it opens the door to a new mode of data analysis by enabling users to access the content by modeled concept. The model is supported with software and example implementations on client and server side which illustrate this potential, as well as validators.

---+++ [[DistributedServicesAndProtocols][Distributed Services & Protocols Working Group]]

The standard proposed is mature and well-documented. DSP accepts it.

-- JesusSalgado - 2026-01-15

---+++ [[IvoaResReg][Registry Working Group]]

The proposed standard is well redacted. We do not foresee impacts on the Registry at this time.

NB: found typo in section 6.1: "The space coordinate system is imported from *coordsSpaceSys*." =&gt; coords:SpaceSys

-- RenaudSavalle - 2026-01-28

*A: typo fixed*
---+++ [[IvoaSemantics][Semantics Working Group]]

---+++ [[IvoaDCP][Data Curation & Preservation Interest Group]]

Ok for DCP with come minor suggestions/remarks: (gilles)

Q1:
   * I like the EpochPosition serialization in a flat output – Mango allows it, except for obsDate!<br />see the alternative proposal which exploits dmtype ( [[https://github.com/ivoa-std/MANGO/issues/85][github issue 85]])
_ANSWER_
   * _[[https://github.com/ivoa-std/MANGO/pull/100][ PR #100 ]] - See complete answer in [[https://github.com/ivoa-std/MANGO/issues/85][github issue 85]]_
   * _=EpochPosition:obsDate= is now a simple attribute typed as mango:jd/mjd/iso/year which are new primitive types derived from ivoa:datetime (see the [[https://github.com/ivoa-std/MANGO/actions/runs/16801301175/artifacts/3709110261][PDF preview]])_

Q2:
   * See also the “Other properties relevance “ ( [[https://github.com/ivoa-std/MANGO/issues/99][github issue 99]])

_ANSWER:_
   * _I have no objection to removing the “mango:DataLink” class, provided that no one requests that it be retained (see more in [[https://github.com/ivoa-std/MANGO/issues/99][github issue 99]])_
---+++ [[IvoaEducation][Education Interest Group]]

---+++ [[HEGroup][High Energy Interest Group]]

I reviewed the Mango RFC, and for HEIG, it’s a PASS. I know IG input isn't required, but I would like to add that this is a model of the type we’ve been striving to create in the DM WG for many years. It has the potential to improve software development for projects interfacing with source catalogs. Astronomy projects, as well as the astronomical community, will have a new tool available to model their data with MANGO. I think it will be an IVOA test of substantive Data Models that serve community data management and analysis capabilities. Over time, community uptake will be the measure of the usefulness of the IVOA's data models to the community. Given that our organization supports a DM WG, I think MANGO is a good representative of the model the WG has envisioned for many years.
---+++ [[IvoaKDD][Knowledge Discovery Interest Group]]

---+++ [[IvoaOps][Operations Interest Group]]

---+++ [[IvoaRadio][Radio Astronomy Interest Group]]

---+++ [[IvoaSS][Solar System Interest Group]]

---+++ [[IvoaVOEvent][Time Domain Interest Group]]

---+++ [[IvoaStdsDocsProc][Standards and Processes Committee]]

---

---++ TCG Vote : Vote_start_date - Vote_end_date

If you have minor comments (typos) on the last version of the document please indicate it in the Comments column of the table and post them in the TCG comments section above with the date.

| Group | Yes | No | Abstain | Comments |
| TCG | | | | |
| Apps |  X  | | | |
| DAL |  X  | | | |
| DM | X | | | |
| DSP |  X  | | | |
| Registry |  X  | | | |
| Semantics | | | | |
| DCP | | | | |
| Edu | | | | |
| HEIG | | | | |
| KDIG | | | | |
| Ops | | | | |
| Radio | | | | |
| SSIG | | | | |
| TD | | | | |
| &lt;nop&gt;StdProc | | | | |

---

<br /> &lt;!--<br /> * Set ALLOWTOPICRENAME = IVOA.TWikiAdminGroup <br />--&gt;
Topic revision: r27 - 2026-01-29 - LaurentMichel
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema