F-UJI Tool Not Reading Metadata Access Rights Properly

[TutasiCSUC]

We are currently using the F-UJI tool to assess the FAIRness of datasets within our repository hosted at https://dataverse.csuc.cat/.

Our repository uses various metadata schemas including Dublin Core, JSON, and OpenAIRE. But, it seems that F-UJI may not be interpreting access rights information correctly from metadata.

From the issue: #183 , we suppose that F-UJI is reading dublin Core schema for the metadata 'acces Rights'. In our Dublin Core metadata, the access rights information is represented as follows:

dcterms:rightsinfo:eu-repo/semantics/openAccess</dcterms:rights>

Running F-UJI tests, we observed that the tool does not seem to recognize or properly interpret this access rights information. Should we change dcterms:rights for dcterms:accessRights?

[huberrob]

Can you please post an example dataset URL/DOI ?

[TutasiCSUC]

Can you please post an example dataset URL/DOI ?

For the dataset: https://doi.org/10.34810/data514 F-UJI for 'Accessible' field, the results are:

[TutasiCSUC]

Can you please post an example dataset URL/DOI ?
For the dataset https://doi.org/10.34810/data899 , I get:

[huberrob]

Thanks for this example.
Unfortunately I cannot discover the Dublin Core property rights nor accessRights (both shoud be OK).
At least these properties are not embeded in the landing page.

I can see this field in the export XML here: https://dataverse.csuc.cat/api/datasets/export?exporter=dcterms&persistentId=doi%3A10.34810/data514

But unfortunately this file is not linked in a way machines can see it (e.g. via typed links, signposting).
I know Dataverse can do this, maybe you should check your Dataverse config or contact the Dataverse team and ask them about 'signposting'.

[mateuszpawlik]

Hi, yesterday I observed the same problem.

Context: We're developing a new repository and I wanted to quickly figure out what should we add to the metadata and how. Since it is quite difficult to find any specific information on which keys or namespaces to use (I also read through the F-UJI paper), I started trying things out in a test project. We want to improve over what we have (example website).

The website generated on the main branch passes the access rights F-UJI test. This version uses schema.org "conditionsOfAccess": "http://purl.org/coar/access_right/c_16ec".

The website generated on a merge request, with has only "dc:accessRights": "http://purl.org/coar/access_right/c_16ec" doesn't pass the access rights test.

The metadata differs only by the schema.org conditionsOfAccess key.

schema.org correctly validates both file versions.

I don't know the F-UJI's code, but is it possible that the accessRights key should be somewhere in fuji_server/helper/metadata_collector_dublincore.py?

[huberrob]

Thanks, for the interesting examples!
This record (http://ccns.gitlab.io/-/neurocog/neurodataops/anc/classification/f-uji-test/-/jobs/7068189568/artifacts/public/index.html) specifies itself as @type: "Dataset" but dc:accessRights is not part of schema.org/Dataset schema and therefore ignored here

[mateuszpawlik]

Thanks. This all is rather new to me. Could you give me a hint on why exactly dc:accessRights is ignored? schema.org correctly resolves it

And the prov namespace works fine.

[huberrob]

Yes the Google tool displays its presence but it as I mentioned accessRights is just not part of the schema.org/Dataset schema. The Google tools also seems to ignore non schema.org properties. You can for example change dc:accessRights to dc:abcdefg and the tool still validates it.

[mateuszpawlik]

This is what I don't understand. JSON-LD format is agnostic to the semantics of specific namespaces. I can combine multiple contexts to better describe my entity. Which mechanism is responsible for ignoring keys that are not part of schema.org type Dataset? I'm happy to read on that if you have any links. And thank you for the help.

[huberrob]

Yes JSON-LD is the format and you are free to use additional triples or properties but you can't expect clients to understand this since you indicated a distinct schema (Dataset). If you want clients to understand some dc terms in your JSON-LD you would have to indicate an additional type, e.g. dcat:Dataset which uses dcterms.

[mateuszpawlik]

Thanks. That helps a bit. I understand that the F-UJI tool is the client in this context, and it's up to the tool to interpret my JSON-LD file.

I also understand that, once I define the type of my entity, I should stick to its schema, for example, dcat:Dataset class has a different schema than schema.org:Dataset. I should pick one.

I don't understand how the access rights is different to prov:atLocation and prov:wasGeneratedBy which I have in my example. F-UJI recognizes the namespace (FsF-R1.2-01M-2), but it actually may not recognize these two properties, because of the same reason as in the case of access rights.

If my reasoning is correct, I wonder what's the best practice to include all these different namespaces which F-UJI requires for a higher score. I have to include a PROV-O ontology (FsF-R1.2-01M-2) but I can't use it, because the type, which I have to (or should) define (schema.org:Dataset or another), doesn't contain PROV-O properties.

For our repository it doesn't matter which type, namespace, or properties we use. We can pick any. But it is difficult to put all F-UJI requirements together.

I'm sorry if I went away from the original issue.

[huberrob]

This is correct, and you are right, F-UJI only checks for the presence of prov namespace which is a bit inconsistent, actually we should test for presence of PROV activities or agents which would be more strict but maybe more correct.
Anyway F-UJI assessments represent one possible interpretation of FAIR which is not authoritative, so if you and you community feel that this and that is not necessary to implement, it is your choice.

[mateuszpawlik]

We use F-UJI as a guideline to add the relevant metadata. Now I know what is relevant, but I'm simply not sure how to implement it. Thanks for your help 🙂