# Text+ Services Policy

Stefan Buddenbohm, Lukas Weimer

► To cite this version:

Stefan Buddenbohm, Lukas Weimer. Text+ Services Policy. Göttingen State and University Library. 2024, pp.9. halshs-04698855v2

HAL Id: halshs-04698855

https://shs.hal.science/halshs-04698855v2

Submitted on 28 Jul 2025

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

<figure><img src="image_1.png" /></figure>

Distributed under a Creative Commons Attribution 4.0 International License
<figure><img src="image_2.png" /></figure>

# Text+ Services Policy

<table><tr><td>Version</td><td>0.9</td></tr><tr><td>Editorial Date</td><td>30.08.2024</td></tr><tr><td>Authors</td><td>Stefan Buddenbohm, Lukas Weimer (beide SUB)</td></tr><tr><td>Peer Review</td><td>Andreas Henrich (MInfBA), George Dogaru (GWDG), Philipp Wieder (GWDG)</td></tr><tr><td>Project</td><td>Text+ Sprach- und textbasierte Forschungsdateninfrastruktur</td></tr><tr><td>Title of Document</td><td>Text+ Services Policy (=Service Lifecycle Management Guidelines IO D 5.2)</td></tr><tr><td>Funding</td><td>DFG FKZ 460033370</td></tr><tr><td>Project Duration</td><td>01.10.2021 - 30.09.2026</td></tr><tr><td>Reporting Period</td><td>not applicable</td></tr></table>
# Table of Contents

<table><tr><td>About this document</td><td>2</td></tr><tr><td>Objective of the services policy</td><td>3</td></tr><tr><td><strong>Service definition</strong></td><td><strong>3</strong></td></tr><tr><td><strong>Additional requirements</strong></td><td><strong>3</strong></td></tr><tr><td>Service catalogue</td><td>3</td></tr><tr><td>Service categories</td><td>4</td></tr><tr><td>Roles</td><td>5</td></tr><tr><td><strong>Text+ service management</strong></td><td><strong>6</strong></td></tr><tr><td>Procedures</td><td>6</td></tr><tr><td>Onboarding</td><td>6</td></tr><tr><td>Service operation</td><td>7</td></tr><tr><td>Offboarding</td><td>7</td></tr><tr><td><strong>Addendum</strong></td><td><strong>9</strong></td></tr></table>

<figure><img src="image_3.png" /></figure>

## About this document

This paper defines the Text+ services policy: How does a service become a Text+ service and how does it leave the portfolio? What categories exist? Which roles are necessary in terms of service management? How does a service integrate into the overall architecture<fnref n="1" /> and what are the requirements for the service operation. For relevant context, this paper refers to the Guidelines for adding Text+ Services to the SSH Open Marketplace<fnref n="2" /> and the 2023 DARIAH Service Policy<fnref n="3" />.

<footnote n="1">¹ See: https://text-plus.org/en/ueber-uns/architektur/</footnote>

<footnote n="2">² Buddenbohm, S., & Weimer, L. (2024). Guidelines for adding Text+ Services to the SSH Open Marketplace. Zenodo. https://doi.org/10.5281/zenodo.12657204</footnote>

<footnote n="3">³ Durco, M., Barbot, L., Tasovac, T., Tóth-Czifra, E., Roi, A., Chambers, S., Benardou, A., Constantopoulos, P., Dobreva, M., Scharnhorst, A., Kálmán, T., Rißler-Pipka, N., & McConville, A. (2023). DARIAH Services Policy. Zenodo. https://doi.org/10.5281/zenodo.10184825</footnote>
**Objective of the services policy**

As an NFDI<fnref n="4" /> consortium for language- and text-based research data, Text+ addresses various tasks within the scientific research data management with its portfolio. A significant part of this portfolio consists of services that are provided by the participating data and competence centers as well as dedicated service developments within Text+. These services are to be provided through the Text+ portal in a simple, understandable, and contextualized manner. Other dissemination channels are taken into account as well.

This document has been published as version 0.9 and serves as preparatory work for a future Text+ Services Policy 1.0.

**Service definition**

In the context of this policy, services in Text+ are considered to be technical or infrastructural (e.g. Text+ Registry, FCS or Indico Eventmanagement) as well as non-technical offerings (e.g. training resources) or offerings primarily based on personnel or work time allocation (e.g. helpdesk). Text+ refers with its service definition to the DARIAH Services Policy as well as the service definition of Base4NFDI<fnref n="5" />, the basic services initiative within the NFDI.

**Additional requirements**

Additionally, technical services are required to possess a certain level of stability and maturity. The maturity of a service would typically need to be defined, for example, through Technology Readiness Levels (TRL)<fnref n="6" />. This requirement is waived in this early phase of Text+. In the future, the assignment of TRLs) will need to be included in this policy.

**Service catalogue**

Text+ selects an approach for cataloging its services that must fulfill the following criteria:

* Use of information sources already established in the community,

* Machine readability of metadata to be interoperable, for example for an NFDI knowledge graph or to allow value-added services such as harvesting by other parties,

* Minimal or, ideally, no manual effort required for acquiring the metadata of the services and maintenance of the catalogue,

* Simple usability without entry barriers such as paywalls, and connection to or the possibility of connection to IAM4NFDI, to ensure access,

* the willingness to cooperate with Base4NFDI basic services funded or to be funded in the future, provided they are compatible for the respective service

* Appealing, clear, and structured data corresponding to community standards.

The approach chosen by Text+ for making services visible therefore relies on:

<footnote n="4">⁴ NFDI: Nationale Forschungsdateninfrastruktur = National Research Data Infrastructure. See: https://www.nfdi.de/</footnote>

<footnote n="5">⁵ See https://base4nfdi.de/process/basic-services</footnote>

<footnote n="6">⁶ More on Technology Readiness Levels: https://ec.europa.eu/info/funding-tenders/opportunities/portal/screen/support/faq/2890</footnote>
<figure><img src="image_4.png" /></figure>

* the SSH Open Marketplace<fnref n="7" /> as the actual provisioning and curation site of the descriptive metadata of the services,

* the Text+ Registry as the delivering service to the Text+ portal, which harvests the metadata from the SSH Open Marketplace (and perspectively as source for harvesting by other initiatives),

* and the Text+ portal itself as the presentation layer on top of the registry.

* Overall, both Marketplace and Registry remain as machine-harvestable sources, with the Marketplace being the authoritative source.

The harvesting of Text+-related services from the SSH Open Marketplace filters resources tagged with "Textplus" as keyword and then selects the entity type tools & services<fnref n="8" />. While the technical approach is not relevant for the user, the described components may be studied in the Text+ Architecture v.1.0⁹.

The result is the list illustrated in the screenshot below.<fnref n="10" /> The list format is preliminary and subject to further development, such as the option to group items or filter them by specific criteria.

<figure><img src="image_5.png" /></figure>

## Service categories

Text+ as a geographically distributed research data infrastructure ("ortsverteilte Forschungsdateninfrastruktur") is supported by the participating and diverse partner

<footnote n="7">⁷ See: https://marketplace.sshopencloud.eu/</footnote>

<footnote n="8">⁸ The related search string: https://marketplace.sshopencloud.eu/search?order=score&categories=tool-or-service&f_keyword=Textplus</footnote>

<footnote n="9">⁹ See also: https://pad.gwdg.de/Dc9IrVYUTJiW97v9D0IIXg?view</footnote>

<footnote n="10">¹⁰ See: https://text-plus.org/en/daten-dienste/dienste/</footnote>
institutions. This necessitates defining basic technical parameters for the services provided.
The following three service categories are distinguished:

* Services (further) developed with funding under the NFDI initiative Text+

* Services provided by Text+ (developed and/or maintained beyond project context)

* Services recommended by Text+

<table><thead><tr><td>Services (further) developed with funding under the NFDI initiative Text+</td><td>Services provided by Text+ (developed and/or maintained beyond project context)</td><td>Services recommended by Text+</td></tr></thead><tbody><tr><td>FCS</td><td>TextGrid Repository</td><td>hypotheses</td></tr><tr><td>Registry</td><td>Indico Eventmanagement</td><td>FAIRCheck</td></tr><tr><td>MONAPipe</td><td>Pads</td><td>DNBlab</td></tr><tr><td>GND-Agentur Text+</td><td>RocketChat</td><td>GND Explorer</td></tr><tr><td>...</td><td>...</td><td>...</td></tr></tbody></table>

## Roles

In the Text+ services policy the following roles are distinguished:

<table><thead><tr><td>Role</td><td>Description</td></tr></thead><tbody><tr><td>Portfolio Manager</td><td>Operations Speaker of Text+. Ensures compliance of a service to the requirements of Text+. A service should ideally contribute to the technological coherence of the architecture and fit in a reasonable way into the portfolio of all services.</td></tr><tr><td>Service Owner</td><td>In FiTSM<sup>11</sup>: The person responsible for a specific (Information Technology (IT)) service offered by the service provider. This role is typically taken on by individuals with management experience. In the context of Text+, this can also be a group of people (decision body) or an institution (represented by one or more persons).</td></tr><tr><td>Process Owner<sup>12</sup></td><td>In FiTSM: an actor with overall accountability for the operation of a specific process. For the sake of simplicity in Text+ the Process Owner iscongruent with the Portfolio Manager. The Portfolio Manager has the decision power regarding onboarding and offboarding a service, taking into consideration the coherence of the overall Text+ service offer.</td></tr><tr><td>Service Provider</td><td>An organisation hosting a service, responsible for ensuring its availability. For Text+ services, this could be a partner institution, a cooperating partner or a third party (for instance, a commercial provider). Text+ does not act as a service provider itself.</td></tr><tr><td>Technical Contact</td><td>A person or group of persons (this could also be via a functional account or a helpdesk system) responsible for the technical provisioning of a service.</td></tr><tr><td>Users</td><td>The audience of the Text+ services. Depending on the service, it can be a global audience, meaning that the services are open to anyone, or a more restricted audience.</td></tr></tbody></table>

<footnote n="11">¹¹ See: https://de.wikipedia.org/wiki/FiTSM</footnote>

<footnote n="12">¹² Grayed out cells are not applicable in the current phase of Text+ but are foreseen as additions in the future.</footnote>
audience. In some cases, users need to be authenticated to access services listed in
the Text+ Service Catalogue.

For the time being only three roles are implemented: the portfolio manager, which is the Text+ operations speaker, the service owner, usually the institution or personnel responsible for an offering, and the service provider, which can be the same as the service owner but in some cases an infrastructure institution like a data center. The latter role in Text+ applies for instance in some cases to the GWDG, which provides basic infrastructure like AAI or virtual machines.

## Text+ service management

A portfolio is an internal inventory of all services - including those in preparation, live and discontinued as well as internal services - offered by an organisation or service provider, along with administrative information about these services, especially contacts of responsible persons. As Text+ is a distributed network, the Service Portfolio encompasses a selection of services provided by organisations affiliated with Text+, as well as services used by Text+ and provided by third parties. The portfolio keeps track of the services' status:

<table><thead><tr><th>Onboarded</th><th>Needs review</th><th>To be offboarded</th><th>Offboarded</th></tr></thead><tbody><tr><td>Service is active and in use and is listed in the Text+ Service Catalogue.</td><td>Service needs attention, e.g. because it is down (not available although it should be), or some aspect of it changed and stakeholders need to be informed, or decision is due.</td><td>There has been a decision or request for a service not to be considered a Text+ Service anymore. This status marks the transitional period until the service has in fact been discontinued as a Text+ Service.</td><td>Service is no longer considered a Text+ Service, either because it is not operational, or is no longer relevant in Text+ context (though it may still be available).</td></tr></tbody></table>

In Text+ the Portfolio Manager is responsible for the lifecycle of the services.

The Text+ service management consists of two lists:

1. The **internal service portfolio**: lists all services including internal ones only accessible to Text+. For all services administrative metadata is maintained, i.e. service responsibilities, roadmaps or contact persons.

2. The **external service catalogue**: the publicly accessible list of services on the Text+ portal. Their metadata is maintained via the SSH Open Marketplace. Anyone can edit/update the according metadata (after which they have to be released to the public by the editorial board).
# Procedures

## Onboarding

Onboarding is the process of adding the service to the Text+ Service Portfolio. This involves gathering information about the service, most importantly, contacts of responsible organisations and persons, as well as categorisation (status and type).

## Service operation

Once onboarded, Text+ services are expected to be run and maintained by the Service Provider in a reliable manner. To this end, various organisational and technical measures are introduced to enable overview of the status, availability, and reliability of the services. These will differ depending on the service type.

At this phase of Text+ the services policy does not require service or operational level agreements. However in terms of quality management this aspect will have to be added in the future as soon as Text+ enters a phase of stable service provision.

## Offboarding

Offboarding means removing a service from the portfolio of Text+ services. This could be either due to a discontinuation of the service, or due to a decision by one of the stakeholders that this service should not be considered to be a Text+ service anymore (because it is superseded by another service, it is not used/useful anymore, etc.). In any case, the Portfolio Manager must be informed as soon as possible. Portfolio Managers themselves can also suggest the offboarding of a service in consultation with the relevant stakeholders. An offboarded service is removed from the catalogue, but is kept in the portfolio with status "Offboarded" for completeness of historical record. Offboarding procedure:

1. Upon discontinuation decision, grace period and final date for end of service is agreed upon between Service Owner, Service Provider and the Portfolio Manager.

2. In order to remove the service from the Text+ Service Catalogue, the service entry in the SSH Open Marketplace is updated accordingly<fnref n="13" />.

3. The Portfolio Manager changes the status of service to "to be offboarded" in the portfolio.

4. The Service Provider assesses the archiving & redirecting needs to ensure proper discontinuation of the service and discusses best solutions with the Service Owner and the Portfolio Manager. Special precautions are needed in the case of transfer to a new service.

5. The Service Provider turns off the service.

Aspects to consider when discontinuing a service:

* Save the data: Any relevant data or content contained in the service SHOULD be exported in a readable, appropriately structured and machine-readable form. Depending on the nature of the content, it can be published to a repository, or archived

<footnote n="13">¹³ At the current state this means the removal of the keyword TEXTPLUS after which the resource doesn't get harvested anymore by the registry.</footnote>
internally by Text+. The location of the archived data MUST be recorded in the
portfolio.

* Save the code: If the service is based on some custom software solution, the latest version of this software SHOULD be made available via a git-repository (by default under the Text+ organisation at GWDG-GitLab), Zenodo or on Software Heritage. This should include at least information about the installation and deployment procedure. Submitting websites to Internet Archive to preserve the full presentation layer is also recommended. The location of the archived code MUST be recorded in the portfolio.

* Save the links: Ensure that the domain and if possible links to the website are either redirected properly to a new service, or at least to an information (tombstone) page informing about the discontinuation of the service. This is especially the case for all services under the Text+ domain.
Addendum

As soon as Text+ provides a stable service portfolio or reaches a certain level of user uptake, Text+ will need to implement Service Level Agreements and Operational Level Agreements for its services (see table below). In the current phase of service development/build-up, the commitments of the involved and ISO 9001-certified data centers<fnref n="14" /> are sufficient.

<table><thead><tr><th>Services provided by Text+</th><th>Services recommended by Text+</th></tr></thead><tbody><tr><td>Service or Operational Level Agreement (OLA) - contract between Process Owner and Service Provider detailing the terms of offering a service</td><td></td></tr><tr><td>OLA between service provider(s) and Text+ MUST be in place.</td><td>No OLA expected, though there could be an OLA on a local level between the partner institution and an actual third-party provider. An exception is made for services provided by partners outside of Text+. For these services, SLA between the provider and Text+ MUST be established.</td></tr><tr><td colspan="2">Ideally, SLA/OLA SHOULD be implemented as part of the onboarding. Existence of an SLA/OLA is recorded in the Text+ Service Portfolio.</td></tr><tr><td>Regular review - check the validity of information about the service in the portfolio by Service Owner</td><td></td></tr><tr><td>Annual review of the portfolio by the Portfolio Manager, involves re-assessment of the status of services, including potential onboarding of new services..</td><td>Annually by the Portfolio Manager.</td></tr><tr><td>Monitoring - Automated continuous checks of the availability of the service</td><td></td></tr><tr><td>Required.</td><td>Optional but strongly recommended. Text+ Monitoring is offered for all Text+ services.</td></tr><tr><td>Analytics - Automated collection of usage of the service</td><td></td></tr><tr><td>Required. Use of Text+ Analytics service preferred.</td><td>Use of an analytics services is optional. Text+ Analytics service can be used.</td></tr></tbody></table>

<footnote n="14">¹⁴ https://qwdg.de/pdf/iso-certs/GWDG_Cert_de.pdf</footnote>