IVOA Provenance DM -RFC- answers to comments

[Laurent Michel]

Hi all

As Mark wrote to the list on November 28, The Provenance proposal is being revised before to resume the RFC process.

I believe it is very important to keep focused on this revision and to preserve the compromise model accepted in College Park.

I suggest to suspend discussions for now about the opportunity of removing elements of that model (e.g. wasDerivedFrom)
- This is confusing for the audience because none knows which proposal you are talking about.
- This is counter-productive for a good progress of the proposal update.

Cheers
LM


Le 29/11/2018 à 09:50, Ole Streicher a écrit :
> Hi all,
> 
> On 26.11.18 14:14, Ole Streicher wrote:
>> On 22.11.18 14:59, Markus Demleitner wrote:
>>> On Wed, Nov 21, 2018 at 05:45:56PM +0100, Mathieu Servillat wrote:
>>> If we have that and find wasDerivedFrom is still worth it, I'm fine
>>> with keeping it in.
>>
>> In many astronomical uses, there is an indicator that the inputs of an
>> activity are not equal: the "DATE-OBS" field (and similar others) in the
>> FITS header. Obviously, for many activities there is one input where the
>> DATE-OBS field is preserved in the output, while for the others, it is
>> removed. I could guess that this one (or few) inputs is what people
>> usually refer as the "main progenitor".
>>
>> However, IMO this is a specific attribute of the "usage" for that input
>> and not a special relation. When we can agree on putting this as a usage
>> category (no idea for a good name, however), then we could solve the use
>> case "I want to trace back my exposure to its raw input".
>>
>> Independent of this, both wasDerivedFrom and wasInformedBy have some
>> uses: One standard use is f.e. when the activity is a "Selector".
>> Imagine an Activity selects (based f.e. on time) the right calibration
>> data set, and you want to document that in prov: Then the selected
>> Entity "was derived from" one of its input entities. You can't put that
>> into a role; it is additional information.
> 
> On our telecon yesterday we had a short discussion about this, and Mark
> convinced me that these use cases are rather theoretical for the moment.
> 
> It may be better to simplify our model in the first standards version by
> removing wasDerivedFrom and wasInformedBy, and to use the following
> solutions:
> 
> * use the "category" attribute of usedDescription to mark the "main
> progenitor(s)". The definition and name of this category (as part of the
> "category" vocabulary) could be left to the local implementation in the
> first version.
> 
> * Always put an Activity between two Entities where one was derived from
> the other, and use "used" and "wasGeneratedBy": f.e.
>   - a "manual edit" Activity when one wants to mark the relation between
> two consecutive versions of a config file
>   - an "update" Activity for the relation between two ActivityDescriptions
> 
> * Always put an Entity between two Activities to carry the information
> between them, f.e. a trigger. This will however require that we define
> an Entity type for which we doesn't have neither value nor location.
> 
> * "Shortcuts" cannot be resolved this way, so it remains open how one
> can provide several levels of detail of the same provenance.
> 
> Best
> 
> Ole
> 

-- 
jesuischarlie/Tunis/Paris/Bruxelles/Berlin

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg