Known issues

Introduction

This page gathers known issues of the onboarding process and the reccomended solutions or work-arounds for the given issue. If the issue you are facing does not appear on the list here, please contact HRI service desk at servicedesk@health-ri.nl and we will assist you.

FDP

Date and DateTime errors when editing

From what we can gather, FDP client v1.17.x exhibits strange behaviour when creating or editing metadata fields with date or date-time values. The bug report describes the details. A workaround could be moving back to v1.16.3, which Radboud seems to be using without issues (needs to be confirmed).

Delete metadata when FDP client gives a error message

Verify the graph uri.

SELECT * FROM <http://localhost/dataset/6dba4d3e-888a-4b8d-bacf-0fd322bef2f7> { ?s ?p ?o }

Drop the graph of the resource that should be deleted.

DROP GRAPH <http://localhost/dataset/6dba4d3e-888a-4b8d-bacf-0fd322bef2f7>

Delete the link from the parent resource to the (deleted) child resource. In the example below a dataset (child) is removed from the catalog (parent), therefore using the dcat:dataset relation.

DELETE DATA { <http://localhost/catalog/7918a701-b33f-4a96-a511-8c16117b21c8> <http://www.w3.org/ns/dcat#dataset> <http://localhost/dataset/6dba4d3e-888a-4b8d-bacf-0fd322bef2f7> . }

mongo. Remove the metadata information from the metadata collection.

Properties not showing in forms

Sometimes properties will not show when viewing or editing metadata. Possible causes are:

  1. The property does not have a dash:viewer or dash:editor defined in the metadata schema. The solution is to update the property’s attributes in the appropriate metadata schema.

  2. Properties defined on a higher level in the hierarchy are not inherited in the extending classes. This seems to be a bug in the FDP reference implementation. An issue is filed in the FDP github repository, you can check on the progress there: [fdp-client] fields inherited from Resource are not shown. · Issue #580 · FAIRDataTeam/FAIRDataPoint

Publicly hosted FDP shows localhost urls

When an FDP is hosted on a public accessible domain (or IP address), subjects or some links in the UI can show up as localhost. A possible solution is to configure the instance.clientUrl and instance.persistentUrl properties in application.yml is not configured properly. These values should reflect the domain (or IP address) the FDP is available at.

After updating the instance.clientUrl and instance.persistentUrl properties, the FDP can show error messages like “Unable to get data”. Possible solutions:

  • Clean the triplestore and mongo database and restart the application. This is a viable solution if there is no metadata entered in the system yet. For a local setup using Docker Compose with GraphDB and Mongo:

    • docker compose down

    • remove the volumes for graphdb and mongo

    • docker compose up -d

Upgrading your FDP shapes

By default, the FDP reference implementation ships with so-called default shapes out of the box, based on DCAT 2. To upgrade them to the Health-RI model, see below.

Upgrade to Health-RI model v1.0.0

  • health-ri-metadata/README.md at v1.0.0 · Health-RI/health-ri-metadata

  • Log in as an admin user

  • Click on the profile button on the top right of the user interface, and navigate to metadata schemas

  • Select the Resource schema

    • In the v1.0.0 model, copy the contents of the Resource shape

    • In the FDP, paste the contents in the Form Definition area.

    • Click Save and release on the bottom of the page.

    • Enter a description to indicate the use of the v1.0.0 model.

    • Select an appropriate version number.

    • Click Release.

  • Repeat for Catalog, Dataset, Distribution, and DataService.

Solve “Unable to update entity data.” on existing metadata after the v1.0.0 upgrade

Version 1.0.0 introduced a new mandatory property on publisher; identifier. While [fdp-client] fields inherited from Resource are not shown. · Issue #580 · FAIRDataTeam/FAIRDataPoint is not solved, the user interface will not allow this value to be filled by a user.

If you have access to the underlying triple store and have the right to execute a SPARQL Update query, the following query will add a default value:

If you do not have access to the underlying triplestore, the known workaround is to manually disable the sh:minCount constraints on both the Agent definitions; one in Dataset (health-ri-metadata/Formalisation(shacl)/Core/PiecesShape/Dataset.ttl at v1.0.0 · Health-RI/health-ri-metadata) and one in Catalog (health-ri-metadata/Formalisation(shacl)/Core/PiecesShape/Catalog.ttl at v1.0.0 · Health-RI/health-ri-metadata).

Solve “unable to get data” on existing metadata after a model upgrade

  • Catalog shape works after upgrading from default shape to v1 shape. Manual edit lets the user enter an identifier for the publisher.

  • dataset shape works after upgrading from default shape to v1 shape.

  • dist shape works after upgrading from default shape to v1 shape. Manual edit lets user add access url and media type.

Moving from v1 to v2(draft)

Cannot edit Dataset that contains distributions after a v1.0.0 model upgrade

When a Dataset resource that contains Distributions is saved, the form displays a Unable to update entity data. error. This is caused by the issue reported in https://github.com/FAIRDataTeam/FAIRDataPoint/issues/445.

The workaround for this issue is manually editing the Dataset metadata schema to disable the sh:class constraint, on line 97: https://github.com/Health-RI/health-ri-metadata/blob/v1.0.0/Formalisation(shacl)/Core/PiecesShape/Dataset.ttl#L97.

ELSI

Email address visibility

Currently, creator and publisher identities are associated with an email-address. There are concerns about public visibility of PI email addresses. The current workaround is to use a departement email address until we know more about other options (e.g. hiding email behind a login).