mmisw
commented
9 years ago From caru...@gmail.com on September 05, 2012 11:45:03
I've just deployed version 2.0.34.beta (*) with an adjustment that should prevent this from happening again. More specifically, the list of working ontologies for an existing mapping ontology is now populated by first scanning the subjects (LHS entities) of all current mappings (to collect the corresponding namespaces), and then the objects (RHS entities).
Unfortunately, since http://mmisw.org/ont/ioos/map_ioos_cf already has subjects in both the A and B namespaces, then this change won't of course be a fix for it. To reduce the potential confusion (but also as a general presentation improvement), the mapping table is now sorted (lexicographically according to the URIs of the subjects, relations, and objects, in that order) so at least all subjects in the same namespace are grouped together.
Status: Fixed
From caru...@gmail.com on September 04, 2012 08:21:31
The summary tries to capture the essence of the following thread.
On Aug 24, 2012, Emilio M. wrote:
On August 30, 2012, Carlos wrote
Thanks for this interesting observation. The key idea for a possible explanation is that the tool preserves the (subject, predicate, object) order of the entered mappings, while the user has some flexibility to indicate what goes under the subjects (left) side of the interface and what goes on the object side.
I hope there is no bug here, but of course please let me know if you think otherwise.
An overall mapping workflow and possible explanation for this "mixed" presentation is as follows:
0) user selects two ontologies, which are abbreviated A and B by the tool. By default, searches on the left and right panels will be on the A and B ontologies, respectively. (but the tool allows to select which ontologies to search on each side). 1) user does a search on the left and a search on the right. All found terms are prefixed A: and B: on the left and right, resp. 2) user selects particular terms on the left (say just A:/x for simplicity) 3) user selects terms on the right (say B:/y) 4) user clicks the desired relation (say, >). So, the triple (A:/x, >, B:/y) is added to the table.
Steps 1-4) are repeated during the same session culminating in a particular version of the mapping ontology. I note that this particular mapping ontology has undergone a number of versions. Perhaps the searched ontologies switched sides in some of those sessions? If so, a triple like (B:/w, =, A:/z) may have been added to the table, so the table would now contain: (A:/x, >, B:/y) (B:/w, =, A:/z)
A possible improvement for presentation purposes is that the tool exploit the inverse property of the relations whenever possible to try to locate all subjects with the same prefix on the same side: (B:/y, <, A:/x) (B:/w, =, A:/z)
However, two comments:
Sara, can you tell us whether something like the above may have happened? I can then try to investigate further if needed.
On Sep 4, 2012, Sara H wrote:
I changed the subject to reflect nature of this thread. Also, I want to reply before I forget.
Thanks for thinking through the issue with mapping on ORR. I did go through several iterations/versions to complete the mapping. I initially started with IOOS (A:) terms and CF (B:). So I would request A in the left-hand-side panel (LHS) and B in the RHS.
However, at one point (not sure when, second or third iteration/version), when I requested to edit the mapping (create a new version), A and B became switched (CF was in A position and IOOS was in B). I remember it because searching terms on the LHS were NOT IOOS terms. I noted it and selected B (IOOS) terms in the LHS and A (CF) terms on the RHS and continued on thinking this was something that was arbitrary on the import and assignment of A and B would have to be aware of it. Also, I did not do any outside and upload. I only worked within the ORR Mapping Tool.
Not sure it is a bug but might be worth investigating how A and B are chosen when creating a new version from existing one.
Original issue: http://code.google.com/p/mmisw/issues/detail?id=299