SEP 046: Changes in the new SBOL 3.0 specification
Fontanapink opened this issue · 19 comments
Working on a document that summarizes all the changes done to the SBOL spec during the HARMONY meeting 2020 in Cambridge, UK.
See SEP at: https://github.com/SynBioDex/SEPs/blob/master/sep_046.md
Since there haven't been any comments, can I move this ahead for a vote?
I have read through and have no objections.
Yes, let's send out the voting form today.
I thought the first list was all changes and second list was non-SEP only.
True, scratch my comment then. It just confused me because some of the changes in the second list don't appear in the first list.
Hmm, that is an issue then. I'm not sure if we want to then make the two lists disjoint. I'm not too bothered though as long as the union is complete, and the 2nd list are definitely all the changes from the SEPs.
I've found an additional issue with Sequence and Location that we should probably address. Previously, when Sequence was optional, you could specify the Location of something without computing what elements actually go there (e.g., "this promoter is in range 1-50", "this cut site is at cut 257").
We have required a Sequence for every Location with good reason. However, this now means that we have to specify elements for a sequence immediately upon making a statement such as this, even if all of those elements are "nnnnn...". That seems like a failing, especially when handling genome-scale data.
I have thought of three potential ways to resolve this issue, and there may be more. The ones that I have thought of are:
- Make elements optional on a Sequence, such that they can be computed later (this probably also implies we only need an encoding if we have elements).
- Allow a "dummy sequence" class that is specified to definitely have no elements yet
- Support constraints that say what the locations will be in the future, when the sequence gets computed.
Of these, I like option 1, letting elements be optional, the best. This lets us keep the same object before and after computing sequence contents, where the other ones involve changing or adding objects respectively.
What do others think?
I think option 1 is better as you already suggested.
I also prefer option 1.
We could also add a recommendation that a Sequence SHOULD have an associated elements unless the actual sequence is unknown or not yet determined.
- Make Sequence optional iff the Component has no Sequences?
Otherwise, I also prefer option 1.
I agree with @jamesscottbrown on adding the SHOULD statement for option 1.
@udp , I believe option 4 would not achieve the desired goal because it would not apply for a system where two sequences need to be computed (e.g., composing a sender/receiver system with a sensor and actuator).
Yes, this is indeed an issue. The current GFF3 converter will have problems when no sequence is provided. I'm not excited though about creating Sequence objects without sequences, but I see Jake's point that if you want to talk about annotations on two sequences, then you are stuck with this. This is also going to complicate rules about locations must be on the sequences, but I guess we will just say if the sequence is specified, then these rules would apply. So, I guess Jake's option 1 is likely the best solution. I think we could still keep the encoding required, since one likely would know what encoding will be used. Or we can make encoding required only when elements is specified. We should make this change to the specification and SEP 046 today then before the vote is officially started.
I've created a pull request for SEP 046 and also for the main specification. The main specification request also includes all of the other copyediting I've done so far, none of which I anticipate being controversial.
The PR has been merged.
I think we can go ahead with the vote if there are no other changes required.
I'll include this change in the email while we open up the vote for SEP 46.
@PrashantVaidyanathan I believe that we are good to go on the vote, though the spec still has its mods outstanding at SynBioDex/SBOL-specification#358
@cjmyers has approved, and we just need an editor to look through also to double-check and then push the button.