RSS Feed for ComparaGrid

ComparaGrid

• More Runcible GUI progress
  I'm off on holiday for the rest of this week so I thought I'd post an entry to describe how the GUI is coming along. I've been busily working my way through the ever-growing list of issues in the GUI over the last week or so, and it's eventually starting to come down. I'm pretty confident the GUI should work in a stable manner for building a mapping rules document in the format Matt expects to feed these rules to runcible. Trevor and I have seen one or two slightly unusual things with nodes "floating away" after the rules have been saved (so in other words the rules haven't saved some object properties. I've as yet not been able to replicate this problem in a new mapping though, so if anyone sees this (Trevor, this is probably you) it would be helpful if you could report an issues letting me know exactly whats going on. Other than that, I've now added a wizard to replicate chunks of the rules tree on restricted nodes, a new style dialog for giving specifying node names which only accepts unique names without any dot-illegal characters, the ability to rename nodes, and made sure post-mapping changes do get stored. The wizard can be invoked whenever the user clicks on a restricted object node in the source window (so any double-octagon). This then presents you with a set of simple options, first to add a new restriction (replacing the custom restrictions on the original node), then to specify the new nodes name, then to add a prefix to all the nodes in the subtree. Then the entire branch of the tree selected gets duplicated creating a new set of nodes with the same relationship. This should considerably speed up the process of creating mappings when you need to select out several chunks of rows from one table. The new dialog simply checks the string the user enters, automatically prefixes it with a "?" as I decided this is a neat way to show that these nodes aren't "real" class names but are selections from a class, and highlights the entered name red if it contains any characters that aren't legal (mainly because dot doesn't like them). It won't allow you to exist the dialog unless you've specified a legal name. Renaming nodes is simple - double click on an existing node, you get a "rename" version of the new dialog mentioned above). You can then enter a new node name and accept it, which then automatically redraws the graph. Post-mapping changes was a bug we noticed due to the rules being created only when the user dragged an arrow to trigger the rules events. This meant once you carried out any action which affected a node that had already been mapped (adding restrictions, fixing types, changing node names (now) those changes weren't reflected in the rules document. I've fixed this by adding a new command type so now they are pushed through, the graph gets redrawn and the document can be saved. Because of the way I have designed the command system, all these changes are undo-able, although there is a slight problem with adding restrictions. As the GUI still uses the Protege owl-api, adding restrictions to a class changes the ontology. This makes it tricky to keep track of, and undo these changes - at the moment if you add some restrictions to a class they are even after you undo the change in the graph. Hopefully this issue will go away when I move the GUI to Protege 4 and start using the new api. So now I'm off to the south of France for a week. More coming on the GUI when I get back!
• Runcible GUI
  I've not posted for a while so I thought it was probably time for an update on the progress of the runcible-gui. I've been fixing lots of issues over the last week or so after we tried to use the GUI in anger - well, not really anger, more mild annoyance - at the last developers meeting in Norwich/ This little session led to the discovery of lots of bugs, reasons why it wouldn't work, and adjustments to conform to Matts latest runcible format. I've managed to put most of the critical ones right now. The biggest bugs stopped the GUI being useable at all and these were the ones I've spent most time fixing. So now, we should be able to use the GUI to generate some mapping rules which we can distribute between ourselves and view without causing anything to go badly wrong. There are still some smaller bugs to fix, that I'm working on, and some design/useability issues that I still have outstanding. So if anyone (probably Trevor really) tries the GUI out and finds any bugs, or has any requests to make it better that aren't already in the issue tracker, please let me know!
• Stack building problems with Java 1.6
  I discovered by accident that the stack won't currently build with Java 1.6 today. I was trying to build the stack on my laptop and after some continual barfing over the fluxion-annotations module (along the lines of javac: can't find directory ..../target/generated-sources/apt) I fixed it by reverting to java 1.5. I guess that'll teach me to jump in with new java versions...
• Description of Postgres Databases on deanmoor
  "blastresults" 1. blastresults.public schema: I have used these tables to store the experiments pig BES to human chromosome pig BES to cow chromosome Details of the parameters of blast analyses Table "public.blast_details" Column | Type | Modifiers -------------------+------------------------+----------- id | integer | not null program | character varying(20) | version | character varying(50) | date | date | source | character varying(20) | external_database | character varying(50) | e_threshold | double precision | match_score | integer | mismatch_penalty | integer | gap_open_score | integer | gap_extend_score | integer | filters | character varying(50) | restrictions | character varying(100) | Indexes: "blast_details_pkey" primary key, btree (id) Details of the sequences used as query and target in the analysis Table "public.sequences" Column | Type | Modifiers ---------------------------+------------------------+----------- id | integer | not null genbank_idstring | text | genbank_gi | character varying(20) | genbank_accession | character varying(20) | genbank_accession_version | character varying(20) | name | character varying(100) | length | bigint | base_sequence | text | species | character varying(20) | Indexes: "sequences_pkey" primary key, btree (id) Details of indivicual blast hits over the threshold given in the blast_details table Table "public.blast_hits" Column | Type | Modifiers --------------------+-----------------------+----------- id | integer | not null blast_details | integer | not null query_sequence_id | integer | not null target_sequence_id | integer | hit_bitscore | double precision | hit_score | double precision | hit_evalue | double precision | hit_query_from | bigint | hit_query_to | bigint | hit_query_frame | integer | hit_target_from | bigint | hit_target_to | bigint | hit_target_frame | integer | hit_align_length | bigint | hit_gaps | bigint | hit_identity | bigint | hit_positive | bigint | query_species | character varying(20) | target_species | character varying(20) | Indexes: "blast_hits_pkey" primary key, btree (id) Foreign-key constraints: "$1" FOREIGN KEY (blast_details) REFERENCES blast_details(id) "$2" FOREIGN KEY (query_sequence_id) REFERENCES sequences(id) "$3" FOREIGN KEY (target_sequence_id) REFERENCES sequences(id)
• The Multiple schema problem...
  I've spent some time this weekend pondering this multiple schema problem and I've come up with a couple of solutions which I think are the best ways to represent a database with multiple schemata in OWL. Firstly, I can generate an OWL class in the ontology to represent classes within a schema (so something like an "OWL:SchemaThing"). We can then attach stuff like the schema name to this class, and then all classes that represent tables within a schema would inherit from this schema class. This pads our class hierarchy a bit, but does allow us to capture the schema of any table in some more robust way then just class naming. Secondly, I could restrict the OWL that gets generated to one-ontology-per-schema. So if a database contains multiple schemata, this would be reflected by multiple ontologies. We can then do some extra stuff on top of this; using OWL imports we can create a "wrapper" ontology that imports a set of single-schema ontologies, enabling us to represent the concept of users having access to multiple schemata. Further, it would be relatively simple to create a composite publisher that publishes these "unified" ontologies. This second approach would be my preference, but I'd definitely be interested in hearing peoples thoughts. I think the natural time to make these changes would be when I switch the publishers over to the OWL 1.1 API (within the next couple of weeks) because I think the support for importing is improved.