Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[bioontology-support] [BioPortal] Feedback from Andrey Fedorov

Jennifer Leigh Vendetti vendetti at stanford.edu
Wed Feb 21 17:51:32 PST 2018


Hi David,

On Feb 13, 2018, at 5:08 AM, David Clunie <dclunie at dclunie.com<mailto:dclunie at dclunie.com>> wrote:

Thanks for explaining why the DCM "ontology" loads more
slowly initially. In this day and age, loading a flat
list of just under 4,000 entries shouldn't take noticeable
time, IMHO, but I understand that your implementation may not
be optimized for this pattern, and 7 seconds is not that
bad for the first response if it is cached afterwards.

However, through the web browser, if I "jump to" a term
after having loaded the top level, say "Segmentation", it
takes quite a few seconds to actually load the class and
quite a few seconds more to "jump to" it in the list.
Again I understand that this may be lack of optimization
for the "large flat list" case (choice of data structure,
size of nodes, indexing/insertion mechanism, re-sending the
list for the user interface frame rather than moving around
in what was already sent if content unchanged, etc.).


I wasn’t on the team when BioPortal was architected, so I can’t speak with complete authority regarding original design decisions. I think it’s fair to say that the “Classes” tab in the BioPortal user interface wasn’t optimized for things on the far left of the ontology spectrum (catalogs, glossaries). It performs better with things a little farther along the spectrum (taxonomies, thesauri, etc.).

In terms of our REST API though, I’m not aware of any performance issues for ontologies like DCM with little or no hierarchy. The REST API is what applications like radlex.org<http://radlex.org> use to access BioPortal’s data.

If you’d like to verify that statement, I’ve listed example calls below that you can enter into a browser window, all of which are quite performant. Use of our REST API requires an API key, and there are instructions for getting one on our wiki:

https://www.bioontology.org/wiki/index.php/BioPortal_Help#Getting_an_API_key

Example REST calls for DCM

1). Get all classes:

http://data.bioontology.org/ontologies/DCM/classes

2). Get a particular class ("Segmentation"):

http://data.bioontology.org/ontologies/DCM/classes/http%3A%2F%2Fdicom.nema.org%2Fresources%2Fontology%2FDCM%2FSEG<http://data.bioontology.org/ontologies/DCM/classes/http://dicom.nema.org/resources/ontology/DCM/SEG>

3). Search for a particular class (“Linear spiculation”):

http://data.bioontology.org/search?q=Linear%20spiculation&ontologies=DCM



On the other hand, if I search for a term across all ontologies,
e.g., "Segmentation" it is pretty fast and finds the DCM class(es).
I assume this is because it a different index is used.


BioPortal only has one index, where each entry corresponds to an ontology class. The search page in the UI is fast because it’s a straight term search across ontologies. The classes page is slower because we’re issuing a different set of queries in order to place the class in the surrounding hierarchical structure, as well as retrieve associated data for display, e.g. notes, mappings, and properties.



One of these days we may make the DCM ontology into
a proper ontology, but mostly it is used as a grab bag
of independent concepts that are used when we can't find
concepts in a "real" ontology like SNOMED, LOINC, FMA or
NCIt, so it doesn't have a meaningful class "hierarchy" (yet),
and building one hasn't been a priority for us (in DICOM). I
have considered various mechanical ways to do this (e.g., using
the context group (value set) labels as pseudo-classes to
produce at least a two level hierarchy), but I haven't got
very far with that yet.

I haven't used the REST API myself.

The only other data point for speed is the RSNA's RadLex
term browser (http://www.radlex.org/) which is sometimes glacial,
and they attribute that to poor performance of Bioportal,
but I have no direct evidence of that myself, and the alleged
slowness does not manifest when using the Bioportal web
browser directly.

E.g., search for "spiculation" from the top level in the RadLex
ontology in Bioportal and compare that with doing the same at
www.radlex.org<http://www.radlex.org> ... I just tried it again and the latter just
says "Loading" forever, which is not uncommon.

I spent some time looking at the RadLex term browser in Chrome with the developer console open. When you start typing in the search box for the Radlex Tree Browser on the home page, they’re issuing calls to our REST API search endpoint to facilitate the autocomplete functionality. For example, I typed the characters “drain”, and I can see in the Network tab of the developer console a REST call like the following:

http://data.bioontology.org/search?also_search_properties=true&ontologies=RADLEX&q=drain

… (API key parameter removed for privacy). I tested a number of these calls, entering different characters in the search box, and they're all returning in roughly 180 to 300ms. I don’t see any performance issue there.

The only way I was able to reproduce the behavior you describe was to enter a term in the search box, then click the search icon. After clicking the icon, the “Loading…” dialog came up, and stayed up overnight until I finally killed the page. The Network tab showed no further traffic after clicking the Search icon, so it doesn’t appear that anything on the BioPortal side is causing the loading failure.

In order to investigate further, our technical program manager John Graybeal arranged a conference call with one of the main developers of radlex.org<http://radlex.org>. We spoke with him this morning, and via screen sharing were able to show the issue you describe. He acknowledged that it looked to be an issue on their side and is looking into it.

If there are any further issues in radlex.org<http://radlex.org> that anyone thinks are attributable to BioPortal, please don’t hesitate to post on this list.

Kind regards,
Jennifer



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/bioontology-support/attachments/20180222/06d12124/attachment-0001.html>


More information about the bioontology-support mailing list