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

[Hugo Buddelmeijer]

Thanks Gerard,

Yeah I realized that the table corresponding to AB will have multiple rows,
so it makes sense to have multiple instances of AB.

The figures in Appendix A.1 of VO-DML-REC-1.0 do not explicitly state which
of the arrow have the multiplicity, so I was confused.

Thanks for your explanation about using AB to designate the role that B
serves in A. That clears things up. Not yet sure how to use this in my
context, but I'll figure something out.

Hugo


On Tue, 28 May 2019 at 12:54, Gerard Lemson <glemson1 at jhu.edu> wrote:

> 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/63490c0d/attachment.html>