8.2.6. Instance identifiers
|
Note
|
text is up to date from this point on. |
Instance identifiers identify context- and role instances. When two PDR installations exchange Transactions, we identify instances in them in terms of GUIDs (with one exception that will be explained below). However, within an installation, we use an extended format to store and look up resources. A resource is the technical term that encompasses both instances and DomeinFiles: the json documents that hold type definitions. This is because, not on the logical level of the language, but on the technical level of the implementation, all json documents that we want to persist are treated as members of the classes Persistent and Cachable.
We introduce the notion of a 'scheme' to identify resources locally. Schemes tell us where to find and store resources. End users have some influence on where resources are stored through the local and remote schemes, the former specifying a local database name and the latter a URL where the end user has facilities to store documents. However, DomeinFiles, with the model scheme, are stored in a local database and public schemed resources are stored in a location determined by their creator. Finally, default schemed resources are stored in a local database. See module Perspectives.ResourceIdentifiers for more details.
However, we allow the end user to associate each type in a model with a scheme. This is accomplished through a special model that provides the end user with a suitable user interface. Using this he can specify a mapping from types to storage schemes in as much detail as he prefers. Any type name functions as a namespace for syntactically embedded types. The system will use the most specific mapping for an instance. For example,
model://perspectives.domains/System$PerspectivesSystem$User
is more specific than
model://perspectives.domains/System$PerspectivesSystem
If a mapping has been specified for the latter but not for the former, instances of the former will be stored according to the mapping of the latter.
8.2.6.1. Default scheme
Identifiers following this scheme point to resources stored in the PDR’s default resource store. Currently, this is implemented as a store accessible through Pouchdb, named <userID>_entities.
8.2.6.2. Local scheme
The local scheme allows us to store resources in another database than the default resource store, albeit locally (i.e. through Pouchdb with a non-url database name).
8.2.6.3. Remote scheme
The remote scheme allows us to fetch and store resources through some REST interface. The URL represents the endpoint where we fetch and store resources. The resources themselves are stored using the <guid> part as key.
8.2.6.4. Public scheme
The public scheme is just like the remote scheme. However, is is used exclusively to publish resources in a public Umwelt, or in other words, according to a public-facing perspective. It is possible to fill a role with an identifier in the public scheme. Unlike the other schemes, the public scheme is preserved in deltas (the other identifiers are stripped to their guid parts, as the receivers themselves decide on where to store them). Note that the storage location of resources in the public: scheme is under control of the modeller. She can include the location verbatim in the model, or she can specify an expression that allows the end users of the model to set it. But this is different from the control that the end user has over storage in the local and remote schemes (the latter can be set per user, while the former is set once for all users).
8.2.6.5. Model scheme
The model scheme form is designed to be equal to the model URI. It was introduced to be able to handle DomeinFiles through the classes Persistent and Cacheable.