3:05 PM Maggie Hellstrom:
Peter's slides: https://www.rd-alliance.org/sites/default/files/web-workshop-intro.pptx
3:05 PM Maggie Hellstrom:
Giridhar's slides: https://www.rd-alliance.org/sites/default/files/Manepalli-webworkshop-doip.pdf
3:06 PM Maggie Hellstrom:
Rob's slides: https://www.rd-alliance.org/sites/default/files/E-RPID-Webworkshop-case-study.pdf
3:07 PM Maggie Hellstrom:
DOBES slides: https://www.rd-alliance.org/sites/default/files/dobes-webworkshop-case-study.pptx
3:12 PM Andrew Treloar:
The list of slides that you can edit, and the slideshow are two different windows. You are sharing the wrong one
3:22 PM Stian Soiland-Reyes:
q: Where/how are types defined?
3:28 PM Stian Soiland-Reyes:
this sounds alot like https://swagger.io/docs/specification/basic-structure/
3:38 PM Stian Soiland-Reyes:
Q How do the default operations compare with: https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods
3:41 PM Stian Soiland-Reyes:
https://www.w3.org/TR/ldp/ shows a structured way to use such collection operations using HTTP
3:51 PM Stian Soiland-Reyes:
Q: how are the indirect references to the larger audio recording bytes included? Are they also DOIs?
3:53 PM Maggie Hellstrom:
The DOBES approach to metadata for their "bundles" (collections) doesn't seem to be compliant with the recommendations of the RDA Research Data Colections WG. This is of course no problem in itself, but how important will it be for future DOIP-implementations that this type of (global) recommandations are followed?
3:59 PM Stian Soiland-Reyes:
( https://doi.org/10.15497/RDA00022 )
4:14 PM Maggie Hellstrom:
During the work with the RDA RDC WG, ePIC people were looking at implementing the group's collection metadata schema and/or layers of operations on top to allow operations on the collection (search, access all members etc.). I'm not sure that this would have involved using CORDRA or not, but in any case the recommendations (linked above) are a good read for anyone wanting to implement machine-actionable DO collections...
4:19 PM Stian Soiland-Reyes:
DO for types is similar to URIs for XML name spaces, JSON Schema's $id HTTP URIs, and RDF/OWL use of ?HTTP URI namespaces. The important extra bit here is the "type registry" so that they are also Findable (and thus can reduce re-inventing types)
4:21 PM Martin Schultz:
Regarding the discussion on Peter's slides, I am wondering if we really get an advantage with DOIP services compared to standard web processing services. Imagine a web processing service, which offers 1000 or more operations (for example all kinds of slicing and trimming of geodata plus operations for averaging and other aggregations across any dimension). If this services goes out of operation or changes its location, you need to update one URL in a service registry. With DOIP you would need to update 1000 service endpoints. The danger is thus that we get more garbage.
4:22 PM Peter Wittenburg:
Martin: this is exactly the point. DOBES would have to make an effort, what is the gain. We need to work this out in more detail.
4:23 PM Stian Soiland-Reyes:
+1 - but I hope the DOIP is not meant as a replacement for SOAP etc. for "doing anything", but mainly for data access in which cas ethe operations should mainly stay general or domain-oriented
4:24 PM Peter Wittenburg:
In EUDAT we had enormous problems with different types of repositories. Where is the GOLDEN inerface standard?
4:25 PM Peter Wittenburg:
NO - for sure DOIP is not a replacement for SOAP. It could be channeled via SOAP or REST whatever you like.
4:25 PM Stian Soiland-Reyes:
(that is what SOAP said.. https://en.wikipedia.org/wiki/SOAP#Transport_methods )
4:26 PM Maggie Hellstrom:
We will need a couple of very well-documented "demonstrators" that data managers of larger projects can investigate in detail - both to understand advantages & disadvantages compared with the current solutions, and to estimate costs & resources required to put the DOIP layer in place.
4:26 PM Thomas Jejkal:
+1
4:27 PM Stian Soiland-Reyes:
I would focus on mapping to the other protocols rather than wrapping - kind of like in the LDP spec which just says how you should use HTTP for that particular purpose. Then wrapping is only needed when something is unnatural in that protocol.
4:27 PM Mark van de Sanden:
I see advantages to have a standardised API for repository technologies, but this API should be supported by the Technologies and Technologie providers. It should not be that the repositories owners should develop these interfaces to the technologies. This will cost to must effort.
4:28 PM Stian Soiland-Reyes:
https://swordapp.github.io/swordv3/swordv3.html is more like that now compared to v2
4:28 PM Martin Schultz:
It's just that at some point you are going to hit the anti-interoperability wall, no matter what you do. I like the way of thinking in DOIs and DOIPs, but I am sceptical that this concept can be implemented, or rather that any implementation provides real advantages over current ways fo doing things. Yet, we need to continue discussing and standardizing. At some point, critical masses will help.
4:28 PM Mark van de Sanden:
How does DOIP compare to SWORD, which has the same aim? SWORD is supported by some of the repository technologies
4:29 PM Stian Soiland-Reyes:
I would say if you are just dealing with files and file collections then SWORD is the right abstraction level
4:31 PM Mark van de Sanden:
What are the added benefits of DOIP? within the metadata data collections and files is or can be referenced via PIDs.
4:33 PM Stian Soiland-Reyes:
If you use PIDs and manage your repos well over HTTP then you don't need DOIP. (or you could say, it is implementing DOIP already)
4:36 PM Maggie Hellstrom:
Yes, Mark's question is very pertinent. System architects and data managers will only "take the leap" to implement DOIP if they see an immediate benefit and/or it becomes what "everybody else" in the relevant scientific domain are doing. (For example because the use of DOIP becomes a strong FAIRness assessment metrics criterium, or is required by service catalogs such as the European Open Science Cloud marketplace.
4:37 PM Stian Soiland-Reyes:
that is the "stick" approach - there should also be a "carrot" motivation
4:38 PM Maggie Hellstrom:
@Stian: well, sort of - but the traditional REST API approach doesn't require you to register the operations and other details of e.g. your repository etc with a Type Registry (which gives them unique PIDs that can be used for unambiguous referencing.) That's one of the good things that DOIP brings to the table IMHO.
4:40 PM Mark van de Sanden:
I am also in favour of the carrot approach. There should be a buying from the technology providers and developers. They should develop the DOIP API on top of their technologies. This makes it easier for repository owners to enable the API.
4:40 PM Maggie Hellstrom:
To clarify: my post from 17:38 was in response to Stian's post from 17:33 ;-)
4:42 PM Stian Soiland-Reyes:
Exactly - so I think something similar to https://www.re3data.org/ with data types (e.g. JSON Schema) and OpenAPI protocols would do that well. Then a subset of those would be marked 'golden' by say EOSC for certain repositories (e.g. how datacite schema is re-used by lots of repos)
4:43 PM Maggie Hellstrom
Carrots are good, but I'm afraid that sticks will also be needed to get the ball rolling to quickly create a critical mass of adopters... (Sorry for mixing metaphors...)
4:43 PM Stian Soiland-Reyes:
say for a map type there would be a corresponding OpenAPI method set. It is this glue ("what can I do?") that is not easy to find today.
4:48 PM Aida Turrini:
I have a question as non-technique person. Is the blockchain structure compatible with the presented architectures?
4:50 PM Christophe Blanchi (DONA Foundation):
Blockchain can be used to demonstrate that the state of a DO is still the same as that added to the chain.
4:51 PM Aida Turrini:
Thank you
4:51 PM Maggie Hellstrom:
Going back to my earlier comment about demonstrators: I think it would be great to have something like a Docker image with all necessary "server side" components built in. That would make it really easy for data center people to instantiate it locally and play around with it - and then to build on the code to implement aspects of their own specific (data) services. Does this exist for e.g. the SEADTrain case?
4:55 PM Maggie Hellstrom:
Can someone post the link to SWORD?
4:56 PM Stian Soiland-Reyes:
http://swordapp.org/
4:56 PM Stian Soiland-Reyes:
v2 is commonly implemented, v3 is work in progress
4:57 PM Maggie Hellstrom:
@Stian: Thanks!
4:59 PM Martin Schultz:
Compare to very basic CRUD: these are abstract operations with defined behaviour, which have been implemented in different APIs/protocols. With DOIP we seem to be mixing the abstract definition and the API, which might lead to trouble as Mark is arguing. Perhaps one can add one more layer of abstract operations to CRUD (things that everyone does, similar to operators in programmign languages, e.g. add, subtract, ...) - but I doubt very much that "yet another standard" (thanks!) helps.
5:01 PM Stian Soiland-Reyes:
focus on best practice using existing technology, and the added value of a registry for types/protocols. Don't re-invent another Semantic Web without Web or without Semantic.
5:01 PM Rob:
https://github.com/rpidproject/puppet
5:01 PM Mark van de Sanden:
Peter, and the presenters, thank you for organising this worklshop. It was very interesting. I have to leave.