Date


Time: 15:00 (CET)

Meeting link https://tib-eu.webex.com/meet/georgy.litvinov

Attendees

Agenda

  • Meeting notes
  • Meeting schedule
  • Planning
  • Previous agenda

    • Access control

      • Search endpoints

    • Endpoint/procedure isolation

    • N3 Template substitutions with array of values
    • Reports

Meeting notes (transcribed automatically)

Georgy: We can just discuss it. So, first as always I'm going to make that transkriptions. So this call will be audio recorded and than I'll use it for transcriptions.
Than I suppose we should meet also twice month, so every two week. I suppose...If that's ok for you, right?

Ivan: Everything. That's last year.

Georgy: Ok. Great, great. And nothing it's should be good for me. So far this week, because it was a first week for me after holidays I was beasy with some other stuff and yeah, I didn't work much on these items we discussed last year.
But I think we especially if Dragan come could discuss some planning what are we going to do this year because I remember Dragan wanted to merge Dynamic API finally in to Vivo main brunch.
Yeah, and we need to decide what do we need before that other than. Yeah, thinks that we already discussed. Do you know maybe something from Dragan about that? So, have you discussed that? 

Ivan: Well, not really. I know that he talked about merging Dynamic API, but not really specifying anything how we would like it to unveil.
From my opinion, I think we are pretty close to have like a perfect crowd operations for entities that we were working on.
I think the only bug that is left now is one regarding entry template substitution of our values. And I think I see in the agenda that we're going to talk about it today.
And if it is fixed or when you fix it, I think we will have working CRUD operations.
But regarding the procedure pool and some other problems, I think, in my humble opinion, is that we can merge it first and then in the next iteration is the next release candidates upgrade the procedure pool to allow multiple values for names 
of the procedures and so on.

Georgy: Ahh, you mean that topic to isolate procedures into graphs, into separate graphs...

Ivan: Yeah, you talked about it last year. And yeah, I think that is one of the necessary, I mean, not necessarily, but real quality of life improvements that we should do.
But for the first version, I think the one, how is it now? The state now is okay.

Georgy: What worried me last year as I remember, was that if we merge it into the main and than make a release than on some next iterations if anybody would like to use this API, create there procedures, 
endpoints and if they would continue to use (how I would call it...) send bald graphs, that we use now, so there everything is one place.
I think that at some point and I think really fast you would like not to load anything from this graph. So we would like, you know to use it as same box but not load will procedures.
So in this case we would have to depricated and yeah, thinks might get ugly for endusers. 

Ivan: But how long do you think would switch to isolated graph stake? 

Georgy: Yeah, in that's why I wanted to dicuss it here, because what I know is that we would need to create a graphs, right? So we would need to create different graphs and that shouldn't be really complicated.
That I think one component but we also planned since last year and that was a planned for last year autumn and that was postpone to update our Jena dependency.
And depends on priority so do you want to first update the Jena, dependens which is quite big, because we will have to remove all sdb code from Vivo and update everything and test it and things quite different in new Jena than an old one.
So that could be just a dependency that we will have to deal first or maybe we will postpone it once again. We'll see. I don't know, I think that depends on Dragan's plan.

Ivan: There is something we need to discuss with Dragon, that is really a big thing.
In my opinion, I think we should first solve the dependency problem and then after that move to implement the isolation of the graphs and then maybe merge it into the next release candidate or the one after this one.

Georgy: Yeah, yeah, maybe. Because this old Jena it's not only has a lot of end the amount of volnurabilities as growing. Of course, because it's not supported since a few years now. 
But also it has some very ugly bugs for example than you try to use the Sparcle query and sort on labels, so sometimes the comporator that implemented in the old version of Jena fails so you don't have a responce you get exeption instead and
that depends only on the date not on your query but on the date that's in system. So as you see you had have very good queries but at some point system could randomly crash and that's not kind of foundation we would like to work on.
And that was fixed so I made an issue for Jena and that was fixed I think some time like a year ago but that was Jena 4 points something and now there are going to release Jena 5 and they are going to drop a lot of Jena funktion.
So I think it make sense to wait for us for a month at least, right? But I think we want started and than migrate to Jena 5. They also updated dependency of Java to Java 17 I suppose. So that's good to it, I think. It should be faster. 

Ivan: Yeah, I don't think we will have a lot of problems.

Georgy: Sorry

Mark: This is one I have also seen where you mentioned Gen 5 and I think you will need to update to a newest version of Java like 17 or 11 I think.

Georgy: 17 for Jena 5. They plan to have 17 but there are a lot of features they have. For example do implast here they created two graph implementation. So for different use cases. So some graphs are made for huge amount of data and efficient at that case,
some ggraphs are very efficient for memory, so they have procent cons of course, but as I looked at the tests the performance improved and thats what I think we would like to use in Vivo.
Yeah becaus performance is not the best side of linked data aplications. Yeah Mark I was ask to right today so I'll ask you I was asked today: Is there what's the progress with reporting tool because one user of reports asked what's happening there.
And I didn't know what to say.

Mark: Okay, I can tell you it has been a bit of stale since like end of the last year.
To them, maybe you can say like, yeah, we are fixing and everything and everything.
I think, so I didn't really have any time recently, but currently I will finally, I think, go there, see what should be done, see your latest dynamic API, because I, like if everything is working on this side or not they will tell to you.

Georgy: Ok

Mark: and yeah maybe in next week starting next week I will try to create some pull request to draft on the Vivo side and then I think people will see and we can discuss it.  yeah.

Georgy: I see. Great news. Also I answered than on my side so on the side if we are going to update this graph isolation I suppose we would like to create different graphs for reports. What do you think about that?
So that each report would reside in a separate graph because report is a functionality and maybe somethink that users can share.

Mark: Okay, but what benefits will it give to us if we will have isolated graphs?

Georgy: So the main idea of isolated graphs...

Mark: Security?

Georgy: I don't think it's real bring us security but safety, safety because you can by mistake for example if now in this shared graph you create some properties or remove some properties that related to many endpoints that everything will break.
And you want be able to you know put it back without turning down the instance. Instead the idea is to have this separate graphs because they are separated so they don't need any other triples to get the endpoint up and running. 
The same with report because each report works as a procedure so in that case if anybody you know does some not safe in the dynamic API shared graph than it want break any reports a thing like that.

Mark: No?  Uh-huh.  Well, yeah, it sounds like it's only have the benefits to the user side until us. 

!!!Georgy: Yeah If you my . I'll find...what I was asked today in maybe ask you once again. So he asked about organisation of reports in subfolders. I don't know was that ever even discussed.

Mark: I think, yes, I think it was just as a start when we, the last year, May or June, somebody mentioned it and we also maybe also mentioned it.
Yeah, it's more, I'm not sure.  So if making subfolders requires some functionality from the backend side, like providing some groups or new labels, or it can be done only on the frontend side. Then I think it can download on front-end side, right?
Like just create some folder, place everything inside, but not really.

Georgy: It will need something so we need some information about this report. So like it's priority maybe some wait how iy should be sorted. Yes, what's I think. So something like that so not much configuration but of course that will
change the request and the endpoints, right?

Mark: Yeah.  Okay.  If, if it sounds like that, then maybe just to postpone it a bit or later and say, yeah.  Okay.  We'll see if this is possible.  So on and so on.

Georgy: Yeah and also he asked about being able to asign rights for certain report or certain user groups. At the moment only admin can run reports. So was that also discussed, know?

Mark: Um, I think maybe just briefly and also between, uh, people who are working on this dynamic API, since if I remember, we are a bit connected to, we have already this, we're discussing the new, uh, new access, uh,
so like people have something currently and we are not, and you have been done. If I remember some work here that you said, it's, uh, there should be some new... you access a role management system.
So if, if, uh, and I think it's mostly on the backend side, this question to have some roles and to access it. And just on the front end side, definitely there will be some like, uh, yeah, I'm sending you a role. 
I have a role of this. Check it. And if I have the nexus.

Georgy: Yeah and that brings I think on the last meeting last year Dragan asked this question so do we want to check permissions on each procedure or only once when we run it.
And for that case that we discussing right now so there is endpoint that you could use to get the list of reports and one endpoint to run any report because you just provide URI of the report, right?
But in that case we would need to check the permissions inside execute the procedure.

Mark: ...like the request or procedure, I think, uh, yes.
So maybe we can achieve some similar solution where for each request for each procedure, we provide some authorization. That's normally, I guess, how they use it with a rest and everything, where you have some rest, you try to send some requests.
It doesn't matter get or post or anything. And it checks if you have permission for this request. If yes, then it just gives you back the result.
If there is something else, maybe. 

Georgy: In our case we have this shared endpoint that right now it can have permission to allow acsess to admins but you can add distinguish between the reports inside so for some reports if as this user ask for some reports you want like to allow 
to executed only for some special user groups and for all other reports for admins that would be complicate. So in that case we would need to check it in internal procedure which is the report, right?

Mark: Yeah. Yes.

Georgy: So that's something that we need to think. That's I think very good user story that we can use to think how to extend this authorisation and aline it with atribute based access control because right now yeah we have two access control, 
so one is homemade in Dynamic API and another is a new one this atribute based in main VIVO already. Yeah and I don't know did you any way have time a review this pull request about private individuals? 
No? Ok. Yeah there was some fixes and there was, I would say, more advanced way to access policies because in policy... in policy templates, I'm sorry, because for policy templates for different groups we need to be able to specify this permission.
That was something complicated and if you find time to rewiev the pull request and have some questions I would happy you know to discuss that. Yeah
Ok. So I don't have much progress with search endpoints. I wanted to have a look at that in the main VIVO so in old implementation of endpoints because right now and I think that's related to this private individuals sore.
I would even called it high sensetive information in VIVO pull request so right now but using maybe you have seen in custom entry forms there are some forms when you can use out to complition, right?
Have you seen something like that in VIVO?
No?

Mark: On a, on a search form, right? On a search form.

Georgy: No at search form when you try to enter some data, so for example you go to publication and you want to add then author and you write the first letter !!!! the author and after third letter it will use ajax request to send it to the server 
and find a suggestions for you. But the problem is... 

Mark: Yeah, I think I have, I have seen something.

Georgy: Sorry?

Mark: I have seen something. Yeah. Yeah.

Georgy: Yeah. But the problem is at now we are you know trying to hide some sensetive data in VIVO and there are multiple requests from multiple pupels about that. And this endpoints for authocomplition they basically...they don't check any authoresation.
So once you are authanticated as a selfeditor or anybody else you're able to use this endpoints and than buy providing name of the class... of any class you are able to read labels of basically any class by using this authocomplitions.
And I guess that something that we would not like to hide the same way it was done for the data in the search index. For the search index if you don't know there was a pull request think last year that provides the way for you to define filters 
that  could be assigned as a default filters for each user role. So for all, for admins, for selfeditors, for public role, of course. And because you are able to apply this filter and not even show it anywhere than you are able to filter out information 
that from the user role can get from the search index all. That's also way to hide sensetive information yeah for different roles. And we don't have that thing in any other search endpoints, so we have other endpoints basically use search index 
but they not applying that so we have this !!!genric search page that does that but for things like authocomplition it doesn't work. As you maybe know there are some other endpoints that VIVO uses to schow the list of individuals on the page.
So the inviduals are only show on there are not query it from sparkle there are query from the Solr. And that also a consern because if some of the individual is hidden it's still will be in the list, right now yeah if you click on that individual
you go to the page you want be able to see the page if the page is hidden but still you are able to see some labels at you might need to hide. Yeah and yeah if we would have search endpoints done in Dynamic API it would be in one place, it would be 
central I so you would just rewiev some procedures here and apply the same rules but nowdays in VIVO it's all in different servlets, different endpoints and yeah that's complicated.
So that's why I asked you at the start of the meeting do you have any plans so maybe implement some new components for Dynamic API like Solr component or maybe Elastic search or things like that.
For example one of the components we planned two years ago is just component to make requests to external services for authority services for example than you have some vocabularies on the external server and you would like to reuse this vocabularies.
So, know? Not many plans to...

Mark: I guess currently no, but then maybe after a few minutes, we will at least understand what has to be done and maybe at least define the components that we need.
As you said, Elasticsearch, Solar Components, I don't know what should be done there because I think currently it's too much. It's too vaguely for us.

Georgy: Yeah. The third one is basicalli HTTP client because I think HTTP client would be enough to query a lot of information from for example Open Alex !!!even. If you want to ingest some data in to VIVO about profiles, about user publications that
would help too. Yeah, but the time of course, pressure time. Yeah so what's else. So we discussed meeting notes, that's it will be transcribed schedule, planning not much planned for all of us. For me it's the same so I have a other project right now
once I have time I will get to this graph isolation and other components but so far I'm quit busy at this point so yeah. We're in the same spot here. So I don't have much else to discuss today. Do you have any other topics? Nope? So it was nice to meet you
on the first meeting this year. Have a nice day. Have a nice weekend.

Mark: Have a nice weekend all.  

Ivan: Have a nice year. 

Georgy: Yeah. See you. Bye bye.  

Ivan: See you. Bye bye.

All content on the LYRASIS Wiki is licensed under the CC BY (Attribution) license, unless otherwise noted.