Tagging VOTable Document

[Bonnarel]

Tagging the VOTABLE Document the note is specifying ...... as being consistent with the Note

[Bonnarel]

There was a discussion during the last days about how the VOTABLE document could inform applications (and human readers ;-) ) to be consistent with what the Note is specifying. After discussion it appeared that a "utype" on the englobbing RESOURCE (type="results") was not the best. Wouldn't it be useful to have an INFO tag as proposed by DALI just after the initial RESOURCE TAG ? Something like : <RESOURCE type="results">

<INFO name="standardID" value="ivo://ivoat.net/standards/vot_annnotaion_for_ts" />

.......

or

<RESOURCE type="results">

<INFO name="citation" value="http://ivoa.net/documents/vot_annotation_for_ts_ada_etal_2020.html" >

[AdaNebot]

I like the idea of adding a TAG to the VOTable which points to the document which describes the annotation of that VOTable:

<INFO name="citation" value="http://www.ivoa.net/documents/Notes/LightCurveTimeSeries/" >

This facilitates to understand why a certain annotation was used.

[AdaNebot]

Before I do any other modification in the text, @msdemlei , can you comment on this?

[msdemlei]

So, citation INFOs are already reserved by DALI (to tell people what to cite when they use the data).

On standardID: as I wrote over on #8, I'd say we should keep them for dataproduct types somewhere in the region of "result list" and say declare what sort of results is in them (or what protocol client ought to interpret them).

That's rather different from what we have here.

We could widen standardId's scope to mean something like "Look here for a definition of the format used in this table". This would let us be more precise than just saying "this is a time series".

But the exact type of the format (as in: specification, version, etc), I'd say, is something we might not even need to specify. As long as we're clear what is what, my expectation would be we could let clients auto-sense that ("see if you find a group with the name PHOTCAL"; if you don't find one, see if there's vo-dml annotation for...").

My vote: Close this issue for now and wait until people have a concrete use case for exact format identifiers. Then see what kind of information they need: Standard name, major version, minor version, micro version, ...?

Until then, I'm quite sure clients will be happy just learning it's a time series.

[disclaimer: I'd be curious what Pierre Fernique has to say about this]

[lmichel]

DALI1.1 section #4.4.3 doe not say that this INFO tag only for citations. It can also be used "to say that the VOTable was produced by a [SIA..] service". The problem is that applying pattern defined in a note is not the same thing that applying a standard. Can we use some IVOID referencing a note? If we can't, we have to move this information within a specific group. I do not agree that the presence of a PHOTCAL is enough to say that a RESOURCE contains a light curve or a time series. There a plenty of reasons to have a PHOTCAL in non-time related data sets. The proposal, whatever it is, will be more consistent if it can be able to say what mapping pattern is used in the VOTable. I'm pretty sure that clients will be happy to deal to VOTAbles enable to say "I'm a TS". This has been easily solved by my VODML-lite proposal by putting a reference to the model at the root place. But with the GROUPs, we do not have any model to refer to. So let's create an ad-hoc UTYPE. Below is a rough option:

<GROUP utype="mapping.patterm">
   <PARAM utype="mapping.pattern.id" value="The.TDIG.Note or whatever id"/>
</GROUP>

[msdemlei]

On Thu, Apr 30, 2020 at 01:59:49AM -0700, Laurent MICHEL wrote:

DALI1.1 section #4.4.3 doe not say that this INFO tag only for

True -- but hijacking INFO[@name='citation'] for this purpose means ruining it for what it was intended to do (let clients have a button "generate reference list for the data you've been using") before it's even been taken up. So, let's not abuse it.

If we can't, we have to move this information within a specific group. I do not agree that the presence of a PHOTCAL is enough to say that a RESOURCE contains a light curve or a time series. There a plenty of reasons to have a PHOTCAL in non-time related data sets.

True, but we wouldn't tag these with dataproduct_type="timeseries", right? I expect there's very little potential for confusion when you have a timeseries with a column referencing a PHOTCAL group.

The proposal, whatever it is, will be more consistent if it can be able to say what mapping pattern is used in the VOTable. I'm pretty sure that clients will be happy to deal to VOTAbles enable to say "I'm a TS".

You are or you are not? Because if "I'm a TS" is enough, then the dataproduct_type PARAM would just fit the bill.

This has been easily solved by my VODML-lite proposal by putting a reference to the model at the root place. But with the GROUPs, we do not have any model to refer to. So let's create an ad-hoc UTYPE. Below is a rough option:

<GROUP utype="mapping.patterm">
   <PARAM utype="mapping.pattern.id" value="The.TDIG.Note or whatever id"/>
</GROUP>

Ah, let's not pretend we're doing actual data modelling here -- of course, if we had a usable and at least halfway agreed-upon mapping syntax, we wouldn't be here discussing this.

Since we don't, let's not make anything normative that will, if and when the mapping syntax comes, collide with it.

If we really feel we need to say more than say "I'm a time series", I'm all for re-using standardId, in addition to dataproduct_type (as it's rather orthogonal). And if we bother to do this, I think we should have a version-sharp standard id, like ivo://ivoa.net/std/TimeSeries#vot-1.0, as clients bothering to look at such a thing would probably have very specialised interests (as in: a validator).

Still, I'd suggest we just mention this possibility in this note and see if people actually want this; if we put it in now, someone has to maintain a StandardsRegExt record for this note (because the ivoid needs to point somewhere). Which is easy as such, but too many easy things weigh us down, too.

[lmichel]

I agree with the Markus suggestion " just mention this possibility in this note and see if people actually want this"