<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Ole, all,</p>
<p>Answer on one point<br>
</p>
<br>
<div class="moz-cite-prefix">Le 05/11/2018 à 09:57, Ole Streicher a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:23196e59-e0eb-3b87-d99c-30e85a753b85@aip.de">
<pre wrap="">Hi all,
I shorten the text to the points where I have comments:
On 04.11.2018 20:26, Mireille LOUYS wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Le 29/10/2018 à 17:26, Markus Demleitner a écrit :
</pre>
<blockquote type="cite">
<pre wrap="">TL;DR: let's only have the core model in 1.0. We can always add
extensions in 1.1.
</pre>
</blockquote>
</blockquote>
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">we need the ActivityDescription class and Parameter class to be able
to search for some specific processing type on the data. Activity is
only the process launched for the computation. It does not hold the
details of the methods , because those details are factorised in the
ActivityDescription class.
</pre>
</blockquote>
<pre wrap="">
We could move (only) the ActivityDescription as a prov:Plan into the
core model.
Parameters are generally questioned as being special thingies that carry
only configuration. Entities already may have the properties needed for
Parameters.
There is an ongoing discussion about Parameters; however it is stalled
since two weeks, since nobody responded to the latest critics on this
concept.
</pre>
<br>
</blockquote>
<br>
<br>
This is (part of ? ) the discussion Ole is tackling on the RFC page<br>
<br>
<blockquote type="cite">
<p>
<span style="color: #808080"><a
href="http://wiki.ivoa.net/twiki/bin/view/IVOA/OleStreicher"
class="twikiLink">OleStreicher</a> - 2018-10-22 :</span>Therefore,
we propose to homogenize the handling of <code>Parameter</code>
with the handling of other <code>Entity</code> by re-using the
<code>used</code>, <code>EntityDescription</code>, and <code>UsageDescription</code>
classes also for <code>Parameter</code>. Then, <code>Parameter</code>
is special only by the fact that they directly contain a value,
while other <code>Entity</code> s would refer to their content
by a link.
</p>
<p>
<em>-- <a
href="http://wiki.ivoa.net/twiki/bin/view/IVOA/FrancoisBonnarel"
class="twikiLink">FrancoisBonnarel</a> - 2018-10-23: No
(Data) Entities have values too.</em> -- <a
href="http://wiki.ivoa.net/twiki/bin/view/IVOA/FrancoisBonnarel"
class="twikiLink">FrancoisBonnarel</a> - 2018-10-23
</p>
<p>
<span style="color: #808080"><span style="color: #808080">-- <a
href="http://wiki.ivoa.net/twiki/bin/view/IVOA/OleStreicher"
class="twikiLink">OleStreicher</a> - 2018-10-24</span></span>
-1 : <span style="color: #808080"><span style="color: #808080"></span>You
did misunderstand this sentence: Our <a
href="http://wiki.ivoa.net/internal/IVOA/ProvenanceRFC/ProvenanceDM-alternate.pdf"
target="_top">alternative proposal</a> is to make <code>Parameter</code>
be a special <code>Entity</code> that carries a value, while
other (Data) <code>Entities</code> refer to the content via
link.-- </span>
</p>
<p>
<span style="color: lightsteelblue;"> </span>
</p>
<p>
<span style="color: lightsteelblue;">-- <a
href="http://wiki.ivoa.net/twiki/bin/view/IVOA/MathieuServillat"
class="twikiLink">MathieuServillat</a> - 2018-10-24 -2
:The limit here is that we should not assume what a general
entity will be (how can we?), so we do not describe the
content/value of it, just the general category (specialized
entity that are commonly manipulated in astronomy) or the type
of container (in e.g. the <span class="twikiNewLink"><a
href="http://wiki.ivoa.net/twiki/bin/edit/IVOA/EntityDescription?topicparent=IVOA.ProvenanceRFC;nowysiwyg=0"
rel="nofollow" title="EntityDescription (this topic does
not yet exist; you can create it)">EntityDescription</a></span>
with format, content_type... i.e. how to read it and not what
we read). However, configuration information in the form of
parameters as an input to an activity are relevevant
provenance information (it helps assess the reliability and
quality of the activity, see section 2.2.6 of the PR), so for
this input parameter, we describe and restrict the expected
value of it, so that it becomes queryable in the standard. The
content/value of a Data entity is not expected to be queryable
using a provenance system, nor to provide relevant provenance
information.</span> <br>
</p>
<p>
<span style="color: #808080"><span style="color: #808080">-- <a
href="http://wiki.ivoa.net/twiki/bin/view/IVOA/OleStreicher"
class="twikiLink">OleStreicher</a> - 2018-10-24 -3 </span>The
value of a <code>Parameter</code> is also stored in the
simpler <a
href="http://wiki.ivoa.net/internal/IVOA/ProvenanceRFC/ProvenanceDM-alternate.pdf"
target="_top">alternative model</a>. Our model does not
restrict the queryability of that value. Also your proposal
does not specify that BTW. </span>
</p>
<p>
<span style="color: #808080"><a
href="http://wiki.ivoa.net/twiki/bin/view/IVOA/OleStreicher"
class="twikiLink">OleStreicher</a> - 2018-10-22 :</span>
This would also make the described hack unnecessary.
</p>
<p>
<em> -- <a
href="http://wiki.ivoa.net/twiki/bin/view/IVOA/FrancoisBonnarel"
class="twikiLink">FrancoisBonnarel</a> - 2018-10-23
: General statement to refuse this evolution: It is true that
Parameter has managed in a special way in the current PR. It
is intentional. Why ?</em> <em>The Parameter class is there
to tackle what astronomy application users generally call
"parameters" of the application.</em> <em>Think to SExtractor
or <span class="twikiNewLink"><a
href="http://wiki.ivoa.net/twiki/bin/edit/IVOA/HipsGen?topicparent=IVOA.ProvenanceRFC;nowysiwyg=0"
rel="nofollow" title="HipsGen (this topic does not yet
exist; you can create it)">HipsGen</a></span>. They have a
couple of parameters such as "ANALYSIS _THRESH",
"MAG_ZEROPOINT" (SExtractor), fov, skyval, border, publisher (<span
class="twikiNewLink"><a
href="http://wiki.ivoa.net/twiki/bin/edit/IVOA/HipsGen?topicparent=IVOA.ProvenanceRFC;nowysiwyg=0"
rel="nofollow" title="HipsGen (this topic does not yet
exist; you can create it)">HipsGen</a></span>).</em> <em>They
are definitly a different concept than <span
class="twikiNewLink"><a
href="http://wiki.ivoa.net/twiki/bin/edit/IVOA/DataEntity?topicparent=IVOA.ProvenanceRFC;nowysiwyg=0"
rel="nofollow" title="DataEntity (this topic does not yet
exist; you can create it)">DataEntity</a></span>, which
are the things we want to follow with our Provenance model,
the things which are used or transformed by the activities.</em>
<em>So parameters are so strongly bound to activities that they
don't have existence outside their bounding to an activity.</em>
<em>They have a value which is either a number or string, or a
reference to external structures (files) or internal entities.</em>
<em>In the latter case it is possible to use as a parameter
value an id of something which has an history in the
provenance.</em> <em>ActivityDescription and <span
class="twikiNewLink"><a
href="http://wiki.ivoa.net/twiki/bin/edit/IVOA/EntityDescription?topicparent=IVOA.ProvenanceRFC;nowysiwyg=0"
rel="nofollow" title="EntityDescription (this topic does
not yet exist; you can create it)">EntityDescription</a></span>
are there to gather all the properties common to activities
sharing the same kind of processing and to Entities they use
or generate.</em> <em>ParameterDescription gathers all the
metadata common to Parameters of Activities sharing the same <span
class="twikiNewLink"><a
href="http://wiki.ivoa.net/twiki/bin/edit/IVOA/ActivityDescription?topicparent=IVOA.ProvenanceRFC;nowysiwyg=0"
rel="nofollow" title="ActivityDescription (this topic does
not yet exist; you can create it)">ActivityDescription</a></span>.</em>
<em>They have the same kind of binding to <span
class="twikiNewLink"><a
href="http://wiki.ivoa.net/twiki/bin/edit/IVOA/ActivityDescription?topicparent=IVOA.ProvenanceRFC;nowysiwyg=0"
rel="nofollow" title="ActivityDescription (this topic does
not yet exist; you can create it)">ActivityDescription</a></span>
than Parameters have to activities.</em> <em>The organisation
you are proposing, Ole, simply miss the specificity of what is
intended by the parameter concept.</em> <em>Parameter class
has also a strong semantic value and so have <span
class="twikiNewLink"><a
href="http://wiki.ivoa.net/twiki/bin/edit/IVOA/ParameterDescription?topicparent=IVOA.ProvenanceRFC;nowysiwyg=0"
rel="nofollow" title="ParameterDescription (this topic
does not yet exist; you can create it)">ParameterDescription</a></span>
and hadConfiguration.</em> <em>Last point: Parameter is a
derivation of Entity and <span class="twikiNewLink"><a
href="http://wiki.ivoa.net/twiki/bin/edit/IVOA/ParameterDescription?topicparent=IVOA.ProvenanceRFC;nowysiwyg=0"
rel="nofollow" title="ParameterDescription (this topic
does not yet exist; you can create it)">ParameterDescription</a></span>
a derivation of <span class="twikiNewLink"><a
href="http://wiki.ivoa.net/twiki/bin/edit/IVOA/EntityDescription?topicparent=IVOA.ProvenanceRFC;nowysiwyg=0"
rel="nofollow" title="EntityDescription (this topic does
not yet exist; you can create it)">EntityDescription</a></span>.</em>
<em>The benefit of this is that generic <span
class="twikiNewLink"><a
href="http://wiki.ivoa.net/twiki/bin/edit/IVOA/W3C?topicparent=IVOA.ProvenanceRFC;nowysiwyg=0"
rel="nofollow" title="W3C (this topic does not yet exist;
you can create it)">W3C</a></span>-aware software can
manage these classes. Parameter is an Entity with a special
type= voprov:parameter.</em> <em>But this type changes all
the "movie" (as we say in French) for behavior and
interpretation.</em></p>
<p>
<span style="color: #808080"><span style="color: #808080">-- <a
href="http://wiki.ivoa.net/twiki/bin/view/IVOA/OleStreicher"
class="twikiLink">OleStreicher</a> - 2018-10-26 : </span>For
the discussion of (IVOA) parameters see point 6 in section
"Several inconsistencies" below.</span>
</p>
<p>
<span style="color: #808080">Independent of this, you did not
explain why specifics of <code>Parameter</code> require a
distinct structure in the model instead of completely
integrating them into the normal <code>Entity</code> - <code>Activity</code>
relations. All the requirements you specified for parameters
are already fullfilled by the simpler <a
href="http://wiki.ivoa.net/internal/IVOA/ProvenanceRFC/ProvenanceDM-alternate.pdf"
target="_top">alternative model</a>. Getting specific
configuration parameters can simply done by querying for the <code><b>hadConfiguration</b></code>
relation. And specifically for parameters like <code>ANALYSIS_THRESH</code>,
I don't see why you never want to give them a provenance and
follow in our provenance model (Where did this value come
from? How was it created? Who entered that value into the
pipeline?). Or why you don't want to re-use the same <code>Parameter</code>
for an <code>Activity</code> with a different <code>ActivityDescription</code>
(f.e. for a bugfixed "HipsGen/1.01" instead of
"HipsGen/1.00").</span>
</p>
<p>
<span style="color: #808080">So, parameters are (from the
provenance point of view) not so different from other <code>entities</code>:
</span></p>
<p> </p>
<ul>
<li> <span style="color: #808080">They <em>may</em> have
provenance information attached, or come without provenance,
</span></li>
<li> <span style="color: #808080">They <em>may</em> be
restricted to a specific <code>ActivityDescription</code>
(which is one specific version of an application), or they
may be applied to other versions, or even other applications
</span></li>
</ul>
<span style="color: #808080"></span>
<p>
<span style="color: lightsteelblue;"><span style="color:
lightsteelblue;">.</span> -- <a
href="http://wiki.ivoa.net/twiki/bin/view/IVOA/MathieuServillat"
class="twikiLink">MathieuServillat</a> - 2018-10-24
: In addition to François' examples, I answer this above, and
it is explained why the value of a parameter is relevant
provenance information in the PR at the beginning of section
2.2.6</span></p>
</blockquote>
As already said the main difference between Parameter and "Entities
with prov:type=data" is semantic and not structural. I think if you
activity is producing a radial velocity or flux at some TimeStamp in
a time series, by processing let's say an image or a spectrum,
nobody in astronomy would like to call this a "parameter".<br>
It is a data entity with a single value. and In some use cases
parameters may be reference to Entities allready known.<br>
So the distinction you propose between Parameter as Entity with a
single value and (data?) Entity for datasets and similar things
introduces confusion and has no added value. I definetely don't
think we have to go in this direction. <br>
The "hadConfiguration" relation is a restriction (simplification)
of used reserved to relations between Activities and Parameters. So
it's reinforces the semantic specificity of using Parameters.<br>
<br>
From the UML point of view the Parameter and ParameterDescription
classes are indeed derived from Entity, but they are REALLY
different classes which can have different serialisation (and it is
indeed the case in VOTable for ProvTAP )<br>
<br>
It is only in W3C serialisation that we have to express Parameter
and Parameterdescriptions in terms of w3c entities (basically the
specification is done by a prov:type=Parameter, etc... in the W3C
entity serialisation )<br>
<br>
<br>
Regards<br>
François<br>
</body>
</html>