Update OBO interconversion of PLANA

[althonos]

Hi !

This PR does two things to improve conversion of PLANA to OBO format:

• fix separate db-xrefs annotations that were merged in the same annotation.
• use OBO shortcut for definition of the restricted_to relationship.

The restricted_to fix will have the effect to change the contents of plana.obo from this:

[Term]
id: PLANA:0000001
relationship: PLANA:0007536 PLANA:0000027 ! specific_to Smed sexual biotype

[Typedef]
id: PLANA:0007536
name: specific_to

to the semantically equivalent but easier to work with in OBO:

[Term]
id: PLANA:0000001
relationship: specific_to PLANA:0000027 ! Smed sexual biotype

[Typedef]
id: specific_to
name: specific to
xref: PLANA:0007536

[srobb1]

Hi @althonos, Thanks for looking into this. Could you try testing out our most current owl file? plana.owl We also have an obo file that is generated by the tool (ontology-development-kit) we use for managing our ontology. plana.owl Does it work with pronto? (note: links are not to raw text)

We are working on a separate branch right now, trying to get it right before merging into main. The dbxref issue is fixed in this version. And there is only one label for specific to, maybe this will help. We are following the rules outlined by the obofoundry. All terms we create need ids in this format PREFIX_0000000. I do not think using just the label for specific to will be appropriate.

But specific to will never be on of the relations we will need for retrieving or listing children when using pronto. I envision it will only be is_a and part_of. Possibly, but probably not, contained_in.

Thanks for this! Sofia

[althonos]

Hi @althonos, Thanks for looking into this. Could you try testing out our most current owl file? plana.owl We also have an obo file that is generated by the tool (ontology-development-kit) we use for managing our ontology. plana.owl Does it work with pronto? (note: links are not to raw text)

The OWL file works at the moment (with the v1.0.0-alpha.1 prerelease), the OBO file cannot be parsed but the error originates from imported terms of the FlyBase CV.

We are working on a separate branch right now, trying to get it right before merging into main. The dbxref issue is fixed in this version. And there is only one label for specific to, maybe this will help. We are following the rules outlined by the obofoundry. All terms we create need ids in this format PREFIX_0000000. I do not think using just the label for specific to will be appropriate.

Actually, this does not remove the ID of the specific_to relationships, nothing changes on the semantic level. On the syntactical level, these annotation are used as shortcuts for the true ID when translating to OBO: see the paragraph about relation tag translation in the OBO 1.4 semantics.

But specific to will never be on of the relations we will need for retrieving or listing children when using pronto. I envision it will only be is_a and part_of. Possibly, but probably not, contained_in.

In case you don't know, there is a specific ontology for relationships: RO, which is almost builtin in the OBO format at that point. Ontologies like GO use RO to handle their relationships, but use the shortcut name as I mentioned earlier so that you can query using negatively_regulates instead of RO:0002630. Once again, this is only on the OBO syntactic level, nothing in the OWL/RDF graph would change.

[srobb1]

@althonos

We use many RO terms. We would be lost without RO :)

I added the shorthand attribute to specific_to

We import a 'posterior to' property from BSPO that imports a couple FBcv terms. I could remove the import statement for the FBcv owl file and then these terms would not have any of their attributes or props only the IDs.