VIVO-1688: Separate VIVO ontology into own repository

chenejac / VIVOTestMigrationJIRANotClosed

0 stars 0 forks source link

VIVO-1688: Separate VIVO ontology into own repository #130

Open chenejac opened 5 years ago

chenejac commented 5 years ago

Andrew Woods (Migrated from VIVO-1688) said:

This task is to extract the vivo ontology from the core codebase, moving it into its own Git repository. The ontology project should produce a Maven artifact that the core codebase then depends on.

chenejac commented 5 years ago

Andrew Woods said:

Questions:

Should only vivo.owl be extracted? https://github.com/vivo-project/VIVO/blob/develop/home/src/main/resources/rdf/tbox/filegraph/vivo.owl
What version number do we want to use for the vivo ontology artifact? 1.10.0?

chenejac commented 5 years ago

Benjamin Gross said:

There is also https://github.com/openrif/vivo-isf-ontology, of course. The proposed VIVO ontology repo and the VIVO-ISF repo should at least... mention each other in a README or something?

chenejac commented 5 years ago

Andrew Woods said:

[~accountid:5bb229e412ef2d4bf3a2233d]: that is a good point. I would be interested to know what the Ontology Group's thoughts are on the relationship between vivo.owl and vivo-isf-ontology.

chenejac commented 5 years ago

Mike Conlon said:

We are moving away from the VIVO-ISF idea. It was an attempt to merge the VIVO (scholarship) and ERO (research resources) ontologies. Several things did not work:

Only VIVO was active.
ERO had little value for us
The combined ontology was crazy big
Ontological practice has moved toward modules built on best practices. ERO is one. VIVO is currently not. The mash-up VIVO-ISF is not. We'd like to move toward best practices. Hence separation.

Do I need to explain this on a call? Which one?

chenejac commented 4 years ago

Benjamin Gross said:

I think it would be helpful to note the pros and cons of doing this in the ticket here. Pros

ontology is explicitly versioned
ontology can be included during build as a dependency
will encourage more rapid ontology development (?)

Cons

The VIVO application is very ontology-aware in some cases. Functionality will break if the ontology changes. Decoupling makes it more difficult to find ontology references across projects.
vitroAnnotations.n3 would be maintained in a separate repo from the ontology.

I guess the argument could be made that despite the added hardship in propagating ontology changes through the application, separating them actually reduces risk since VIVO will import a specific version of the ontology which cannot change. Worst case the ontology is upgraded and the application is not, but it still works since it will point toward the old ontology version.

chenejac commented 4 years ago

Andrew Woods said:

That all sounds right, [~accountid:5bb229e412ef2d4bf3a2233d].

Is there an argument for potentially managing vitroAnnotations.n3 differently as a result of this ticket?