search

SynBioDex / SBOL-specification

The Synthetic Biology Open Language (SBOL)
http://sbolstandard.org
14 stars 9 forks source link

What URIs are allowed for SequenceConstraint restriction property? #12

Closed jakebeal closed 3 years ago

jakebeal commented 9 years ago

Currently says: "The URI value of this property SHOULD come from the RECOMMENDED URIs in Table [restriction_types]"

Per Mike B comment: changed ``MUST ... or an [ill-defined] appropriate ontology'' to SHOULD, since that's the same. -JSB

I'm not sure about this. I think it is MUST, as these are the only ones we allow right now. Same for all enumerated types we have defined. -CJM

I agree with CJM. The original wording was problematic because it said 'restrictions MUST come from table 7 or anywhere else,' which we've simplified to a SHOULD. But implementors need a solid definition of each option, and a complete enumeration of options, because a hard constraint MUST never be disobeyed -- and that means that implementors MUST enforce all constraints. So this can't be open-ended. -MB

So the outstanding question is do we want to make this SHOULD or MUST? -CJM

[imported from LaTeX]

jakebeal commented 9 years ago

Decided to leave this as "SHOULD" for 2.0 and consider the possibility further for 2.0.1.

If it is left as SHOULD long-term, a concern that needs to be addressed in the future is how a program should gracefully deal with SequenceConstraints that it does not understand.

jakebeal commented 8 years ago

Changed from 2.0.1 to 2.1 because a "SHOULD" to a "MUST" requires software change.

drdozer commented 8 years ago

We have a paper in the pipe here at Newcastle that defines essentially all the binary constraints we can think of that apply to biopolymers, both stranded and unstranded. We were hoping that this could be a candidate for recommendation as the terminology for >2.0.0. I had presumed that when a particular tool doesn't understand a constraint that it simply ignores it, presumably informing the user that there are constraint(s) that it could not apply.

On 15 October 2015 at 15:34, Jacob Beal notifications@github.com wrote:

Changed from 2.0.1 to 2.1 because a "SHOULD" to a "MUST" requires software change.

— Reply to this email directly or view it on GitHub https://github.com/SynBioDex/SBOL-specification/issues/12#issuecomment-148405007 .

Dr Matthew Pocock Turing ate my hamster LTD mailto: turingatemyhamster@gmail.com

Integrative Bioinformatics Group, School of Computing Science, Newcastle University mailto: matthew.pocock@ncl.ac.uk

gchat: turingatemyhamster@gmail.com msn: matthew_pocock@yahoo.co.uk irc.freenode.net: drdozer skype: matthew.pocock tel: (0191) 2566550 mob: +447535664143

jakebeal commented 8 years ago

This would be valuable indeed to add into the discussion.

jakebeal commented 4 years ago

I believe this is moot, given the expanded constraint structure in SBOL 3.

cjmyers commented 4 years ago

To be clear, in SBOL2, the URI for a restriction was left open and not restricted like all the other enumerated types. Given that we have a more comprehensive list, can we simply say that the restriction MUST come from the list?

jakebeal commented 4 years ago

I don't think that we should do that. I think that we can simply have tools ignore any constraints that they do not understand. That will give us space to experimentation and expansion of the set of constraints.

cjmyers commented 3 years ago

@jakebeal I think this one is sorted in SBOL3. Can you confirm and close if so?