<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Dear all,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">In the minutes Markus wrote</div>
<div class="moz-cite-prefix">
<blockquote type="cite">
<ul style="margin-top: 0px; background-color: rgb(255, 255,
255); color: rgb(0, 0, 0); font-family: arial, verdana,
sans-serif; font-size: 13.65px; font-style: normal;
font-variant-ligatures: normal; font-variant-caps: normal;
font-weight: 400; letter-spacing: normal; orphans: 2;
text-align: left; text-indent: 0px; text-transform: none;
white-space: normal; widows: 2; word-spacing: 0px;
-webkit-text-stroke-width: 0px; text-decoration-thickness:
initial; text-decoration-style: initial;
text-decoration-color: initial;">
<li style="background-color: transparent;">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.</li>
</ul>
</blockquote>
That's a good summary of what we discussed last monday<br>
</div>
<div class="moz-cite-prefix">My 2 additional cents. The use case I'm
considering also come from recent discussions within ESCAPE about
VO integration of gamma data.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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). <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">In a DataLink context could we use
#progenitor for both ?</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I think not because the event list
comes from the observation and will be specific to these DL5
datasets.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">A smart client would have to take these
two "ancestors" of our DL5 dataset in a very different way.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">My suggestion for the IRF semantic term
is to simply use a new term #irf</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">----------------------------------</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">About the "sorting out" issue of
#progenitor, #calibration-applied and #irf for display purposes
... <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Having different semantics terms for
those different concepts would allow the client to display them
in different sections of the tool.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Descriptions (even if they are well
filled) would never allow to separate automatically such things.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Descriptions should complete the
semantics information to really describe the specificity of the
considered link, not to type them.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Regards<br>
</div>
<div class="moz-cite-prefix">François<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Le 15/03/2022 à 13:27, Markus
Demleitner a écrit :<br>
</div>
<blockquote type="cite"
cite="mid:20220315122708.awvqtm5uxsljdn5x@victor">
<pre class="moz-quote-pre" wrap="">Dear Semantics, Dear Registry,
We had a telecon yesterday (for the Semantics WG: The minutes are at
<a class="moz-txt-link-freetext" href="https://wiki.ivoa.net/twiki/bin/view/IVOA/SemanticsCalls-6">https://wiki.ivoa.net/twiki/bin/view/IVOA/SemanticsCalls-6</a> -- 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: <a class="moz-txt-link-freetext" href="http://www.ivoa.net/rdf/voresource/date_role">http://www.ivoa.net/rdf/voresource/date_role</a>
Author: Markus Demleitner <a class="moz-txt-link-rfc2396E" href="mailto:msdemlei@ari.uni-heidelberg.de"><msdemlei@ari.uni-heidelberg.de></a>
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.
<a class="moz-txt-link-rfc2396E" href="http://dc.zah.uni-heidelberg.de/wirr/q/ui/fixed?field0=restype&operator0=%3D&operand0=doc%3Adocument"><http://dc.zah.uni-heidelberg.de/wirr/q/ui/fixed?field0=restype&operator0=%3D&operand0=doc%3Adocument></a>)
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
<a class="moz-txt-link-freetext" href="http://dc.g-vo.org/VOTT">http://dc.g-vo.org/VOTT</a> 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
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>