We are still learning what it means to design an application in a linked data style. Rational teams have tended to want to decouple the “API” of the application from the storage of the data. I have never understood why they do this, and I cling to the hope that the overall application can be simplified by having a direct relationship between the application API and the stored data. This is one of the hypotheses I want to test. In particular, I want to try an architecture where there is a “core” data model that is read/write that is common to the application layer and the storage layer. The application layer adds a “view” data model that is read-only which maps to the “core” data model. Here is an attempt to draw this:
Note that our recent discussion of the implementation of the basic profile container API in the context of the system registry follows this pattern. The “core” model consists only of the entries themselves – the container is not part of the stored model. The container itself is constructed in the “view” layer in the application.
Regardless of whether my drive to align API and storage models succeeds, I believe it is extremely important that the storage model be documented as an external contract. This is very important for query and for version migration. Tools developers have a history of treating the storage model as an internal implementation detail that they are not obliged to share. This is a bad practice, even though it is pervasive.