VEP-009 Re: VEP-013 (and minutes of SemCalls 6)

[BONNAREL FRANCOIS]

Dear all,

In the minutes Markus wrote
>
>   * VEP-009 (datalink#progenitor) -- Francois want to restrict the
>     concept to "science data" (e.g., for normal optical observations
>     the raw, uncalibrated frame). One use case for separating out
>     other progenigors would be "display the science data", which you
>     might not want for calibration data. Markus is not convinced this
>     is functionality is actually something a client would want to do
>     in a debugging session. François is also offers that telling apart
>     science and calibration data using semantics would be useful where
>     human-readable descriptions are shoddily done, against which
>     Markus points out that rather than complicating things in
>     semantics, the data publishers should improve their descriptions
>     in such cases. François will continue the discussion on the
>     mailing list.
>
That's a good summary of what we discussed last monday
My 2 additional cents. The use case I'm considering also come from 
recent discussions within ESCAPE about VO integration of gamma data.

When we consider a so called DL5 dataset (a gamma source spectrum, or a 
gamma ray map) we know that this has been produced by complex processing 
of event lists with the appropriate "Instrument Response function" (IRF).

In a DataLink context could we use #progenitor for both ?

I think not because the event list comes from the observation and will 
be specific to these DL5 datasets.

On the other side the IRF would be common to plenty of sources or  DL5 
datasets as far as I understand. So they require to be accessed differently.

A smart client would have to take these two "ancestors" of our DL5 
dataset in a very different way.

My suggestion for the IRF semantic term is to simply use a new term #irf

----------------------------------

About the "sorting out" issue of #progenitor, #calibration-applied and 
#irf for display purposes ...

Having different semantics terms for those different concepts would 
allow the client  to display them in different sections of the tool.

Descriptions (even if they are well filled) would never allow to 
separate automatically such things.

Descriptions should complete the semantics information to really 
describe the specificity of the considered link, not to type them.

Regards
François



Le 15/03/2022 à 13:27, Markus Demleitner a écrit :
> Dear Semantics, Dear Registry,
>
> We had a telecon yesterday (for the Semantics WG: The minutes are at
> https://wiki.ivoa.net/twiki/bin/view/IVOA/SemanticsCalls-6  -- as
> usual, feel free to amend), and it was found that the identifier
> "Validated" from VEP-012 was, indeed, too close to #Valid and even
> vr:validationLevel, and we thought #Inspected was more appropriate.
>
> Hence, VEP-012 is now abandoned and replaced with VEP-013, reproduced
> below.  After yesterday's deliberations, I would forward it to TCG
> review in about two weeks unless someone speaks up here.
>
> Vocabulary:http://www.ivoa.net/rdf/voresource/date_role
> Author: Markus Demleitner<msdemlei at ari.uni-heidelberg.de>
> Date: 2022-03-15
> Supercedes: VEP-012
>
> New Term: Inspected
> Action: Addition
> Label: Last Inspected
> Description: Dates with this role indicate when the resource has last
>    undergone a non-formal inspection, typically by a human, as to whether
>    it is still working as expectable, both technically and as regards
>    science content.
> Relationships:
> Used-in: The registry record ivo://edu.gavo.org/hd/gavo_addpms (and most
>    other IVOA document records; cf.
>    <http://dc.zah.uni-heidelberg.de/wirr/q/ui/fixed?field0=restype&operator0=%3D&operand0=doc%3Adocument>)
>
> Rationale:
>    The prototypical case is for tutorials, where the date of the last
>    inspection as given in the document's registry record (in
>    curation/date) is a good indication for the amount of work that might
>    be necessary to use the tutorial in teaching VO technology -- or, in
>    self-study, how many deviations of actual behaviour are to be
>    expected.  The directory of registered texts at
>    http://dc.g-vo.org/VOTT  lets users sort the results by this date
>    ("Date Checked").
>
>    It is conceivable that data centers use this concept for data
>    services, too, for instance as part of a certification procedure,
>    but the author does not see that as an immediate need.
>
>    This term is not intended for use with vr:validationLevel.  For one,
>    even validation level 4 only applies to the registry record rather
>    than the resource itself, and hence the concept does not apply anyway.
>    In addition, validationLevel elements are, if at all, added by
>    harvestable full registries which must not modify the records outside
>    of the validationLevel elements and hence could not add curation/date
>    elements anyway.
>
>    The non-standard, mixed-case form of the concept identifier is for
>    consistency with the other terms in the vocabulary, which again
>    preserve the form of DataCite date roles.
>
> Discussion:
>    This concept was first proposed as #Validated.  During the Semantics
>    Calls 6 telecon, it was found that this identifier is too close to the
>    existing #Valid (with an entirely different meaning), and that a
>    different identifier would also clearly distance the concept from
>    vr:validationLevel.  After some consideration, #Inspected seemed to
>    suitably convey the intended usage.
>
> Thanks,
>
>             Markus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20220318/2c068586/attachment.html>