Coordination on project YAML schema

[jamesaoverton]

Can we converge on a common project.yml file schema?

Background: As discussed in #298, I'm very keen to follow ODK's lead on lots of things, even though I usually want only a subset of ODK features for my ontology projects.

Immediate use case: My team is working on a script for reserving term IDs, which needs to know GitHub repo coordinates, IDSPACE, and ID pattern stuff. ontodev/gizmos#2

ODK uses YAML config files, many of which are here in configs/. They already contain most of what that script needs (IDSPACE, GitHub coordinates), plus other useful stuff (dependencies, products, etc.)

Across OBO we have a few other project YAML files:

• OBO registry YAML files, with lots of project metadata, now including some build and dependency information
• PURL config files, which have the IDSPACE but are specialized

We also use or could use project configuration data for DROID, ROBOT, and Protege. And in working on the OBO Dashboard I realized that if I knew that a project was using the GitHub release mechanism, then the dashboard code could look there for new releases. I can think of many more use cases, and there may be relevant open issues already.

I'm not asking for one config file to rule them all. I think the separation between OBO registry and PURL config files is ultimately more helpful than it is annoying. On the other hand, the line between ODK config and OBO registry is not clear to me.

I don't know the right way to go with this. Maybe it won't work at all. But I'll pitch two ideas. First idea:

1. Draw a sharper line between OBO registry and ODK configs
   • e.g. maybe move GitHub coordinates to OBO registry
   • ODK repositories would still keep local copies of both files
2. Update code to read both OBO registry and ODK configs and work with the merged results
3. Expand the scope of ODK configs to include stuff other tools need, e.g. ID patterns, term reservation branch name
4. Define a schema for ODK configs

Second idea: Shove all this stuff into the OBO registry.

[matentzn]

I will come back to this issue soon, perhaps we can discuss next week during our call.

[matentzn]

Maybe its rather ugly, and different audiences for OBO configs - maybe separate repo path is better.

[jamesaoverton]

On the call there was consensus that merging this tool config into the main OBO project metadata files is a bad idea.

Nico volunteered to move the ODK configs to a new home that we have shared access to. I like that idea, but it's really important that we don't break these ODK configs and Nico's workflows!

We discussed two possible new homes:

1. new directory in OBOFoundry.github.io repo
2. new repo under OBOFoundry org

I think (2) is a better option, mainly so we can restrict write access to a handful of developers.

We should also write a strict schema, and add Travis check to enforce the schema.

We'd really like to hear @cmungall's thoughts.

[matentzn]

There is one other thing I did not think about. Based on a really old comment by @cmungall, I recently started to migrate the configs to a standard location in the ontology repository itself, namely src/ontology/$(ONT)-odk.yaml, e.g. src/ontology/wbphenotype-odk.yaml, for an example see here. That would also be an option which is less centralised and gives the editors more fine-grained control. Again, pros and cons. I just wanted to register that as option 3.

[matentzn]

(name and location of the file is arbitray, could be anything)

[jamesaoverton]

I'm also fine if these files are in a predictable place in each project's repo. I mainly care about a shared schema that we agree to coordinate on.

On today's call we didn't talk about coordinating with Protege, but way back at ICBO 2017 in Newcastle there were positive feelings about that possibility.

[matentzn]

I agree; shall we manage a full-blown exemplar together for now (so we can continue working), and just shove stuff in there whenever we need things? We can simply add one yaml file in a location we both have access to (obofoundry github), and add example entries to it whenever we need a new feature. We can develop a schema in parallel (in the same directory), but I think exemplar (plus some comments) is, for now, easier until I am out of these mad times.

[jamesaoverton]

Yes, that sounds good. I'll take care of those first steps. When we have an exemplar I'll link to it from this issue and close. Thanks!

[jamesaoverton]

@cmungall @matentzn I talked to Rafael today about possibly coordinating this with Protege and he started the new issue above.

[matentzn]

This is great! I will start throwing things at the exemplar as soon as it is there.

[cmungall]

Sorry just catching up on this Why move from top level Top level is v standard - pom, package.json etc

…

On Mon, Mar 2, 2020, 09:24 Nico Matentzoglu ***@***.***> wrote: There is one other thing I did not think about. Based on a really old comment by @cmungall <https://github.com/cmungall>, I recently started to migrate the configs to a standard location in the ontology repository itself, namely src/ontology/$(ONT)-odk.yaml, e.g. src/ontology/wbphenotype-odk.yaml, for an example see here <https://github.com/PHI-base/phipo/blob/master/src/ontology/phipo-odk.yaml>. That would also be an option which is less centralised and gives the editors more fine-grained control. Again, pros and cons. I just wanted to register that as option 3. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#328?email_source=notifications&email_token=AAAMMONWO7MAFEODCP64GWDRFPTTFA5CNFSM4K4IZZN2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENQFUXA#issuecomment-593517148>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMMOOPBGPU7IIZQ6DTLOTRFPTTFANCNFSM4K4IZZNQ> .

[matentzn]

Current location does not matter. I just moved it there at some point for no particular reason, but happy to use top level as well.

[matentzn]

@jamesaoverton Did you ever get around to produce an exemplar? Should we say file location is project.yaml in top level of repo?

[jamesaoverton]

I haven't yet, sorry. Here's the draft config that inspired this thread:

https://github.com/ontodev/gizmos/blob/create_term_id_reservation_script/scripts/gizmos.yml

I have an irrational preference for three-letter file extensions (.yml) that you can ignore.

project.yml seems very generic, and I'm worried it will conflict with other tools, but I don't have a better suggestion at the moment.

[matentzn]

Thanks! Yeah I was thinking analogies, and pom.xml came to mind.. so I thought project.yml may be fine. Maybe ontology-config.yml better?

[jamesaoverton]

I think ontology-config.yml is better.