Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

typos, grammatical changes, and clarification requests #63

Open
mcdittmar opened this issue Jan 29, 2025 · 6 comments
Open

typos, grammatical changes, and clarification requests #63

mcdittmar opened this issue Jan 29, 2025 · 6 comments

Comments

@mcdittmar
Copy link
Collaborator

I'm hoping one issue for the set is OK.. I don't expect any of them should spark too much controversy.

  • Section Model Name:
    • states the MANGO acronym is for "Metadata ANnotation for Generic Objects" rather than the usual "Model for ANnotating Generic Objects"
  • Section 3.1.1: Supported Properties
    • “supports a limited list of properties” => “supports a limited list of property types”
      But, of course, that stems from my impression that 'PhysicalProperty', ‘Status’, ‘Label’, ‘Shape’, ‘Color’, ‘DataLink’ represent different classes of Property rather than individual Properties. (Mango can’t possibly include the thousands of individual properties identified by the use cases).
  • Section 3.1.3: MANGO and MIVOT...
    • I’m not quite understanding what this is describing. It looks like you are describing 2 strategies for using MANGO
      1) Single Object by Row
      2) Scattered Independent Quantities
      I think the distinction is that 1) would include a MangoObject, and 2) would just be a collection of Property?
      And then the MIVOT part is describing what the annotation would be like for each of the above approaches
      REQUEST: could you make the connection more clear? maybe using the same label to match them. eg: “Single Object per Row:” =>? “MANGO as a Global View:”
  • Section 4: Model
    • the expanded acronym for MANGO has 2 typos: “MO-del” -> “M-odel” and “O-objects” -> “O-bjects”
    • and the same expansion in other locations does not include the hyphens.
  • Section 4.6.5/6: EpochPosition.pmLongitude/pmLatitude
    • says “The current version of the model (meas) only allows a representation in the Polar Coordinate space.”
      This is not correct. The meas. model says that it uses Point for the coordinate to allow representations other than the usual velocities in Lon/Lat.. for example Polar coordinates. This is for the case that was described to me as ProperMotion described as velocity and angle in polar coordinates centered at the Position… which would be a fairly complicated Coordinate Space to describe.
  • Section 4.6.7: EpochPosition:epoch
    • 'coords:epoch' -> coords:Epoch
  • Section 4.6.11/12: EpochPosition.spaceSys/timeSys
    • multiplicity == 0..1: what does it mean if these are missing? Or is MANGO also adopting the defaults described in the coordinates model for the types used in this object?
  • Section 4.10.2: MangoObject.propertyDock
    • Here, and in several other places, the description says “Reference to”… which has meaning in the model which is not intended for the attribute being described. For example, here.. the propertyDock IS the collection of MangoObject properties, it is not a ‘Reference to the open-ended collection of the MangoObject properties’.
      • Note: this is different from 4.10.3 where dataOrigin is described as “Reference to the description”… which is true, this is a reference to a DataOrigin instance.
  • Section 4.12.1: PhysicalProperty.calibrationLevel
    • the ObsCore reference is 1.0, the current REC is 1.1 the citation should be updated
  • Section 4.13: Property
    • 'of the MANGO object' -> 'of the MangoObject'
    • “Class holder for a particular property, either physical or calculated"
      • 'particular property' -> ‘flavor of property’ ie: there should be a Property subclass for each ‘flavor’ of Property being hosted.
      • the property types are not limited to “physical or calculated” (eg: flags, assigned labels)
    • constraint: Is this referring to the associatedProperty? why the constraint rather than setting the multiplicity?
  • Section 4.13.1: Property.semantics
    • the description reads like the value is a URI rather than a VocabularyTerm instance
    • ‘semantic fieldz’ -> 'semantic fields' ( z -> s )
    • ‘the semantic concept apply to a single property’ -> applies
    • the last sentence of the description repeats much of the first sentence of the same paragraph
  • Section 4.13.2: Property.description
    • is this free-form description really required? or should the multiplicity be [0..1]?
      for example, could one provide the description for the ‘set of associated properties’ in the primary property, and not provide descriptions in the associated ones?
  • Section 4.19: ShapeFrame
    • seems unused and redundant with ShapeSerialization (4.20) ?
@lmichel
Copy link
Collaborator

lmichel commented Jan 30, 2025

Section Model Name:

Done

Section 3.1.1: Supported Properties

Done

Section 4

Done

Section 4.6.5/6: EpochPosition.pmLongitude/pmLatitude

controversial sentences removed

Section 4.6.7: EpochPosition:epoch

Done

Section 4.6.11/12: EpochPosition.spaceSys/timeSys

TimeSys multiplicty set to one.

Section 4.10.2: MangoObject.propertyDock

reference replaced with contains

Section 4.12.1 PhysicalProperty.calibrationLevel

Done: refer to a vocabulary, no longer to Obscore

Section 4.13: Property

done

Section 4.13.1 Property.semantics

done (label optional)

Section 4.13.2 Property.description

Description made optional

Section 4.19: ShapeFrame

The frame refers to the space frame whereas the serialization refers to the way the shape is serialized (MOC...). I agree that the serialization can include the frame and thus the latest has to been made optional

@mcdittmar
Copy link
Collaborator Author

Section 4.19: ShapeFrame

The frame refers to the space frame whereas the serialization refers to the way the shape is serialized (MOC...). I agree that the serialization can include the frame and thus the latest has to been made optional

I don't understand.. the enumeration SpaceFrame is defined in the document and vo-dml/xml, but it is not used anywhere. It is an orphaned object.

@lmichel
Copy link
Collaborator

lmichel commented Jan 30, 2025

There is a ShapeSerialization enumeration but no SpaceFrame. ARe you looking a a recent version?

1 similar comment
@lmichel
Copy link
Collaborator

lmichel commented Jan 30, 2025

There is a ShapeSerialization enumeration but no SpaceFrame. ARe you looking a a recent version?

lmichel added a commit to lmichel/MANGO that referenced this issue Jan 30, 2025
@mcdittmar
Copy link
Collaborator Author

There is a ShapeSerialization enumeration but no SpaceFrame. ARe you looking a a recent version?

Sorry.. typo in the last message, but not the original. ShapeFrame is an orphaned object.
wd-v1.0: MANGO/vo-dml/mango.vo-dml.xml lines 35-50

@lmichel
Copy link
Collaborator

lmichel commented Jan 30, 2025

Ok, I's an orphaned, it has been replaced with mango:ShapeSerialization

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants