Solid integration

[agentydragon]

Solid is a combined specification of:

• Personal databases (called pods) which users can self-host. Instead of apps owning a database for a user when a user registers, in the Solid model, a user allows a Solid app to read/write data into the user's pod, so the user stays in control of their data.
• Apps are encouraged to use Linked Data Platform spec to format & store the data, in shared vocabularies where possible.

My main motivation for why I'd like Athens integrated with Solid is that I wish I had a single unified view not just of the notes I enter into Athens, but all my digital life. For a given day, I'd like to see what notes I made in Athens, what PRs I sent, what messages I wrote to whom, ...; but currently all this data is stored in separate databases which don't talk to each other.

So I often find myself either entering data into one app where it's then not visible to other apps (e.g., I can't see my mood tracker for today in Athens), or entering data multiple times.

Ideas:

Athens → Solid

• Embedding RDF data in Athens pages (like "this page is about a person named John Doe, it's the same person as this contact in my Solid pod").
  • Allowing Athens data to be accessed by the LDP interface
    • Should be possible by adding a plugin to solid-rest which would expose current state of Athens db via HTTP

Solid → Athens

• Click-through from Athens to the linked data (e.g., "open the contact for this person in the Solid app I use for contact management")
• Display linked data from Solid inline
  • e.g., if I open a person's page in Athens, also show inline [in Athens] other things my Solid pod knows about the person.

Solid as an Athens backend

It should be possible to write a backend hitchhiker-tree that would store data in Solid, and that would enable Solid as a datahike backend. However, that would write the tree structure into Solid as a raw tree, rather than usual semantic data. Triples like "page:123 is a person, the person's name is John Doe" would have to be recovered by walking that tree.

Solid currently does not have support for history. If we store Athens data in Solid in a form close to Athens representation ("page 123 has blocks a1, a2, a3, block a1 has text Foobar"), that representation would lose history.

It might be viable to store the low-level data in RDF format, and then expose a higher-level read-write view of the current state using something like solid-rest.

Ideas for first steps

I think this is the rough order in which I'd try to do things:

• Add some special syntax in Athens for attributes
  • For use to link Athens pages together and/or into Solid (e.g., "(my page Alexander the Great, talks about, https://www.wikidata.org/wiki/Q8409)")
• Create a solid-rest plugin that translates current state of an Athens database into triples

I can't really commit to having any progress by any date, but I wanted to share my ideas.

[tangjeff0]

Have chatted before with @travis who is working on @itme, a project using Solid Pods

[mateicanavra]

@agentydragon thanks for this great write-up! I think the Solid approach/protocol is exactly what Athens needs to differentiate itself from all the other tools for networked thought. You could discover, explore, and discuss your data across all of your databases from a single interface. Most importantly, storing your data in RDF format would allow you to build and share your personal ontology across the semantic web. It opens up the way for a true knowledge marketplace.

It seems that building on top of Solid as a backend may be pretty cumbersome, however. I'm curious if it would be possible to use Fluree to handle the queries, transactions, etc. and simply store the ledger in a Solid pod.

Relevant discussion here