Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

As a data or service provider for metadata on repositories I want a defined interface (a kind of protocol) to exchange this kind of data in both directions in order to make the exchange of data easier #25

Open
fsummann opened this issue Dec 6, 2019 · 12 comments
Labels
question Further information is requested user-story User Story

Comments

@fsummann
Copy link

fsummann commented Dec 6, 2019

No description provided.

@fsummann
Copy link
Author

fsummann commented Dec 6, 2019

This should make the connectivity between all the related stakeholders easier and I address all the different kind of registries, community lists, national lists, network lists, host service lists as re3data or the planned CRIS registry and many others. Discovery would become easier!

@fsummann fsummann changed the title As a data or service provider for metadata on repositories I want a defined interface (a kind of protocol) to exchange this kind of data in both directions As a data or service provider for metadata on repositories I want a defined interface (a kind of protocol) to exchange this kind of data in both directions in order to make the exchange of data easier Dec 6, 2019
@paulwalk paulwalk added the question Further information is requested label Dec 6, 2019
@paulwalk
Copy link
Contributor

paulwalk commented Dec 6, 2019

what is the benefit they are trying to achieve?

@fsummann
Copy link
Author

fsummann commented Dec 6, 2019

Some of the mentioned registries (OpenDOAR, re3data) deliver APIs (with different settings) and most of the others act proprietary (mostly html lists). To get the information in a standardized way would make the exchange and communications (naturally for automatic purposes) much more efficient

@paulwalk
Copy link
Contributor

paulwalk commented Dec 6, 2019

Yes, that's the function. We just need to identify the benefit (i.e. why do we care?)

@fsummann
Copy link
Author

fsummann commented Dec 6, 2019

The benefit for all information exchange stakeholders (and I see the COAR IRD as one of them or better on top of all this data providers) is: getting and delivering the relevant information is easier, more information is availabe and I expect this influences the quality and reliability and comprehensiveness of the repository metadata.
It is valid for delivering the IRD information back into the community (mentioned in some of the issues) as well.

My idea is: the players in our group (NII, La Referencia, OpenDOAR, Core, BASE, re3data agree on some specifications and try to implement them at least in their communication related to this initiative

@paulwalk
Copy link
Contributor

paulwalk commented Dec 6, 2019

So, is this more about standardising the metadata held in the registry?

@fsummann
Copy link
Author

fsummann commented Dec 6, 2019

Standardiszing the communication and using the same metadata schema would be a detail aspect.

@paulwalk
Copy link
Contributor

paulwalk commented Jan 6, 2020

This seems to require that the registry be able to accept incoming data from service providers, which is a fundamental requirement. If the registry is a read-only system (from the point of view of service providers which use it) then this is a advantageous in terms of the possibilities for providing low-cost responsive interfaces.

Or is this more about adopting a community convention for how the data can be read from the registry's API(s)?

@paulwalk paulwalk added the user-story User Story label Jan 6, 2020
@fsummann
Copy link
Author

fsummann commented Jan 9, 2020

I would like to adress the bi-directional view and that can help the IRD in two main aspects:

It would be helpful for the IRD (and its sub-deliverers of data) if the spread information on repositories could be checked and ingested on a more reliable and efficient way. Currently we have lists (NII, HAL, the German DINI, the Swedish DiVA, Norways BRAGE, OCLCs OAIster, Islandora, DSpace and many others) of related repositories, or more or less specific APIs (OpenDOAR, re3data) which can be observed and checked automatically (by the COAR IRDs and others)

If this data communication procedure could be made more standardized it would help collecting
and checking (repositories disappear or change some of their atttribute more often) for every interested stakeholder and especially the IRD (or the instance which collects for the COAR IRD).

On the other side the re-distribution of data from the IRD would be made easier because this service can use a standardized way which makes it easier and efficient to be used.

So related to your last question: It adresses incoming data but also the outgoing data and in deed
it has to do with a communication convention.

@paulwalk
Copy link
Contributor

paulwalk commented Jan 9, 2020

So, if I have understood correctly, this is more about establishing a standard/convention for information exchange between the IRD and the systems from which it consumes data (repositories) as well as the systems to which it provides data (services).

I agree that this would be very good to have... but I'm not convinced that this can be added as a requirement for the IRD itself (i.e. for this project).

It seem to me that we might be advised to develop this idea separately, perhaps as a separate COAR initiative?

@fsummann
Copy link
Author

fsummann commented Jan 9, 2020

No problem for me. I think this is a very convenient time to discuss and perhaps make the first steps to optimise the situation. Many of the stakeholders are talking in this COAR activity about it and could support implementing it.

And it would make the IRD implementation much more efficient, flexible and transparent.

@paulwalk
Copy link
Contributor

paulwalk commented Jan 10, 2020

OK, agreed - I will move this to "deferred" for this project, but will raise this as an issue more generally in the COAR context.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested user-story User Story
Projects
None yet
Development

No branches or pull requests

2 participants