20171023 Ontology Improvement Call

Date: 23 Oct 2017

Attendees: Marijane White, Christian Hauschke, Graham Triggs, Muhammad Javed,

Agenda: updates/comments from last meeting

Graham: Mike is traveling to Berlin this week for FORCE17.

Javed: I have more feedback on the last meeting's agenda. We discussed there are triples that should exist in the a-box and not in the t-box and vice versa. We discussed that we should have three folders, one for t-box, a-box, and another for configuration. I looked into the t-box files, let me show you.

So on the merged filegraph.owl Mike created, opening it in a text editor. There are named individuals for document status class members in here. They should not be in the t-box, they are already in the a-box, so there is some duplication here. The instances for DateTimePrecision class are also in here.

Christian: Should all Named Individuals in all ontologies be in the a-box for all ontologies or are we just talking about VIVO?

Javed: All named individuals, no matter what ontology they come from, should be in the a-box.

Marijane: I would say that these serve as a sort of lightweight taxonomy function, I am not surprised to see them in the t-box.

Javed: We already have taxonomies, and they are defined in the a-box. And as already noted, the ones in the t-box are also already defined in the a-box.

And then there are annotations. InitialTboxAnnotations.n3, this file has a number of annotations, which should be put in the configuration folder. But the rdfs:labels in this file should be in the merged t-box files. The formatting of the file means we may have to use Jena to extract them out of this file so we can put them in the t-box.

Graham: The easiest way would be to load it into a Jena model and removes the labels when we serialize it.

Javed: So if we take out the named individuals and add in the labels from the annotations file, we will have clean t-box file.

Marijane: So the last time I was in this meeting we assigned tickets for triage. Did we discuss that last

Christian: Mike said enough have been triaged that there is plenty to work on now.

Javed: I have one question for Mike, we worked on this merged filegraph file, do we also want a merged a-box file, or leave them separate, and I have the same question about the application annotations.

Christian: So you're going to separate all of the annotations?

Javed: if they are used by the application, yes.

Christian: That sounds like a good idea.

Javed: So if someone downloads the VIVO ontology, they will not get the Vitro annotations in the file.

So I don't know who should do the named individuals work, and adding the labels. But once we do that we can move forward.

Marijane: As for your question for Mike about merging the a-box files, I think it might be easier to edit and update them if we keep them separate.

Javed: agreed.

Marijane: As for the named individuals and labels work, since we're talking about the VIVO codebase, it seems that we need a VIVO committer to volunteer.

Javed: If we need to write a tool to remove the labels, I can do that. Graham, do we have anything like that?

Graham: No, but it's a simple Jena wrapper to load them into a model.

Javed: Ok, I can do that. I will add the labels to the filegraph.owl, and remove the named individuals. I will send out the updated file before the next meeting.

So let's say we did that by our next meeting. What's next?

Christian: I think we agreed a lot of weeks ago that we need a clean single ontology file in order to do the first minor ontology change. I can't imagine anything that would stand in the way of this now. Maybe we should think about trying new processes now?

Javed: Let's say we have this one single ontology file. Should we test it on a VIVO instance?

Marijane: I think that's a good idea.

Christian: I also think more than one instance/institution should test it.

Marijane: Once you email the file, anyone who wants to can test it?

Javed: not exactly. We need to test the whole VIVO instance, including the moved configuration annotations.

Marijane: is there anything else that needs to be done before that testing? any code changes required?

Graham: I think that is part of the testing, to discover if code changes are needed.

Javed: yes. Our hypothesis is that everything will work, now we need to test it. We need to find 2 or 3 instances that can test it.

Marijane: Did I hear Christian volunteer to test earlier?

Christian: We can't make code changes right now, but otherwise yes we can test it.

Graham: It would require spinning up a clean VIVO (remove all the triplestore) and change the RDF directory to have the new files.

Javed: shares screen, shows what files need to be changed for the test

Graham: so those files are loaded into TDB/SDB when VIVO is started. You should get a VIVO with the new ontology.

Graham: so I just delete everything here and start with the filegraph.owl file, ok.

Javed: We need to decide if we're just replacing the filegraph folder or the whole RDF folder. I think we need to replace the RDF folder as a whole. Is that right, Graham?

Graham: Yes, we need to make a new RDF folder that is consistent with the changes we are making.

Christian: So I can rename that folder and make a new one?

Graham: yes, sort of. It needs to follow the existing file structure.

Christian: so...

Javed: I don't think Christian should be responsible for the structure. The people making the changes should be responsible for the structure.

Marijane: I agree. Can we distribute a zipfile of the directory to testers?

Javed: yes

Christian: That would make things a lot easier and faster.

Javed: question for Graham, where should the annotations go?

Graham: I'm trying to work out where display goes to. The application metadata is going into the main triplestore under ... I am not sure where display is going.

Javed: It looks like if we move the labels into the merged filegraph t-box file, then the rest of hte annotations should go either into display or metadata.

Graham: it's going into the t-box, but... This makes me think there is something specific going on with certain files. Most of the files it's loading out of filegraph, it is putting them into a graph named as that file, ie. tbox-bfo.owl. But that initial t-box file, there is no corresponding graph, and that makes sense, because you want to put them somewhere where the application is not going to modify, because it controls what is displayed where.

Javed: ok, we don't need an answer right now, we just need to be aware that they need a place to go.

Graham: yes, but they should be going into a graph. thinks ah, they should be going into kb-display-metadata-display. They might not show up in the UI because they're configuration.

Javed: so what this means, if they are in a specific graph, the code is looking for them on first run. If we push them into a different location, that means the code is changing, right?

Graham: yeah, if you move them somewhere else, they'll go into a different graph, and who knows what the application will do. In fact they may end up in the content triplestore rather than the configuration triplestore and things may just not work.

Javed: so something may need to be changed. Ok, so we have two options. If we move those triples into a different folder, then the path in the code needs to be updated. If we don't move these triples, then it will work. Ah, ok, these are in the first time folder, so I think we should leave them here.

Graham: yes, those are ones that go into the content triplestore.

Javed: ok, maybe we can just leave them there for now, so we don't have to change any code.

Ok, so i think that's a good next step. I will work on those files and send them via email. Not the RDF folder, just the file, and we can have a look and make sure it's fine, and then we can prepare the RDF folder that can replace on any VIVO instance, and then we can test.

Marijane: That sounds like a plan.

Javed: I need to duck out early for another meeting.

Marijane: That's fine, I think we just hit a good stopping point.