We've had some discussions and a few iterations over an initial idea of what an architecture of a PIT solution might look like. The methods enumerated here are not meant to be exhaustive or even correct. They are meant to illustrate the problem we are trying to solve and to elicit additional discussion to help us refine and hopefully fairly quickly define our problem space.
To ease stepwise adoption, we suggest a multi-layered architecture. As adoption progresses, layers might move closer to each other or become merged. Existing infrastructures may pick up higher-layer functionality in the long term. For example:
The lowermost calls should be designed in a way so that any interested infrastructure provider can support them largely out of the box. One task of the WG implementation team is to develop clients specific to these infrastructures, which connect to the common API layer. Infrastructures will differ in their support PIT-specific metadata. We will need to account for this by using a separate database when necessary. It is important to note however that this is only a preliminary solution (the PIT WG - or any partner - can and should not bear the maintenance burden) and we must work together with infrastructure providers to come to long-term viable solutions. The overall PIT service also connects to a Type Registry service to register and retrieve information about types to support minting PIDs according to a type, retrieving PIDs by type, and so on.
The higher-level service layer is dedicated to functionality that is more sophisticated than what the PIT API offers. It acts as a placeholder for things this WG may deem important, but cannot provide within the WG timeframe, as is the case for much of the aggregation functionality. get_aggregation_of_element(pid) is a potential exception and may be implemented with an index in the PIT service layer database.
The PIT architecture also relies on three main entities: Profiles, Types and Properties. Services can be defined that deal with these distinct layers: