Synthetic Biology:Semantic web ontology/Design: Difference between revisions

From OpenWetWare
Jump to navigationJump to search
No edit summary
No edit summary
Line 16: Line 16:


==Knowledge representation==
==Knowledge representation==
from [http://www.synberc.org/thrusts.html SynBERC thrusts]
 
===Abstraction hierarchy===
*Part - simple biological function encoded in DNA
*Device - simple logical function; collection of parts
*System - collection of devices
*Device is_a part in context of the system but also device has_a part.
*Device is_a subclass of Part, System is_a subclass of Device
*How to represent barriers and interfaces betwee levels of abstration?
*Genetic, protein and cell devices
* :RBS :subclassOf :BasicPart OR :RBS :typeOf :BasicPart (instance)
*Basic parts: detailed specs and sequence data
*Composite parts: basic parts plus assembly (composite parts have are the same if they have the same basic parts)
*Device: not necessary on a single piece of DNA
*Separate spaces: set of hierarchies
**Physical (DNA sequence assembly)
**Design
**Standards (Performance)
*Class of Standards: assembly standards, performance standards?
 
===[http://www.synberc.org/thrusts.html SynBERC thrusts]===
;Parts
;Parts
:any genetically encoded, basic biological function (e.g., a ribosome binding site, transcription termin-ator, or phosphorylation motif).
:any genetically encoded, basic biological function (e.g., a ribosome binding site, transcription termin-ator, or phosphorylation motif).
Line 23: Line 42:
;Chasses
;Chasses
:provide materials, energy, and other basic resources that are needed for proper system function.
:provide materials, energy, and other basic resources that are needed for proper system function.
===Biobrick descriptions===
*Parts/basic parts/subparts encode basic biological functions (RBS, CDS)
*Devices/composite parts are made from a collection of parts and encode some human-defined functions, such as logic gates in electronic circuits) (inverter)
*Systems perform tasks, such as counting (oscillator)
*No need to specify deep_components vs component_list
*Right now: composite parts have only components listed; deep components produced from that list
Types: what type are Plasmid, Cell and T7?
[http://parts2.mit.edu/r/parts/partsdb/index.cgi Registry Parts Index]
*A part is not allowed to contain both its own sequence and other parts
*Subparts - ordered set
Naming convention
*Part name/number - unique ID
*BB a _ X nnnnnn
*BB: BioBricks
*a: alpha stage of development
*X: part type
*nnnnnn: 4-6 digit part number
*Normally, the part name contains the letter associated with the part's type. Confusion is possible when a part fits into multiple categories.
Part properties ([http://parts2.mit.edu/r/parts/partsdb/view.cgi?part_id=153 example]) (* marks properties that belong to composite, possible value(s) are in parenthesis)
*name
*short_description (Promoter (lacI regulated, lambda pL hybrid))
*description
*type (Regulatory)
*status/availability (Available)
*results/usefulness (None|Fails|Works)
*component_list (NULL | BBa_B0032 BBa_C0051 BBa_B0010 BBa_B0012 BBa_R0063 BBa_B0030)*
*base_components (0 | 9)*
*deep_components (NULL | 149 156 603 145 193 147 161 603 145)*
*deep_components_2 (own part_id | _149_156_603_145_193_147_161_603_145_)* ?
*deep_component_count (1 | 9)*
*device_name (NULL | inverter)*
*sequence (why is sequence available for the composite parts)
*feature(s)
**type
**start
**stop
**label
*usage
**lastmod_user
**lastmod_date
*biology (Very weak promoter)
*functional parameters
**efficiency 0.6
*design
**author (names(s) or id)
**owner (number: owner_id)
**creation_date
**container_id
**version
**source (Bacteriophage 434 right operator)
**notes
**reference?
**owning groups
*physical DNA (instances?)
**plasmid
**plasmid_length
**part_and_plasmid_length
**VF2-VR
*location(s) - This part may be found in these wells/tubes
**library
**well
**plate
**plasmid - this the same plasmid as in physical DNA section above?
**cell
*files
*references
*licenses


==Software architecture==
==Software architecture==

Revision as of 16:05, 20 September 2006

Home        About        Conferences        Labs        Courses        Resources        FAQ       

Registry use cases

  • Subpart Search: search for parts that match a portion of this part or this sequence of parts. Software agent would take a part name and using the ontology definitions would query other registries via their semantic web interfaces (no need to know about schema: e.g., just say "need all <#part>s that match a <#component> of the given <#part>"). Software agent can search anyone's registry if they use a common ontology: simply follow URLs (or use query language) and add triples to the local RDF store.
  • Superpart Search: search for parts that contain the given parts
  • What about sub- and superpart searches in distributed registries?
  • Search for function (case insensitive): repressor, reporter, inverter, etc.
  • What are the available (instances of) parts? Are they used in any devices already? (saves time for constructing expression device). Problem: different names for exactly same DNA sequence
  • What kinds of devices/systems have been built?
  • Search for "similar" parts
  • Find all parts of the form promoter.Q04400 where promoter can be any promoter. It would also be nice to specify whether you want any parts, just available parts or available and working parts.

Miscellaneous use cases

  • Find a low-copy vector (1 to 2 per cell) which carries two antibiotic marker genes. (preferably one sensitive such rpsL, and one resistant such at Tetracycline, Chloramphenicol, etc.) and are FLANKED between two LoxP sites.

Knowledge representation

Abstraction hierarchy

  • Part - simple biological function encoded in DNA
  • Device - simple logical function; collection of parts
  • System - collection of devices
  • Device is_a part in context of the system but also device has_a part.
  • Device is_a subclass of Part, System is_a subclass of Device
  • How to represent barriers and interfaces betwee levels of abstration?
  • Genetic, protein and cell devices
  • :RBS :subclassOf :BasicPart OR :RBS :typeOf :BasicPart (instance)
  • Basic parts: detailed specs and sequence data
  • Composite parts: basic parts plus assembly (composite parts have are the same if they have the same basic parts)
  • Device: not necessary on a single piece of DNA
  • Separate spaces: set of hierarchies
    • Physical (DNA sequence assembly)
    • Design
    • Standards (Performance)
  • Class of Standards: assembly standards, performance standards?

SynBERC thrusts

Parts
any genetically encoded, basic biological function (e.g., a ribosome binding site, transcription termin-ator, or phosphorylation motif).
Devices
collections of parts that perform one or more human-specified functions under defined con­ditions (e.g., a Boolean logic oper­ation, a feedback control loop, or a chemical transfor­mation).
Chasses
provide materials, energy, and other basic resources that are needed for proper system function.

Biobrick descriptions

  • Parts/basic parts/subparts encode basic biological functions (RBS, CDS)
  • Devices/composite parts are made from a collection of parts and encode some human-defined functions, such as logic gates in electronic circuits) (inverter)
  • Systems perform tasks, such as counting (oscillator)
  • No need to specify deep_components vs component_list
  • Right now: composite parts have only components listed; deep components produced from that list

Types: what type are Plasmid, Cell and T7?

Registry Parts Index

  • A part is not allowed to contain both its own sequence and other parts
  • Subparts - ordered set

Naming convention

  • Part name/number - unique ID
  • BB a _ X nnnnnn
  • BB: BioBricks
  • a: alpha stage of development
  • X: part type
  • nnnnnn: 4-6 digit part number
  • Normally, the part name contains the letter associated with the part's type. Confusion is possible when a part fits into multiple categories.

Part properties (example) (* marks properties that belong to composite, possible value(s) are in parenthesis)

  • name
  • short_description (Promoter (lacI regulated, lambda pL hybrid))
  • description
  • type (Regulatory)
  • status/availability (Available)
  • results/usefulness (None|Fails|Works)
  • component_list (NULL | BBa_B0032 BBa_C0051 BBa_B0010 BBa_B0012 BBa_R0063 BBa_B0030)*
  • base_components (0 | 9)*
  • deep_components (NULL | 149 156 603 145 193 147 161 603 145)*
  • deep_components_2 (own part_id | _149_156_603_145_193_147_161_603_145_)* ?
  • deep_component_count (1 | 9)*
  • device_name (NULL | inverter)*
  • sequence (why is sequence available for the composite parts)
  • feature(s)
    • type
    • start
    • stop
    • label
  • usage
    • lastmod_user
    • lastmod_date
  • biology (Very weak promoter)
  • functional parameters
    • efficiency 0.6
  • design
    • author (names(s) or id)
    • owner (number: owner_id)
    • creation_date
    • container_id
    • version
    • source (Bacteriophage 434 right operator)
    • notes
    • reference?
    • owning groups
  • physical DNA (instances?)
    • plasmid
    • plasmid_length
    • part_and_plasmid_length
    • VF2-VR
  • location(s) - This part may be found in these wells/tubes
    • library
    • well
    • plate
    • plasmid - this the same plasmid as in physical DNA section above?
    • cell
  • files
  • references
  • licenses

Software architecture

  • User
    • Ontology-based knowledge sharing
    • Ontology-based presentation platform
    • Ontology-based search engine
  • Backend
    • Inference and query engine
    • Persistant storage for ontologies and metadata
    • Extraction tools for metadata
  • Architecture based on open standards: RDF, OWL, HTTP, etc
  • Possible initial setup: Adapting SQL Databases (slide 20)
    • Persistent RDF store (MySQL + Jena)
  • Possible final setup: Triple Store (slide 19)

Examples

Resources

This site is hosted on OpenWetWare and can be edited by all members of the Synthetic Biology community.
Making life better, one part at a time.