search

edi3 / edi3-json-ld-ndr

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

Eliminate derivable properties from the vocabulary #27

Open Fak3 opened 3 years ago

Fak3 commented 3 years ago

The CEFACT BSP RDM has some properties, carrying information which can be trivially derived from other properties.

For example, Consigment has transportEquipmentQuantity and transportEquipmentSplitGoodsIndicator, which are both easily obtained from existing utilizedLogisticsTransportEquipment property.

Instead of using these two properties, the data can list ids of all utilized transport equipment:

{
  "utilizedLogisticsTransportEquipment": [
     "http://maersk.com/containers/123", "http://maersk.com/containers/456"
  ]
}

Any programming language or database query language can easily make an expression or query to tell the length of the list (transportEquipmentQuantity) and if it is greater than 1 (transportEquipmentSplitGoodsIndicator)

nissimsan commented 3 years ago

@Fak3, I agree 100%. Those attributes are redundant and absolutely not pretty! The main question in my head is whether this should be cleaned up at the NDR level or passed back to the modeling teams as feedback. I suppose it COULD fit into our NDRs, since this is sort of technology-specific ("given the technologies which edi3 is targeted, it can be assumed that a count and <1 are easily available at query time"). So I'm certainly open to this. How would we manage it, though? We would have to keep a list of every attribute which we don't bring over and a reason why...

Fak3 commented 3 years ago

We would have to keep a list of every attribute which we don't bring over and a reason why...

As I suggested in #12, we can have a machine-readable vocabulary graph of all CEFACT BIEs separated from edi3 vocabualry. In that CEFACT graph, we can tell which BIE was included or omitted, and annotate the reasons why.