Open Fak3 opened 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
@kshychko can you please blacklist the https://edi3.org/vocab/#IdentificationIdentifier property in the vocabulary generator code, so that it is never created?
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:
translates to turtle:
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:
translates to turtle:
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.