[Datasource / Service] datasource_model_eosc #16

Merged
claudio.atzori merged 9 commits from datasource_model_eosc into master 2022-05-03 11:45:40 +02:00

This PR extends the Oaf Datasource model to include the extra fields about the EOSC services.

This PR extends the Oaf Datasource model to include the extra fields about the EOSC services.
alessia.bardi was assigned by claudio.atzori 2022-05-02 10:15:04 +02:00
miriam.baglioni was assigned by claudio.atzori 2022-05-02 10:15:04 +02:00
claudio.atzori added 7 commits 2022-05-02 10:15:05 +02:00

To me the PR can be integrated

To me the PR can be integrated
alessia.bardi reviewed 2022-05-02 17:51:51 +02:00
pom.xml Outdated
@ -7,3 +7,2 @@
<packaging>jar</packaging>
<version>2.11.34-SNAPSHOT</version>
<version>2.11.34-eosc-SNAPSHOT</version>

Is this the expected version that must go into the beta branch?

Is this the expected version that must go into the beta branch?
Author
Owner

Nope, I will remove the eosc tag right before releasing the module.

Nope, I will remove the `eosc` tag right before releasing the module.
claudio.atzori marked this conversation as resolved
@ -488,6 +578,12 @@ public class Datasource extends OafEntity implements Serializable {
datasourcetypeui = d.getDatasourcetypeui() != null && compareTrust(this, e) < 0
? d.getDatasourcetypeui()
: datasourcetypeui;
eosctype = d.getEosctype() != null && compareTrust(this, e) < 0

If I remember well, the EOSC Catalogue does not tell (yet) if a service is a data source or not. Are the EOSC services aggregated with lower trust than the other registries?
If yes, I am ok with this logics, otherwise I think the value "Data Source" should win over "Service" by default

If I remember well, the EOSC Catalogue does not tell (yet) if a service is a data source or not. Are the EOSC services aggregated with lower trust than the other registries? If yes, I am ok with this logics, otherwise I think the value "Data Source" should win over "Service" by default
Author
Owner

The Datasource deduplication is performed beyond this logic and I don't think we are going to exploit it to build a representative record whose attributes are actually set according to the trust. So I propose to get rid of any specific businness logic and limit the implementation to invoke the super.mergeFrom() method.

The Datasource deduplication is performed beyond this logic and I don't think we are going to exploit it to build a representative record whose attributes are actually set according to the trust. So I propose to get rid of any specific businness logic and limit the implementation to invoke the ```super.mergeFrom()``` method.

You are right, Claudio. We can assume that the data sources enter the graph in the final good shape and the mergeFrom method is not expected to be called by anyone.

You are right, Claudio. We can assume that the data sources enter the graph in the final good shape and the mergeFrom method is not expected to be called by anyone.
claudio.atzori marked this conversation as resolved
claudio.atzori added 1 commit 2022-05-03 10:43:28 +02:00
claudio.atzori added 1 commit 2022-05-03 11:45:16 +02:00
claudio.atzori merged commit 2f960f6a18 into master 2022-05-03 11:45:40 +02:00
claudio.atzori deleted branch datasource_model_eosc 2022-05-03 11:45:50 +02:00
Sign in to join this conversation.
No reviewers
No Label
No Milestone
No project
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: D-Net/dhp-schemas#16
No description provided.