search

coar-repositories / registry

Design documents for an international registry of repository systems.
1 stars 0 forks source link

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 4 years ago

fsummann commented 4 years ago

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!

paulwalk commented 4 years ago

what is the benefit they are trying to achieve?

fsummann commented 4 years ago

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 commented 4 years ago

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

fsummann commented 4 years ago

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 commented 4 years ago

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

fsummann commented 4 years ago

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

paulwalk commented 4 years ago

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)?

fsummann commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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