Graph raw mapper from postgres database: map new information about "validated" contexts and relationships from the claim table #66

New Issue

alessia.bardi · 2020-12-07T19:37:59+01:00

alessia.bardi commented

2020-12-07 19:37:59 +01:00

The claim table on postgres keeps track of claims that have been approved/rejected by gateway managers.
In particular, we have the two columns:

approved
curation_date

For now, we are only considering the approved: if it is false, the claim is not added to the graph.
We should now also consider the case when approved is true. If it is, then the relationship or the context can be set as "validated". the value in curation_date can be used for the validationDate
If approved is empty, then the claim must be added to the graph without any validation information (i.e. as it is now).

For the overall activity, please refer to https://issue.openaire.research-infrastructures.eu/issues/6226

The claim table on postgres keeps track of claims that have been approved/rejected by gateway managers. In particular, we have the two columns: * approved * curation_date For now, we are only considering the `approved`: if it is `false`, the claim is not added to the graph. We should now also consider the case when `approved` is `true`. If it is, then the relationship or the context can be set as "validated". the value in `curation_date` can be used for the `validationDate` If `approved` is empty, then the claim must be added to the graph without any validation information (i.e. as it is now). For the overall activity, please refer to https://issue.openaire.research-infrastructures.eu/issues/6226

alessia.bardi added the

enhancement

label 2020-12-07 19:37:59 +01:00

michele.artini was assigned by alessia.bardi

2020-12-07 19:37:59 +01:00

michele.artini commented

2020-12-11 09:50:11 +01:00

I summarize the cases:

approved = false : no graph
approved = true : to graph with oaf.validationDate = curation_date
approved = null : to graph with oaf.validationDate = null

Is it right?

Until now we loaded only the claims with approved = TRUE using this sql:

SELECT source_type, source_id, target_type, target_id, semantics FROM claim WHERE approved=TRUE;

but observing the production database I see that all the claims are approved = true and curation_date = null, is it a problem?

I summarize the cases: * approved = false : no graph * approved = true : to graph with oaf.validationDate = curation_date * approved = null : to graph with oaf.validationDate = null Is it right? Until now we loaded only the claims with approved = TRUE using this sql: ``` SELECT source_type, source_id, target_type, target_id, semantics FROM claim WHERE approved=TRUE; ``` but observing the production database I see that all the claims are **approved = true** and **curation_date = null**, is it a problem?

alessia.bardi commented

2020-12-11 10:13:52 +01:00

Thanks @michele.artini ! based on what you see, then it seems that the Link functionality sets the fields in a different way than what I remembered.

I would go for:

approved = false : no graph
approved = true : to graph with oaf.validationDate = curation_date
~~approved = null : to graph with oaf.validationDate = null~~
approved = null : no graph

The last case is to reflect what we are already doing now: not including the claims with approved != true.
In case approved is true, it goes into the graph. If it has a null curation_date, then it means it was not validated. If it has a curation_date, then it means it was validated and we can use the curation_date as validationDate.

Thanks @michele.artini ! based on what you see, then it seems that the Link functionality sets the fields in a different way than what I remembered. I would go for: * approved = false : no graph * approved = true : to graph with oaf.validationDate = curation_date * ~~approved = null : to graph with oaf.validationDate = null~~ * approved = null : no graph The last case is to reflect what we are already doing now: not including the claims with approved != true. In case approved is true, it goes into the graph. If it has a null curation_date, then it means it was not validated. If it has a curation_date, then it means it was validated and we can use the curation_date as validationDate.

michele.artini referenced this issue

2020-12-14 15:42:59 +01:00

validation in claim rels #77

michele.artini commented

2020-12-14 15:43:37 +01:00

I created the following PR: #77

I created the following PR: https://code-repo.d4science.org/D-Net/dnet-hadoop/pulls/77

claudio.atzori commented

2021-01-08 18:18:48 +01:00

PR was integrated in 6299f75807, closing

PR was integrated in https://code-repo.d4science.org/D-Net/dnet-hadoop/commit/6299f7580720b592c64177e0c9e2a0f3d486a74e, closing

claudio.atzori closed this issue