You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The discussion in Issue SynBioDex/SBOL-examples#6 makes it clear that we have a means for handling insertions. I do not believe, however, that we currently have a good way of handling deletions (e.g., due to mutation, targeted editing, or assembly side-effects).
The problem is that ComponentDefinition -> Component -> ComponentDefinition relationships are currently formulated on the assumption that sequences always get larger as you go up in hierarchy. If you make a sequence smaller as it is used in a new context, you cannot include it as a Component in a new CD, but must instead define a different CD for the smaller component. This is awkward and makes relationships unclear between components.
Please correct me if I am wrong. If I am right, however, I believe that a simple fix can be performed by adding an optional "Location" field to Component or ComponentInstance. This would then specify the portion of the original CD to be included in the Component's new CD parent.
The text was updated successfully, but these errors were encountered:
I agree that this appears to be missing. In SBML, there are replacements and deletions. Our MapsTo is effectively a replacement (though I think we need to more clearly define its affect when flattened), but we don’t have a construct for deletion. One option would be to make the Local field of a MapsTo optional. This would then be interpreted as the Remote object is mapped to nothing (i.e., deleted) in the higher-level construct.
On Jan 14, 2017, at 1:42 PM, Jacob Beal ***@***.***> wrote:
The discussion in Issue SynBioDex/SBOL-examples#6 <SynBioDex/SBOL-examples#6> makes it clear that we have a means for handling insertions. I do not believe, however, that we currently have a good way of handling deletions (e.g., due to mutation, targeted editing, or assembly side-effects).
The problem is that ComponentDefinition -> Component -> ComponentDefinition relationships are currently formulated on the assumption that sequences always get larger as you go up in hierarchy. If you make a sequence smaller as it is used in a new context, you cannot include it as a Component in a new CD, but must instead define a different CD for the smaller component. This is awkward and makes relationships unclear between components.
Please correct me if I am wrong. If I am right, however, I believe that a simple fix can be performed by adding an optional "Location" field to Component or ComponentInstance. This would then specify the portion of the original CD to be included in the Component's new CD parent.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#91>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADWD9weCIMAnaNZugF74b1TuvBG-mmC3ks5rSNCsgaJpZM4LjoJ1>.
The discussion in Issue SynBioDex/SBOL-examples#6 makes it clear that we have a means for handling insertions. I do not believe, however, that we currently have a good way of handling deletions (e.g., due to mutation, targeted editing, or assembly side-effects).
The problem is that ComponentDefinition -> Component -> ComponentDefinition relationships are currently formulated on the assumption that sequences always get larger as you go up in hierarchy. If you make a sequence smaller as it is used in a new context, you cannot include it as a Component in a new CD, but must instead define a different CD for the smaller component. This is awkward and makes relationships unclear between components.
Please correct me if I am wrong. If I am right, however, I believe that a simple fix can be performed by adding an optional "Location" field to Component or ComponentInstance. This would then specify the portion of the original CD to be included in the Component's new CD parent.
The text was updated successfully, but these errors were encountered: