edi3 / edi3-json-ld-ndr

GNU General Public License v3.0
0 stars 2 forks source link

NDR for Data Type Qualifier #45

Open nissimsan opened 3 years ago

nissimsan commented 3 years ago

NDR: Ignore Data Type Qualifier, but add Data type qualifier and Data type qualifier ID into the CEFACT Element (for traceability).

nissimsan commented 3 years ago

Adding some more details to this, consider the following attributes:

image

... Are these three highlighted attributes the same? Or are they different depending on:

  1. The name and qualifier
  2. The UNID
  3. The TDED values
kshychko commented 3 years ago

After taking TDED column into account and linking UN/EDIFACT codes as rdf ranges, the following NDRs for BBIEs were improved to keep the names as short as possible but avoid grouping of BBIEs that have different data types:

  1. If TDED is empty or isn't one of UN/EDIFACT code lists, BBIEs are grouped by Property Term Qualifier(s) + Property Term + Representation Term as RDF Properties
  2. If TDED is one of UN/EDIFACT code lists and Datatype Qualifier(s) is empty, BBIEs are grouped by Object Class Term Qualifier(s) + Object Class Term + Property Term Qualifier(s) + Property Term + Representation Term as RDF Properties
  3. If TDED is one of UN/EDIFACT code lists and Datatype Qualifier(s) is not empty and Datatype Qualifier(s) doesn't contain Property Term, BBIEs are grouped by Datatype Qualifier(s) + Property Term Qualifier(s) + Property Term + Representation Term as RDF Properties
  4. If TDED is one of UN/EDIFACT code lists and Datatype Qualifier(s) is not empty and the same as Property Term, BBIEs are grouped by Object Class Term Qualifier(s) + Object Class Term + Datatype Qualifier(s) + Representation Term as RDF Properties
  5. If TDED is one of UN/EDIFACT code lists and Datatype Qualifier(s) is not empty and contains Property Term, BBIEs are grouped by Datatype Qualifier(s) + Representation Term as RDF Properties

And for the information about how often the rules above have been applied for BSP RDM vocabulary, below the number of the RDF Properties produce by each rule:

  1. 950
  2. 46
  3. 44
  4. 34
  5. 7

From the numbers above we can see that most of the RDF properties names are kept as simple as possible, but linking to the UN/EDIFACT code lists requires making about 10% of them unique enough so they won't cross with the properties with another rdf range.

nissimsan commented 3 years ago

Looks really good, @kshychko! The three parties we looked at (in the snapshot) look good now!

kshychko commented 3 years ago

Below are some examples with comments

  1. consignorProvidedInformation or netVolumeMeasure . For consignorProvidedInformation TDED is not empty, but it's value 4070 doesn't represent a code list, Property Term Qualifier(s) = "Consignor Provided", Property Term = "Information" and Representation Term = "Text". For netVolumeMeasure TDED is empty, Property Term Qualifier(s) is empty, Property Term = "Net Volume" and Representation Term = "Measure", but Datatype Qualifier(s) = "Volume_ Unit" isn't a part of the property name.
  2. validationStatusReasonCode Here TDED is set to "(9013)", that represents a code list Status reason description code and Datatype Qualifier(s) is empty, but to separate it from appliedAllowanceChargeReasonCode that has TDED set to 4465 - Adjustment reason description code , we need to use Object Class Term Qualifier(s)(Validation and Applied) and Object Class Term (Status and AllowanceCharge) to build properties names.
  3. logisticsStatusConditionCode
  4. transportServicePaymentArrangementCode
  5. logisticsSealSealingPartyRoleCode