changedate + add VEP_UCD#50
Conversation
loumir
commented
Apr 27, 2026
loumir
commented
- changed the document date to today
- added VEP_UCD to read and improve if necessary
- need to review VEP for obs.event --> definition, used-in , etc.
loumir
left a comment
loumir
left a comment
There was a problem hiding this comment.
this uploads the VEP-UCD so that they can be reviewed by all authors and improved .
| Section 5.4. Excess rms-flux correlation | ||
|
|
||
| Discussion: TBD in semantics & HEIG | ||
| Propose stat.error.below instead of stat.error.negative ( Mireille) |
There was a problem hiding this comment.
Below is not really from a quantitative sematics, more a geographic one...
There was a problem hiding this comment.
I find stat.error.negative ambiguous. is it understandable in every context ? a discussion with inputs from semantics is probably needed.
There was a problem hiding this comment.
I find stat.error.negative ambiguous. is it understandable in every context ? a discussion with inputs from semantics is probably needed.
I think stat.error.negative/stat.error.positive are less ambiguous than (for example) stat.error.lower/stat.error.upper, stat.error.inf/stat.error.sup, or stat.error.below/stat.error.above. Negative/positive I think is fairly clear in the sense that the quantity with negative/positive error is always numerically lower than/higher than the actual quoted value.
For lower/upper, inf/sup, below/above etc. it's easy to get into trouble with quantities for which the more significant value is more negative, for example, a surface brightness of xxx mag/square degree. Does the stat.error.above value mean a larger surface brightness (smaller magnitude) or a larger magnitude (lower surface brightness)? I've seen both definitions used many times and would prefer a term that ideally eliminates this ambiguity.
|
|
||
| - name: Build the document | ||
| run: make biblio ${{ env.doc_name }}-draft.pdf | ||
| run: make ${{ env.doc_name }}-draft.pdf |
There was a problem hiding this comment.
why removing the bibliography??
There was a problem hiding this comment.
I don't know how this happened.
The workflow has been changed .
I agree we must have the bibliography .
There was a problem hiding this comment.
seems fixed now in the updated version of preview.yml
| Rationale: | ||
|
|
||
| Discussion: suffix E exists and allows various combinations already. | ||
| Harmonize with UCDList1.6 definition |
There was a problem hiding this comment.
This proposes an amendement of the current definition, adding simplicity and the dimension.
There was a problem hiding this comment.
Ok if the additional dimension property is adopted as a new feature in the UCDs .
E means Q already + belonging to the category of spectral data
| Used_in: ?????? | ||
| Rationale: | ||
|
|
||
| Discussion: can we use instead "phys.fluence;phys.count;em.energy"? never clear whether we multiply by em.energy or divide... |
There was a problem hiding this comment.
no because adding "em.energy" does not mean "division per energy"! This proposal is ambiguous in term of dimension, which is not the scope of this VEP.
| Used_in: | ||
|
|
||
| Rationale: | ||
| Discussion: defined in UCDList1.6 with suffix E already allowing pre/post combinations |
There was a problem hiding this comment.
This proposal is an amendement, precising the dimension
Co-authored-by: Bruno Khélifi <khelifi@in2p3.fr>
Co-authored-by: Bruno Khélifi <khelifi@in2p3.fr>
Co-authored-by: Bruno Khélifi <khelifi@in2p3.fr>
Co-authored-by: Bruno Khélifi <khelifi@in2p3.fr>
Co-authored-by: Bruno Khélifi <khelifi@in2p3.fr>
3 participants
