Hi Henning<br><br>Sorry I should have mentioned some of the things I&#39;ve been doing. First of all just to say this is all work in progress, so none of the things I commit have to be taken as they are so anybody please feel free to modify things. <br>
<br>Ok the questions one by one, I&#39;ll see if I can answer:<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

- For the classes that implement some interface, you had @Override<br>
annotations for all implemented methods (I guess your Eclipse is doing<br>
that automatically). For some reason, my Eclipse is giving me<br>
compilation errors (not even warning) and asks me to remove the<br>
annotations. Do you have an idea why that could be happening? Do you<br>
get warnings for missing annotations when you check out my latest<br>
changes? (I have seen something like this happening)<br></blockquote><div><br>Yes I&#39;ve seen this kind of problems too. I get no warnings here at all. Could you check if you are using a 1.6 compliant level for the compilation? (I have 1.6 here and I&#39;d say it&#39;s a good idea to keep it 1.6 compliant as 1.6 has been out for quite a while). Go to Window-&gt; Preferences-&gt; Java-&gt; Compiler-&gt; JDK compliance. Other than that it could only be the version of eclipse (I&#39;m using 3.5.2). Let me know what you find.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
- Your UniprotHomolog is using a local standalone blast database,<br>
right? So you will have to use formatdb and make sure that you use a<br>
current Uniprot DB. Apart from the effort to create that DB, that is<br>
actually nice, because the results will be reproducable. I had been<br>
using the Uniprot Java API which can also do blasting against the<br>
online Uniprot (mutanom.UniprotConnection). This is nice but the<br>
results change with every Uniprot update, which is sometimes not<br>
optimal.The reason why I havn&#39;t moved UniprotConnection to OWL yet was<br>
that it requies lots of external jars to function properly and I was<br>
hesitating whether it&#39;s worth it. Eventuelly we should probably move<br>
it there. What are you using currently to retrieve the actual Uniprot<br>
entries identified with blast? The perfect solution would be a class<br>
which can use both online and offline Uniprot versions so you can<br>
switch depending on the purpose. Maybe even parsing Uniprot text<br>
format would do. Any success on that?<br>
<br></blockquote><div><br>Ok sorry I should have told you what I&#39;ve been doing here. I did already commit your UniprotConnection class with all its dependencies... I thought it was really nice and it was a pity not to have it in (and I needed exactly that for the project I&#39;m working on ;-) ). So basically I&#39;m using it to retrieve Uniprot info and even I put a new method in to read multiple entries (provided in the API). What I didn&#39;t do was redirect your structuralimpact code to the new class in owl. <br>
<br>What I&#39;m then doing is using this UniprotHomolog to store sequence and related data (at the moment blast hit, taxonomy id, associated embl cds sequences, uniprot ids). I need local blast for this because it&#39;s a lot of queries that I&#39;m doing. Then I use your UniprotConnection to get related data like the EMBL CDS identifiers or the taxonomy id. The name UniprotHomolog was the best I could come up with.<br>
<br>Another thing I commited is owl.core.connections.EmblWSDBfetchConnection which is a web service that EMBL provides to get data using simple URLs. At the moment you can retrieve with it Uniprot sequences or EMBL CDS sequences (DNA coding sequences). I also use it in UniprotHomologList to retrieve the EMBL CDS.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- The SiftsFeature for mapping Pdbs to Uniprot sequences is really<br>
nice. How do you get the mapping then? Shall we move my SiftsMapping<br>
class to OWL (maybe calling it SiftsConnection)?<br>
<br></blockquote><div><br>Ok here as usual I&#39;m working as I go along... The SiftsConnection class does the parsing of the local/remote SIFTS file. Then it stores it all in a Map in memory and you can then query it and it returns SiftsFeatures (which are actually just mappings of pdb sequences to uniprot sequences, essentially the same as your SiftsMappings class). Those you can then add to a Pdb (see owl.tests.core.connections.SiftsConnectionTest for an example). I&#39;m really not sure whether SiftsFeature is an appropriate name for the mappings but after giving it some thought that&#39;s the best solution I came up with. Please feel free to restructure/refactor any of this if you have clearer ideas about how to do it. (BTW perhaps SiftsFeature should belong in owl.core.structure.features instead of owl.core.features)<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- Once you have selected the appropriate protein from your<br>
UniprotHomologs, do you have a UniprotEntry class which owns the<br>
SiftsFeatures? Otherwise shall we create one in owl.core.sequence?<br>
<br></blockquote><div><br>No I don&#39;t but as I say I was really confused about how to structure all this. All I&#39;m doing now is adding SiftsFeatures directly to Pdbs, but I haven&#39;t used that yet anyway. I guess if one would use it a lot more things would be needed like an alignment to proper map pdb to uniprot and so on. Ideas welcomed as usual.<br>
<br>Cheers<br><br>Jose<br></div></div><br>