Lately I’ve been ramping up my interest in triple stores and SPARQL. And as I operate #mage-party I find myself with a very concrete example of why I want to use it.
Okay, XEPs, amirite? I want to have a straightforward guide to assist in federating the jabber network. While I love Prosody, I want to document the other servers, as well as all the clients.
One issue of course is which XEPs are supported by which client, server, config, whatever.
Think of this: a best practice for Prosody that I’ve never seen explicitly stated as such is to clone the entire modules repo. Then you can basically turn on any config setting, they are all there.
But if I am listing a page of XEPs supported by Prosody, which do I list? The ones in the community modules? Those supported by core?
Now multiply that by jabber server; okay, there aren’t that many. But they do come and go, so tracking that over time is a bit difficult, especially if recommending a particular setup.
Okay, now let’s break all these things apart and relate them! We can suddenly query a XEP, get back a list of servers and clients that support it, as well as the nature of that support (core, contributed, experimental, stable, deprecated, no support, dev hate, etc.).
Another pool of integrations would be something like WordPress, which has become an ecosystem to such a point that any new technology will eventually disappear or have a WordPress integration (or both…).
If WordPress happened to support an XEP, I’d want it to be queryable. But imagine all the things that WP would have integrated. Some core, some other, some overlapping with jabber servers!
And being able to model these relationships allow me to build automated systems to track the status of those facts, enabling narrative driven queries that produce timely, useful documents for people.
Is this starting to make sense?