Minor (and non blocking) comments

[bsipocz]

• Page 16:

All of these components are described in alphabetical order in the next
section

I'm afraid I don't see which section is alphabetical?

• Table1; please include an example instead of many for the Brightness and Color rows

• 4.1.3 - shouldn't this id MangoObject.associatedMangoObjects be singular, rather than plural given the type is plural, too? Or is it a container of multiple mango:AssociatedMangoObjects? If that is the case maybe the id and type should be more different.

• 6.1 EpochPosition - I wonder if all of these properties indeed must have a 1 multiciplity or could be 0..1 (assuming the 0 means that they are optional). e.g. are parallax, RV, pm all mandatory?

Similarly, I wonder why is the 7.1.2 Brightness.error optional but 7.1.3 Brightness.photCal is mandatory?

[lmichel]

Table1; please include an example instea

examples given

[lmichel]

I'm afraid I don't see which section i

No more reference to the alphabetic order which is no longer applied

[lmichel]

6.1 EpochPosition

The idea of a mandatory field does not translate well to a model designed to map existing data. The fields present in the model instance are those available in the data, rather than those required by the model.
In the context of MANGO, mandatory fields are those required to provide a full description of a physical property. For instance, position parameters are necessary for locating an object in the sky, but not semantics. However, this does not mean that a serialisation must include all mandatory fields to be valid.

Similarly, I wonder why is the 7.1.2 Brightness.error optional but 7.1.3 Brightness.photCal is mandatory?

Same reason as above, you need a value and a PhotCal to describe physically a Mangitude, bu you do not need an error.

The cardinality of EpochPosition.spaceSys and EpochPosition.timeSys must have been set as 1-1 accordingly

[lmichel]

4.1.3 - shouldn't this

mango:MangoObject.associatedMangoObjects is it a container of multiple mango:AssociatedMangoObject instances.

mango:MangoObject.associatedMangoObjects renamed as mango:MangoObject:mangoObjects

[bsipocz]

Thank you for making the changes this super fast.

As for 4.1.3 it was mostly a question from my side to understand if the plural name was indeed to indicate it's a container which you confirmed. So it's totally fine if it's called mango:MangoObject.associatedMangoObjects or mango:MangoObject:mangoObjects.

[lmichel]

I'm ready to merge if there is no further issues

[bsipocz]

Yes, please go ahead!