<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Dear Paul,</div><div><br></div><div>thanks for looking into this. I have a couple of comments. </div><div><br><blockquote type="cite"><div text="#000000" bgcolor="#ffffff">
I looked into your report of problems with the HTTP PUT and DELETE
methods. We do support these, in fact it's exactly how the reads and
writes to our persistent store work, but it does look like the "raw"
HTTP methods weren't being detected properly. Most of our calls use
"tunneled" methods where you add a parameter to the query string to
indicate which method you're using. For example, adding "method=PUT"
when doing a POST will allow a PUT method to be detected. This is to
support clients that don't implement the HTTP methods fully (most
browsers support GET and POST only).<br></div></blockquote><div><br></div><div>But that kills the purpose of RESTful interface where certain type of actions are supposed to be done by certain types of HTTP requests, e.g. delete actions should be done by DELETE requests. Yes, that's true that most browsers do support only GET and POST, but for browsers you have the BioPOrtal GUI, or one can use RESTful plugins for browsers. Anyway, it's rather a thought ...</div><div><br></div><blockquote type="cite"><div text="#000000" bgcolor="#ffffff">
I've fixed the improper detection in
rev2735.<br></div></blockquote><div><br></div>Thanks<br><br><blockquote type="cite"><div text="#000000" bgcolor="#ffffff"><br>
If there's anything else I can help out with, please let me know.
We're happy to accept bug reports, you can submit them at our
<a class="moz-txt-link-freetext" href="https://bmir-gforge.stanford.edu/gf/project/bioportal_core/tracker/?action=TrackerItemBrowse&tracker_id=103">https://bmir-gforge.stanford.edu/gf/project/bioportal_core/tracker/?action=TrackerItemBrowse&tracker_id=103</a><br></div></blockquote><div><br></div><div>I'm not sure whether this is a bug. But I guess when you set up a new version of BioPortal, new Lucene indexes are not created automatically, that leads that BioPOrtal can't start. On my local machine I have a small patch that checks whether indexes exist at all, and if not bioportl creates an initial version. This patch is useful upon initialization only. Can you recall something like this, or should I rather provide a detailed report in the bug tracker?</div><div><br></div><div><br></div><div>Thanks,</div><div>Vyacheslav</div><div><br></div><br><blockquote type="cite"><div text="#000000" bgcolor="#ffffff">
Paul R Alexander<br>
Web / UI Developer<br>
<a href="http://bioportal.bioontology.org/">NCBO BioPortal</a><br>
Stanford Center for Biomedical Informatics Research<br>
On 9/8/10 4:23 AM, Immanuel Normann wrote:
<blockquote cite="mid:1283945019.9272.293.camel@kant" type="cite">
<pre wrap="">Dear BioPortal support team,
We have installed an instance of BioPortal to store ontologies for our
own project: <a class="moz-txt-link-freetext" href="http://ontologies.informatik.uni-bremen.de/">http://ontologies.informatik.uni-bremen.de</a>
Unfortunately, the BioPortal revision we have taken (revision 1875,
path /tags/1014) turned out to be buggy. We considered to upgrade to
BioPortal 2.5, but deferred that for three reason: 1) the content
migration seems to be not that straightforward (according to a mail by
Paul Alexander) and thus currently to risky for us. 2) The REST API has
changed in BioPortal 2.5, but our partners rely on the REST API of our
current BioPortal. 3) Our main developer, Slava, who takes care for the
BioPortal installation figured out that some (for us fundamental) bug
apparently hasn't been fixed in the latest version: RESTful DELETE and
PUT does not work.
Slava says that to fix this bug is very easy and so he did it on a local
installation. But there are some other bugs that we haven't yet
identified. We came to the decision that the best solution for us is to
check out the stablest BioPortal revision that is still close enough to
our current revision (1875, /tags/1014) so that we do not need to
migrate content and that uses still the same REST API.
Our problem is that we cannot figure out from the revision logs which
revision satisfies our needs. Appearently, it is even unclear to figure
out to what release a certain revision belongs.
We would be very grateful for any clarification!
Thanks in advance,
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset>
bioontology-support mailing list
<a class="moz-txt-link-abbreviated" href="mailto:firstname.lastname@example.org">email@example.com</a>
<a class="moz-txt-link-freetext" href="https://mailman.stanford.edu/mailman/listinfo/bioontology-support">https://mailman.stanford.edu/mailman/listinfo/bioontology-support</a>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div>Best,</div><div>Vyacheslav</div><div><br></div></span><br class="Apple-interchange-newline">