GBOL - Genome Biology Ontology Language

jjkoehorst commented 5 years ago

Ontology title

Genome Biology Ontology Language

Requested ID space

GBOL

Ontology location

https://gitlab.com/gbol/GBOLOntology

Contact person

Name: Jasper Koehorst Email address: jasper.koehorst@wur.nl GitHub username: jjkoehorst

Issue tracker

https://gitlab.com/gbol/GBOLOntology/issues

Ontology license

[ ] CC0 (public domain)
[ ] CC-BY (version 3 or later)
[ *] Other: MIT License

Available ontology formats

OWL / SheX / OWL+Shex (original)

What domain is the ontology intended to cover?

To provide a formal representation of genomic entities, along with their properties, relations and provenance.

Related OBO Foundry ontologies

GO, and currently is connected with BIBO / foaf and exact matches to SO / Faldo / WikiData

Intended use/related projects

Storage of genetic information, predictions and related provenance

Data source

Genetic information from ENA, bacterial 80000+, viruses, human, salmon, fungal,

Additional comments or remarks

We currently have the documentation regarding to the ontology stored at http://gbol.life and we have incorporated it with an OWL / Shex generator + Java API generator empusa.org to incorporate this into current software to ease data analysis and incorporation.

pbuttigieg commented 4 years ago

Hi @jjkoehorst

Apologies for the delay, we had stack of issues to clear during the operations calls and have only just reached this item.

The committee discussed GBOL and its applications and are very much encouraged by both its utility and its reuse of existing ontologies.

We recognise that this is an applied ontology, but see its potential as a reference for genomic entities. For this to be realised, the "core" content of GBOL would need to be identified and carried forward as the candidate for the Library. Thus a few points of definition are needed. Initially:

"Genomic entities" is quite a broad domain - could you provide examples of what these entities are and what the scope of GBOL is? Currently, the TTL file contains entities for entities such as telomeres, but also countries.
To adhere to the OBO principles, GBOL classes that are exact matches with SO (or other OBO resources) would need to be replaced with imports of those classes. Is this or can this be placed on your roadmap?
Alignment to the BFO upper-level ontology is helpful and encouraged - with our assistance, is there scope to align the "core" GBOL content to BFO?
License: would there be scope to move GBOL towards CC-BY or CC-0?

jjkoehorst commented 4 years ago

"Genomic entities" This is indeed a very broad definition. The core of GBOL is to store genetic information and can be seen like a semantic representation of embl formatted annotation files with in addition contains element-wise (genes) and dataset-wise (entry info) provenance. We have indeed included countries as we wanted to store origin information (where was this sample taken). These country IRI's should be replaced by an official country ontology but are not sure yet if and which one to use.
OBO principles We have used exact matches where possible to match with SO / WikiData / Faldo (and still looking for more matches) but replacing the class IRI could become cumbersome as the ontology is converted to an API interface for java which is currently heavily used in a Semantic Annotation Platform with Provenance (SAPP). Need to look into that to what extent this will cause problems. Exact matches of course are never a problem.
Alignment I am not familiar with (BFO?) but I do not yet see a problem there. Might need to change something in the code generator but we can look at that once we work on it.
License Yes no problem, indeed CC-0 should be used in general...

pbuttigieg commented 4 years ago

@jjkoehorst many thanks

"Genomic entities" ... The core of GBOL is to store genetic information and can be seen like a semantic representation of embl formatted annotation files with in addition contains element-wise (genes) and dataset-wise (entry info) provenance.

I would say then that genes and genetic elements would be the main focus of the subset of the GBOL application ontology that would be pushed into OBO space.

To keep in line with the orthogonality and scoping principle, we'd have to think about where GBOL content extends SO and where it breaks new ground.

For those parts that are extensions or refinements of SO, it would be very interesting to work with the SO team.

Those parts that are new kinds of entities not covered by SO

We have indeed included countries as we wanted to store origin information (where was this sample taken). These country IRI's should be replaced by an official country ontology but are not sure yet if and which one to use.

Of course, this makes sense. GAZ is OBO's gazetteer, and it has country subsets which may be useful here.

There are others such as official UN country names which may be worth considering, but ontological compatibility may become an issue.

Alignment I am not familiar with (BFO?) but I do not yet see a problem there. Might need to change something in the code generator but we can look at that once we work on it.

If we keep this to the top-levels of your ontology, there shouldn't be too much turbulence downstream. This would be done after we find out what the core GBOL contribution to OBO would be and I can assist there.

License Yes no problem, indeed CC-0 should be used in general...

Great!

jjkoehorst commented 4 years ago

@jjkoehorst many thanks

"Genomic entities" ... The core of GBOL is to store genetic information and can be seen like a semantic representation of embl formatted annotation files with in addition contains element-wise (genes) and dataset-wise (entry info) provenance.

I would say then that genes and genetic elements would be the main focus of the subset of the GBOL application ontology that would be pushed into OBO space.

Yes indeed

To keep in line with the orthogonality and scoping principle, we'd have to think about where GBOL content extends SO and where it breaks new ground.

Sounds good but how do we proceed best?

For those parts that are extensions or refinements of SO, it would be very interesting to work with the SO team.

Those parts that are new kinds of entities not covered by SO

We have indeed included countries as we wanted to store origin information (where was this sample taken). These country IRI's should be replaced by an official country ontology but are not sure yet if and which one to use.

Of course, this makes sense. GAZ is OBO's gazetteer, and it has country subsets which may be useful here.

Indeed will look into for example to: http://www.ontobee.org/ontology/GAZ?iri=http://purl.obolibrary.org/obo/GAZ_00001549 and we can replace the GBOL countries with those uris?

There are others such as official UN country names which may be worth considering, but ontological compatibility may become an issue.

I looked into FAO but 404 and couldn't find a working version yet, http://aims.fao.org/geopolitical.owl

Alignment I am not familiar with (BFO?) but I do not yet see a problem there. Might need to change something in the code generator but we can look at that once we work on it.

If we keep this to the top-levels of your ontology, there shouldn't be too much turbulence downstream. This would be done after we find out what the core GBOL contribution to OBO would be and I can assist there.

License Yes no problem, indeed CC-0 should be used in general...

Great!

Have updated the license on git: https://gitlab.com/gbol/GBOLOntology

pbuttigieg commented 4 years ago

@jjkoehorst

On behalf or the OBO Operations Committee, I apologise for the long waiting period in processing your request:

As new requests have come in, it became clear that a revision of our policies for inclusion of new ontologies was needed. The current state of those policies is viewable here: http://obofoundry.org/docs/Policy_for_OBO_namespace_and_associated_PURL_requests.html

If you are still interested in pursuing a prefix and IRI handling service for GBOL through OBO Services, please respond to this message within two weeks (when our next OBO Operations call will take place).

If we do not hear from you, we will close this issue; however, you can always reopen it if desired. Thank you and our apologies once again.

nlharris commented 4 years ago

If we do not hear from you, we will close this issue

We didn't hear back; should we close the issue?

OBOFoundry / OBOFoundry.github.io