Map oaf:eoscifguidelines from mdstore to the graph #256

alessia.bardi · 2022-10-23T18:21:35+02:00

alessia.bardi commented

2022-10-23 18:21:35 +02:00

Field in a transformed record:

<oaf:eoscifguidelines code="EOSC::RO-crate" label="EOSC::RO-crate" url="" semanticrelation="compliesWith"/>

will add an EOSCIfGuidelines in the list Result.eoscifguidelines.

Field in a transformed record: ``` <oaf:eoscifguidelines code="EOSC::RO-crate" label="EOSC::RO-crate" url="" semanticrelation="compliesWith"/> ``` will add an EOSCIfGuidelines in the list `Result.eoscifguidelines`.

alessia.bardi added the

enhancement

label 2022-10-23 18:21:35 +02:00

miriam.baglioni was assigned by alessia.bardi

2022-10-23 18:21:36 +02:00

claudio.atzori was assigned by alessia.bardi

2022-10-23 18:21:36 +02:00

alessia.bardi added 3 commits 2022-10-23 18:21:36 +02:00

31a10f000b Map the field oaf:eoscifguidelines from mdstores. Currently we can find it in ROHub metadata

ee759ac92d file format after mvn compile

208ed32315 fixed xpath for semantic relation

claudio.atzori commented

2022-10-27 16:50:23 +02:00

I was probably not paying (enough) attention when you agreed to introduce this change in the mapping layer, apologies for this... but I would not include such specific conditions in there.

Instead, as we already got a process dedicated to set the eoscifguidelines field in the graph pipeline, I would extend it instead to cover also this case. After all, it already defines all the criteria (although very much hardcoded FTM) for this purpose and I would keep them all in the same place rather than spreading all over the source code.

The condition it would verify could be based on the instance.hostedby.key == '<ROHub ID>'.

What do you think?

I was probably not paying (enough) attention when you agreed to introduce this change in the mapping layer, apologies for this... but I would not include such specific conditions in there. Instead, as we already got a process dedicated to set the `eoscifguidelines` field in the graph pipeline, I would extend it instead to cover also this case. After all, it already defines all the criteria (although very much hardcoded FTM) for this purpose and I would keep them all in the same place rather than spreading all over the source code. The condition it would verify could be based on the `instance.hostedby.key == '<ROHub ID>'`. What do you think?

claudio.atzori added 1 commit 2022-11-07 12:18:42 +01:00

7c3390ac10 Merge branch 'beta' into eoscifguidelines-from-mdstores

alessia.bardi commented

2022-11-14 12:19:39 +01:00

No, Claudio, I disagree.

Miriam had to implement the process because we cannot find the information about the EOSC guidelines in the metadata we collect.

With ROhub, this is not the case: it is the first source that tells us which are the guidelines supported by each product. We need to exploit that, which should be the "normal" way of setting the field about the EOSC IF guidelines.

Please merge the PR and I think you should do it also on the master branch, because I have been informed that we need this asap on the EOSC EXPLORE portal (for sure before the review of EOSC Future).

As you can see the change is minor and the tests work, I do not like to put in prod something that was not tested on beta, this goes against our best practices for deployments, but it looks we have no option...

No, Claudio, I disagree. Miriam had to implement the process because we cannot find the information about the EOSC guidelines in the metadata we collect. With ROhub, this is not the case: it is the first source that tells us which are the guidelines supported by each product. We need to exploit that, which should be the "normal" way of setting the field about the EOSC IF guidelines. Please merge the PR and I think you should do it also on the master branch, because I have been informed that we need this asap on the EOSC EXPLORE portal (for sure before the review of EOSC Future). As you can see the change is minor and the tests work, I do not like to put in prod something that was not tested on beta, this goes against our best practices for deployments, but it looks we have no option...

claudio.atzori merged commit 24f99d7310 into beta

2022-11-14 15:40:34 +01:00

claudio.atzori referenced this issue from a commit

2022-11-14 15:40:35 +01:00

Merge pull request 'Map oaf:eoscifguidelines from mdstore to the graph' (#256) from eoscifguidelines-from-mdstores into beta

claudio.atzori commented

2022-11-14 15:57:41 +01:00

As a second though I agree, knowing we already had a procedure in place for setting the eoscifguidelines I just thought to avoid spreading the same logic in multiple places across the pipeline. However, you have a point: mapping them directly from the source is surely a cleaner approach.

The three commits below are also integrated in the master branch

As a second though I agree, knowing we already had a procedure in place for setting the `eoscifguidelines` I just thought to avoid spreading the same logic in multiple places across the pipeline. However, you have a point: mapping them directly from the source is surely a cleaner approach. The three commits below are also integrated in the master branch * https://code-repo.d4science.org/D-Net/dnet-hadoop/commit/31a10f000b200d047ad50be1c0a376a7316d8be9 * https://code-repo.d4science.org/D-Net/dnet-hadoop/commit/ee759ac92da0116f2f6c0c8b11aacce98e5a55a3 * https://code-repo.d4science.org/D-Net/dnet-hadoop/commit/208ed323153a0b19189f6ddf65776f67a6df2e67

Sign in to join this conversation.

No reviewers