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.
- 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)
- Standards (Performance)
- Class of Standards: assembly standards, performance standards?
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?
- A part is not allowed to contain both its own sequence and other parts
- Subparts - ordered set
- 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)
- short_description (Promoter (lacI regulated, lambda pL hybrid))
- 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)
- biology (Very weak promoter)
- functional parameters
- efficiency 0.6
- author (names(s) or id)
- owner (number: owner_id)
- source (Bacteriophage 434 right operator)
- owning groups
- physical DNA (instances?)
- location(s) - This part may be found in these wells/tubes
- plasmid - this the same plasmid as in physical DNA section above?
- Ontology-based knowledge sharing
- Ontology-based presentation platform
- Ontology-based search engine
- Inference and query engine
- Persistant storage for ontologies and metadata
- Extraction tools for metadata
- Architecture based on open standards: RDF, OWL, HTTP, etc
- Semantics - the meaning that is implied by words and sentences.
- Software agent can search distributed registries using an ontology. This is impossible right now because storage schema is unknown.
- Data is represented by a graph of triples (statements about resources)
- Syntax doesn't matter: there are many ways to serialize the data (XML, N3, etc).
- Ontology vs taxonomy vs thesaurus vs list
- Ontology vs Taxonomy vs Folksonomy vs Collabulary
- Taxonomy - concepts and relationships but no attributes.
- Controlled vocabulary - only concepts.
- "lowercase semantic web"
- humans first, machines second
- HCLS task forces:
- Architecture of the World Wide Web @ W3C
- Reification @ Wikipedia
- XSLT vs XQuery
- A Semantic Web Primer for Object-Oriented Software Developers - OO vs SW, links to software, etc
- rdfs:label vs rdfs:comment
- used to describe a resource with human readable text in addition to "pure" RDF properties (may have multiple values for internationalization needs)
- rdfs:label is used to give a human-readable name of a resource
- rdfs:comment is used to give a longer description
- rdf:about and rdf:ID in RDF/XML
- Resource manipulation and description: URIQA, REST, WebDAV, WSDL, etc
- Map parts database schema to RDF/OWL (D2R, other?)
- Use RDF/OWL to describe neuronal data available in SenseLab - similar project
- 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?
- Do we need "Device"?
- I want to build a NOR gate vs. I have a NOR gate
From XML to RDF
- Thinking XML: Basic XML and RDF techniques for knowledge management
- IBM Systems Journal - Knowledge Management
- Principles of Knowledge Representation and Reasoning, Incorporated (KR, Inc.) is a Scientific Foundation incorporated in the state of Massachusetts of the United States of America concerned with fostering research and communication on knowledge representation and reasoning.
- 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.
- 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.
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.