Is this still maintained?

[pricesmith]

Activity has seemed to slow down-- seems worth asking the question!

<3

[jamesaoverton]

Fair question. The short answer is that the current implementation does what I wanted it to, and I don't plan to invest more in it.

I built RDFTab to let me load RDF and OWL into a SQL database and then read parts out. It works as intended for reading and editing simple graphs, and even for reading more complex graphs with nested blank nodes, but it's not convenient for editing complex graphs (including OWL).

To support that use case my team has been working on LDTab, which "folds" blank node structures into nested JSON objects so that a single SQL row can encode an annotated OWL axiom or RDF list, without having to juggle blank nodes. It's not "done" and it's not well documented yet, but we have implementations in Clojure https://github.com/ontodev/ldtab.clj and Rust https://github.com/ontodev/ldtab.rs. Building an LDTab table is a lot more work than building an RDFTab table, so it's slower.

Regarding RDFTab, the upstream https://github.com/oxigraph/rio library has come a long way, and it might be a bunch of work to catch up with it. https://github.com/INCATools/ontology-access-kit was using RDFTab but I think they switched to a pure Python implementation. RDFTab is such a simple idea that it's easy to reimplement. If you're interested in OWL, consider https://github.com/phillord/horned-owl or the https://github.com/jannahastings/py-horned-owl prototype Python wrapper.

Do you have a specific bug or feature in mind for RDFTab?