[Datasource / Service] datasource_model_eosc #16

Merged
claudio.atzori merged 9 commits from datasource_model_eosc into master 2 years ago
Owner

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 2 years ago
miriam.baglioni was assigned by claudio.atzori 2 years ago
claudio.atzori added 7 commits 2 years ago
Collaborator

To me the PR can be integrated

To me the PR can be integrated
alessia.bardi reviewed 2 years ago
pom.xml Outdated
@ -7,3 +7,2 @@
<packaging>jar</packaging>
<version>2.11.34-SNAPSHOT</version>
<version>2.11.34-eosc-SNAPSHOT</version>
Owner

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

Is this the expected version that must go into the beta branch?
Poster
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
Owner

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
Poster
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.
Owner

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 2 years ago
claudio.atzori added 1 commit 2 years ago
claudio.atzori merged commit 2f960f6a18 into master 2 years ago
claudio.atzori deleted branch datasource_model_eosc 2 years ago
The pull request has been merged as 2f960f6a18.
You can also view command line instructions.

Step 1:

From your project repository, check out a new branch and test the changes.
git checkout -b datasource_model_eosc master
git pull origin datasource_model_eosc

Step 2:

Merge the changes and update on Gitea.
git checkout master
git merge --no-ff datasource_model_eosc
git push origin master
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
Loading…
There is no content yet.