Martynas J. Great to see another RDF based no code/low code product. I might find some time to give it a look.
Martynas J. Thanks for the feedback. I also wish that building applications directly on top of RDF would be easier and better. In fact, I wished that for years over many different teams and fairly large applications deployed in production for more than a decade already (yes, sorry to say, but way before building apps on top of RDF was considered even by the RDF community itself). Sadly, as it turned out, it is not easy at all and even when you do it, the outcome is just badly engineered applications. That's because of a much more important and bigger impedance mismatch between RDF as a (meta) data model and both the mental model and programming language constructs used by regular developers.
Thomas T., I think you are raising exactly the right questions. Yes, LPGs appear (but I think only superficially so) ahead of RDF when it comes to programmatic interfaces and OGM, but that is a big part of what we are trying to do with FDR - fill that void. But also, backend APIs are still a perfectly valid and often desirable architectural choice. FDR + SPARQL endpoint is not the only scenario. In fact, the project using FDR I alluded to above does NOT have a SPARQL endpoint, but an API at the back. However, I just want to make it clear that we don't have a complete OGM yet. Some ideas, but not ready to commit to an approach. You are right that there are some interesting attempts using SHACL. I have never build serious apps directly over SPARQL endpoints, only quick POCs. Mid-tier APIs are ok, they have a role to play, I just don't think they have to fully "own" the business model so to speak. I also don't think what one does to map RDF<->runtime object model has to follow the traditional ORM approach. As you realized, ontologies change and that's one of the advantages over RDBMs (the no schema, or flexible schema aspect), so we have to content with that. In general, ORMs allow a programmer to easily move from a relational representation (and mental model) to an object representation (and mental model). We need to find a way to do something analogous for RDF: move between the two representations & mental models. But the analogy stops there, the solution may not look exactly the same as an ORM.
Renato I. Thomas T. Sure, but again that's also just a means querying, an interface to a triplestore. I am more interested in a domain model expressible in the programming language used to develop the app, how that domain model gets mapped to the underlying RDF substratum, how mutations are handled, both in the front-end, but also coming from the backend in the form of push notifications for example. I want a familiar looking JavaScript/TypeScript object that is somehow mapped to an RDF representation (I don't care how exactly) and I don't want to spend 80% of my engineering effort thinking how to propagate changes to my model between its different realizations.
Raphael Troncy I wasn't familiar with SPARQL Transformer, thanks for pointing it out. I have written similar JSON-LD template/pattern query systems (sort of inspired by Freebase's MQL if you have seen it), including one capable of federating b/w RDBMs and triplestores, and I do appreciate the value of this approach. FDR is a programming API/framework that comes in after you've solved the problem of how to query your data. What does a mutable JavaScript object, mapped to some RDF subgraph, look like and how does one manage changes to the graph, including things like front-end reactivity.
Dear KGC Community, Announcing the release of a new front-end application development library for RDF. Most of us have heard time and again how programmer unfriendly RDF is. Having bitten the bullet several times and having built some fairly large applications on top of RDF, I want the next one to be more fun and easier to write. Link: https://github.com/kobrixinc/fdr. Would love to hear feedback, or even better, get some collaboration if you like where this is going. While not a 1.0 yet, it is being actively used in another project, it is solid and worth your attention if you are contemplating writing browser based apps with a semantic back-end. Kindly, Boris
Hi, Semantic Arts is looking for an Ontologist: https://www.linkedin.com/jobs/view/3028055012/?refId=%2Bskkbm572BLtoapyzdpRKw%3D%3D&trackingId=xiYg9XyU8hs%2F9EEimhIxTQ%3D%3D if you have some questions before making the decision to apply, feel free to DM me.
Sarra Ben Abbès This thread caught my attention because some years ago, I led a team that developed precisely this. Last release is for Protege 4.3: https://github.com/hypergraphdb/protegeowl It’s a full OWLAPI implementation based on HyperGraphDB and a Protege plugin that allows the ontologies to be stored in a database versioned at the axiom level with git like abilities to commit/push/pull/revert etc. At the time we emailed to Protege mailing list to see if there would be interest and unfortunately there wasn’t. More recently, I’ve been looking for motivation to bring that work up to the latest iterations of OWL API and Protege because it’s still a gap, except that more and more people are realizing what an important functionality this is. If you want to use the older Protege 4.3,I’d be happy to help you set it up. Otherwise, just looking for some encouragement (and perhaps someone interested to help?) to get back to work on this.
