More detail about how ResourceStore deals with LDP-BC / LDP-RS / LDP-NR
Closed this issue · 2 comments
The resource store knows about both LDP-RS and LDP-NR, but it will need to treat them differently. How does that work if you would build a Solid pod server with this architecture in practice? Would you use a triple store + a binary store? And in which one of those two would containment triples live?
The resource store knows about both LDP-RS and LDP-NR, but it will need to treat them differently.
This statement is not correct as written.
ResourceStore is an interface, and that interface does not expect implementations to know about LDP-RS or LDP-NR, as you can see from the method signature. It just knows about resources and representations.
Some implementations might want to make that distinction, but not all of them.
How does that work if you would build a Solid pod server with this architecture in practice?
There will be specific implementations of ResourceStore, as depicted here: https://rubenverborgh.github.io/solid-server-architecture/solid-architecture-v1-1-0.pdf#page=4 (happy to elaborate)
Would you use a triple store + a binary store?
That is one possibility. How that possibility would work in the architecture is using three components:
TripleStoreFileSystemStore(or other binary store)CompositeResourceStore
This latter store would then be responsible for switching between one or the other.
Note how TripleStore in that design does not know about binary files, how FileSystemStore does not know about triples, and how CompositeResourceStore does not know about either. Again a good example of managing complexity.
And in which one of those two would containment triples live?
That's up to the implementation; there might even be different implementations. Or there might even be a fourth store just doing containment. That's the flexibility the architecture affords. You can pick one, someone else can pick another, they can even live in different modules. Because components are independent of each other, and knowledge is kept very local, such flexibility becomes possible.
Resolving this for now; can be reopened if new concerns arrive.