Menu
▾
▴
[Tm4j-commits] tm4j/src/org/tm4j/topicmap/tmdm/merged MergedTopicMapView.java, 1.1, 1.2
|
From: Xuan B. <med...@us...> - 2008-01-21 19:21:12
|
Update of /cvsroot/tm4j/tm4j/src/org/tm4j/topicmap/tmdm/merged In directory sc8-pr-cvs10.sourceforge.net:/tmp/cvs-serv12342/src/org/tm4j/topicmap/tmdm/merged Modified Files: MergedTopicMapView.java Log Message: Spelling fix: s/wether/whether/ (found thanks to a code-review by Benjamin Bock <bb-...@bo...>) Index: MergedTopicMapView.java =================================================================== RCS file: /cvsroot/tm4j/tm4j/src/org/tm4j/topicmap/tmdm/merged/MergedTopicMapView.java,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 *** MergedTopicMapView.java 21 Jan 2008 11:13:45 -0000 1.1 --- MergedTopicMapView.java 21 Jan 2008 19:21:15 -0000 1.2 *************** *** 430,434 **** Each such commonality link between two topics can be regarded as an edge of a graph where vertices are BasicTopics. The graph is connected. Now this method may remove such a link and divide the graph in two connected subgraphs which are not connected which each other. In this case, and only in this case, the MergedTopic is to be split ! into two MergedTopics. But how to determine (1) wether the split into two connected components happened and (2) which member topics belong to which side? One can view the problem also indirectly by considering a bipartite graph, where one vertex partition are the BasicTopics and another vertex partition are the subjectLocators, and the edges are the --- 430,434 ---- Each such commonality link between two topics can be regarded as an edge of a graph where vertices are BasicTopics. The graph is connected. Now this method may remove such a link and divide the graph in two connected subgraphs which are not connected which each other. In this case, and only in this case, the MergedTopic is to be split ! into two MergedTopics. But how to determine (1) whether the split into two connected components happened and (2) which member topics belong to which side? One can view the problem also indirectly by considering a bipartite graph, where one vertex partition are the BasicTopics and another vertex partition are the subjectLocators, and the edges are the *************** *** 629,633 **** /** ! Returns wether the given MergedTopic is now unknown, not indexed anywhere and basically not reachable from this TopicTopicMapView. This method is only used by assertions. --- 629,633 ---- /** ! Returns whether the given MergedTopic is now unknown, not indexed anywhere and basically not reachable from this TopicTopicMapView. This method is only used by assertions. *************** *** 646,651 **** if (!enablePartialSupport) { // FIXME ! // check wether the topic is used as a reifier ! // check wether the topic is used as a name type, occurence type, association type, association role type, association role player throw new UnsupportedOperationException(); } --- 646,651 ---- if (!enablePartialSupport) { // FIXME ! // check whether the topic is used as a reifier ! // check whether the topic is used as a name type, occurence type, association type, association role type, association role player throw new UnsupportedOperationException(); } *************** *** 699,703 **** // normal unindex ! unindex(mergedTopic); // normal unindex as last, as assertions check wether unindex is successful. //=== atomicize ===// --- 699,703 ---- // normal unindex ! unindex(mergedTopic); // normal unindex as last, as assertions check whether unindex is successful. //=== atomicize ===// *************** *** 782,787 **** MergedAssociationKey newKey = oldKey.changeType(destination); ! assert oldAssociation.getType()==source1; // one should investigate wether this holds when nested mergings occur. Maybe the current destination topic will already be merged with another topic and thus should be replaced? ! assert oldKey.getType()==source1; // one should investigate wether this holds when nested mergings occur. Maybe the current destination topic will already be merged with another topic and thus should be replaced? MergedAssociation mergedAssociation = mergedAssociationByKey.remove(oldKey); --- 782,787 ---- MergedAssociationKey newKey = oldKey.changeType(destination); ! assert oldAssociation.getType()==source1; // one should investigate whether this holds when nested mergings occur. Maybe the current destination topic will already be merged with another topic and thus should be replaced? ! assert oldKey.getType()==source1; // one should investigate whether this holds when nested mergings occur. Maybe the current destination topic will already be merged with another topic and thus should be replaced? MergedAssociation mergedAssociation = mergedAssociationByKey.remove(oldKey); *************** *** 809,814 **** MergedAssociationRoleKey newKey = oldKey.changeType(destination); ! assert oldAssociationRole.getType()==source1; // one should investigate wether this holds when nested mergings occur. Maybe the current destination topic will already be merged with another topic and thus should be replaced? ! assert oldKey.getType()==source1; // one should investigate wether this holds when nested mergings occur. Maybe the current destination topic will already be merged with another topic and thus should be replaced? MergedAssociationRole mergedAssociationRole = oldAssociationRole.getParent().mergedAssociationRoleByKey.remove(oldKey); --- 809,814 ---- MergedAssociationRoleKey newKey = oldKey.changeType(destination); ! assert oldAssociationRole.getType()==source1; // one should investigate whether this holds when nested mergings occur. Maybe the current destination topic will already be merged with another topic and thus should be replaced? ! assert oldKey.getType()==source1; // one should investigate whether this holds when nested mergings occur. Maybe the current destination topic will already be merged with another topic and thus should be replaced? MergedAssociationRole mergedAssociationRole = oldAssociationRole.getParent().mergedAssociationRoleByKey.remove(oldKey); *************** *** 836,841 **** MergedAssociationRoleKey newKey = oldKey.changePlayer(destination); ! assert oldAssociationRole.getPlayer()==source1; // one should investigate wether this holds when nested mergings occur. Maybe the current destination topic will already be merged with another topic and thus should be replaced? ! assert oldKey.getPlayer()==source1; // one should investigate wether this holds when nested mergings occur. Maybe the current destination topic will already be merged with another topic and thus should be replaced? MergedAssociationRole mergedAssociationRole = oldAssociationRole.getParent().mergedAssociationRoleByKey.remove(oldKey); --- 836,841 ---- MergedAssociationRoleKey newKey = oldKey.changePlayer(destination); ! assert oldAssociationRole.getPlayer()==source1; // one should investigate whether this holds when nested mergings occur. Maybe the current destination topic will already be merged with another topic and thus should be replaced? ! assert oldKey.getPlayer()==source1; // one should investigate whether this holds when nested mergings occur. Maybe the current destination topic will already be merged with another topic and thus should be replaced? MergedAssociationRole mergedAssociationRole = oldAssociationRole.getParent().mergedAssociationRoleByKey.remove(oldKey); *************** *** 1068,1072 **** /** ! Returns wether we need to notify a listener that <ul> <li>a topic was split into two topics or</li> --- 1068,1072 ---- /** ! Returns whether we need to notify a listener that <ul> <li>a topic was split into two topics or</li> *************** *** 1085,1089 **** /** ! Checks wether the given ReadableTopicMap is one of the topicmaps this MergedTopicMapView represents. */ protected boolean isRepresentedTopicMap(ReadableTopicMap topicMap) { --- 1085,1089 ---- /** ! Checks whether the given ReadableTopicMap is one of the topicmaps this MergedTopicMapView represents. */ protected boolean isRepresentedTopicMap(ReadableTopicMap topicMap) { |
