The overall functionality of the CDCS can be understood as a family of functional applications each of which can be combined to support different configurations of functionality.
The different types of CDCS systems, such as the curator and the registry, are specific configurations of this overall functionality.
The functionality can be understood in terms of existing in different functional layers of the system. In general, we can understand the CDCS functionality in the following 5 layers:
This is closely related to Scott Ambler's layered system architecture. By thinking about the system functionality in this way, we are able to understand current functionality as well as how to approach future generalizations of the current system in these terms.
In particular, the specific objects supported by the system (in the core layer) as well as the operations necessary to manipulate and use those objects are shown at each layer.
The CDCS supports interfacing with the essential objects and functionality of the system via manual (currently web-based) user interfaces as well a programmable REST-based API. These interfaces allow users to manipulate and share objects such as templates, types, records, files (BLOBs), forms, XSLTs (for visualation and transformation/export), etc. The system uses a web-framework for making the system online and distributed. It uses MongoDB and SQLite (or PostGreSQL) for handling its application and user data. It uses Django's framework for access-controls. It uses Celery for large task processing and number of other packages to support various functions. Over time, the system will continue to grow and become more generalized so that it can accomodate additional kinds of persistence (storage technologies), interfacing (different user and programmatic interfaces), search (more powerful methods), etc. These all fit nicely into this framework.
From a data flow perspective, one can imagine that work and data flow from users who are using web clients (either browsers or programs). These access pages which generate HTTP requests to the web server, which is configured to forward those to the web application framework, which routes them to the appropriate handling logic. The handling logic may access the database for various requested data elements and may need to render those via custom templates, themes, and designs (using combinations of HTML, CSS, JavaScript, etc., currently), returning responses back to the client.
When users have configured the system for remote search and exchange - such as when "harvesting" records from remote systems using OAI-PMH (as is done in registry sytsem) - then two or more CDCS systems can exchange records according to the commands in that protocol.
