Update of the RDF and SPARQL (RDF star) families of specifications

The problem is that they aren’t tabular and the examples they give which make them look simple are incomplete. For example, they rarely show examples that specify the language or data type. A truly tabular format is hextuples. https://github.com/ontola/hextuples

I'm using Apache Jena and Java, and using TDB.

Performance? I have nothing to compare it too. I can't complain. I know whenever I saw info about triple stores in the past, they only seem to crow about was how fast it takes to import things. "Eleventy trillion triples per bleem!" I guess nobody ever actually queries the data, they just store it.

I routinely export the model to a file, and that takes seconds (As for queries, well, it either can find it or it can't. It's either trivially indexed (I assume each of the properties of the triple are indexed), or it table scans. Internally when you do a query from Java, you basically set the base net you want to throw (you've only got 3 values to work with) and iterate through to filter it. When I did my "select count" query to count all the triples, that took a beat or two to be sure as it hoovered the entirety of the model and cursored through it. I have not done any crazy SPARQL queries (I can barely spell SPARQL), so I don't know what kind of decisions is makes, but, in the end, there's really only a few ways you can actually query a triple store.

Now, I have a recent Intel iMac I'm running this on, so that may well impact things as well. I have no idea how much memory I'm using, it hasn't been a problem. I've done no tuning whatsoever, I honestly don't know what tuning is available.

I do not foresee my dataset growing much more, so TDB is "fast enough" for my purposes. All told I'm pretty happy with everything.

Yes, having seen this from both ends the more «sciency» guys at reporting/analytics try to bring SOTA practices to bear before core business realizes a need.

If the need is in fact communicating $100bn design specifications between multiple transnational engineering and construction co’s, even the most grounded and pragmatic engineer will gladly inplement RDF and ontologies in the hot path. It’s the best tool for the job on the merits.

Sometimes they need a little nudge. A python or C# library here or there, just to take the edge off, you know?

My impression is that the trade off when choosing RDF vs a property graph when trying to model graph data is between maximal schema flexibility and the ability to infinitely break apart the data model down to the smallest atomic structures because literally everything is a node that is either an IRI(as unique identifier) or a primitive. Vs the convenience of having more complex nodes and edges with some structure built in where you can collapse some fields down and call them properties to describe individual nodes and edges. In RDF you have to create all of that yourself with triples which can lead to some large structures for relatively common tasks like referencing edges and for reification of statements.

Defense industry, part of ARTT (Acquisition Requirements for Training Transformation, ), which is an incredibly-overdue-effort to merge specs. It's also being used to draft MBSE schemas for SysML, SysML has undefined overlap with the many many many other architect tools, and it's going to be the main player for MBSE (maybe . . there's some fighting about that).

These so-called "semantic web" technologies seem to come into their own when there's large scale organizations interfacing without a common reference frame. Like one org that does a spec from a programmer standpoint, and another org does one from a formal linguistics standpoint, then they have to integrate. For example, the USDoD Logistics steering group makes a spec for parts data from their requirements based on MTTF, cost, sparing, shelved space. USN makes a spec for parts data based on burn rate, transport, fuel type. It goes on and on like this, repeat a few dozen times, and you have a dump truck full of specs doing the same thing. See where I'm going here? They're speccing out the same thing from their own ivory towers, and - here's the kicker for those trying to LLM their way out of the situation - none of them are going to show their data to anyone else. The only thing that's exposed is the semantics. ARTT/CredEng is - or was, I am not sure if the program OR CredReg is still healthy - trying to solve this by unifying the semantics.

Ultimately someone's got to come along and give all these people a kick in the pants, one way or the other. You can't just float a boat around the ocean with no missiles, not these days.