Date
Call-in Information
Time: 10:00 am, Eastern Time (New York, GMT-04:00)
To join the online meeting:
https://lyrasis.zoom.us/j/84378615572?pwd=bGUxSjlyRTdjOGl5U1B6L0Yva3RQdz09
Meeting ID: 843 7861 5572
Passcode: 556561
One tap mobile
+16699006833,,84378615572#,,,,*556561# US (San Jose)
+19292056099,,84378615572#,,,,*556561# US (New York)Dial by your location
+1 669 900 6833 US (San Jose)
+1 929 205 6099 US (New York)
+1 253 215 8782 US (Tacoma)
+1 301 715 8592 US (Washington DC)
+1 312 626 6799 US (Chicago)
+1 346 248 7799 US (Houston)
877 853 5257 US Toll-free
888 475 4499 US Toll-free
Meeting ID: 843 7861 5572
Passcode: 556561
Find your local number: https://lyrasis.zoom.us/u/kerqtGDrJ4
Slack
- https://vivo-project.slack.com
- Self-register at: http://bit.ly/vivo-slack
- Self-register at: http://bit.ly/vivo-slack
Attendees
Indicating note-taker
- Dragan Ivanovic
- Brian Lowe
- Georgy Litvinov
- Michel Héon
- Benjamin Gross
- Fadwa Alshawaf
Agenda
- Questions/Issues/Pull requests/Announcements
- DSpace-VIVO integration
- The February sprint
- Completion of PR reviews
- Resolving dependency conflict
- Creation of a PR for main branch
- Preparation for the Dynamic API demonstration meeting - https://docs.google.com/presentation/d/1EiVyBeXYgX363ykAmP6OKgfnorsUdkLdorPCYnmjGiA/edit?usp=sharing
- Update of the Roadmap - https://docs.google.com/document/d/1hJSWAa3ENoFOYyp0GyvDqBdehra3AmFBAD9X2dX3cSo/edit?usp=sharing
Notes
Dragan: I don’t have any news for this week. Maybe after this meeting we will be able to announce a date for demonstration.
DSpace-VIVO integration:
Dragan: Michel, can you briefly create some introduction in the project.
Michel: OK. We have a page on Lyrasis WIKI DSpace - VIVO integration task force, some of them about calls. Everything is available for everybody. The goal of the project is described on wiki. We are working on using DSpace in the VIVO environment. This is the metamodel to migrate data from DSpace to VIVO. Approach is based on model driven development methodology. From the created metamodel we can generate some schema of the model. We are using OpenAPI technologies. With OpenAPI you can generate client and server in multiple languages and have a capability to generate java code from the model. This java class can be used as a JSON serializer. DSpaces teams working on extractor arrow and mission of this to extract data from DSpace and format based on metamodel. For the VIVO team, the mission is to translate from the metamodel to Turtle representation to upload in the VIVO triple store. To do that process we need to transform data from JSON and save it in Turtle format before putting it in the VIVO triple store. We also have. We have project DSpace-VIVO in Github, we have 3 branches. Just below DSpace to VIVO metamodel and there is a schema that provides manipulation with data. The first high level structure is a repository, a community for representing library, institutions. Community points to a set of collections and these collections encapsulate a bunch of items that are in DSpaces. Because we are using swagger it is easy to generate models of the model (JAX-RS). This mission is extracting data from DSpaces to Model, it is a contract. All the code is on GitHub. If you go further in a notes, you will see DSpace ontology. It is a representation of the structure, for mapping we need matching DSpace ontology matching VIVO. This is the state of this DSpace Ontology.
This is the same model structure as in yaml. It is not just dummy data and this is where we are right now. It is processed via java class. This is a JSON representation of a repository.
If you look inside VIVO UI you will see this type of data, but before that we need to integrate the DSpace object inside the administration side of data input. For the next week we will need to work on representation of data in VIVO.
From my part all the pipelines are up. We will have to discuss how we will implement the pipeline after that. We will need to decide about that later, how we are going to call this new pipeline.
Dragan: How is the DSpace item linked with VIVO? Is the DSpace item a new entity?
Michel: It is a metadata of the item you put inside DSpace. There is no metadata to identify things pushed in DSpace. We need to establish a mechanism for how we are going to identify data inside of VIVO.
William: How is metadata schema defined? Are you going to inspect the registry on the items itself?
Dragan: In DSpace could be a metadata registry, it is some kind of localization.
Michel: This is kind of information that is directly injected in VIVO. So for now you can declare a statement inside a metamodel and inject VIVO. If VIVO doesn't know how to manage the statement, then the UI will do nothing, but the statement will be inside of VIVO.
William: Is there going to be some automation process?
Michel: When you create new things inside of VIVO, VIVO creates a bunch of triples, so when translators translate data from DSpace to VIVO, then it generates other triples that need to represent data inside of VIVO. Transformation process does two things: interpret data to conform to VIVO and directly takes statements and puts them directly inside VIVO.
William: Everything from DSpace will get to VIVO triple store?
Michel: yes.
William: How they are going to be linked with VIVO entities.
Michel: It is a big problem to create a match.
William: We might use ORCID and other identifiers in efforts trying to match data. I don’t see much value in loading all the data without linking it to VIVO entities.
Michel: The idea behind that is to give VIVO all the capability DSpace does. If you make some metadata declaration we need to have this type of data inside of VIVO. That’s why we need to have this data inside of VIVO.
William: How are we going to link data?
Michel: If in DSpace you have a declaration, so you can declare that in DSpace and use this declaration is VIVO later.
William: For existing implementations of VIVO and DSpace. DSpace is a user of symplectic elements.
Michel: DSpace 7 is broken in two packages. At the end it would be very nice to have VIVO as a frontend of DSpace.
Michel: If you have VIVO as a frontend, you can make a query on data and metadata of DSpace.
William: DSpace 7 has an endpoint.
Michel: It is not compatible with VIVO ontology, there is a mistake in how they create uris. We need to fix these uris.
William: It seems like we are growing code, not functionality. What is the goal of having so many microservices? It seems like a lot of features have been attempted.
Michel: Inside our University. The fact is that DSpace is not part of semantic web technology. We have an interest in improving DSpaces to be part of semantic web. So we can do a lot just by converting data from DSpace to VIVO.
William: Are we going to configure VIVO to be compatible with multiple repositories?
Fedora is keen on PCDM.
Michel: Fedora is based on a semantic web, you only need to make a transformation map. Extraction step is not easy, it is a complex job to do.
I think it would be really interesting to have SPARQL Endpoint.
William: I think there will be a lot of issues with this.
Dragan: I think that data from DSpace should be integrated with VIVO to make some benefits. If we use MDD it might be used for other repositories. It would be really nice to have that option.
William: I would pull links from DSpace and use them in VIVO.
Michel: How many records can you have in the DSpace repository?
William: Wild guess might be ~115 000 items. It would be great to link datas between VIVO and DSpace.
Dragan: We will be updating about our progress regularly.
February Spring topics:
We need a review for 3 Pull requests.
Dragan: Please review these PRs.
William: I will resolve the problem with my PR.
Dragan: After all PRs are resolved we will discuss in the committers group how to deal with that branch.
I am not sure it is clever and well to demonstrate it to a wider community. I prepared a couple of slides for demonstration. So at the moment we have a draft version of the engine.
It would be great to demonstrate OpenAPI specification generation.
I have two API endpoints: for dynamic action and geolocations. The reading of geolocations is reading all instances of this type.
I want to add some countries and verify that countries are added.
After that I would like to present a generation of OpenAPI Specification.
I want to show that we will be able to create a UI for actions.
When do you think it should happen?
William: My thought is to demonstrate it to the steering committee. It is nice.
One note is to use Swagger UI instead of Postman.
Dragan: If we create new action can we then see the documentation after that?
William: Yeah.
Dragan: Hopefully when this problem will be completed this week we can announce a demonstration. Hopefully we will resolve what we started.
Benjamin: Leadership group would need some context, some explanations about this goal.
Dragan: Plan is to demonstrate this next week on Thursday March 31st at 10 am Eastern Time.
