20180206 Ontology Change Improvement Call

Date: 2018.02.06

Attendees: Brian Lowe, Muhammad Javed, Marijane White, Damaris Murry, Christian Hauschke

Agenda:

• Review vivo.owl

• Review applicationConfiguration.owl

• Broken functionality and what to do about it

• Potential changes

Brian: It’s unfortnately been a while since I’ve been able to attend one of these meetings, can someone remind me what the goal of putting everything into one file is?

Javed: When someone asks where the vivo ontology is, we can point to it anywhere.

Marijane: Also so we can have the same file everywhere, in the source code, on the web, eventually extracted from the ISF, etc.

Javed: Brian, let me explain what we’ve did, and maybe you can help with some of the issues Mike has encountered in the app. So let me start with what we did.

• shares screen * https://wiki.duraspace.org/display/VIVO/2018-01-23+Ontology+Improvement+Meeting

Mike took all the files from the first time tbox folder and merged them using ROBOT. Then he gave me that file, filegraph.owl, and I looked into it, checked it to make sure it all made sense. The first thing I noticed that there were some A-Box level assertions in that file, which already existed in the A-Box folder. Then there were these Vitro assertions, as Mike mentioned in his email. Those annotations are now in the ApplicationConfig.owl file.

Mike added the ones required by the application back into vivo.owl to get it working.

When we loaded the new files into a new VIVO, it didn’t work. We realized we needed a file with all the definitions of the ontologies. After adding it, we can see all the ontologies in the new VIVO.

One possibility is that we put things back, the other possibility is to change the software and have it look somewhere else.

So here we are. I believe most things are working, other than these annotations.

Brian: So those are the only things that don’t work?

Javed: Yes.

Brian: It must be doing anything really bizarre, because it’s hard to imagine it wouldn’t find them. I think we should track them down and make them do whatever everything else is doing, so we don’t have to monkey with the ontology files, hopefully that won’t be too complicated to fix.

Javed: Let me look, Mike sent some snapshots. shows a snapshot of the ontology list Here you can see there were no prefixes and only three ontologies listed, which led to the ontologies.owl file. Once we added that, the full list of ontologies showed up in Vitro

Brian: So you did get the prefixes back?

Javed: Yes, but I’m not sure what Mike did?

Brian: [missed this comment]

Javed: Mike added some vitro:ontologyPrefixAnnotation assertions in the firsttime/vitroAnnotations.n3 file.

Brian: And that would be in the firsttime folder because we want them editable in the UI.

Javed: Yes, so we added these and we got the prefixes back.

And then someone has to test it. I think only Mike has tested it so far.

Christian: We have this evaluation thing going on here this week, but I talked to Anna about it and we want to have a look in the next week or two.

Brian: So are we testing from the ontology lab repo or is there another branch?

Javed: the lab branch.

Brian: OK.

Javed: The only changes are in the tbox folder.

Brian: I can’t promise I can do it right away but I can try to test it.

Javed: Yes, you have experience with both the ontology and the code, it would be nice if you could look at it.

Brian: Yes, I can try to break it.

Christian: So we can just empty out the files in the folder and replace it with the new ones?

Javed: Yes.

And I believe once it is tested by a couple of people, then we will move on to ontology change. But I’m not sure what we should do first, if we should just do one single ontology, and not change anything in the existing models, and then next version do another small change?

Christian: I think it depends on the release schedule. If we are going to have a release in the next few months, we should only release the merged file, but if it’s going to take longer we should consider adding some other changes. Mike’s not here, but we should ask him about the release date.

Javed: Yes. Last time I told him I would look for some small changes to make. Let me share my screen again and show you what I had in mind. So I’m looking for some very very minor things. One thingI saw was the affiliatedOrganization property, which has the same domain and range of foaf:Organization, why can’t a person be affiliated? So maybe we should add Person to the domain. So that’s one small thing I thought about.

Brian: While we’re on that property, can I raise the more annoying question of whether that’s a property we want to keep? Is that in our namespace?

Javed:Yes.

Brian: Do we think there might be a better way of doing that, something from the RO-BFO world?

Javed: I’m trying to change things that won’t affect anyone using the property.

Brian: I completely understand that goal, but it would be great if we could find the intersection of things that are not going to affect anybody with the things we want to keep in the long term. If there are doubts about things we want to keep, it doesn’t make sense to change them if we’re just going to remove it later.

Javed: Yes, but changing this property to something from BFO would really break things.

Marijane: Is that a pre-1.6 property?

Brian: It probably is. I’m not advocating we make a bigger change right now, just for a useful change that won’t get removed later.

Marijane: What about just adding things? Like ISNI, which Mike has been talking about for a very long time.

Javed: Yes.

Christian: ISNI could be useful for organizations.

Javed: Yes, so additions could always be good.

Brian: If the question is going to be in conjunction with the release schedule, there was an interesting thread in the Slack about potentially putting off the next software release until there are compelling features, rather than just upgrading the libraries and the software looks the same. Adding ontologies that would make upgrades more compelling to users.

Javed: We have a new theme for VIVO, I believe there are changes that they are making in the UI, and then the Jena upgrade.

Christian: But the users don’t see those changes.

Brian: My point is that if we make users make big changes without something shiny and new to give them, people may not want to upgrade. When we made the big change for 1.6, it was compelling, but everyone needed to fix their ingestion scripts and they didn’t get anything new or exciting things to go along with it. So we should consider giving them something new and compelling.

Damaris: I agree with Brian’s point that nobody will make the effort if there’s nothing new, but I thought part of this was to work out the communication process around changes?

Javed: Yes, we started this task force talking about ontology change management and how that process will work. But we realized before we do that, we need one single ontology file. So I think we are just trying to take things one step at a time, make sure the A-box and T-boxes are separate. One that is done and good, we do a very small no-impact change, and see how that process goes and what kind of steps it involves, how to communicate it with the community. Once we have that, then we can start making more impactful changes, communicate more complex upgrade processes, etc. There are lots of questions and we’re just trying to take it one step at a time.

Marijane: Might just have to recruit hard for testers when we make a more minor change.

Javed: Moving forward…​ we have the contributingRole property, the label needs to be updated to match the property. I also found a deprecated property, it has this weird ISF namespace.

Marijane: Oh wow, I didn’t realize that http://isf namespace was anywhere in the source code. I’ve definitely seen it in the ISF repository.

Javed: So I don’t know what’s going on with these deprecated properties.

Brian: I’ve never seen that before, and I don’t think it’s used for anything real, it might have been brought in by some tool.

Javed: And it only has one property under it, and the inverse of that property is not deprecated. And it’s been that way for a long time.

Another minor issue: facilityFor has no label.

Marijane: Adding labels sound like good changes to make to me.

Chrisitan: I agree.

Christian: Did you write issues about that yet in the openrif repo?

Javed: Not yet.

Marijane: That was my question too.

Christian: So should we try editing a label?

Javed: Well we have the question that Mike raised, to address.

Marijane: Is the question whether we should fix the code first?

Javed: Yes, I think we should decide on how to fix the annotation properties, either put them back or change the software.

Marijane: I think this all makes sense, I have questions. How big of a change will this be, etc?

Brian: My off the top of my head guess is that it probably is not going to be a major change, there are a zillion things configured by RDF that affect application behavior, and in most cases they don’t care where they come from, so the fact that these three random little things are behaving differently, I suspect it’s probably just a matter of the person writing that functionality not knowing what object to use to make that query, so it would be fairly minor. Even if it’s not minor, it should still absolutely be fixed, we shouldn’t kick this technical debt down the road. So we should just assume it’s just going to get fixed, and we might try it in the lab repo first. It shouldn’t hold us up either way from making whatever changes we think are appropriate.

Marijane: Well said, Brian.

Brian: A tangential discussion, because I didn’t realize we were still at the point of making at minor change, I agree that we should figure that out before we move ahead with larger changes.

Marijane: So I think the next question is where does the responsibility for fixing this lie? Do we need to coordinate with Andrew?

Brian: I could look at that, I should be able to find it pretty quickly, and then we can submit a pull request.

Marijane: Would we have to submit the consolidated ontology with that pull request?

Brian: No because the fix should make the code not care about where the annotations come from. I am optimistically believing that it will work that way.

Javed: I just looked again in the applicationConfiguration.owl file, another thought I have, we can leave the definitions here, but when they are used on the properties, we move those into the vivo.owl file. I am still thinking about this part.

Brian: I think we should wait and only do that as a last resort if it proves impossible to fix the other part. Normally the TBox model is just queryable, if this thing is not finding them when they are in this other file, that means it’s doing something bizarre. I think it should be a simple fix

Christian: If it’s possible to fix it, it will be cleaner, and then if we have another situation like this we will better be able to deal with it. Fixing the code sounds better to me.

Javed: I remember why I put these in here, they are related to the VIVO application, so they’re not useful to anyone not using the software. So I take my previous comments back, I agree with what Brian said.

So action item for Brian Lowe, fix the code. =)

Marijane: This sounds like a good place to wrap up, since we have 10 minutes left.

Brian: is there a place we should track this?

Christian: It could go in the JIRA.

Brian: Ok, I will make a ticket in the JIRA

Christian: Could we also have a ticket in the repository?

Marijane: I don’t know, the VIVO project doesn’t use Github issues currently does it?

Javed: I don’t think so.

Marijane: OK, then I think the JIRA should be sufficient, we should stick with the current development convention.

Brian: OK, I will just do that then.

Marijane: OK, I think we can adjourn this meeting, we know what needs to happen next.