I agree with Hunter, it’s really a good timing for this 
Thanks for your research @oetyng ! I’ll read through the code and will summarise my thoughts.
In a very direct way, I think. Linked Data is indexable and searchable by its very nature and RDF with SPARQL simplifies the task a lot.
Not necessarily but everything depends on what approach will have the best performance and require least number of changes in the network code. And there are many options for this: RDF can be stored as a graph in a key-value storage (that is Mutable Data) – and as an example there is e.g. RDFLib that has a back-end storage implementation on top of Berkeley DB, a key-value storage too. But I think tests will also show if storing RDF in a separate triple-based data type is more efficient.
There’s lots to research and consider, so any extra input helps!
Yes, with federated queries I’d imagine it as the query parser / constructor / handler will live on the client side, and the client side will decide where to send the partitioned queries and how to compose the final result. The individual queries most likely need to be handled by Vaults, because otherwise we’ll have to fetch the entire data sets and it’s a very inefficient approach.
The network fundamental of “storing data in perpetuity” also simplifies this task in a lot of ways: with the assumption that the data at a given location never changes, it’s possible to cache it at different levels and make the queries very efficient.
Still, there are many unanswered questions that I’m trying to answer, like e.g. how to deal with the encrypted data. But judging just by the number of research papers on LinkedData/RDF out there, it seems like the community has already thought of everything. I’ll keep on researching and will keep you posted.