Welcome to the EOSC Future wiki!

IMPORTANT: Please be aware that this Wiki space is no longer actively maintained. The information in it applies to the discontinued EOSC Marketplace and Provider Portal, which have been replaced by the EOSC EU Node.
Information related to the EOSC EU Node is available via the official page <here>

TitleResearch Products Accounting: Architecture and Interoperability Guidelines
URI

https://zenodo.org/record/8362353(this is the newest version) 

Revised version links
Link to Metadata
Date Issued to EIAC02.05.2023
Submitted byDimitris Pierrakos (OpenAIRE AMKE) and Paolo Manghi (OpenAIRE AMKE)
Outcome of EIAC reviewendorsed, 22.08.23
Date Issued to EIAB22.08.23
Outcome of EIAB review
On portal?yes, published 29.09.23

Overview

The proposed document has been submitted for inclusion in the EOSC Interoperability Framework. 

Comments should be made either on eiac@eoscfuture.eu, where they will be archived for future reference or added to the change log below.  Comments posted to other discussion methods will not be included in the review.

Statements of Support/Deny

All members of the EIAC are encouraged to make a statement of support or dissension in consideration of this proposal.

Name

Organisation

Support or Deny

Reason (if denied)

Jorik van KemenadeSURFsupport
Paul Gondim van DongenSURFsupport
Sabeel Shah
support




Comment/Change Log

Please fill in any comments or proposed changes below or add them as issues on the github repository.

Number

Current Text

Proposed Text / Query

Commenter

Action

1Section 3: The service forms metrics of usage activity of EOSC Data sources, categorizing the data retrieved by number of downloads, number of views, number of repositories and all derivative quantitative open metricsCould this be integrated in section 2?Paul Gondim van Dongen (SURF)OK
2Section 4: High-level Service ArchitectureIt can be clearer if the components are described before the workflow.Paul Gondim van Dongen (SURF)OK
3Section 10: Interoperability GuidelinesI noticed that in other guidelines this section has a paragraph describing its purpose. Could be better for clarity if there was one here too.Paul Gondim van Dongen (SURF)OK
4Section 10.1.1: A set of parameters are required for the configuration of the software above, which are summarised in the Table below:Are there parameter sets documented elsewhere too? If so, would links to the original location be easier to maintain?Paul Gondim van Dongen (SURF)OK
5Section 1: Intended AudienceCould this section be a little bit more textual, so that these groups have an idea of what to expect from reading the document?Paul Gondim van Dongen (SURF)OK
Section 2: Description and main featuresIs EOSC Research Products Accounting service == OpenAIRE  UsageCounts service ? this is not clearAndrea Manzi(EGI Foundation) OK
7Section 4: High-level Service ArchitectureWorkflow description moved before the figureAndrea Manzi(EGI Foundation) OK
Section 9: Integration ProcedureIt's not clear which steps are belonging to the push workflow and which ones to the pull workflowAndrea Manzi(EGI Foundation)OK
9Section 10.1.2: PULL Workflowbetter to refer explicitly to Table 2Andrea Manzi(EGI Foundation)OK
10Section 11: Examples of solutions implementing this specificationIt would be better to add also a small paragraph for the 2 services implementing the specification instead of only including the figuresAndrea Manzi(EGI Foundation)OK
11Intended AudienceAdd: “This interoperability guideline is intended for adoption by”Andreas CzerniakOK
12Description and main featuresMaybe a small elaboration on what is considered an (EOSC) Data source would make things clearer. Just a suggestion.Thanassis MantesOK
13Licensing InformationCC ATTRIBUTION 4.0 INTERNATIONAL LICENSELink/reference to it would be niceThanassis MantesOK
14Integration ProcedureSteps are listed in order, so I suggest it would be better to be numberedThanassis MantesOK
15Related Guidelinesadd linksThanassis MantesOK
  • No labels