[BUG] remove "def" field requirement for is_a

[Brilator]

Describe the bug The term-directed search only yields is_a sub-classes to choose from if the terms hold a def.

Works

[Term] id: NFDI4PSO:1000003 name: RNA-Seq def: "Test definition to see wether this is the reason, SWATE won't show the is_a options...." is_a: NFDI4PSO:0000035 ! Library strategy

Does not work

[Term] id: NFDI4PSO:1000003 name: RNA-Seq is_a: NFDI4PSO:0000035 ! Library strategy

Why do I care?

• Yes, in principle every term should have a definition, but...
• ...Protege allows to very easily "dump" a list of terms (i.e. copy pasted from an excel list of endpoint repository controlled vocabularies) and store them as is_a subclasses of some parent term. Example: list of instrument models, which really just need to be selectable and besides...
• ...these terms probably exist already in another ontology (incl. a definition) and should at some point be xrefed there.
• For me, this is really just about having a quick way to offer drop-down selectable terms.

Additional context

This is related to #150 and to the question how to properly handle instances / individuals. According to https://owlcollab.github.io/oboformat/doc/GO.format.obo-1_4.html#S.2.2 there's a special [Instance] Stanza (rather than [Term]), but from what I've seen this isn't used in any of the .obo files in swateDB https://github.com/nfdi4plants/SwateDB/tree/main/projects/obo2sql/data so we shouldn't limit it to that.

[Freymaurer]

If i am not mistaken this is an issue with Swobup, as the SwateDB already contains Terms with empty definitions. Maybe Marcel can give some additional input on this @Zerskk.

[Zerskk]

I've tested it with this commit: https://github.com/nfdi4plants/nfdi4plants_ontology/commit/54f90fe74ea0fbbfbeb9cc1511c042df4abac1b5

In tests, the is_a relation was written to database with and without the def field.

Not tested: What happens, if the is_a relation already exists in database?

[Zerskk]

tested it with this example obo-file:

format-version: 1.2
data-version: init/2020-12-01
saved-by: muehlhaus
property_value: http://purl.org/dc/elements/1.1/title "The DataPlant Ontology" xsd:string
property_value: http://purl.org/dc/elements/1.1/creator https://orcid.org/0000-0001-9021-3197 xsd:string
property_value: http://purl.org/dc/elements/1.1/creator https://orcid.org/0000-0003-1476-2121 xsd:string
default-namespace:NFDI4NFDI4PSO
remark: coverage: Missing Terms for the DataPLANT end-point repository templates
remark: creator: Dominik Brilhaus <dominik.brilhaus<-at->hhu.de>
remark: creator: Hajira Jabeen <hajira.jabeen<-at->uni-koeln.de>
ontology: nfdi4pso

[Term] 
id: NFDI4PSO:0000001
name: growth plot design
def: "A plan specification that states how treatments are allocated to the experimental units during an agronomic trial. It refers to the conceptual framework within which the experiment is conducted"
alt_id: http://purl.obolibrary.org/obo/AGRO_00000343
synonym: "Experimental Randomisation"

[Term] 
id: NFDI4PSO:0000002
name: Read Alignment Software
def: "The software used for read alignment i.e http://edamontology.org/operation_3198 or http://purl.obolibrary.org/obo/OBI_0002478"
comment: “ We might need to add the relationship with the class referenced above”

[Term]
id: NFDI4PSO:1000094
name: other
def: "placeholder def of other" []
comment: To be transformed to an instance. DB
is_a: NFDI4PSO:0000012 ! Bio entity
property_value: NFDI4PSO:1000001 "GEO_RNASEQ" xsd:string
property_value: NFDI4PSO:1000002 "SAMPLES_molecule" xsd:string

[Term]
id: NFDI4PSO:1000093
name: protein
comment: To be transformed to an instance. DB
is_a: NFDI4PSO:0000012 ! Bio entity
property_value: NFDI4PSO:1000001 "GEO_RNASEQ" xsd:string
property_value: NFDI4PSO:1000002 "SAMPLES_molecule" xsd:string

Last term was not written to database and no is_a relation was created in TermRelationship table. Could be a problem with the obonet library, that swobup uses for parsing.

[Zerskk]

Problem found: Swobup currently skips Terms, that has no "def"-field. This is by design.

I can change this behavior easily to one of the proposals below.

1. Terms without a "def"-field are skipped, but are reported in the Commit-Mails.
2. Terms without a "def"-field are not skipped and the field is filled with an empty string.