Open cmungall opened 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)?
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.
From @trapperkeeper
URL: http://sig.biostr.washington.edu/share/downloads/fma/release/latest/fma.owl tracker: https://bitbucket.org/uwsig/fma/issues
What should the status of the OBO purls be? Both class purls and ontology purls?
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
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.
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
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
any more thoughts on this? http://purl.org/sig/ont/fma.owl still doesn't resolve
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.
Tested link and its resolving
Not sure why this was closed, the issue is still not resolved. OBO is serving an old version of FMA
who could fix this?
take this to an ops call
this is actually a seriously bad problem
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.
$ 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>
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.
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).
Thanks, @trapperkeeper!
Can we now close this issue?
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@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?
@cmungall what are the action items now?
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
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.
@matentzn does this still need attention from CJM?
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
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.
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 .
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?
@matentzn does this still need the nuclear "attn:CJM" label?
Nope, I removed it. This is now mostly a @dosumis issue.
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.
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:
I will leave this up to @dosumis and his team to deal with once they get deeper into Human Anatomy land.
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.
Are there still actions required to close this ticket?
Has the FMA group responded/provided feedback ?
We need to do something about this situation, we are confusing the community here.
@trapperkeeper - looks like FMA is no longer available from http://sig.biostr.washington.edu/share/downloads/fma/release/latest/fma.owl?
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:
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.
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?)
Seems unlikely, see this thread
@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.
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.
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.
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
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.
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
Thanks @brinkleyjf and the FMA team! This all makes sense.
Here is my recommended action:
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
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.
@jamesamcl
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):
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
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