hostedbymap #136

This PR is related to ticket #5644

It build on demand a new hostedbymap by exploiting two external sources:

https://pub.uni-bielefeld.de/download/2944717/2944718/issn_gold_oa_version_4.csv - https://doaj.org/csv)

It applies the HBM on the entities in the graph, the entities involved by its application are the Datasources and the Publications.

The Datasource will be modified in the openairecompatibility field and only if its classid is set to UNKNOWN. In this case, it will be set as hostedBy, and the classname will become "collected from a compatible aggregator".

The publications that will be affected by the application of the HBM are those having only one instance. For those with journal information for which exists a match with the hbm, the hostedby information in the instance will be modified according to the information in the hbm. If in the map the journal identifier is marked as OpenAccess, the accessright of the publication will be set to OPEN and the OpenAccessRoute to hybrid. Also the bestaccessright at the level of the result is possibly changed.

This PR is related to ticket #5644 It build on demand a new hostedbymap by exploiting two external sources: - https://pub.uni-bielefeld.de/download/2944717/2944718/issn_gold_oa_version_4.csv - https://doaj.org/csv) It applies the HBM on the entities in the graph, the entities involved by its application are the Datasources and the Publications. The Datasource will be modified in the `openairecompatibility` field and only if its classid is set to UNKNOWN. In this case, it will be set as `hostedBy`, and the classname will become "collected from a compatible aggregator". The publications that will be affected by the application of the HBM are those having only one instance. For those with journal information for which exists a match with the hbm, the hostedby information in the instance will be modified according to the information in the hbm. If in the map the journal identifier is marked as `OpenAccess`, the `accessright` of the publication will be set to OPEN and the `OpenAccessRoute` to `hybrid`. Also the `bestaccessright` at the level of the result is possibly changed.

It seems that many files, not related with the implementation of this new fature got changed. In particular, ISSN (uppercase) got replaced with issn (lowerase) in many files that have nothing to do with this PR. Please check and revert them to their previous state.
On dhp-workflows/dhp-graph-mapper/pom.xml I see a new dependency:

<dependency>
   <groupId>com.opencsv</groupId>
   <artifactId>opencsv</artifactId>
   <version>5.5</version>
</dependency>

I got nothing against the introduction of new libraries, but two comments on this

didn't we already manage CSVs with an external library? If yes, why do we need yet another one?
dependency versions should be declared only in the external pom file, all the submodules must refer to them without specifying the version.

On dhp-workflows/dhp-doiboost/pom.xml I see a new dependency towards the dhp-aggregation. In general, common utilities neeeded by more than one submodule should be moved in dhp-common, let's try to keep the dependencies well organised.

* It seems that many files, not related with the implementation of this new fature got changed. In particular, `ISSN` (uppercase) got replaced with `issn` (lowerase) in many files that have nothing to do with this PR. Please check and revert them to their previous state. * On `dhp-workflows/dhp-graph-mapper/pom.xml` I see a new dependency: ``` <dependency> <groupId>com.opencsv</groupId> <artifactId>opencsv</artifactId> <version>5.5</version> </dependency> ``` I got nothing against the introduction of new libraries, but two comments on this 1. didn't we already manage CSVs with an external library? If yes, why do we need yet another one? 2. dependency versions should be declared only in the external pom file, all the submodules must refer to them without specifying the version. * On `dhp-workflows/dhp-doiboost/pom.xml` I see a new dependency towards the `dhp-aggregation`. In general, common utilities neeeded by more than one submodule should be moved in `dhp-common`, let's try to keep the dependencies well organised.

I have reverted all the modified ISSN on the files. I have also removed the not needed dependecies from the poms.
The new library to import csv files should replace the previous one. A new PR will follow for refactoring

I have reverted all the modified ISSN on the files. I have also removed the not needed dependecies from the poms. The new library to import csv files should replace the previous one. A new PR will follow for refactoring

Labels Milestones

hostedbymap #136

Reviewers

Step 1:

Step 2: