Polyglot Modeling

[VladimirAlexiev]

WHO: As an information architect
WHAT: I want data modeling language(s) independent of technical artefacts
WHY: So that:

• the language is understandable to domain experts
• it can generate a variety of required technical artefacts
• all these artefacts are kept in sync, thus lowering maintenance effort

For efficient RDF modeling, you need to define multiple related artefacts:

• ontology
• shapes (SHACL (@HolgerKnublauch) or SHEX (@ericprud))
• diagrams and other documentation
• JSON-LD context,
• maybe JSON-LD frames,
• JSON schema or Avro schema
• API bindings and hypertext controls (HATEOAS)
• etc

Thus, many people have expressed the desire to define a unified or "technology independent" modeling language.

• See eg Modeling tool requirements w3c-ccg/traceability-vocab#296 for a brief list of modeling framework requirements

Many communities like to have a LD expression of their data, but mostly care about defining the data with JSON schema. Efforts to marry JSON Schema with JSON-LD contexts have been undertaken in:

• w3c-ccg @OR13 @nissimsan @msporny
• WoT: https://www.w3.org/2019/wot/json-schema, http://www.w3.org/2019/wot/hypermedia @vcharpenay, @maximelefrancois86, María Poveda Villalón
• OAS: OpenAPI-Specification/, OAS Semantic Context in particular for eGovernment APIs @ioggstream @pchampin @giorgialodi

Examples of polyglot frameworks include the following (many but not all are YAML-based):

• LinkML (github) (@cmungall)
• FHIR (@ericprud): note, this is not YAML-based
• ShExC/ShExJ/ShExR, and now YAML representations (ShExY?) (@ericprud)
• Schema Salad (@mr-c @tetron)
• A.ML and cloudinformationmodel @danmoralesatx
• RAML (RESTful API Modeling Language), https://github.com/raml-org/raml-spec @sichvoge @krishahn
• Dragon at Uber (Joshua Shinavier and others).
  Eg see Dragon: Schema Integration at Uber Scale, US Semantic Technologies Symposium, March 2020, cached PDF. YAML schema examples start slide 42
• SOML (@VladimirAlexiev) used in the Ontotext Platform to generate GraphQL querying, mutations, and SHACL shapes.
• smart-data-models (@albertoabellagarcia)) (FIWARE, IUDX, SmartCities, TM forum). Example: Aircraft; See Contribution manual gslides, EU DATA SP4CE - final event - Brussels - 31 May 2024 (manufacturingdataspace-csa.eu). The single-source-of-truth is YAML. But there are systemic modeling problems: fatal modeling flaws smart-data-models/dataModel.EnergyCIM#3
• shapiro by @mathiasrichter uses SHACL for modeling, converts models to JSON-Schema, and can serve them as HTML, SHACL, JSON-Schema
• yml2vocab by w3c (@iherman, @msporny, @gkellogg), used widely by the VC community. Generates ontology, context and HTML like w3c specs with respec (see examples: test.yml, rendered test.html; previews, security/vocabulary.yml)
• Target Vocabulary Maps (@niklasl): simpler way of getting data using "Ontology A" into data using "Ontology B": maps the used terms from A to B, taking some variances such as granularity into account. See SWIB 2019: slides, video. Used in the Libris XL library system to harmonize data.
• TreeLDR (@timothee-haudebourg)
• Semantic Treehouse (@oosterheertl, @Michiel-s, @WvandenBerg) that is used as a Vocabulary Hub in data spaces.
• jargon.sh (@jargon.sh) that's used by UNECE and UNTP, eg for https://jargon.sh/user/unece/DigitalProductPassport
• OpenSemanticLab (@simontaurus, @SimonStier, @raederan), blending JSON-SCHEMA and JSON-LD as Object-Oriented Linked Data Schema (OO-LD). JSON playground, YAML playground. Pub: Linked Data Schema Repositories for Interoperable Data Spaces (2023)

YAML-LD should not take over these modeling-framework efforts, but should show how they can be used together, show archetypical examples, and maybe make a comparison.

Even if no Modeling requirements make it into any YAML-LD spec, this git repo could serve as a "meeting place" for people working on these topics, potentially resulting in some unification.

[gkellogg]

This was discussed during today's call: https://json-ld.org/minutes/2022-06-22/.

[ericprud]

Another polyglot example: ShExC/ShExJ/ShExR. YAML representations (ShExY?) assume that json2yaml covers the subset of JSON needed by ShExJ, i.e. JSON with arrays and objects with ASCII keys.

[niklasl]

On the topic of semantic polyglot mechanisms (i.e. not dependent upon syntactic, "irrelevant" idiosyncrasies), I'd like to add Target Vocabulary Maps as a reference. It is focused upon a simpler way of getting data using "Ontology A" into data using "Ontology B" than using OWL reasoners. This mechanism instead maps the used terms from A to B, taking some variances such as granularity into account.

The relevance here is mostly about contrast: TVMs should have nothing to do with syntax, but the form and meaning of the information expressed. Wherein, I'd suggest, lie the real and hard problems of interoperability.

My worry is that parts of the problems tackled in the efforts listed in this issue stem from a failure to separate syntactical differences (which should be about "typography" / editorial ergonomics), from semantic differences (the topic of the role, denotation and scope of identities, and different perspectives on temporality, generality, granularity). I believe we must both recognize that the latter are reasonably orthogonal to syntax — but also that it is much harder to separate them in practise (since syntaxes and tools are all we have). Therefore diligence is required to keep them distinct.

One of the most challenging things here is the (quite reasonable) motivation to package and insulate specific solutions (any given "simple REST API" is such a thing). I think JSON-LD in essence is an attempt to bridge those isolated solutions and the Semantic Web. By extension, so is LinkML (I'd say that that, through extension, is even more "tooling-oriented"). However, neither of these really attempt to unify the resulting combinatorial knowledge graphs. They "just" result in URI:s for all the terms. That is a good start (I'd say a necessity of sorts), but without the Semantic Layer Cake —or something simpler— we've actually gotten nowhere in terms of combining the graphs. The resulting "triple soup" becomes unintelligible in its proliferation of terms. That is a hard problem. Syntactic differences and contextual "walls" are just symptoms and mitigations.

Methods for guiding or restricting forms of expression may be an aid. Those are commonly realized by structures such as enumerations and schema restrictions within or upon term definitions, either tied to vocabulary terms, or application ("context" or "profiles"), or both ("application vocabularies"). I believe we need to seek a fruitful, simplified convergence here rather than to attempt to seek "independence", which actually introduces, indirected, multilayered dependence.

That, however, is reasonably not the task of YAML-LD. What I do believe is that is is up to YAML-LD not to further the divide by isolation, by which I mean it should avoid invention of solutions that only work within its particular syntax. Or, if that is too alluring (well, valuable), we must learn from that and attempt to generalize its solution beyond the syntax.

Of course, that position relies upon the assumption that a fundamental RDF-based substrate is of value, and that RDF vocabularies themselves can be practically used for interoperability. (An opposite position would be that the type system of a particular language (say Haskell) is sufficient and the actual limit beyond which no practical interoperability can be achieved. Even REST API:s will, by and large, be divided by application, mere simplified—even crass and ephemeral—surfaces for certain interaction with a system realized through its internal, isolated application complexity.)

[ericprud]

I'd describe JSON-LD as doing purely syntactic transformations. There's the intention of mapping to something more semantic, but that's realized not by JSON-LD but by the @context author who's instructions may produce something that unifies with other SemWeb documents. I'd reserve the term "semantic transformation" for toolchains that can infer conceptual equivalence and perform both labeling and structural changes. To wit, sed does not perform semantic transformations, even if the resulting document may have more useful semantics.

[gkellogg]

This issue was discussed in today's meeting.

[TallTed]

@ericprud -- Please edit your #19 (comment) to put a code fence around @context so that GitHub user doesn't get pinged every time this issue is updated.

[gkellogg]

@ericprud -- Please edit your #19 (comment) to put a code fence around @context so that GitHub user doesn't get pinged every time this issue is updated.

I took care of it.