How to Aggregate? Appendix A.1 and Figure 23 unclear

[Gerard Lemson]

HI Hugo
It is as you mention in the end:
The reference from AB to B should have multiplicity 1. The relation between A and AB has multiplicity * (could be 1..* in some cases).

I think this is the proper, non-ugly solution:
In a sense the AB defines the “role” a particular B plays in the definition of the A.
To have an explicit concept for that (AB) is a very common pattern.
The AB allows you to define extra attributes (often a “role” indeed) for the B it represents.
I don’t know how that might play out in your context, but for example if A is Paper, B is Person, that AB could be Author (with affiliation, way to write the name for the particular paper, who is main contact etc).

Note, in a traditional relational representation of the model  this is actually the standard way to represent the relationship.
With a separate AB table with foreign keys to the A and B tables.

Hope this helps

Cheers
Gerard

From: dm-bounces at ivoa.net <dm-bounces at ivoa.net> On Behalf Of Hugo Buddelmeijer
Sent: Tuesday, May 28, 2019 6:16
To: dm at ivoa.net
Subject: How to Aggregate? Appendix A.1 and Figure 23 unclear

Dear Data Modelers,

Could someone please give me a VO-DML/XML example of the Aggregation pattern shown in Figure 23 of VO-DML-REC-v1.0?

Background:
VO-DML-REC-v1.0 gives various arguments to why aggregation is excluded VO-DML. These reasons make sense. Using a composition has it's advantages and is indeed how aggregation is implemented in our relation database backends.

But the document is not quite clear on how to represent something like an aggregation. The only prose it has is "aggregation can be represented by the pattern illustrated in Figure 23", and this figure is not clear to me.

Problem:
Here is figure 22, the UML aggregation:
  A blue-open-diamond-arrow-> B
  A ◇⟶ B

Figure 23, the VO-DML aggregation pattern:
  A  blue-filled-diamond-arrow-> AB green-arrow-> B
  A ◆⟶ AB ⟶ B

My interpretation of figure 23 is that the blue-filled-diamond-arrow represents a composition. This makes sense: every A is composed of one AB (among other things), and AB's are only used for composing A's. So far so good.

But the green-arrow is a normal reference right? So the AB refers to 0 or more B's. This again violates the multiplicty guidelines as stated in 4.19. What am I missing?

Goal:
A bit more background for clarification. What I'm modeling is the relationship between a MasterDark and a set of RawDarks. That is, a MasterDark calibration frame is created by median stacking (or whatever) a set of RawDark calibration frames of a specific time period.

So both the RawDark and the MasterDark are standalone entities. Any MasterDark instance should refer to many RawDark instances somehow. The same RawDark can be used in the creation of many MasterDark instances. And RawDarks can be used for other things than creating MasterDarks. How to do this in VO-DML?

(There is some overlap here with ProvenanceDM obviously. I haven't yet looked how it is solved there.)

Solution?:
Maybe the idea is that an A is composed of multiple AB's and that each AB refers to a single B?

That does work but looks rather ugly to me.


Thanks,

Hugo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20190528/091ab93f/attachment-0001.html>