Question about classes Was...
Kristin Riebe
kriebe at aip.de
Mon Dec 5 13:26:36 CET 2016
Hi again, Laurent,
we used the classes explicitly because of different reasons:
* "role"-attribute attached to relation-class:
For Used/WasgeneratedBy we wanted to have the "role" attribute attached
to the relation, because one image could fulfill different roles for
different activities.
E.g. When producing composite images using 3 images as input for R, G
and B-band, one and the same image could be used as R-band image or as
G-band image, depending on which features need to be highlighted etc.
The same holds for the Agent-relations: one person can have the role
"author" for one entity (an observation proposal, a documentation, a
paper) and be a "curator" for another entity.
* Implementation needs
In relational databases, whenever there is an additional attribute to a
relation, then it will (almost always?) automatically need to be
implemented as an extra mapping-table. I got the impression (from talks
with other data modelers) that it is more desirable in data modelling to
mention the relation-tables explicitly rather than not, in order to
avoid ambiguities and for easier VO-DML-description of the model.
* Avoiding aggregations
In very early thoughts for the Provenance Data Model we modelled the
relation between data entities and activities as an aggregation without
an explicit relation class in between. We wanted an aggregation and not
a composition, because a data entity can be used as input for many
different activities, so there is no strong "binding" between the data
and their activities as in a composition.
However, VO-DML does not allow aggregations-relations, only
compositions. It's a design decision that was made for avoiding
ambiguities, since an aggregation can always be replaced by a
composition and a reference, with a mapping class in between.
So that's the formal reason to have the mapping classes.
One could also name the classes differently; e.g. "Used" could be called
"InputData", with links to the data entities and to the activity for
which the data is used. But for compliance with the W3C model we used
the term "Used". This is surely something that will come up again when
comparing with the Simulation Data Model classes and other Data Models.
So it's one of the points we'll address at our next meeting in
Strasbourg on Tuesday next week
(http://wiki.ivoa.net/twiki/bin/view/IVOA/ProvDayDec2016)
Cheers,
Kristin
On 12/02/2016 06:05 PM, Laurent Michel wrote:
> Hello,
>
> I do not see why you are using classes to model the relationships
> (WasAssociatedWith, Was....)
> This could complicate the serialisation whereas using the names of the
> relationship could do the job
>
> Cheers
> LM
>
> Le 28/11/2016 à 14:34, Kristin Riebe a écrit :
>> Dear Data Modelers,
>>
>> the working draft for the Provenance Data Model is now available at
>> http://www.ivoa.net/documents/ProvenanceDM/
>>
>> We are still about to implement the model and test serialisations in our
>> different use cases. You are very welcome to try it for your own use
>> cases and give us some feedback!
>>
>> There are some remaining issues which we will discuss in our Provenance
>> meetings; the next one is scheduled for 13th December 2016 in
>> Strasbourg, see
>> http://wiki.ivoa.net/twiki/bin/view/IVOA/ObservationProvenanceDataModel
>> (where you can also find upcoming events in the future and a link to the
>> volute repository)
>> and
>> http://wiki.ivoa.net/twiki/bin/view/IVOA/ProvDayDec2016
>>
>> Please put your name there if you want to participate as well!
>>
>> Here are some of the main discussion points which need to be addressed
>> in the future:
>>
>> * Description classes
>> - Which projects need them, which don't
>>
>> * "ActivityFlow"
>> - Class for grouping activities or whole parts of a provenance graph
>> (of a workflow) together
>> - When introducing this class we needed to allow multiple
>> wasGeneratedBy-activities for one entity, though logically there should
>> be only one "true" activity that generated an entity; but if activities
>> can be grouped, then it must be allowed to have wasGeneratedBy-links to
>> the activity-groups (ActivityFlow) as well
>>
>> * VO-DML representation
>> - We are working on this. It seems that we have included many double
>> compositions (at the relation-classes in between), which seem not to be
>> allowed by VO-DML. We have to carefully check this.
>>
>> * Links to other data models
>> - We have identified links with the Dataset Metadata Model, but we need
>> to further investigate the other data models (e.g. SimDM)
>>
>> You are very welcome to join us and help/give advice on one or more of
>> the points above!
>>
>> Cheers,
>>
>> Kristin Riebe, Mathieu Servillat and the Provenance Working Group
>>
>>
>
--
-------------------------------------------------------
Dr. Kristin Riebe
E-Science & GAVO
Email: kriebe at aip.de
Phone: +49 331 7499-377
Room: B6/25
-------------------------------------------------------
Leibniz-Institut für Astrophysik Potsdam (AIP)
An der Sternwarte 16, D-14482 Potsdam
Vorstand: Prof. Dr. Matthias Steinmetz, Matthias Winker
Stiftung bürgerlichen Rechts
Stiftungsverzeichnis Brandenburg: 26 742-00/7026
-------------------------------------------------------
More information about the dm
mailing list