Optimize 'magic tetrahedron'

[odungern]

Design the ensemble of the scaffold (basic Javascript classes), the RDF/Turtle, the JSON-LD as well as the GQL patterns such that

• bidirectional transformation between those formats is made easy, nearly or fully lossless (tbd).
• Includes how to deal with namespaces and property names.
• Can available libraries be used? E.g. listed at json-ld.org.
• The transformation between RDF/Turtle and JSON-LD should, if ever feasible, follow the algorithms described by W3C.

Potential supporting technologies:

• W3C De/serialization,  (here and there) 
• JSON.parse/stringify
• URDNA2015
• JSON Canonicalization (JCS)

See: JSONLD-RDF Transformation Considerations

The metamodel (driving the scaffold) including the naming can be changed to optimize the design.

This task may include prototyping and testing before adopting the design.

[odungern]

Consider also:

• Semantic layer as infrastructure
• RDFUnit

[odungern]

@rivettp proposes:

• See https://github.com/zazuko/rdf-validate-shacl
• There are also reusable libraries they use for RDF triples etc. See https://rdf.js.org/

[odungern]

Let's take the first step to represent entity classes and entities in RDF/Turtle and JSONLD.

As an example, I am taking the DDP Dictionary defining a set of entities and relationships with their properties similarly of an ontology:

• DDP-Classes in RDF/Turtle
• DDP-Classes in JSONLD as converted from the above by zazuko.

We see three levels:
1, The metamodel items pig:EntityClass and pig:Entity
2. The ontology terms as instances of pig:EntityClass (expressed by rdf:type)
3. The model (payload) as instances of pig:Entity (expressed by rdf:type), here just one subject 'Anouk Aimée'.

Design Decisions:

• All entity classes and entities are tied to a PIG metamodel item by rdf:type. This is transformed to @type in JSONLD.
• An entity is tied to its entity class with a self-defined predicate pig:hasClass. This governs the entity's shape, i.e. which properties with which datatypes/ranges are eligible (where the shapes will be developed, later).
• If an ontology term is a specialization of another (like sailboat specializes ship), we will apply a predicate rdfs:subClassOf (not yet in the metamodel). We also could use uml:generalizes (in the opposite direction, of course), which would be semantically more correct, but less useful when reasoning. Anyways, both will be tied to pig:EntityClass via rdf:type.

What do you think? Is this approach adequate?