|
|
(48 intermediate revisions not shown) |
Line 1: |
Line 1: |
| + | {{Team:USTC_Software/Header}} |
| + | <html> |
| + | <head> |
| + | <style type="text/css"> |
| + | p.normal {font-variant: normal} |
| + | p.small {font-variant: small-caps} |
| + | </style> |
| + | </head> |
| | | |
- | == Chain Sorting and Weighting Scheme == | + | <body> |
- | <font color='Yellow'>liaochen@mail.ustc.edu.cn</font> | + | <p class="normal">This is a paragraph</p> |
| + | <p class="small">This is a paragraph</p> |
| + | </body> |
| | | |
- | Chains in our Chain-Node Model should not have any order since there are no natural ways to sort them. One chain is not
| + | </html> |
- | preferred to another, since in a complex of multiple chains, which are connected via binding interaction of binding bites on their own, all chains are equivalent. However, a chain-sorting program is a prerequisite for implementations of many other functions, such as comparison of two Chain-Node structures, or pattern matching of template species to those with definite structure.
| + | |
- | | + | |
- | | + | |
- | Sorting is always performed under some rules. Since there are no natural options, we design one to generate the unique order for a list of chains. The rule we developed is something like that for comparing two strings: comparing first the '''partRef''' and '''partType''' defined in database of the first part of two chains in alphabet order and if equal, then comparing the next until there are differences or to the end of either chain. For convenience, we generate a '''uni code''' (a string) for each chain by putting their '''partRef''' and '''partType''' attributes one by one, for example:
| + | |
- | | + | |
- | <font color='Yellow'>[placI185:ForwardDNA][RBS147:ForwardDNA][lacI153:ForwardDNA][TE145:ForwardDNA]</font>
| + | |
- | | + | |
- | If one part is binded with another part (a binding site), we will mark it with *, the example above becoms (if placI185 is binded with some part, say lacI153 protein):
| + | |
- | | + | |
- | <font color='Yellow'>[placI185:ForwardDNA:*][RBS147:ForwardDNA][lacI153:ForwardDNA][TE145:ForwardDNA]</font>
| + | |
- | | + | |
- | If '''unicode''' of each chain is different with others, then we could sort the chain list by comparing their '''unicode''' (just the same with comparison of two strings). However, it is not always so: chains with same '''unicode''' may be equivalent or not. It is due to the mark asterisk *. '''Unicode''' knows where are the binding sites, but it does not know the binding details of that part. In other words, '''unicode''' could not soly determines the order of the chains since it lacks of information of the trees defined in our Chain-Node model. The forest (tree set) in Chain-Node Model describes the binding details of parts in chains. We need to find something like '''unicode''' to represent the essence of the associated trees. Our weighting scheme will be first introduced below.
| + | |
- | | + | |
- | | + | |
- | Assume the chains are sorted already. Each part will be assigned a weight based on its position in the chain list. The weight of the jth part on the ith chain is (i,j). For example, the first part on the first chain posses a weight (0,0) (in '''C''' style, counting number from zero). After assignment of parts' weight, we turn to weights of the nodes in trees. Since leaf nodes in trees are actually the representation of parts in binded state on chains, the weight of each leaf node could be inherited from the weight of its corresponding part. For parent node, its weight equals to the maximum of weights of all its children nodes (we define a weight (i, j) is greater than another (i',j') if i < i' or i = i' while j < j').
| + | |