Fluree

supports:

type: storage products: ["InterPlanetary File System", "S3"]
type: data_format products: prdct.json-ld
Graph Database RDF Graph Database
written-in: #clojure JVM!
hasApplication Knowledge Management
hasBlog https://flur.ee/blog/
hasFeature
- Time Travel
  - resources: https://flur.ee/2019/02/21/time-travel-with-fluree/ x
- " optionally decentralized (e.g. using StorJ via Tardigrade)"
  - hasSource https://github.com/athensresearch/athens/issues/9#issuecomment-786844129
- JSON-LD support

Features

FlureeQL is similar to SPARQL,
- results from queries can be exported as JSON-LD
a query peer "runs as an in-memory database peer to the ledger it's subscribed to. But like you mention, it doesn't only need (or need at all) to do so because it's intended to answer Fluree queries from other clients. It could very usefully just subscribe to a ledger in order to monitor data events like newly committed blocks and then to evaluate if that data meets a certain criteria, and--if so--to then trigger some downstream function or additional side effect... the NodeJS peer subscribes to the ledger as a particular cryptographic identity, which means that the listener itself will only be privy to data updates that that identity SHOULD be able to access."
"can be embedded inside of your applications (Clojure, NodeJS for now)"
Time and Immutability in Data Systems... probably only for clock-time, natively.
inferencing (e.g., equivalent properties, but that's only useful if you're using data from different ontologies; okay, it's just useful, period) and
- Aliasing makes it possible to not only find equivalent data, but return it in the terms that are useful to us.
Objects: you can further describe the subgraph you want to build by including nested objects. Our dataset doesn't actually include any data with multiple layers of connections
History Queries: also powered by immutability, but are preformed differently than time-travel queries. While time-travel allows users to view the ledger from different points in history, history queries capture each of the data state changes that effected a given entity up until the present moment.

Use Cases

A particular use case around user-specific ledgers, where each user has their own ledger, would demonstrate this perfectly. Given the ability to run database/query peers directly off of an individual ledger, this would also allow ledger-specific users to efficiently build their own applications off their own database peers without any of the security complexities of establishing a downstream peer to a multi-tenant ledger

Learning Resources

References

Children

Backlinks