There are ways to address data. In Web 1.0/2.0 it's URLs. In filesystem it's paths. Some data might represent programs. In fact in Web 2.0 URLs address data entangled with a program (with rare exceptions) and there is no way to untangle and address each piece (data, program) individually.
We desperately need a way to not only address data and program individually but also a projection of data through a program data→program.
Addressing data→program through URLs does seem viable
ipfs://Qm...5MdVo/document/ipfs://Qm...F9Ufd/parse
It is also possible to express projection pipelines data→parse→render
ipfs://Qm...5MdVo/document/ipfs://Qm...F9Ufd/parseipfs://Qm...F9Ufd/render
Addressing data→program through path does seem problematic
/ipfs/Qm...5MdVo/document/ipfs/Qm...F9Ufd/parse
because end of data address and start of program address is no longer obvious. Note that /ipfs/Qm...5MdVo/document/can represent directory containing ipfs entry.
During early days if web URL was an address to a piece of data. There was a markup to make viewing it more pleasant, but never the less it was just marked-up data. As web matured and data shared on it became more complex JS programs came to rescue adding some interactivity so viewers could manage complexity of viewing complex data. As web transitioned from readonly to read/write model data aided with JS viewer became the default. Today URL is no longer address to a data, it is address to a JS program that on can also fetch some data from a home-base inside a walled garden. Consequently:
Even motivated authors can easily end up with creative applications that cause data silos due to overhead of creating inter-operability. Even if system takes care of decoupling data from programs that does not necessarily empowers users to pair arbitrary app with desired data. We need URLs that address pieced of data viewed through a piece of application logic.
Maybe even take it step further and embrace unix pipes to allow addressing piece of data projected through piece of code to other data format that is projected through piece of application logic to the view:
local://Data/intro.quill | local://Lens/quill-to-markdown | local://Lens/markdown-viewer