NTR: implemented in programming language

[cthoyt]

It would be nice to have a property that is appropriate for connecting a software like HTSeq (SWO:1100140) to the programming language in which it's implemented like Python (SWO:0000118). This would be useful for the Data Science Ontology for better aligning with OBO as well. CC @epatters

I would label this relation implemented in programming language and it would have the following properties:

1. Range: software (SWO:0000001)
2. Domain: programming language (IAO:0000025)

[allysonlister]

That is a good idea. I need to tidy and make a new release here anyway, so happy to have this included. It's a volunteer project so may take a little bit of time. Thanks!

[cthoyt]

If you can point me to your contribution guidelines, I'd be happy to add something like this myself and send a PR.

[cthoyt]

For example, which file should I edit? Is there a release process? Or should I make the same change in multiple artifacts?

[cthoyt]

Also, it appears that is encoded in (SWO:0000741) has been previously used for doing this kind of thing, but this doesn't have an obvious label nor does it have specific constraints. Would it be better to continue using this, or to make a sub-property that has more strict domain/range and switch existing usages that conform to this?

[allysonlister]

SWO has been updated my a small number of people over a long period of time. Thanks for the offer - give me a few days to take a look at things and I'll get back to you wrt "is encoded in" as well as the build process (it is the build process itself that needs the main overhaul).

Thanks!

[cthoyt]

Thanks so much for the feedback! Ping me if/when you're ready for me to get involved.

[allysonlister]

Sorry about the delay here.

is_encoded_in is intended to be quite generic, and applicable across different class types. You can see that because it has a child term has_format_specification that has a domain of data item and a range of data format specification.

We have two options:

1. make a sub-property of is encoded in that has more strict domain/range and switch existing usages that conform to this.
2. continue using is encoded in, but without the restrictions you mention perhaps it's not exactly what you need?

Item 2, which I'm leaning towards, would mean:

• is encoded in - remains as-is, but could have better annotation
  • has format specification - remains as-is
  • implemented in programming language - with domain and range as you suggest

And then we would need to re-curate the existing software -> programming usages of is encoded in to be implemented in programming language

I would be very happy for you to contribute to this ticket. Information is in our contributing and editors documentation, and is built upon the standard ODK build procedure.

Essentially, update swo-edit.owl and then as for us to check your updates, then I can build the release once done.

Here's the setup for the ID ranges, and I've added your id range to the editors documentation. Note the non-standard EBI IRIs - this is a holdover of SWO as one of the very early OBO ontologies, developed at the EBI and I'm still torn about updating the IRIs, as the ontology is being used. Any additional thoughts here (with associated SWO ticket here) on that would be welcome too!