Currently no. I am concerned with making dictionaries better (especially mobile applications), so I don't have a general purpose solution but I propose something for that use case. I basically started from scratch and came up with a very simple type system which aggregates a few values (name, id, type, ...). This type system is not hierarchical so no inheritance; you could implement it with a few classes in a OO language.

Also, nodes can host complex structure but do not expose it to the graph (edges are made only between nodes) and edge can be of n-arity. The system is regular enough to implement simple and complex lexicographic constructs easily as well as to use the graph in an actual application.

Issue with RDF et al if that before you start even working on your real data, you have to come up with an ontology, that is to describe the world in categories, which is not easy. Another problem is that a lot of projects want to define standards that works with everything. That's not realistic. So I took an approach where you can learn from your domain by working directly on your data, make something useful with it, and then expand it you need it. KISS.

Ontologies first is an idiocy! Whenever you deal with a real data environment, you discover that your use cases drive your data model. Not the opposite way. For example, the DBPedia ontology is plainly wrong (or outdated, I don't know). If you want the real data model, you really should infer it from the data itself (Guess what, you CAN do that. Because proper RDF auto-describes its data model. But it is a lot of work). The more i deal with data, the more i realize that the exposed data models are not matching the data. And that is a SHAME for whoever calls himself/herself a data engineer.

There are plenty of ontologies already defined that someone could use. I'm currently involved in work to map STEP [1] onto RDF/OWL/SKOS and it seems to be working out well.

I know that some of my collegues are using JSON-LD as the interchange format for this kind of thing.

[1] https://en.wikipedia.org/wiki/ISO_10303

It totally depends on what you are doing. You need to take in account if using an ontology will solve any problem at hand. Also you may have an ontological system not build in RDF. At least in what I'm doing, RDF is creating more problems than it solves. Finally there is all the political layer that may go against publishing your data in an open and (web) accessible format and then you need another solution anyway.

To counter the argument of opening data to the outside world, LinkedOpenData has been studied inside companies. I.e opening only inside the walled garden. And guess what? It failed. Simply because companies are not organized so data can "travel" flawlessly. Companies are organized as silos. With boundaries & (implicit) contracts between people, teams, hierarchies. Of course, everyone knows the information is somewhere here or there, but eventually it is a real hard job to get it for real.

All this sort of sounds like topic maps, though they never gained much of attention and very few people know of or remember them, and beside Java there are virtually no libraries or tooling for them.

Prolog + Datalog? Prolog should even parse JSON without 3rd party libs with minimal fuss using just its integrated parser construction facilities (eg. the `op` built-in predicate).

Prolog won't come with reasoners for the description logic profiles supported by OWL 2 (EL, RL), but can be used to implement such reasoners if needed.