SBOL Workshop San Diego, CA 2011

SBOL
Workshop


June 8, 2011


San Diego, CA


Location: Omni San Diego, Balboa 4


Time: 9am – 6pm




Sponsored by:






Goals:



  1. Discuss overall requirements that SBOL should
    satisfy


  2. Discuss what information should be in SBOL and how it should
    be structured


  3. AVOID implementation details, e.g. class names, field names,
    etc. (leave that to the programmers who are actually
    implementing it)


  4. To decide on a basic governance structure for the
    community.


Topics:


(needs to be re-arranged in to time schedule with estimates
(consider “
Utes”

leave at 4pm))



  • Unfinished business from Virginia


    • SBOLv


      • Finalize a release of the SBOL vocabulary


      • Finalize the set of symbols


    • SBOL-semantic


      • Discuss and add revision notes re: the SBOL Level 1
        RFC (in rough draft state now, I need 1 more day on
        it). (I’ll present briefly if needed and hopefully
        everyone will have read it/ maybe
        edited.)


      • Move to ratify if any revisions needed are
        completed.


    • Governance (Herbert)


  • New Business


    • Quick Review of Use Cases


    • Lessons Learned from the Cytoscape Open Source community
      (Allan)


    • Go over test cases (Mike and Nic)


    • Discuss progress towards use cases for current spec
       (Cesar, Nic, Mandy, Deepak, Doug?)


    • Discuss the proposed performance extension to the Core
      Data Model


    • Discuss new use cases and extensions needed (cesar, and
      anyone else)


    • SBOL-genocad update? (Mandy)


    • Decide on convention for version management libSBOLj and
      SBOL standards


      • Responsibility for work and financing


      • Discussion on design, implementation, and
        deployment


    • Pursuing industry adoption of SBOL


    • Discuss the implementation of a simple governance
      structure


  • Discuss personal use cases and experiences relevant to SBOL
    development


    • strictly 5 minutes per person (w/o questions)


      • no schedule, just “walk-in”


      • recommended: post anything requiring more than 5mins
        on google groups


    • general discussion session after each talk. no time
      limit, but discuss topics relevant to SBOL


  • Discuss paper. (The group)


Expected Attendees
:


Laura Adam (VBI)


Deepak Chandran (UW)


Douglas Densmore (BU)


Michal Galdzicki (UW)   


Allan Kuchinsky (Agilent)


Curtis Madsen (Utah)


Chris Myers (Utah)


Tyler Patterson (Utah)


Cesar Rodriguez (BIOFAB)


Nicholas Roehner (Utah)


Herbert Sauro (UW)


Guy-Bart Stan    (Imperial)


Mandy Wilson    (VBI)


This Meeting was Sponsored by: CIDAR (Densmore)


TODO:



  1. Mike: get easel pads, easel or other mounting, and
    markers.



    1. There is an Office Depot relatively close (20min
      walk):

      http://goo.gl/GImfk


  2. Doug: bring projector


  3. Drinks/ snacks


  4. Lunch location or take-out to bring in to meeting room for
    working lunch.


  5. Collect materials created at workshop and post to website
    and or an “internal website”.



    1. last time there where disclosure concerns


Discussion notes


1.  What do we do about parts which have yet to be
assigned a sequence?


2. Cesar: suggestion change 1 to 0 on uml diagram


3. Alternative levels of abstraction, cf. views in electronic
design. SBOL 1 is however open to this idea in future
levels


4. Make sbol more general, do we need to be able to specify the
actual parts? Current design may be be suitable for this. What
about specifying the order of parts without a DNA sequence. Use
partial ordering, suggestion to put in in level 2 or should be
put it into level 1? Level 1 looks too much like
genbank?


5. A DNAComponent may or should have a sequence
feature?


6. A DNAComponent may or should have a DNA
sequence


7. Does a DNAComponent have to be in a valid SBOL
file?


8. Use cases from Mike’s slides, eg Lib-DC is a valid but
perhaps not so useful


9. Add a new field(s) to SequenceAnnotation (partial order
field)?


10. What happens if some of the features have sequences but
others do not.


11. Ratify Mike’s slides, slides updated by Chris, Mike
and Deepak


12. Add Mike’s slides to the sbol web site


Motions


Motion: displayId are required fields for LIB, DC and
SF


Motion passed


Motion: displayIds are unique within a library


Note (Mike), not relevant to current standard


Motion passed


Motion: all name and description fields are
optional


Motion passed


Motion: remove isCircular in DC


Motion passed


Motion: Research will be carried out on the utility of the
dnaRef in DS and it will be removed for now.


Motion  passed


Motion: Change number on both arcs named dnaSequence to
0..1


Motion passed


Motion: Change field name dnaSequence to
nucleotides


Motion passed


Motion:  start, stop and strand fields should be optional.
In addition, add a relation that a SA may proceed a SA with
0..n cardinality.


Motion passed


Validation Requirement: The set of precedes relations on the SA
are required to be linearized to a sequence.


Motion: SF is a subclass of DC. The SF displayid, name and
description are removed and is the relations to LIB and DS.
 The SA feature relation points to DC rather than
SF


Motion passed


Motion: The above set of motions describes SBOL Level 1.0,
Version 1.0


Motion pass


Motion Governance


Motion pass


Provisional motions: for the sbol forum


1. Separate the “Core” already in use and
“Provisional” in development symbols – Central
dogma up to before  insulator. The rest are
not.


Recommended to pass


2. Stability symbols should be circles on top of a stick of an
iconic representative hairpin with optional text specification
of level high medium low indications abbreviated by H/M/L or
numercial.


3. Examples of use should be included in the RFC for all
symbols Suggested to use lambda phage system.


4. and examples of use in a circular context.


5. Promoters get rid of the plus and minus and 0


6. Note and consider to revise to include regulatory
interaction arcs.


Suggestions for a Simple SBOL Governance Structure


Herbert Sauro


With SBOL gaining wider interest in the synthetic biology
community, it is time to consider a more formal organization
for the SBOL working group. Up to now, development has been
informal. What follows is a suggested organizational structure
which at this stage should be kept as simple as possible. To
begin with, SBOL is a community and participative based
project. To facilitate this process the SBOL community can be
divided into two groups:


1. The SBOL Forum


2. SBOL Editors


These divisions however are not mutually
exclusive.


The SBOL Forum


The SBOL forum is where the SBOL community can voice its
concerns, suggestions and general discussion on SBOL matters.
Membership to the SBOL forum is open to all interested parties
by registration. SBOL face-to-face workshops will also provide
the community additional discussion time.


The SBOL Editors


Documentation

In order to keep track of changes, proposals and other elements
of interest, a specific group of people, called the SBOL
editors, will take responsibility  to track, respond and
process requests for changes or additions  to the SBOL
specifications. SBOL editors will accomplish this by
maintaining an open SBOL specification text, through writing,
editing, and coordinating changing in the document. Non-SBOL
editors can also submit corrections, amendments (after
discussion in the SBOL forum) to the SBOL editors. The reason
to have this formal structure is to put responsibility for
maintaining the documentation in one place. Good documentation
is critical to any standardization process to be
successful.


It should be emphasized that the editors will not unilaterally
decide new functionality for the standard. To repeat what was
said before, SBOL is a community driven standard. Suggestions
and proposals will be decided by the entire community as voiced
in the SBOL forum. Whether a given feature or change is
included in the standard documentation  or not will be
decided either by majority online voting or majority voting at
face-to-face SBOL workshops.  Online voting mechanisms
will be organized by the editors.


Majority decisions suitable? Voting based on consensus driven
discussions (See Wikipedia)


Editors take care of specific extensions packages.


Software

In addition to the specification document, there will also be
maintenance of the SBOL software libraries. Maintenance can be
coordinated between SBOL editors and non-SBOL editors who have
a particular interest in software development. The reason to
route part of the software development through the SBOL editors
is to ensure code consistency, adequate code commenting and
development of tutorial material (possibly supplied by
non-editors). In all cases, the editors will also ensure proper
attribution of all contributions. Other duties of the editors
include: maintaining the SBOL web site, the GitHub source
repository, electronic mailing lists, helping to organize (or
delegating) the organisation of SBOL events and help coordinate
the publication of SBOL in peer reviewed journals.


Selection of Editors

Apart from a discussion of the above general proposal, one
question to address is how editors should be selected. Most
likely two to three editors will be required at any one time in
order to balance the work load. Such editors should serve a
limited time, say 2 or more years. In addition to the editors,
an SBOL chair should be assigned who oversees the work of the
editors, assists with publication writing and encourages
continued progress by the SBOL community.


I hope at the meeting on Wednesday in San Diego we will have
some time to discuss this proposal.


Cesar:


Discussion



  1. Discussion to approve SBOL level 1 – tabled


  2. Chris: lets move to separate SBOL spec from the
    implementation. Discuss the spec


  3. Chris: add the propsed 1.5 URis now.


  4. Chris: What should happen at SB5.0


  5. Doug Mike get me three slides on SBOL!!


  6. Discussion of part order. Motivated by Jake’s case of
    an unspecified “AGRN”



    1. SBOL ordering could be based on a separate ordering
      object which can be applied to SFs or DCs



      1. see Motion to add preceeds


  7. Make Virtual Part legal SBOL valid



    1. aka Seq is optional for object validity; not for
      reproducibility


  8. TC fallacy is valid


  9. False SF Library  – invalid still


  10. Add Chris Winstead to sbol-dev and docs


  11. by Jul 4th decide on next workshop time/ place


  12. Allan Kuchinsky: Maybe take a look at

    http://sfld.rbvi.ucsf.edu/django/

    and

    http://www.ebi.ac.uk/Rebholz-srv/GRO/GRO.html


    and

    http://bioportal.bioontology.org/

    (the guys that are doing the bioportal and in particular the
    GOslim ontology are based in Stanford so it might be useful
    to check with them before, during or after SB5.0)


  13. Mandy Wilson, Cesar A. Rodriguez, Michal Galdzicki elected as
    SBOL editors