How is the parent mapping in feature_levels.yaml and so.obo files used by AGAT?

[svigneau]

Thank you @Juke34 for putting the time and effort into developing and documenting this extremely useful software!

I couldn't find anywhere so am asking here:

• Is there any documentation describing when the parent mapping in feature_levels.yaml and so.obo files are used by AGAT?
• For instance, in which cases does it matter to indicate a true parent feature in feature_levels.yaml instead of a dummy "1" parent?
• Likewise, in which step is the information from the so.obo file used?
• Somewhat related, what is the best way to indicate that some feature types can have multiple types of parents (a common case in SGD reference GFF)?

[Juke34]

Hi @svigneau, thank you for your questions

* Is there any documentation describing when the parent mapping in feature_levels.yaml and so.obo files are used by AGAT?

Excepted the mention in the log generated while running a script no. Moreover this is not really explained...
I should definitly add some information in the doc.

* For instance, in which cases does it matter to indicate a true parent feature in feature_levels.yaml instead of a dummy "1" parent?

Actually this not really used yet... I wanted at some point to implement something that use this information when AGAT needs to create a missing parent feature. What really matter is to set the feature types in their proper category level1, level2, level3 respecting the relationships you expect in your file.

* Likewise, in which step is the information from the so.obo file used?

This is used only to provide information to the user if the feature types meet in the file follow the sequence ontology (SO) or not. As in GFF3 format the feature types are constrained to be part of the SO, it helps the user to see if his file is fully compliant or not. If not, the user may modify the feature types to match an existsing one or apply to add a new term in SO.

* Somewhat related, what is the best way to indicate that some feature types can have multiple types of parents (a common case in SGD reference GFF)?

The best and only way should be to have the correct relationships set in the file. e.g. using ID/Parent attributes as for GFF, or using transcript_id and genet_id as in GTF or to use a common attribute that is shared by all features belonging to the same record.
The only constraints will be that the feature_levels.yaml is coherent with the relationships. e.g CDS cannot be a parent of a mRNA because CDS is described as a level3 feature and mRNA as level2 feature, and a level3 cannot be above a level2 (the order level1>level2>level3 must be respected).

[svigneau]

Thank you for your detailed answers! This is extremely helpful.