Hi all, I just replied to @andrewzhurov on that referenced thread on this subject and just read over the latest posts here, so wanted to follow up here.
Exactly so, and that is basically what JSON-LD is designed for. To start, I think it might be as simple as the sketch I offered on the other thread for decorating property blocks with JSON-LD @context and @type tags at the system level.
From the schema.org homepage:
Schema.org vocabulary can be used with many different encodings, including RDFa, Microdata and JSON-LD. These vocabularies cover entities, relationships between entities and actions, and can easily be extended through a well-documented extension model. Over 10 million sites use Schema.org to markup their web pages and email messages. Many applications from Google, Microsoft, Pinterest, Yandex and others already use these vocabularies to power rich, extensible experiences.
Beyond providing a shared namespace of types which benefit from relational composability, there are huge wins baked in, including making real graph queries across federated graphs, a path to being indexed by traditional search engines, and so on. In short, JSON-LD is the lingua franca of linked data on the web these days, and is isomorphic to standard RDF triples.
Having gone there, I’m going to take one more swing at my Fluree pitch to support a lot of the goals I read through in this thread. Andrew had expressed (in the other thread) that while Fluree would be a fairly straight forward engine to drop in, but come with added complexity that seemed misplaced in the application. Given the discussion here, I beg to disagree.
I’ll preface this by recognizing Logseqs origins and mission are around being a second brain and is a more inwardly focussed mindset with a more ah hoc evolution that doesn’t lend itself to strong typing. Yet, to be interoperable with the semantic web, type consistency is needed.
Anyway, I realize the notion of shared editing of graphs may seem sacrilegious, yet, I need to share my knowledge and not by rendering out graph segments and hosting them as webpages, and I actually do want to co-edit knowledge graphs. And even further, I want to have granular access control on the graph. And to be clear, I get that isn’t/wasn’t the target use-case of Logseq. But it would be great, lol.
Anyway, to clear up a couple things about the fluree architecture. It has two layers which run (and scale independently) in separate containers:
- A blockchain persistence/state, and
- A RDF graph overlayed/indexing the state (this can even be run on client side javascript).
So, yes, the underlying state is immutable and append only. When an object is deleted or updated, a new block is written to reflect that change of state, while the graph (which is what is queryable) is updated the new state. The graph can time travel across state for free… queries include a “at time t” input and it costs the same to look into the past as the present. It also provides for independent scaling of read and write performance. The engine can achieve millisecond response time for queries. Clients register for updates from the ledger nodes for commits to triples in their local cache (basically functions like a CDN).
Granted, there is complexity added around consensus, and why do it if you don’t need consensus. But for shared editing of a graph state that all parties can rely on, it would be well worth it either on a local node or in the cloud.
Turning to the out of the box advantages:
- Semantic Web native out of the box. Can be queried using SPARQL and GRAPHQL. Native JSON-LD in first half of the year.
- All transactions are cryptographically signed by identities and encrypted; absolute provenance.
- Built in “smart functions” for identity based access control
- ACID transactions
- Client edge-node graph only reads in the data in needs and loca queries are blazing fast. Write performance can be scaled (and paid for) according to need.
Then, finally, the power to use real, nestable, graph queries executed directly against the Fluree API seems very powerful.
Anyway, I hope you’ll give Fluree a second look in light of the developments in this thread as it seems to hit a lot of the features that have been discussed here.
All the best!