... | ... | @@ -19,7 +19,7 @@ All actual data processing; HTTP POST, PATCH etc are forwarded to the services c |
|
|
## Application structure
|
|
|
To allow flexibility with respect to ontology and workflow supported, the application conceptually consists of a front end that knows how to render any number of input fields grouped by tabs and connected to specific RDF targets such that each tab roughly concerns some aspects of one resource. A resource in this case can be a _Work_ og a _Publication_. These corresponds to resource types from the ontology. Each tab also has a button to navigate to the next tab, supporting a particular work flow e.g. search for a work, then create a publication of it and then link it to the work. In addition, tabs may be selected explicitly once enabled by the workflow state. The application is designed to be capable of handling a somewhat shallow hierarchy of resources, more specifically _Work_ as top nodes and one or more _Publication_ as children. Depending on context, the editor at any time targets a _Publication_ and its parent _Work_ or only a _Work_ instance. In the former case, the uri of the _Publication_ infers also the uri of the _Work_, so only the uri of the _Publication_ is present in the address bar.
|
|
|
|
|
|
A guiding principle during development has been to separate the general from the specific, so that the front end in principle should be able to handle any type of resource in a structure, not only _Work_ and _Publication_, but e.g. Buildings and Floors. "Publication" and "Work" are therefore mentioned as rarely as possible in the code, but it has not been totally avoided. One could argue that the mindset has been kept, however. To support the principle above, all specific behavior is configured in the file `workflow_config.js`, which is served by the back end. The configuration file describes which predicate from the ontology goes to which tab in the workflow, and other helper functions like how to search for relevant values when linking to authorities, which fields should be shown when creating new authorities etc.
|
|
|
A guiding principle during development has been to separate the general from the specific, so that the front end in principle should be able to handle any type of resource in a structure, not only _Work_ and _Publication_, but e.g. Buildings and Floors. "Publication" and "Work" are therefore mentioned as rarely as possible in the code, but it has not been totally avoided. One could argue that the mindset has been kept, however. To support the principle above, all specific behavior is configured in the file `workflow_config.js`, which is served by the back end. The configuration file describes which predicates from the ontology goes to which tab in the workflow, the order of the predicates, and other necessary configurations like how to search for relevant values when linking to authorities, which fields should be shown when creating new authorities etc.
|
|
|
|
|
|
Following the from above, all solutions are designed to be as generic as possible, even if used only once. The separation of code and configuration means that it should be fairly easy to adapt to another workflow or ontology, simply by replacing the configuration file or parameterize it, supporting other needs.
|
|
|
|
... | ... | |