Compatibility Check for Static vp-index with Latest Meta Data Schema Changes

[ammarbarakat]

Describe your problem.

We are currently actively developing on the vp-portal. In order to ensure a seamless integration with the latest changes in the meta data schema, we're sharing the current version of the static vp-index. We kindly request your assistance in reviewing the provided list of attributes and their compatibility with the recent schema updates.

Describe the solution you'd like

Please evaluate the list of attributes we've shared and verify their compatibility with the latest meta data schema. If any discrepancies or incompatibilities are identified, we kindly request your guidance on the necessary adjustments that need to be made to ensure a 100% compatibility with the latest schema changes.

Attachments

STATIC-VP-INDEX

Additional context

If you have any questions or require further explanations, please don't hesitate to reach out to us. We're also available to schedule a meeting in order to go over all the necessary details.

[henrietteharmse]

@ammarbarakat Please provide the list of attributes rather than have a link to an access controlled document to ease review by EJP RD members.

[ammarbarakat]

@henrietteharmse It's not only about the attributes; the values linked to them also matter. For this reason, I've made an update to the LINK, making the list accessible to everyone for viewing.

[vabishaa]

Hi @henrietteharmse can resources be described with types other than Catalog, Patient Registry, Biobank, Guideline, Dataset ?

[vabishaa]

• Maybe a type attribute should be added to DataService to differentiate between the Catalog and Individual endpoint
• Can one resource just have one resourcetype or multiple entries for this attribute
• Could the responseType added in the FDPs to retrieve the information and display the type of results which are returned from the resources?

[henrietteharmse]

@ammarbarakat It is not clear how these attributes map to the resource metadata schema. What seemed to be missing are:

1. creation date
2. update date
3. contact info, in particular email.

The rest is there as far as I can see.

[henrietteharmse]

Hi @henrietteharmse can resources be described with types other than Catalog, Patient Registry, Biobank, Guideline, Dataset ?

I think it depends on what you mean by describe. All resources can be described using the attributes as defined for `dcat:Resource. Key is you have to specify:

1. dct:description can provide a textual human readable description of the resource.
2. With dcat:theme you can define the list of themes the resource deals with. This could refer to anything even outside of the biomedical context that is used for EJPRD.
3. dct:keyword can provide further information to describe the resource.
4. dct:conformsTo can be used to reference specify standards this resource conforms to. This could potentially be used to describe the record level data of the resource.

etc... All this can be used to describe the metadata of the resource. What it cannot do is describe the record level data of the resource beyond the reference to the specification as defined by dct:conformsTo. Personally I think adding Biobank, PatientRegistries and Guidelines have been a mistake and adds confusion as it blurs the line between metadata vs record level data.

[henrietteharmse]

Meeting 30 Aug 2023:

1. Add dct:identifier
2. dcat:DataService 2.1. Make dcat:endpointURL mandatory 2.2. Make dcat:hasVersion mandatory
3. Add dcat:contactPoint to dcat:Resource.

[markwilkinson]

Please hold-off on these changes. We have just reversed some of them in the onboarding meeting (and besides, these things need to be discussed in the Metadata group, before such decisions are made...)

Thanks!

[markwilkinson]

Summar of the OA decisions:

   1. Add dct:identifier

This is good, but we should probably ensure that we constrain identifiers to URI/URNs

   2. dcat:DataService
      2.1. Make dcat:endpointURL mandatory

We cannot do this! Not all Data Services are APIs! Currently, the specification (in the FiaB installation instructions, and the SHACL) is that if you are an API, then you must have a dcat:endpointURL, and a dcat:endpointDescription. If you are NOT an API, then you must have a dcat:landingPage. We can only enforce this as a policy, not via SHACL or other validation.

    2.2. Make dcat:hasVersion mandatory

This is a bad idea. The concept of "version" in DCAT is that there are multiple versions of a record, where "hasVersion" points to one or more other URIs with other versions of the record. It is not a "version number"!! It is highly unlikely that our users will be able to use this field correctly.

   3. Add dcat:contactPoint to dcat:Resource.

As of the last OA meeting, the VP is expecting there to be a contactPoint, that has a vcard as its range, that contains at least a "URL" properly (required)

[henrietteharmse]

@markwilkinson Can I assume that these changes are ratified?

[markwilkinson]

Just checked with Luiz and Marco - as per our understanding of the conversation, these have been ratified.

There is one more, that Luiz reminded me of:

Instead of the dcat:hasVersion (that we made not mandatory, above), we add dcat:version, which differs in that its value is some kind of identifier string. (e.g. "1.0"). This should also not be mandatory, but should be included in the metadata schema at the Resource level.

[henrietteharmse]

Just checked with Luiz and Marco - as per our understanding of the conversation, these have been ratified.

@markwilkinson Thanks Mark! That is helpful to know!

[markwilkinson]

Pleasure!

The other discussion that happened was that we should perhaps replace "issues" with "pull requests", so that the suggestion is more transparent. What do you think?

[henrietteharmse]

I am unsure about that. Issues I see as changes that needs to be implemented. Pull requests are more for changes that has been pushed to a branch and needs to be merged in. From the Github docs:

Pull requests let you tell others about changes you've pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch.