OBOFoundry / OBOFoundry.github.io

Metadata and website for the Open Bio Ontologies Foundry Ontology Registry
http://obofoundry.org
Other
164 stars 201 forks source link

Decide on action for FMA entry in OBO #21

Open cmungall opened 9 years ago

cmungall commented 9 years ago

Currently hardcoded to be the ancient obo format version I made. Should be made the complete ontology now it is in OWL. obo-basic can be a subproduct

cmungall commented 9 years ago

cc @trapperkeeper

Now FMA natively produces OWL (not valid OWL2 but will be soon) do we just point directly to it? Do we create a distinct OBO-compatible version? (e.g. OBO PURLs, standard annotation properties and object properties)?

trapperkeeper commented 9 years ago

Of course my vote, speaking for the FMA team, would be to use the FMA directly. It is confusing having multiple differing versions in play.

cmungall commented 8 years ago

From @trapperkeeper

URL: http://sig.biostr.washington.edu/share/downloads/fma/release/latest/fma.owl tracker: https://bitbucket.org/uwsig/fma/issues

cmungall commented 8 years ago

What should the status of the OBO purls be? Both class purls and ontology purls?

  1. Keep these active, and have them direct to an 'OBO translation' of FMA
  2. Obsolete them
  3. FMA obsoletes its existing purls and joins the OBO system

We are effectively doing 1 right now. With the new FMA being natively OWL we can update the translation to be a minimal one of rewriting IRIs, thus the OBO shadow will be semantically equivalent

2 may well break lots of things

3 is up to @trapperkeeper but I suspect the answer is no

See also https://github.com/OBOFoundry/purl.obolibrary.org/issues/63#issuecomment-161012932

trapperkeeper commented 8 years ago

Sorry for the late response. I brought this issue up with the FMA team but, as suspected, we are not prepared to obsolete our existing purls. First, some of our purls are already in use, as data annotations, referenced from other sources like UMLS, etc. Second, there are multiple community ontology efforts out there, and sometimes professional tension between them. The FMA, in an attempt to remain neutral, has adopted a purl that is not aligned with any specific effort (just trying to remain Switzerland here).

Of course, there are factors that may affect FMA purls. The future of purl.org being one that we are watching.

Regarding choices 1 or 2, from our perspective if would, of course, be nice if there were only one set of purls. But, for legacy reasons and to maintain exiting references I can certainly understand that some mapping or translation method may be necessary.

cmungall commented 8 years ago

Thanks

Just to point out one thing: purl.obolibrary.org is now completely independent of purl.org. You should not use purl.org for anything as the future is, as you hinted, in doubt. purl.org could vanish tomorrow and the obolibrary ontologies would not be affected

On 14 Dec 2015, at 13:16, trapperkeeper wrote:

Sorry for the late response. I brought this issue up with the FMA team but, as suspected, we are not prepared to obsolete our existing purls. First, some of our purls are already in use, as data annotations, referenced from other sources like UMLS, etc. Second, there are multiple community ontology efforts out there, and sometimes professional tension between them. The FMA, in an attempt to remain neutral, has adopted a purl that is not aligned with any specific effort (just trying to remain Switzerland here).

Of course, there are factors that may affect FMA purls. The future of purl.org being one that we are watching.

Regarding choices 1 or 2, from our perspective if would, of course, be nice if there were only one set of purls. But, for legacy reasons and to maintain exiting references I can certainly understand that some mapping or translation method may be necessary.


Reply to this email directly or view it on GitHub: https://github.com/OBOFoundry/OBOFoundry.github.io/issues/21#issuecomment-164562226

trapperkeeper commented 8 years ago

Any purl scheme is a tie to a purl provider, be it purl.org or purl.obolibrary.org. We chose purl.org some time ago because we thought, at the time, that it would be the most universal and neutral provider. We expected the purl user community to embrace the unbranded purl and therefore expected it to be a stable resource. They are now on the ropes, as you say. However, we are already using them. Those FMA purls are already out there in the world. So, until we know its fate for sure, we are holding out to see what happens to purl.org. There is some talk of it being picked up and maintained by w3id.org: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1511&L=DC-ARCHITECTURE&F=&S=&P=3711 https://groups.google.com/forum/#!topic/persistenturls/Zpd4BHQxxIM

cmungall commented 6 years ago

any more thoughts on this? http://purl.org/sig/ont/fma.owl still doesn't resolve

trapperkeeper commented 6 years ago

I can make it resolve to a web accessible copy of the OWL file itself, but it does not specify a version of the ontology.

OK, I have modified the PURL to resolve to the latest version (i.e. http://sig.biostr.washington.edu/share/downloads/fma/release/latest/fma.owl ).

I'm not sure of the context in which this arose, does this fit the bill?

-Todd

From: Chris Mungall notifications@github.com Reply-To: "OBOFoundry/OBOFoundry.github.io" reply@reply.github.com Date: Thursday, November 30, 2017 at 8:18 AM To: "OBOFoundry/OBOFoundry.github.io" OBOFoundry.github.io@noreply.github.com Cc: trapperkeeper det@uw.edu, Mention mention@noreply.github.com Subject: Re: [OBOFoundry/OBOFoundry.github.io] FMA (#21)

any more thoughts on this? http://purl.org/sig/ont/fma.owl still doesn't resolve

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

cstoeckert commented 6 years ago

Tested link and its resolving

cmungall commented 4 years ago

Not sure why this was closed, the issue is still not resolved. OBO is serving an old version of FMA

nlharris commented 4 years ago

who could fix this?

cmungall commented 4 years ago

take this to an ops call

cmungall commented 4 years ago

this is actually a seriously bad problem

dosumis commented 4 years ago

I'd really like this to be fixed. Need the latest FMA for a couple of projects currently. Can we have this resolve to the obolibrary PURL in addition to any PURL preferred by FMA?

I notice the owl files are now provided zipped. I think this can work OK with at least some infrastructure if they are names FMA.owl.zip, but they seem to be just FMA.zip.

cmungall commented 4 years ago
$ curl -L -s http://purl.org/sig/ont/fma.owl 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /share/downloads/fma/release/latest/fma.owl was not found on this server.</p>
</body></html>
$ curl -L http://sig.biostr.washington.edu/share/downloads/fma/release/latest/fma.owl 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>404 Not Found</title>
</head><body>
<h1>Not Found</h1>
<p>The requested URL /share/downloads/fma/release/latest/fma.owl was not found on this server.</p>
</body></html>
trapperkeeper commented 4 years ago

Hey all, I will stick a static copy of the FMA.owl at that address, as an interim solution. I can't do it until tonight, but will do so.

trapperkeeper commented 4 years ago

I grabbed a few moments away from what I was working on and posted that file. The PURL should work now (at least until the next FMA release which isn't pending).

nlharris commented 4 years ago

Thanks, @trapperkeeper!

Can we now close this issue?

cmungall commented 4 years ago

unfortunately not

On Mon, Jul 27, 2020 at 9:16 PM Nomi Harris notifications@github.com wrote:

Thanks, @trapperkeeper https://github.com/trapperkeeper!

Can we now close this issue?

— You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/21#issuecomment-664767005, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOOAK6EI6DPHU5RRIALR5ZGLBANCNFSM4BNANH7A .

matentzn commented 3 years ago
matentzn@mbp:~/tmp_data $ curl -L -s http://purl.org/sig/ont/fma.owl | head
<?xml version="1.0"?>
<rdf:RDF xmlns="http://purl.org/sig/ont/fma.owl#"
     xml:base="http://purl.org/sig/ont/fma.owl"
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:owl="http://www.w3.org/2002/07/owl#"
     xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
     xmlns:fma="http://purl.org/sig/ont/fma/"
     xmlns:dc="http://purl.org/dc/elements/1.1/">
    <owl:Ontology rdf:about="http://purl.org/sig/ont/fma.owl">
curl -L http://sig.biostr.washington.edu/share/downloads/fma/release/latest/fma.owl | head
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0<?xml version="1.0"?>
<rdf:RDF xmlns="http://purl.org/sig/ont/fma.owl#"
     xml:base="http://purl.org/sig/ont/fma.owl"
     xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
     xmlns:owl="http://www.w3.org/2002/07/owl#"
     xmlns:xsd="http://www.w3.org/2001/XMLSchema#"
     xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
     xmlns:fma="http://purl.org/sig/ont/fma/"
     xmlns:dc="http://purl.org/dc/elements/1.1/">
    <owl:Ontology rdf:about="http://purl.org/sig/ont/fma.owl">

These work now?

matentzn commented 3 years ago

@cmungall what are the action items now?

cmungall commented 3 years ago

OK, PURLs work for me now

the question now is what to do with the class PURLs. We have OBO class PURLs for FMA from my translation that predates official FMA PURLs. The official FMA purls are not OBO formatted

Some options

  1. Deprecate OBO class PURLs, and "re-admit" FMA into OBO registry with the new PURLs as canonical
  2. Have shadow OBO class PURLs, as we do for NCIT

I am not sure how best to implement 1. I guess a one time release of the old OBO FMA version with all classes obsoleted and replaced by the sig PURLs. This would create an odd situation. the deprecated OBO class PURLs would be maintained within OBO infrastructure but the official FMA purls would exist without.

It's not really clear how meaningful it is to have FMA "in" OBO with 1.

nlharris commented 3 years ago

@matentzn does this still need attention from CJM?

cmungall commented 3 years ago

I am not sure I am needed for any of this

I already made #1458 but no one commented on it :-).

I think we just need shared agreement between FMA and OBO

dosumis commented 3 years ago

Do we need to arrange a call with someone at FMA to finalise and implement agreement on this? We need resolution for pending work with HCA and HubMap.

cmungall commented 3 years ago

I think so but I would recommend HCA/HM just use the native FMA download PURL and class PURLs, and doesn't depend on OBO registry issues (we'd also need to coordinate with Uberon, and likely switch the Uberon bridge PURLs)

On Fri, Jul 16, 2021 at 2:20 AM David Osumi-Sutherland < @.***> wrote:

Do we need to arrange a call with someone at FMA to finalise and implement agreement on this? We need resolution for pending work with HCA and HubMap.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/OBOFoundry/OBOFoundry.github.io/issues/21#issuecomment-881304563, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAMMOLOEFTFUPF4AQSEMHLTX72XHANCNFSM4BNANH7A .

nlharris commented 3 years ago

What is the status of this? Does someone need to relay info to FMA? What about the linked draft PR, DO NOT MERGE: one solution to FMA problem #21 #1458?

nlharris commented 2 years ago

@matentzn does this still need the nuclear "attn:CJM" label?

matentzn commented 2 years ago

Nope, I removed it. This is now mostly a @dosumis issue.

cmungall commented 2 years ago

Let's just update the entry in obo metadata, unobsolete it and include the following as the text:

This entry is for the official Foundational Model of Anatomy. Note that this ontology differs from other ontologies in OBO, it does not use OBO PURLs. It may also not have the same QC procedures applied, and the ontology may not be compatible with OWL reasoners. See https://github.com/OBOFoundry/OBOFoundry.github.io/issues/21 for details.

Note that previously there was a historic OBO conversion of the FMA that used OBO purls from 2009. This can still be used:

http://ontologies.berkeleybop.org/fma.owl

But note this is never updated, has out of date content, and is not sanctioned by the FMA and may be removed later.

Then at the same time we update purl.obolibrary.org/conf and have fma.owl redirect to

http://sig.biostr.washington.edu/share/downloads/fma/release/latest/fma.owl

We would remove the obo format download.

What we put for the browser is largely irrelevant as there are no more class PURLs to redirect

Is this ideal? Far from it.

  1. we are essentially deleting OBO class PURLs, and adding an ontology to OBO that does not use OBO PURLs
  2. the standards for which annotation properties are used are very different from the rest of OBO
  3. there are vastly different modeling patterns. See for example the branch 'General anatomical term' or 'Deprecated term'
  4. the current OWL version of FMA above is logically incoherent, which will cause problems for any pipeline using a reasoner

However, it is far better than the current situation, and we can implement it immediately, so let's do it, but let's email the FMA group first for confirmation.

Note the Uberon group can work on making new coherent version of FMA that follows OBO practice, for use in projects like hubmap and hca. However, this becomes an uberon / anatomy ontology group problem and we can close this issue.

cc-ing @graybeal this brings us closer to bioportal which is showing the latest fma (5.0.0 from 2019), although bioportal shows the UMLS version which lacks some axioms in the full OWL (which actually has the advantage of being coherent)

As an aside, for information purposes, no action required for OBO purposes, here is an example explanation of an incoherency:

image

image

matentzn commented 2 years ago

I will leave this up to @dosumis and his team to deal with once they get deeper into Human Anatomy land.

lschriml commented 2 years ago

Looping in Melissa Clarkson who is working on the FMA to this conversation.

Sent from my iPhone

On Dec 14, 2021, at 7:07 PM, Chris Mungall @.***> wrote:

 Let's just update the entry in obo metadata, unobsolete it and include the following as the text:

This entry is for the official Foundational Model of Anatomy. Note that this ontology differs from other ontologies in OBO, it does not use OBO PURLs. It may also not have the same QC procedures applied, and the ontology may not be compatible with OWL reasoners. See #21 for details.

Note that previously there was a historic OBO conversion of the FMA that used OBO purls from 2009. This can still be used:

http://ontologies.berkeleybop.org/fma.owl

But note this is never updated, has out of date content, and is not sanctioned by the FMA and may be removed later.

Then at the same time we update purl.obolibrary.org/conf and have fma.owl redirect to

http://sig.biostr.washington.edu/share/downloads/fma/release/latest/fma.owl

We would remove the obo format download.

What we put for the browser is largely irrelevant as there are no more class PURLs to redirect

Is this ideal? Far from it.

we are essentially deleting OBO class PURLs, and adding an ontology to OBO that does not use OBO PURLs the standards for which annotation properties are used are very different from the rest of OBO there are vastly different modeling patterns. See for example the branch 'General anatomical term' or 'Deprecated term' the current OWL version of FMA above is logically incoherent, which will cause problems for any pipeline using a reasoner However, it is far better than the current situation, and we can implement it immediately, so let's do it, but let's email the FMA group first for confirmation.

Note the Uberon group can work on making new coherent version of FMA that follows OBO practice, for use in projects like hubmap and hca. However, this becomes an uberon / anatomy ontology group problem and we can close this issue.

cc-ing @graybeal this brings us closer to bioportal which is showing the latest fma (5.0.0 from 2019), although bioportal shows the UMLS version which lacks some axioms in the full OWL (which actually has the advantage of being coherent)

As an aside, for information purposes, no action required for OBO purposes, here is an example explanation of an incoherency:

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

nlharris commented 1 year ago

Are there still actions required to close this ticket?

lschriml commented 1 year ago

Has the FMA group responded/provided feedback ?

cmungall commented 1 year ago

We need to do something about this situation, we are confusing the community here.

cmungall commented 1 year ago

@trapperkeeper - looks like FMA is no longer available from http://sig.biostr.washington.edu/share/downloads/fma/release/latest/fma.owl?

cmungall commented 1 year ago

OK, here is a reminder of where we are, and some paths forward.

Currently the version of FMA from OBO class and ontology PURLs is a very old subset I made over a decade ago. We need to deprecate this product ASAP. I made the subset when there was no official FMA OWL, since then the FMA team have made an OWL product available. However:

Option 1: Keep a live entry in OBO with a link to bioportal

We would keep the current FMA entry in the metadata, the products field would be an empty list, and the textual description would have a link to bioportal and the bioportal download URL. There would be some minimal text explaining the history, explaining the special status of FMA in OBO

Ontology browsers such as OLS and ontobee would not get the official version from an OBO PURL, they would add an additional entry to their own registries.

We would add redirects for the class PURLs to go to a designated ontology browser.

Option 2: mark entry as deprecated

Mark the entry as deprecated and state that FMA is not part of the OBO library - making it clear this is not a reflection of quality or content, it is purely a technical decision regarding use of a common technical framework.

As for 1, we would add redirects for the class PURLs to go to a designated ontology browser (perhaps with different http redirect code?)

Option 3: engage the FMA team to use OBO PURLs and make FMA fully part of OBO

Seems unlikely, see this thread

matentzn commented 1 year ago

@deepakunni3 can you drive this issue forward?

The first thing is to read the meeting minute notes and figure out what the best way forward is. I think @lschriml wanted to double check what the concrete status today is of FMA (not in the sense of "we have plans to revive FMA at some point in the future, but concrete evidence that it is currently active). If that is negative, we can go with option 2.

I think no matter what we do, we should do option 1 anyways; I think @deepakunni3 you can make a PR to that end. This is safe, it merely gets rid of the ancient obo FMA. Note there needs to be an update in the purl config as well.

lschriml commented 1 year ago

My suggestion was that the OBO Foundry contact and speak with the FMA. @cmungall -- as you have been leading this task so far, would contact the FMA.

brinkleyjf commented 1 year ago

After reading more about how OBO works I have unzipped fma.zip so that fma.owl is now available directly from http://sig.biostr.washington.edu/share/downloads/fma/release/latest/fma.owl. (The same file is still downloadable from Bioportal). However, the file is 254M so it takes awhile to download. The zip file, which also contains fma puns, is only 9.6 M. And FMA URIs like http://purl.org/sig/ont/fma/fma62955 (Anatomical Entity) still resolve to our local FMA browser.

PS For those who don't know me I'm the longtime director of the Structural Informatics Group (SIG) and am now the only one maintaining the SIG website (http://si.washington.edu), which also has the downloadable FMA and the FMA browser via redirects. If Onard Mejino supplies me with any new versions I'll be the one who adds them to the site. I really like the idea behind the OBO Foundry, especially the idea of linking ontologies and data, so I'll be happy to work with you to help that happen as much as possible, even if we don't have the resources to make the FMA fully compliant with OBO Foundry principles.

cmungall commented 1 year ago

Thanks Jim. The 254M is fine, it's better to have the ontology PURL be unzipped as the whole OWL infrastructure works better that way.

Note also that in fixing the sig URL you have also fixed the canonical ontology PURL http://purl.org/sig/ont/fma.owl - thank you!

From the email thread, it's still not entirely clear to me if you are still considering moving to OBO class PURLs, or if that is off the table? It sounds like you do not have resources for this.

I'm also still not entirely clear on the difference between the different versions. Clearly the files from your site are the same regardless of whether compressed or not. But my reading of the thread is that the sig version uses OWL punning whereas the bioportal version does not? It's important for us in OBO to have clarity on the different versions. We can absolutely have different download links in OBO, so long as each product is clearly described. But maybe I misread and all versions are the same?

Note things like punning are not necessarily an issue, but as I mentioned previously, the OWL is unfortunately incoherent (in the technical not pejorative sense). If you run a reasoner you will see many unsatisfiable classes. We can help you resolve these - but we should be sure we have a strategy in place to avoid them popping up again if Onard does make any new releases.

Thanks for your information. Here are the options moving forward

  1. We retain the FMA entry in OBO, but extend the OBO metadata so we can have non-OBO PURLs in the system. We have the existing OBO class purls redirect to FMA class PURLs like http://purl.org/sig/ont/fma/fma62955, and we redirect the OBO ontology PURL to the official purl.org/sig one. We put a note on the page that the ontology is known to have unsatisfiable classes and include instructions on how to repair using ROBOT
  2. the OBO/anatomy team creates a variant of the official FMA that has OBO PURLs, fixes the unsats, and potentially rewires some of the relations to RO. We commit to syncing this with any future releases of FMA (which may be unlikely)
  3. As 2, but Jim/the SIG team does this [seems unlikely given current resources]
brinkleyjf commented 1 year ago

Chris, some responses: OBO vs FMA purls I basically need to understand the pros and cons of this better, and also talk with others like Todd, Onard and Melissa Clarkson. I know the biggest issue in the past was our belief that alot of people are already using the FMA purls, so it would be a pain for them to change. I don't know how many are actually using them though. Seems like it would be relatively easy for you or someone to write a script to replace the purls in fma.owl with OBO purls, and the FMA would still get credit since OBO purls have the source ontology in them. But if alot of people are already using fma purls that could be a problem. How important it is for OBO to use only obo purls for the goals of linked data to be achieved? I saw somewhere you have made an exception for NCIT. Could the FMA be another such exception as you suggest in your option number 1?

FMA puns I am pretty sure fma.owl on our site is the same as in Bioportal, ie no puns. pun_fma.owl is a separate file that can be imported into fma.owl. I modified the description of fma resources at http://si.washington.edu/content/summary-fma-resources in order to better explain this.

Inconsistencies in reasoning Seems like these should be removed even in our current release, but I don't know how hard it would be to do that, or how doing so would affect the content. I'll check with Todd and Onard to see what they did. My vague recollection is that the reasoner never completed, but maybe they fixed that. Maybe your ROBOT tools could do better.

Your options These seem to be about the same as your earlier ones, except that you can now include a "product" in the metadata since fma.owl is again accessible. Option #1 seems like the best near-term solution until we all can figure out the issue of purls. I like the suggestions in #2 but will need to understand the implications better. And you are probably right that we don't have the resources for #3, although I would be interested in being involved in some way in the process.

I'll keep looking into this, and talk to others on the FMA team, maybe more with you and other members, in order to better understand these options.

brinkleyjf commented 1 year ago

Chris etal, Sorry I've taken so long to follow up on this, but if I'm honest I think my delay is in itself a response. I have finally gotten around to talking with the main developers of the FMA: (Cornelius Rosse, Onard Mejino, Todd Detwiler, and Melissa Clarkson), and they basically concur with what follows.

There is currently no one working on the "official" UW version of the FMA, and there is not likely to be anyone working on it. We are all retired or working elsewhere, and I (and I believe all of us) have become distracted by too many other things. Thus, the UW can't meet many of your criteria for inclusion in OBO, one of the most important being that the team be responsive to requests for change. I just don't see that happening, nor do I foresee anyone from our group taking on a task like converting the FMA URIs to OBO URIs. So here are some suggestions from us regarding: 1) The current UW FMA, and 2) FMA-OBO as the vehicle for moving forward with FMA content.

The current FMA This is essentially your option #1, treating the FMA as an inactive artifact that nevertheless could be of use to others because of its history and the availability of FMA Ids. As long as Bioportal is running the FMA should continue to be available there. And it will also continue to be available at our own site via a browser and SPARQL endpoint as long as the server I've been maintaining stays up. So far, I plan to keep that server going since it requires minimal effort, but I can't guarantee how long that will go on. If possible, you might use the Bioportal address as the main place to get the FMA and add the UW address as a secondary source (with the notation that the versions are the same in both cases).

FMA-OBO Many people, including you, have pointed out issues with the current FMA that make it difficult to add it as a full-fledged member of OBO. So, one possibility might be for someone in OBO to make a clone of the current FMA, called FMA-OBO, and fix some of the issues that have been raised. These would primarily include changing all the URIs to conform to OBO conventions, fixing errors that prevent the reasoner from working, and submitting FMA-OBO to the OBO GitHub repository. This is essentially your option 2, except that it would be for the clone FMA-OBO, not the original UW FMA.

Ideally, someone could then take over FMA-OBO and respond to requests for change. If someone becomes available to do this, the UW would be willing to freeze the UW FMA to the current version 5.0 (it’s essentially frozen already), and if anyone, including Onard, wants to add to or edit it, he or she would agree to do so in FMA-OBO via the OBO methods. The UW would also put a note on our web page saying that the UW FMA is frozen at version 5.0, is no longer being developed, and any new developments or requests for change should go through OBO and OBO-FMA.

We would also request that within FMA-OBO, proper credit be maintained to the UW FMA as the original source of FMA-OBO, and a computable mechanism be established for relating FMA IDs to FMA-OBO – possibly as annotations within FMA-OBO, a translation service, or both.

All of us appreciate your interest in the FMA and your desire assure its viability among the OBO family. We hope that it will be possible to implement the modifications needed to transform the current version of FMA into FMA-OBO.

Any thoughts?

Jim - and the rest of the FMA team

cmungall commented 1 year ago

Thanks @brinkleyjf and the FMA team! This all makes sense.

Here is my recommended action:

brinkleyjf commented 1 year ago

Chris, Your recommendations sound fine, but I don't hear much about FMA-OBO, which would be yet a third version of the FMA: 1) FMA-UW, the original FMA, as per your first three points above; 2) FMA lite, which is the old version you already have, and is very outdated, but could be needed for continuity as your note in your 4th point; and 3) FMA-OBO, which would be a complete copy of the current FMA-UW Version 5.0, with URI's replaced by OBO URIs, and reasoning problems fixed. Sounds like your last point indirectly refers to that.

In your comment on March 3, your point 2 suggests "the OBO/anatomy team creates a variant of the official FMA that has OBO PURLs, fixes the unsats, and potentially rewires some of the relations to RO. We commit to syncing this with any future releases of FMA (which may be unlikely)".

Is it possible for you or members of your team to do that? If you did you wouldn't have to worry about syncing with any future releases of the FMA since the UW would commit to freezing any further development beyond version 5.

At least initially I think this path would mostly be a programming task as you probably already did with OBO lite. Even if no anatomy group wanted to take it on right away this version of the FMA could at least be available as a more OBO-compliant version of FMA-UW, would be accessible via GitHub and the OBO ecosystem, and would be the basis for further development. That in itself would be a great help to us, since we are trying to find a way to pass the torch to a group who can include it in a larger effort than we’ve been able to do with our small team.

In any case, your ideas for the FMA-UW and FMA lite seem very doable, and from your last point it sounds like OBO will keep the door open for further development. I just think this further development would be more likely if a computationally-derived FMA-OBO were available.

I and others on our team would be happy to discuss this further.

Jim

dosumis commented 6 months ago

Hi all, Given how long this has sat around, we have decided to request addition to OLS4 in it's current form. We will need some way to name it to distinguish from the old OBO translation which is still the only FMA on OLS4. If there is movement on this soon OLS could take FMA with the new IDs, otherwise we will take as-is.

dosumis commented 6 months ago

@jamesamcl

brinkleyjf commented 6 months ago

David, As I wrote in my comments on 7/31/23 I was hoping that someone from OBO might take on the programming task of converting FMA ID's to OBO IDs to create FMA-OBO (ie a translation of the full FMA-UW into OBO format), since the UW won't have the resources to do so in the forseeable future. Sounds like thats not going to happen (and I didn't really expect it to since I think the world is moving on to other things since the FMA was active), so I agree with your plan to incorporate FMA-UW as is into OLS - which I presume means Ontology Listing Service - keeping the original UW FMAIDs.

So that would mean there will be two versions of the FMA accessible from OBO (or OLS):

  1. FMA-UW, frozen at version 5.0, and currently available at Bioportal and our UW website http://purl.org/sig/ont/fma.owl
  2. FMA-lite, the OBO compliant version that Chris Mungall created several years ago.

If anyone ever does programmatically create a mostly OBO compliant version of FMA-UW (which I called FMA-OBO above), this could replace or augment FMA-UW in OBO. But until and if that happens I think your plan to incorporate FMA-UW as is (without OBO-compliant IDs) make the most sense.

(And thanks for doing so).

Jim