Nicer names for build plans

[jakebeal]

The build plans have displayIds like: Anderson_Promoters_in_vector_BBa_J23100_pOpen_v4 This has two problems:

1. It's likely to be too long for Twist (who have a 32-character limit)
2. It's not very pretty

We should have the displayIds for a vector embedding be just BBa_J23100_pOpen_v4, and then we should give them a name as well, like "BBa_J23100 in pOpen_v4"

We will also need to check and make sure there are no collisions of displayId

[noahsprent]

As far as I can tell by looking at https://github.com/iGEM-Engineering/iGEM-distribution/blob/develop/Anderson%20Promoters/views/package.nt this is still an issue that would be worth addressing. @jakebeal I've tried to break this issue down into a checklist of steps that need achieving, would this match your thinking?:

• [ ] Modify the build scripts to give the SBOL objects displayId that follow the convention '[PARTNAME][VECTOR_NAME]'
• [ ] Modify the build scripts to add a property name that follows the convention '[PART_NAME] in [VECTOR_NAME]'
• [ ] Add a test to make sure that there aren't any parts in the distribution that have the same displayID

[noahsprent]

Ok I've been looking into this today and I'm not entirely sure I'm on top of it but I believe that the names given to the build plans come from the expansion of the CombinatorialDerivation by the SBOL utilities function expand_derivations, more specifically maybe cd_assigment_to_display_id which just concatenates the display IDs to give the final ID. @jakebeal are we looking to modify that behaviour or instead convert the predictable names that come out of that function into the format given above?

[jakebeal]

That's correct.

We will also want to put an entry in the optional "name" field (which is allowed to have spaces and such) while we're at it.

[noahsprent]

Thanks! Which one of the two approaches do you recommend? Editing the function in SBOL-utilities or an addition to the distro scripts?

[jakebeal]

I would suggest doing it in SBOL utilities. Likely a good choice would be to have an option for "compact names" that selects the new way vs. the old way.

[noahsprent]

Notes on how this is implemented (mainly for me):

• When expanded by expand_derivations, the display_ids of expanded CombinatorialDerivation objects are currently determined combining the id of the CD object with the ids of any variants that are expanded, by cd_assigment_to_display_id. So if the CD is called 'CD1' and the id of the variant that is used in the template to create the new component is 'Variant1' then the ID of the new component is 'CD1_Variant1'
• In our case we have a CD inside a CD. Firstly the CD that creates all of the composite parts by combining the parts listed in the Part 1 etc. and creating a CD if there is more than one basic part in the box. This has the name of the "Short and human friendly name for the part" from the excel sheet, with an appended "_ins" if there is a locus/backbone specified as well.
• If there is a backbone/locus specified then a second CD is created which adds this "_ins" CD to this CD. The identity for this CD is just the "Short and human friendly name for the part".
• So in the case of the anderson promoters, where we have a combinatorial assembly of the promoters, we end up with one CD: "Anderson_Promoters_in_vector_ins" which is the CD for assembling the promoters inside the overhangs either side, then this is within a second CD, "Anderson_Promoters_in_vector" for the combination of this set of linear fragments of promoters either side with the backbone specified. In our case pSB1C5.
• When these are expanded by expand_derivations the displayID ends up as: "Anderson_Promoters_in_vector_Anderson_Promoters_in_vectorins[PROMOTERNAME]"

Discussion/questions:

I'm not sure that the behaviour of expand_derivations or cd_assigment_to_display_id is wrong, as I don't know how it's supposed to know what is a backbone/locus and what is an insert etc.

So in order to make the change I think we might need to change the Excel-to-SBOL function to change the name of the "_ins" CD to the name of the backbone/locus so that the name will be e.g. "Anderson_Promoters_in_vector_pSB1C5_J23110".

We'll then need to parse this back into "J23110_pSB1C5" in the distribution scripts. But how will we know when we want to keep the "Short and human friendly name" and when we don't want to? Possibly if the user leaves the name blank then it isn't used, but otherwise it is?

[jakebeal]

Maybe a sufficient shortening would be to have the names be: library_backbone_variables for the plasmid and library_variables for the insert, e.g., "Anderson_Promoters_in_vector_pSB1C5_J23110" and "Anderson_Promoters_in_vector_J23110". That would make them pretty human-friendly.

[noahsprent]

Ok, I agree. I'll have a think about the best way to implement this.