Shifting base coordinates for SequenceAnnotations is more difficult than it should be

[bbartley]

A routine operation in sequence editors is to shift the frame of reference for base coordinates. For example, a user may set the origin of the coordinate system at the multiple cloning site, or they may set it at the origin-of-replication. The origin of the frame of reference is arbitrary, and it possible to shift and re-calculate the location of sequence annotations within this frame of reference.

Currently this is not really feasible with the current representation of Locations. If a user wants to shift the frame of reference for a previously published ComponentDefinition, then the user must copy and mint a new ComponentDefinition (see below). This operation is contrary to the principle of re-use that SBOL aims to facilitate.

There are other cases where it is problematic that coordinate systems are not based on an arbitrary frame of reference, but this is a simple example that is intended to start discussion and recognition of the issue.

[jakebeal]

I think this might be able to be addressed by creating a new Location type with a relative coordinate. I think we'd want to work through some real examples and check the level of value before we add this, though.

[jakebeal]

Another example of where it would be useful to have relative coordinates: describing the construction of structures where material is removed from the end of a sequence.

For the start, the numbers are always relative to zero. If you want to describe removing something from the end, however (e.g., removing stop codons), then you have to perform the computation immediately. If you are building a library, however, you can't express this correctly in a template. It would be useful to have a location type that allows us to say, e.g., "any of these four coding sequences, minus the last 3 base pairs", when the coding sequences are of different lengths.

[cjmyers]

Need a more precise definition of relative locations and a concrete example.

[jamesamcl]

My concern with adding relativity to locations is that locations start to look a lot like Constraints. I wonder if we therefore need to think about whether Locations and Constraints could or should be merged rather than starting to duplicate functionality across them.

[jamesamcl]

The above comment was mostly in reply to Jake. I'm still not sure I understand Bryan's problem, as it seems to me you could simply instantiate the left hand Component as a SubComponent with a location at 100. Apparently the issue arises with CombinatorialDerivations but I think we would benefit from a better example in this case.