[Data Model] Standard values of enumerations are needed

[grichka]

What are the standard values for enumerations below?

• OtherIdentifier#otherIdentifierType
• Ranges#ratingType
• Address#addressCodeType
• Product#hscode
• Product#hsType
• ULD#uldTypeCode
• Waybill#waybillType
• Ratings#chargeType
• SecurityDeclaration#securityStatus
• ExternalReference#documentType
• SpecialHandling#code
• Piece#securityStatus
• Piece#loadType
• PackagingType#typeCode
• DgProductRadioactive#dgRaTypeCode
• ContactOther#otherType
• Request#requestType
• Request#shipmentSecurityStatus (SCR, NSC?)
• Routing#aircraftPossibilityCode
• Booking#bookingStatus
• Booking#shipmentSecurityStatus
• RegulatedEntity#regulatedEntityCategory (only RA, KC, AO?)
• TransportMeans#vehicleType
• ServiceRequest#statementType
• ProductDg#hsCode
• ProductDg#hsType
• ProductDg#packagingDangerLevelCode
• Characteristics#characteristicsType (CLR etc?)
• Value#unit
• Contry#contryCode
• Event#eventTypeIndicator
• Event#eventCode (for each type of event, all partners should share the same codes)
• Person#contactType
• Person#salutation
• Location#locationType (can it be AIRPORT? is there a standard for location type?)

This is crucial to have common values for these enumerations because if it is not the case, ONE Record Servers won't be technically able to work together.

[lambertciata]

Hi, we have different use cases with enumerations:

• Some are part of existing standards outside IATA's ownership and cannot be part of the ontology (e.g. HS codes)
• Some are part of IATA's standards and we are discussing if and how they should be part of the ontology (e.g. all Code Lists that are part of Cargo-XML toolkit)
• Some are already listed when values are known and can be used. These can always be modified of course

I will update when we have further info on the 2nd point

[grichka]

I think these enumerated values should be precisely documented, otherwise two implemtations of ONE Record could diverge :/

[mskopp]

I like to add

• ServiceRequest#code, especially asking for ServiceRequest#statementType vs. #code. If ServiceRequest is designed to take the data from (X)FWB-HandlingSSRInstructions, (X)FWB-IncludedAccountingNote and (X)FWB-HandlingOSIInstructions, then it has to be documented which attributes takes what SSR/OSI/Handling-coding and which attributes takes the IncludedAccountingNote.ContentCode
• OtherIdentifier#otherIdentifierType example: IATA-1R-DM-Logical-Data-Model-vCOTB-Nov2020.xlsx tells "account number -> up to carrier" when it comes to map the shipper/consignee/agent XFWB account number. If it's designed to map this into a OtherIdentifier, then the otherIdentifierType to use "should be precisely documented" (to quote grichka here).

[lambertciata]

Topic still in discussion.

On the short term we can mention existing standards/code lists in the description or comments of the data properties when they are known. That would answer the documentation aspect.

[lambertciata]

Decision from last workshop:

• Review of all reference data with identification of standards/lists to be used
• Values will be enumerated if possible. As of now they should not be part of another IATA commercial product or other non-open source standard (topic in discussion)
• When values cannot be enumerated, reference to be used will be clearly mentioned

[mskopp]

Especially Ratings#chargeType irritates me because the comment is given as Type of charge e.g. Freight, Surcharges, etc. which mixes singular ("Freight") with plural ("Surcharges"). Additionally the "etc." leaves room open for nearly putting anything into this type-field which does not workout if we don't have a well defined standard of the types to be used.

For the time being, I propose to limit the chargeType to { "Freight", "Surcharge" }.

[mskopp]

Waybill#waybillType is { "Master", "Direct", "House" } in my understanding.

@grichka maybe you like to browse https://github.com/riege/one-record-ontologymodel/blob/main/src/main/java/org/iata/cargo/codelists/WaybillTypeCode.java and it's directory.. it's in the making and we appreciate feedback on that.

[lambertciata]

@mskopp Did not see your previous comment about Ratings#chargeType. I changed the description of this field as the description is supposed to match the codes that are either in chargeCode, otherChargeCode or billingChargeIdentifier.
For the remainder I consider this issue closed a we had a first look at standard values that could be shared and they will be within the ontology.