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 4.0: How to efficiently query classes and their superclasses

Paul R Alexander palexander at stanford.edu
Thu Oct 17 10:32:18 PDT 2013


Erik,

We are still evaluating ways to improve the system performance for the new API. One of the things we can look at is raising the page size on the /classes call sot hat less calls would be required. There are also some parameters that we haven't exposed yet that turn off the extra hypermedia links and JSON-LD context information. Try appending "no_context=true&no_links=true" if you can live without this information.

Paul


On Oct 17, 2013, at 1:33 AM, Erik Fäßler <erik.faessler at uni-jena.de> wrote:

> Paul,
> 
> thank you very much for your answer. It is good to hear there will be a SPARQL endpoint at some time. The main reason I ask for it is that while the new API is very clear and easy to use, it takes a lot of time scrolling through the pages (max-size pages) of a middle-sized ontology compared to the respective SPARQL-query if you want to retrieve all classes with their preferred name, synonyms, description and their subClassOf relation.
> 
> I'll observe how things evolve and change my algorithms accordingly, if it will make sense. Thanks again for your time!
> 
> Best,
> 
> 	Erik
> 
> On Oct 16, 2013, at 7:27 PM, Paul R Alexander <palexander at stanford.edu> wrote:
> 
>> Erik,
>> 
>> The SPARQL endpoint will eventually be updated to match the data that we are using in the API. This will likely break older SPARQL queries because we've changed the structure and naming of the data.
>> 
>> In terms of what might be faster, it would depend on exactly which task you were doing. Either way, we won't ever support the SPARQL endpoint as production-capable service.
>> 
>> The service for Ontology Recommender exists in the new API, unfortunately we neglected to document it. Basic usage is as such:
>> http://stagedata.bioontology.org/recommender?text=melanoma
>> 
>> We'll get documentation up for it soon.
>> 
>> Paul
>> 
>> 
>> On Oct 4, 2013, at 1:02 AM, Erik Fäßler <erik.faessler at uni-jena.de> wrote:
>> 
>>> Paul,
>>> 
>>> I understand it's work in progress, I will observe how things evolve with interest.
>>> 
>>> Another question concerning the same general topic: Before the release of BioPortal 4.0 I was using the SPARQL endpoint at http://sparql.bioontology.org/ to achieve the same thing I'm now trying the new API for.
>>> I have to confess, I'm a bit confused about what is replaced by the new API and what is not. So the question is: Will die SPARQL endpoint mentioned above continue to exist and will it be updated with new ontologies? The SPARQL endpoint seemed to be faster at my specific task before BioPortal 4.0 than the new API.
>>> Similar question concerning the Ontology Recommender: Is there an equivalent in the new API or will the old API call be supported in the future?
>>> 
>>> Sorry for such basic questions, I am sure I just missed some information you already gave to the public. Please bear with me :-)
>>> 
>>> Best,
>>> 
>>> 	Erik
>>> 
>>> On Oct 3, 2013, at 7:04 PM, Paul R Alexander <palexander at stanford.edu> wrote:
>>> 
>>>> Erik,
>>>> 
>>>> We've been evaluating how to make some of these calls more efficient in terms of the data being provided back while still being performant at the database level. We'll also evaluating adding some more advanced means of controlling the type of information available in 'embedded' data.
>>>> 
>>>> Thanks for the suggestions and feedback, they are much appreciated.
>>>> 
>>>> Best,
>>>> Paul
>>>> 
>>>> 
>>>> On Oct 2, 2013, at 12:12 AM, Erik Fäßler <erik.faessler at uni-jena.de> wrote:
>>>> 
>>>>> Paul,
>>>>> 
>>>>> thanks for your answer. I don't think there is a bug, I just understood it wrong: Since my data had a field "parents" with an URL, I thought this already would be the attribute. Now I see, it's not, or just the link to the actual attribute. When I add the include=parents parameter, I get the actual parent data. So this works, thank you!
>>>>> 
>>>>> Now you're right the output is going to explode for many parent classes. I was hoping for a possibility to restrict the parent data to just the ID. Is this possible somehow? I don't need the whole records because I am querying all classes anyway. In other words: I successfully retrieved the nodes of the taxonomical graph, now I'd like to get the edges in the most concise possible form, i.e. ordered pairs (source, target) or (class1Id, class2Id).
>>>>> 
>>>>> Alternatively it could be useful to be able to restrict the parent-record-output. Perhaps in the manner of an additional parameter dependent on the queried attribute. What I mean is, currently I am appending the
>>>>> 
>>>>> include=parents
>>>>> 
>>>>> parameter. If I now could do something like
>>>>> 
>>>>> parents.include_exclusively=id
>>>>> 
>>>>> which would cause the parent attribute to omit all attributes other then the "id" attribute, the output explosion wouldn't be so bad.
>>>>> 
>>>>> I hope I made myself understandable. Anyway, I am now able to accomplish what I need with the new API, thank you very much!
>>>>> 
>>>>> Best regards,
>>>>> 
>>>>> 	Erik
>>>>> 
>>>>> On Oct 1, 2013, at 7:55 PM, Paul R Alexander <palexander at stanford.edu> wrote:
>>>>> 
>>>>>> Erik,
>>>>>> 
>>>>>> If you request the classes call with the attribute `parents` included, you will get back parent classes. This can cause the output to explode if you are working with an ontology that assigns many parents to single classes.
>>>>>> 
>>>>>> Here is an example:
>>>>>> http://data.bioontology.org/ontologies/GEOSPECIES/classes?include=parents
>>>>>> 
>>>>>> You can add other attributes of interest in the `include` parameter as well (prefLabel, for example).
>>>>>> 
>>>>>> If adding `include=all` to your request does not increase the amount of content you see, then it is likely a bug. Typically, we try to provide information we think users would like to see and oftentimes what is hidden is data used for internal NCBO processing.
>>>>>> 
>>>>>> I'm glad you like working with the system. Ease of use and clarity for developers was one of our overarching goals for BioPortal 4.
>>>>>> 
>>>>>> Best,
>>>>>> Paul
>>>>>> 
>>>>>> 
>>>>>> On Oct 1, 2013, at 2:41 AM, Erik Fäßler <erik.faessler at uni-jena.de> wrote:
>>>>>> 
>>>>>>> Dear all,
>>>>>>> 
>>>>>>> before BioPortal 4.0 went available, I was working with the BioPortal SPARQL endpoint to retrieve classes together with their superclasses to be able to store the taxonomical graph. This was done simply be the respective SPARQL query where I could query the classIri and the superClassIri, so I always knew which class had which super class(es).
>>>>>>> 
>>>>>>> With the new API, I'm not sure how to do that in an efficient manner. That is, I see how I can get all classes of an ontology quite easily and I also see the link to the parents. But since it is only a link, I would have to issue a new HTTP query for each class in the ontology. This will take some time and cause load for the HTTP server on side of BioPortal.
>>>>>>> 
>>>>>>> Thus I'd like to ask whether there is a more concise method of getting classes and their respective super classes.
>>>>>>> 
>>>>>>> Beside of this, I'd like to thank you very much for the new API, it is very clear and easy to use. Especially if you have to learn SPARQL first when using the SPARQL endpoint ;-)
>>>>>>> 
>>>>>>> Only thing that occurred to me with the new API is that the documentation says there would be default attributes which would be given and if one wanted to get all attributes, one had to define this separately. It seems, however, that I always get all attributes without asking for them. This can easily be seen when clicking on the example links in the documentation. But also when querying programmatically without setting any header (other than the API key) and without setting any REST parameters, I always retrieve all attributes in the responses.
>>>>>>> 
>>>>>>> Best regards,
>>>>>>> 
>>>>>>> 	Erik
>>>>>>> _______________________________________________
>>>>>>> bioontology-support mailing list
>>>>>>> bioontology-support at lists.stanford.edu
>>>>>>> https://mailman.stanford.edu/mailman/listinfo/bioontology-support
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 



More information about the bioontology-support mailing list