-
Notifications
You must be signed in to change notification settings - Fork 0
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
Comments
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! |
what is the benefit they are trying to achieve? |
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 |
Yes, that's the function. We just need to identify the benefit (i.e. why do we care?) |
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. 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 |
So, is this more about standardising the metadata held in the registry? |
Standardiszing the communication and using the same metadata schema would be a detail aspect. |
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)? |
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 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 |
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? |
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. |
OK, agreed - I will move this to "deferred" for this project, but will raise this as an issue more generally in the COAR context. |
No description provided.
The text was updated successfully, but these errors were encountered: