Stephan Heunis
91720317ca
All checks were successful
Deploy on webserver / Build site and deploy on success (push) Successful in 1m12s
Along the same lines as 478015 which introduced a generalization for the taxonomy list page,
this commit generalizes the term page template, so that we can remove all duplicates for
taxonomy-specific layout templates.
Several new partials are introduced that are now used in a term page heading and info section,
specifically for the date, identifiers, links, licenses, and related terms such as persons or
topics. These same partials are also worked into the existing 'taxonomy-list-vertical-item'
partial to remove further redundant code. As part of these changes, new icons were added. Also
content has to be updated to change 'date_created' to 'date' in order to streamline its handling
in the single generalized template. The associated jinja templates were also updated with this
change.
The term page layout can be customized in the same taxonomy's '_index.md' page front matter as
is done for the taxonomy list page customization. Newly introduced options are all sub-properties
of the new 'term' property under 'params':
- 'person_display': When a list of persons are rendered for a given term, what should those
people be called? This is a string value that defaults to 'Contributors'.
- 'depiction_type': The type of depiction that should be rendered for the given term page (and
in 'taxonomy-list-vertical-item'), if such a file exists in the term bundle. This expects a
string that will be matched against image files in the term bundle, and will default to 'depiction'.
This option is necessary because the depiction registration workflow saves depiction files with
names representing their types, e.g. 'portrait', 'logo', etc.
- 'show_relations': In which format should term relations be displayed at the bottom of the term page,
if at all. The default is to display no relations (explicitly: 'none'). Other options include
'expandable', which will show list of expandable taxonomy groups, each group containing all terms of
that taxonomy that relate to the current term; and 'congo', which will render the Congo-theme default
list of related terms.
Here are two example configurations for the term options:
'content/persons/_index.md':
---
title: Persons
params:
term:
depiction_type: portrait # portrait | logo | depiction (default)
show_relations: expandable # expandable | congo | none (default)
---
'content/publications/_index.md':
---
title: Publications
params:
term:
person_display: Authors # defaults to 'Contributors'
---
Finally, new config is added to several taxonomy index pages to perform these customizations for terms:
- persons: should render the 'portrait' depiction type and show expandable relations
- publications: display persons as 'Authors'
- instruments: should render the 'logo' depiction type
55 lines
2.2 KiB
Markdown
55 lines
2.2 KiB
Markdown
---
|
|
title: Dump Things Service
|
|
persons:
|
|
- christian-moench
|
|
params:
|
|
graphRootNodePID: xyzrins:instruments/dump-things
|
|
pid: xyzrins:instruments/dump-things
|
|
doi: null
|
|
date: null
|
|
source_code_url: null
|
|
documentation_url: null
|
|
title: Dump Things Service
|
|
description: 'The Dump Things Service is an implementation of a service that allows
|
|
to store and retrieve data that is structured according to given schemata.
|
|
|
|
|
|
Data is stored in collections. Each collection has a name and an associated schema.
|
|
All data records in the collection have to adhere to the given schema.
|
|
|
|
|
|
The canonical format for schemas is [LinkML](https://linkml.io/). The service supports
|
|
schemas that are based on DataLad''s *Thing* schema, i.e. on https://concepts.datalad.org/s/things/v1/.
|
|
It assumes that the classes of stored records are subclasses of `Thing`, and inherit
|
|
the properties `pid` and `schema_type` from the `Thing`-baseclass.
|
|
|
|
|
|
The general workflow in the service is as follows. We distinguish between two areas
|
|
of a collection, an incoming area and a curated area. Data written to a collection
|
|
is stored in a collection-specific incoming area. A curation process, which is outside
|
|
the scope of the service, moves data from the incoming area of a collection to the
|
|
curated area of the collection.
|
|
|
|
|
|
To submit a record to a collection, a token is required. The token defines read-
|
|
and write- permissions for the incoming areas of collections and read-permissions
|
|
for the curated area of a collection. A token can carry permissions for multiple
|
|
collections. In addition, the token carries a submitter ID. It also defines a token
|
|
specific zone in the incoming area. So any read- and write-operations on an incoming
|
|
area are actually restricted to the token-specific zone in the incoming area. Multiple
|
|
tokens can share the same zone. That allows multiple submitters to work together
|
|
when storing records in the service.
|
|
|
|
|
|
The service provides an HTTP-based API to store and retrieve data objects, and to
|
|
verify token capabilities.'
|
|
kind: Software
|
|
author:
|
|
- pid: xyzrins:persons/christian-moench
|
|
given_name: Christian
|
|
family_name: "M\xF6nch"
|
|
topic: []
|
|
license: []
|
|
|
|
---
|
|
|