search

wmo-im / wmdr

WIGOS Metadata Standard: UML model and schemas
8 stars 7 forks source link

Assign WMO RA to contact #38

Open joergklausen opened 4 years ago

joergklausen commented 4 years ago

Presently, OSCAR/Surface API uses gmd:contactInstructions to assign the WMO RA to a contact. This is misleading. If a contact needs to be assigned to a WMO RA, another element should be used for this, because the conventional use of gmd:contactInstructions is different.

joergklausen commented 4 years ago

@tomkralidis Do you think we could use administrativeArea [0] for the WMO RA, or is this equally misleading? Or do you have another idea? Unfortunately, CI_Contact_Type doesn't seem to allow a more generic attribute. The requirement is to associate a contact with a WMO RA, so that we can search for contacts in an RA.

[0] https://www.isotc211.org/2005/gmd/citation.xsd

tomkralidis commented 4 years ago

@joergklausen it seems that gmd:contact is wound pretty tight. gmd:adminstrativeArea is defined in ISO 19115 as "state, province of the location" so I would advise not using.

Other options:

  1. gmd:deliveryPoint is repeatable, but not a good fit/cumbersome
  2. another option is representing the RA as a gmd:geographicIdentifier (spatial keyword), but this element is not in scope for contact information
  3. extend gmd:contact with something like wmdr:regionalAssociation
  4. set gmd:CI_Address/@id with a value which is the RA
  5. add an ra attribute or gmd:geograhicIdentifier to wmdr:ResponsibleParty
joergklausen commented 4 years ago

Summary and Purpose Several territories are distributed over more than one WMO Regional Association (WMO RA). To properly manage contact information, it is therefore desirable to be able to attribute the WMO RA to a contact.

Proposal Extend wmdr:ResponsibleParty with an attribute wmdr:wmoRegion of type WMORegionType (a code list in codes space http://codes.wmo.int/wmdr).

Reason The tight typing of gmd:contact doesn't allow to include WMO RA directly. wmdr:wmoRegion is already used in other contexts as well and an extension of the FeatureType wmdr:ResponsibleParty is a clean and straight-forward solution.

Alternatives A possible alternative, namely to use gmd:geographicIdentifier appears less ideal, because it is normally wrapped around gmd:MD_Identifier with its own elements. It would appear that this makes the XML structure unnecessarily complex.

tomkralidis commented 4 years ago

Would/could this be applied as well to wmdr:recordOwner?

amilan17 commented 4 years ago

ISO 19115-1 added extents to contacts for exactly this type of reason. I recommend researching the options to using this or at least aligning the WMDR solution with this one.
https://github.com/ISO-TC211/XML/blob/master/standards.iso.org/iso/19115/-3/cit/2.0/citation.xsd#L405 https://wiki.esipfed.org/File:CI_Responsibility.png

joergklausen commented 3 years ago

@amilan17 Thanks for these suggestions. I looked at this, but I find that extent refers to the extent of the role (something more like period or area of responsibility) and doesn't seem to be intended as an extension of the address information, which is the purpose here. @tomkralidis If you think this is needed, then I have to use the wmdr:ResponsibleParty type instead of directly using CI_ResponsibleParty. This is possible but of course creates more overhead. Pls let me know.

tomkralidis commented 3 years ago

I would create wmdr:regionalAssociation which can be optionally used by wmdr:ResponsibleParty. If we think this is also valuable as a property of wmdr:recordOwner then we would have to rethink given the object/property/value pattern of WMDR (and ISO for that matter).