edi3 / edi3-json-ld-ndr

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

Eliminate primary ID properties from BSP vocabulary #10

Open Fak3 opened 3 years ago

Fak3 commented 3 years ago

Most legacy CEFACT RDM classes have primary identifying properties and some also have secondary identifying properties. For example, Consignment has ID, ConsignorAssignedID, CarrierAssignedID, and some others.

In Linked Data RDF model, the primary identifier commonly appears in the subject position of the triples. Json-ld syntax uses reserved property @id to assign a primary identifier: json-ld { "@id": "http://maersk.com", "name": "Maersk org" } transates to rdf triple <http://maersk.com> <name> "Maersk org"

While it is possible to have secondary id or blank node id in the subject position, it is fine for machine processing, looks ok for humans in json-ld, but harder to read and understand in the triple\graph form:

{
  "Identifier": "consignment123",
  "exporter": {
    "Identifier": "http://maersk.com",
    "name": "Maersk org"
  }
}

translates to turtle:

_:b0 <Identifier> "consignment123",
_:b0 <exporter> _:b1
_:b1 <Identifier> "http://maersk.com"
_:b1 <name> "Maersk org"

To make the graph node ids more conceivable, in the json-ld content we should either use reserved @id property everywhere, or we could alias it in the provided json-ld context:

{
  "@context": {"Identifier": "@id"},  // alias for @id
  "Identifier": "consignment123",
  "exporter": {
    "Identifier": "http://maersk.com",
    "name": "Maersk org"
  }
}

translates to turtle:

<consignment123> <exporter> <http://maersk.com">
<http://maersk.com"> <name> "Maersk org"

If we accept the goal of having more human-friendly graphs and take either way to solve it, then it makes existence of primary-identifying properties in the vocabulary useless, probably even confusing for developers.

I would suggest we leave only secondary-identifying properties in the vocab, like ConsignorAssignedID, CarrierAssignedID, and remove ID.

onthebreeze commented 3 years ago

I think that's fine - it's a repeatable and reversible transformation between RDM and JSON-LD serialisation so whatever makes the output more natural for developers seems reasonable to me

Fak3 commented 3 years ago

@kshychko can you please blacklist the https://edi3.org/vocab/#IdentificationIdentifier property in the vocabulary generator code, so that it is never created?