User:Ilya/Registry: Difference between revisions

From OpenWetWare
Jump to navigationJump to search
Line 246: Line 246:


==Links==
==Links==
*[http://www.mozilla.org/rdf/doc/ RDF in Mozilla]
 


</div>
</div>
{{Synthetic biology bottom}}
{{Synthetic biology bottom}}

Revision as of 17:00, 6 June 2006

Home        About        Conferences        Labs        Courses        Resources        FAQ       

Data or Metadata

(from LSID best practices) Data is defined as a sequence of unchanging bytes. Examples of data are microscope images, a protein sequence, a text file, etc. Metadata is usually information that describes the data either literally (date created, MD5 check sum, size) or contains information describing the relationship between the data and other objects. If you cannot determine what should be data and what should be metadata from your data model, follow this rule of thumb: Large byte sequences are easier to manipulate as data, while short byte sequences can be included as data, metadata, or made available in both forms.

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?

Current Design

Biobricks come in three flavors:

  • 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

New Design

  • 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


Miscellaneous

To Do

  • Map parts database schema to RDF/OWL (D2R, other?)
  • HCLSIG BioRDF subgroup tasks - interesting projects
  • Use LSID for parts identification
    • setup LSID resolution service
  • How to represent sequence features (do they belong to sequence or part)?
    • Part has features and has a sequence (piece of DNA with molecular function combined by BB assembly)
    • Sequence has features but a part already has sequence
  • Tools to create and edit ontology and RDF instances?
    • Protege from Stanford?
    • IsaViz from W3C?
  • existing RDBMS <-> RDF <-> objects (e.g., Javascript)
  • Do we need "Device"?
  • I want to build a NOR gate vs. I have a NOR gate
  • Find a way to use MediaWiki software to work with the Semantic Web ontology of biological parts: create a UI from the description of a part in the ontology that would check the entered information for correctness according to the part definition in the ontology.

From XML to RDF

(from [1])

  • ?

Knowledge Management

(knowledge represenation, extraction, etc.)

Description Logics

  • Description Logic - a cornerstone of the Semantic Web for its use in the design of ontologies
  • Logic: a well formalized part of agent knowledge and reasoning.
  • Reasoning: logical inference, "processing knowledge" (implicit knowledge has to be made explicit)
  • Expressive Power of representation language - able to represent the problem
  • Correctness of entailment procedure - no false conclusions are drawn
  • Completeness of entailment procedure - all correct conclusions are drawn
  • Decidability of entailment problem - there exists a (terminating) algorithm to compute entailment
  • Complexity - resources needed for computing the solution
  • Logics differ in terms of their representation power and computational complexity of inference. The more restricted the representational power, the faster the inference in general.
  • First-order logic: we can now talk about objects and relations between them, and we can quantify over objects. Good for representing most interesting domains, but inference is not only expensive, but may not terminate.
  • DL vs OWL (from Description Logic @ Wikipedia):
    • A concept in DL jargon is referred to as a class in OWL
    • A role in DL jargon is a property in OWL.
  • DL vs ER (from http://www.inf.unibz.it/~franconi/dl/course/slides/db/db.pdf):
    • An ER conceptual schema can be expressed in a suitable description logic theory.
    • The models of the DL theory correspond with legal database states of the ER schemas.
    • Mapping ER schema in DL theory:
      • Reasoning services such as satisfiability of a schema or logical implication can be performed by the corresponding DL theory.
      • A description logic allows for a greater expressivity than the original ER framework, in terms of full disjunction and negation, and entity definitions by means of both necessary and sufficient conditions.

Knowledge Bases

(from http://www.inf.unibz.it/~franconi/dl/course/slides/kbs/kbs-modelling.pdf)

  • Distinctions:
    • Primitive vs. Defned.
    • Defnitional vs. Incidental.
    • Concept vs. Individual.
    • Concept vs. Role.
  • Steps to design:
    • Enumerate Objects. As a bare list of elements of the KB; they will became individuals, concepts, or role.
    • Distinguish Concepts from Roles. Make a first decision about what object must be considered role; remember that some could have a "natural" concept associated. The remaining objects will be concepts (or maybe individuals). Also, try to distinguish roles from attributes.
    • Develop Concept Taxonomy. Try to decide a classifcation of all the concepts, imagining their extensions. This taxonomy will be used as a first reference, and could be revised when definition will be given. It will be used also to check if definition meet our expectations (sometime, interesting, unforeseen (re)classifications are found).
    • Devise partitions. Try to make explicit all the disjointness and covering constraints among classes, and reclassify the concepts.
    • Individuals. Try to list as many as possible generally useful individuals. Some could have been already listed in step 1. Try to describe them (classify).
    • Properties and Parts. Begin to define the internal structure of concepts (this process will continue in the next steps). For each concept list:
      • intrinsic properties, that are part of the very nature of the concept;
      • extrinsic properties, that are contingent or external properties of the object; they can sometime change during the time;
      • parts, in the case of structured or collective objects. They can be physical (e.g., "the components of a car", "the casks of a winery", "the students of a class", "the members of a group", "the grape of a wine") or abstract (e.g., "the courses of a meal", "the lessons of a course", "the topics of a lesson").
      • In some cases some relationships between individuals of classes can be considered too accidental to be listed above (e.g., "the employees of a winery"; but the matter could change if we consider Winery as a subconcept of Firm).
      • In general, the above distinctions depend on the level of detail adopted.
      • Some of the listed roles will be later considered defnitional, and some incidental.
      • After this and the next steps check/revision of the taxonomy could be necessary.
    • Cardinality Restrictions. For the relevant roles for each concept.
    • Value Restriction. As above. Also, chose the right restriction.
    • Propagate Value Restrictions. If some value restrictions stated in the previous step does not correspond to already existing concepts, they must be defined.
    • Inter-role Relationship. Even if hardly definable in DL, they can be useful during the populating and debugging phases.
    • Definitional and Incidental. It is important distinguish between definitional and incidental properties, w.r.t. to the particular application.
    • Primitive and Defined. As above.

Links

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.


Retrieved from "https://openwetware.org/mediawiki/index.php?title=User:Ilya/Registry&oldid=39882"