Update SWO metadata: clarify license, update description, mark inactive

[cmungall]

@rvita updated the SWO metadata in #679

However, I would like to request some additions and clarifications.

SWO makes heavy use of EDAM, this is visible in the 'comment' field in the ontology header. I recommend including more detail in the markdown section of the SWO entry in OBO to describe this relationship.

The licensing implications are not clear to me. EDAM is CC-BY-SA (https://creativecommons.org/licenses/by-sa/2.0/). By my reading this means SWO should be CC-BY-SA as well. However, it's listed in OBO as CC-BY. Is this allowed? (cc @kltm). By my reading the "ShareAlike" clause means that SWO (a derivative) would inherit the more restrictive license.

The comment field in the SWO ontology header states:

SWO and EDAM include some terms released under CC-BY license from the OBO Foundry. We acknowledge those with the use of the OBO PURLs were appropriate. Some of the definitions have been modified from the original; for the latest original definition please visit the URI.

I don't quite understand this but it seems like this is attributing terms taken from the rest of OBO, not EDAM? In fact such a statement is not actually required (although confusion over this kind of thing leads many to prefer CC-0).

My other question is on frequency of updates. SWO was last updated in Oct 2016. EDAM was last updated in July 2018. So people downloading SWO will get an out of date EDAM. Do we want to encourage this?

Note that ideally for a software ontology, updates would be regular. Software and bioinformatics datatypes changes faster than most domains in OBO!

Given the paucity of updates, there is a case to be made for marking SWO as inactive. I appreciate it is hard keeping such as ontology up to date, but note that inactive is weaker than deprecation, it just sends a signal to OBO users that the contents may not be up to date.

@rvita can you work with @allysonlister @jamesmalone on updating the metadata.

[allysonlister]

Hi all,

@cmungall thanks very much for writing this ticket. Again, apologies for the delayed response - I was on vacation.

While SWO hasn't been updated recently, I still have plans for it. Indeed, I am planning this month to perform a basic update to it. Until now, these updates have just been in my head - tickets / milestones / discussions with other developers who originally brought me into the SWO project (like @jamesmalone, Robert Stevens, and Helen Parkinson) will appear in the next days/weeks. We have some ideas about using it in the future in some projects I am currently associated with, but right now SWO is unfunded and is maintained by volunteers.

Updates will address some of your concerns:

1. Licensing - it seems there was a bit of a snafu with the licensing. I'll have a word with the others and get it sorted out.
2. Frequency of updates - I'm planning to upgrade the build procedure to use ROBOT and some other tools; when we were working on it more actively a few years ago, the build was still quite clunky. This is a high priority for me, and will make updates really simple.
3. Integration with EDAM - as part of improving the build procedure, we will be able to maintain an up-to-date link with EDAM rather than losing sync with them. As part of this, we will also not need to import as much of EDAM - after all, we have MIREOT etc for a reason! So SWO will be more streamlined and (hopefully) more relevant to software itself after this.

Please keep an eye on https://github.com/allysonlister/swo/milestone/1 as I add tickets to it, and I will repost here once it's all sorted.

As I said, this is all going to be done in the evenings outside of work hours but I would like to get it done this month. It's a lovely bit of work and just needs some TLC :-)

Thanks again :) Allyson

[allysonlister]

I've had a little look at https://wiki.creativecommons.org/wiki/ShareAlike_compatibility and it seems that we may have an issue with SWO being CC BY (less restrictive) and EDAM being CC BY-SA (more restrictive):

One-way compatibility means that you may adapt work under one license (X) and apply a second license (Y) to your own contributions, but you may not adapt work under the Y license and apply the X license to your contributions. For example, CC BY is one-way compatible with BY-SA. You may adapt a BY work and apply BY-SA to your contributions, but you may not adapt a BY-SA work and apply BY to your contributions.

I'm not quite sure how to resolve this. @cmungall do you have a rough idea of how many other OBO Foundry ontologies might run into similar issues?

[cmungall]

Now my turn to apologize for delayed response.

Thanks for your first response, v helpful, glad to see things moving forward

Second response, licensing. I am not aware of a precisely analogous situation. Indeed the OBO licenses are set up to avoid such a thing, if everyone is CC-BY or CC-0 we don't run into this. But EDAM is not in OBO...

I am not an expert but my suggestions

Avoid something vague like an assurance over email that it's fine to use some restricted resource within some less restricted one. Good to be precise.

One option is to independently develop content. Not ideal. But maybe wikidata could be a good home for some of this and it's CC-0?

Another option to specify what content you need (class subset, axiom subset - e.g. do you need definitions or synonyms) and petition EDAM to release a subset under a less restrictive license.

Better yet, get EDAM to release the whole thing under a less restrictive license - happy to broker a conversation on this tracker ticket or anywhere else..

[kltm]

For the purposes of licensing, our rubric (http://reusabledata.org) regards CC BY-SA as a somewhat less "reusable" category, due to the fact that it prevents redistribution if not under the same license. (If you are familiar with software licenses, it is similar to the differences between BSD and GPL-style licenses.)
Practically, from reading this thread, it would mean that derivative works with EDAM would need to also be CC BY-SA. (IANAL, YMMV)

[allysonlister]

Hi Chris, all,

This is a very interesting thread, thanks. My personal preference would be to contact EDAM and see if we could have a conversation with them about licences. I think the next move should be to post an issue in their tracker. Happy for you to do this, Chris, if you'd like to, or I can get things started if you prefer?

Thanks :) Allyson

[cmungall]

ok, even more delayed response this time!

Yes, I would really like to move this forward. There is a lot of great content that is unique to EDAM and it would be great to make it more OBO-compatible, including SWO imports. Anyhing you can do to move that along much appreciated! Thanks!

[allysonlister]

I think we don't need to worry about lateness, life is too "interesting" at the moment :-) I will put this on my SWO list with the other stuff, though lockdown schooling and trying to fit work it means that things may take longer at the moment.

Thanks!

[cmungall]

Thanks @allysonlister - just checking in to see if there is any progress.

I note also that OBI has some things in the domain of software too: obi-ontology/obi#1175

[allysonlister]

Thanks @cmungall - finding time at the moment for SWO is tricky, however I think that this summer, when things are quieter, I will tackle a few small changes that I've been planning (updates for OBO dashboard alignment etc). As part of this I will start things off by writing a ticket with EDAM to ask about licencing. If it turns out this is unfeasible, if necessary I can decouple SWO from EDAM, though this would not be ideal.

Secondarily, perhaps I should join an OBI call at some point to discuss points of commonality - I used to develop OBI, but it's been a long while since I did that! I will reply to the ticket you linked with the thought that I can join in one of the calls as it's convenient.

I'm not funded for SWO, so it needs to come in between other work, but it's a lovely ontology that could just needs a wee bit of updating.

[nlharris]

What is the status of this? Should SWO be marked inactive until such time as it is reactivated?

[allysonlister]

I am still keeping an eye on it, although I've been busier than usual. Please do keep it active for now. :-)

[allysonlister]

Good morning!

I believe the licence has been clarified at edamontology/edamontology#724 (comment) so that should have been resolved now. We have also updated the description.

As far as I can tell, this issue is now resolved and we can close?

[ddooley]

I see now that SWO uses OBO style purls (resolving to EBI site). It reuses some EDAM terms. I assume that's ok too.

[cmungall]

Except Edam has a license that is more restrictive…

…

On Tue, Mar 28, 2023 at 12:17 PM Damion Dooley ***@***.***> wrote: I see now that SWO uses OBO style purls (resolving to EBI site). It reuses some EDAM terms. I assume that's ok too. — Reply to this email directly, view it on GitHub <#1040 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMMOL7C3HBLRDNJGCV473W6M2M7ANCNFSM4INM2QPQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[allysonlister]

Over time we have gradually reduced the EDAM terms and I would be open to a discussion of removing them completely, if this would help clear up issues. Apologies for any delay, I am currently on annual leave but wanted to make sure you knew I'm happy to have conversations and generally implement anything sensible in this regard.

[nlharris]

Can this be closed?

[allysonlister]

I really am not sure if it can be closed? Is there an official policy on the use of EDAM terms? I think that's what we're circling around here. If OBO Foundry says that EDAM shouldn't be used, then I will remove them. It's all about that classic grid of important and/or urgent really in terms of my to-do list.

It seems as though it's likely the licensing issues are "ok", but that most around here these days (remember, SWO has been around for a long time!) would prefer no integration between EDAM and OBO because such issues make it a bit tricky to use, am I right?

So, in short, some guidance around this and I will certainly implement it. Thanks!

[cmungall]

There’s no policy on the use of Edam terms, this is just about accurate metadata and licensing. So long as swo mireots terms with a more restrictive license then it inherits that more restrictive license (this is my interpretation of the linked thread but no one responded to @kltm), and this should be reflected in the metadata. You can explore other options like getting Edam to release the subset of terms use under a less restrictive license, or you could release a version of swo that doesn’t mirror Edam and leave it to the user to stitch together, but until then I think you’ve inherited the stricter license

…

On Tue, Dec 19, 2023 at 11:48 PM Allyson Lister ***@***.***> wrote: I really am not sure if it can be closed? Is there an official policy on the use of EDAM terms? I think that's what we're circling around here. If OBO Foundry says that EDAM shouldn't be used, then I will remove them. It's all about that classic grid of important and/or urgent really in terms of my to-do list. It seems as though it's likely the licensing issues are "ok", but that most around here these days (remember, SWO has been around for a long time!) would prefer no integration between EDAM and OBO because such issues make it a bit tricky to use, am I right? So, in short, some guidance around this and I will certainly implement it. Thanks! — Reply to this email directly, view it on GitHub <#1040 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMMOOARUR7QXDIFRKN2UDYKKJ3LAVCNFSM4INM2QP2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBWGQYDCMRWGQZA> . You are receiving this because you were mentioned.Message ID: ***@***.***>