"First" PoBoL BBF RFC 31 "Provisional BioBrick Language (PoBoL)"
Michal Galdzicki
We have put together a snapshot of PoBoL, as imperfect as PoBoL is we
feel this may be a good place to start a dialogue. Attached is the
rough draft of BBF RFC 31 "Provisional BioBrick Language (PoBoL)"
(rfc31_20090428.pdf) Please tell us what you think it about it and
offer suggestions for the document. Those that are already in the
authors' list please respond with comments and if you approve for this
to be submitted to the BBF RFC repository. Everyone else, we invite
you join the authors list by providing comments.
Keep in mind that the purpose of this document is to serve as a
starting point or a reference point to which we can refer to as we
propose changes to the underlying core data model. A "second" PoBoL
RFC is being organized for the purpose of critique and proposal for
changes. This 2 RFC approach allows us to say 1st how things are and
2nd how and why we should change it. Therefore you should propose how
to make PoBoL better, but say it is for the "second" PoBoL RFC.
Attached also is the pobol_0.4.zip which contains files referred to in
Appendix A of RFC 31.
Thanks and looking forward to your responses,
-Michal
Jason Morrison
Thanks for sending the document our way. I had the chance to read it this morning, and have a few (small, nitpicky :) questions/comments, but am very happy with the scope and contents.
- In 10.1.1 (or in 10.1), I'd suggest clarifying that properties can exist multiply; i.e. you have specify two authors simply by specifying the hasAuthor property twice. This isn't clear until the BBa_I0462 example later on, I think.
- Why date/reference vs hasAuthor/hasFormat ("has" vs no "has")? Is this an OWL standard? If so, it might be worth pointing out.
- The RFC uses the property hasSubPart (singular) but the attached files (OWL/turtle) use the property hasSubParts (plural).
I think the scope of the document is just right, and the included examples (11.1, 11.2) are spot-on and help a great deal.
Thanks,
Jason
--
Jason Morrison
jason.p....@gmail.com
http://jayunit.net
(585) 216-5657
Michal Galdzicki
-mike
Mackenzie Cowell
I have some mostly-trivial suggestions below.
But first, I was wondering how we would feel about including a data model diagram like the one Jason M put together a couple of months ago. Both are linked to at pobol.org. The more detailed of the two (attached) is slightly out of date. Jason said he would be happy to dig up the original files and update it if we want to include it. I think it would be a really good idea because it would quickly help reader understand the 5 classes of PoBoL.
So what do you think about that?
More comments here:
Section:
8 "In OWL subClassOf, means that..." - strike comma
9 "The BioBrick class has a subclass, more specific concept, defined as Vector." - discontinuous commas. Also, is it Vector, or BioBrickBasic?
10.1 As Jason mentioned, we should explicitly state that some of these properties can defined multiply (0,1-n). 10.1.3 says hasSubPart MUST have *one or more* BioBricks... - we MUST identify for each property if it can occur *only once*, *zero or more*, or *one or more* times. We should change all of the properties of the classes in 10.1 to be disambiguous in this way. Additionally, we should add clarification to the preamble for 10.1 explaining that when we specify that a property may have one or more values, this means that attribute-pair occurs multiple times in the document.
10.1.1 preamble uses "concept" twice - tighten this up?
10.1.1 "OPTIONAL Property: hasAuthor MUST have one value of type xsd:string" - can this point to FOAF stuff? Can multiple authors be specified? I presume they can - see jason/my comments for 10.1 about property multiplicity.
10.1.2 "PoBoL SHALL NOT have instances of BioBrickBasic which..." - is it PoBoL which shall not have the instances, or someone's local collection of RFD docs, or what? Change to "PoBoL documents SHALL NOT..."
10.1.6 "Describes the DNA molecule as a combination of the Vector and the Insert." This is the first time "insert" has been used. Consider replacing with "... combination of the Vector and the BioBrick insert."
10.1.7 "RECOMENDED Property: tubeIsLabeled SHOULD have one value value of type ..." RECOMMENDED has typo; value is repeated twice
11. In "The PoBoL schema, by itself can be found..." strike the following phrase: ", by itself".
11.2 consider modifying the ">>print getTextAttribute(part, "format")" print-out example to display the format according to RFC29. Or is this an historical example.
11.3 I think we should reference RFC30 again here and reiterate the value of OWL as the basis of PoBoL - generally speaking:
As described in RFC30, an OWL-based architecture enables the extension of the PoBoL data model and facilitates a "rolling standardization" process for these extensions, which enables future expansion in scope of BioBrick description documents while adhering to a core standard like PoBoL. Additionally, "OWL is a good citizen of the web" because it supports sharing (in the sense of synchronizing) and interlinking (distributing and connecting databases) information.
Mac (& Jason)
Mac Cowell
DIYbio.org
p: 231.313.9062
tw: @macowell
Michal Galdzicki
I'll be traveling to DC on Sunday and I'll incorporate your comments
during that trip.
Re: to the diagram, it's a good idea. To add it, could you or Jason
send me the graphics file used to make it? There would be some
changes to it, i'd like to make, but its hard to describe it by
writing. Jason, what software did you use to make it? If i don't have
a way of editing, could we talk on the phone about it?
It's really great to see everyone contributing to this. It's a great
team to be a part of.
thanks for your help,
mike
Jason Morrison
I used OmniGraffle for the document. The class diagram is available in OmniGraffle, PDF, and PNG as "pobol class diagram.*" here:
http://code.google.com/p/pobol/source/browse/#svn/trunk/doc/diagrams
Feel free to check out the SVN repository and commit your changes (http://code.google.com/p/pobol/source/checkout), as you're a member of the google code project.
Let me know if you have any questions. If you can't edit OmniGraffle files, I can export it as a vector file (PDF, EPS, PICT), or bitmap (TIFF, PNG, GIF, JPEG, BMP, or Photohop.)
Thanks!
Jason
Raik Gruenberg
great job! And lot's of work obviously...
Some quick comments:
* 10.1.3 -- BioBrickComposite:
BiobrickComposite is supposed to be defined by an *ordered sequence* of Basic
Biobricks. I think the current hasSubProperty would only give you an un-ordered
set. Then we still have another problem: the sequence of BasicBioBricks is still
not enough, we also need to know which type of scar is connecting them. One
could argue that this is covered by the BioBrickFormat of the basic parts but
that's not always clear-cut. In Brickit I use a linked chain (BioBrickChain) but
it would be nice if we could solve this issue with simple lists.
10.7.1 -- Sample:
there are not only tubes but also wells and other types of samples.
instead of tubeLabel I would just call that property label.
BTW, samples can also contain cells (stock cultures) which contain the DNA.
And one general comment: I know that the RDF people like descriptive verb-like
properties like "hasName" to emphasize the 'subject-predicate-object' relation.
Personally, I would rather remove the "has" in front of every property. It's
kind of redundant, isn't it? The Foaf ontology also doesn't use it (its' simply
foaf:author rather than foaf:hasAuthor) and even OWL is describing things like
owl:range and not owl:hasRange.
What's your feeling about that?
Greetings,
Raik
________________________________
Dr. Raik Gruenberg
http://www.raiks.de/contact.html
________________________________
Raik Gruenberg
J. Christopher Anderson wrote:
> Hi Raik,
>
> Could you expand on what you meant by "In Brickit I use a linked chain"
> ? What is a linked chain?
Sorry, that was not clear at all. So the construction goes like this:
class BrickChain:
* previous -> BrickChain
* last -> Biobrick (basic)
* scar_format -> BrickFormat
* explicit_scar -> string
You then build up a sequence of Biobricks bb1 .. bb3 with intervening scars like
that (but of course there is also a convenience function that does that in one
line from a simple list):
chain_1 = BrickChain( previous=None, last=bb1, scar_format=fusion ) # start..
chain_2 = BrickChain( previous=chain_1, last=bb2, scar_format=fusion )
chain_3 = BrickChain( previous=chain_2, last=bb3, scar_format=fusion ) # ..end
chain_3 is then the complete linked list that represents a sequence of 3 basic
Biobricks with intervening scars. On the database level it creates three
BrickChain records but you only need to handle the last one. The object has
recursive methods to return the complete DNA sequence, the list of Biobricks, etc.
There are also functions to automatically decompose non-basic biobricks so that
the same sequence can only be represented in one unique way. Intermediate chains
are automatically created and deleted.
It's all packed into the module brickit/registry/brickchain.py. Check it out if
you are pondering at the same problem. It's less than 200 lines and less than
100 lines are actual code, the rest is doc strings and spacing. Took me quite
some effort to arrive at this solution though.
This is quite efficient as an internal representation of a sequence of
BioBricks. But for the Pobol RDF, I would probably prefer a more simple
list-based record.
Greetings,
Raik
> >>>> (585) 216-5657
> >>>>
> >>>
> >>
> >>
> >> --
> >> Mac Cowell
> >> DIYbio.org
> >> p: 231.313.9062
> >> tw: @macowell
> >>
> >
> > >
> >
>
> --
> ________________________________
>
> Dr. Raik Gruenberg
> http://www.raiks.de/contact.html
> ________________________________
>
> >
>
>
>
> J. Christopher Anderson, Ph.D.
> Assistant Professor
> Department of Bioengineering
> http://andersonlab.qb3.berkeley.edu/
>
> Office: 308A Stanley Hall
> Lab: 327 Stanley Hall
>
> Office Phone: 510-666-3611
> Lab Phone: 510-664-4200
> Fax Line: 510-664-4200
>
> Mailing Address:
> J. Christopher Anderson
> University of California, Berkeley
> 327 Stanley Hall, Mailcode #1762
> Berkeley, CA 94720
Michal Galdzicki
I'm in DC for an ontology workshop which is keeping me busy. I'll get
back to you all Friday with the revised version.
Thank you again,
mike
On Mon, May 4, 2009 at 4:33 PM, Sean Sleight <sle...@u.washington.edu> wrote:
> OK, here's just some very minor comments to the RFC since some of the other
> points I thought of have already been brought up, but it looks great!
>
> 1. In the Acknowledgements section, should probably say, "This workshop was
> sponsored by the Microsoft..."
>
> 2. For consistency, in the next paragraph, Mac should be changed to
> Mackenzie.
>
> 3. In 10.1.4, you say "used in prokaryotic cell engineering", but probably
> should just be changed to "cell engineering" since yeast are commonly
> engineered cells.
>
> 4. In 11.1, I was curious why you used a different example F2620 when you
> could have used the previous example I0462 since that one has already been
> described.
>
> 5. In section 13 obviously the other authors contact info should be
> included.
>
> 6. Section 15 "Appendix A" is missing the second p.
>
> That's it!
> Sean
>
> Michal Galdzicki wrote:
>>
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>> Warning text added to this message by
>> UW Technology
>> he...@u.washington.edu
>>
>> ATTACHMENTS RENAMED
>>
>> This message came to the UW with an attached file with a
>> name that ended in .zip or .exe. Because files of this
>> type can automatically infect computers with a virus, the
>> attachment has been renamed.
>>
>> o If the sender of the message is known to you, and you
>> were expecting the message, you need simply save the
>> attachment using the original name or save it as is and
>> rename it back to the original name on your computer.
>>
>> o If the sender is not known to you, it is possible that
>> the attachment contains a virus and you may simply
>> delete the message.
>>
>> o If this message claims to be official and
>> instructs you to open the attachment to get
>> important information, it is likely to be fake.
>> Virus writers are increasingly using sophisticated
>> social engineering techniques to mislead people.
>>
>> UW Technology never sends important information about your
>> account or password in an email attachment. Instead
>> you will be directed to a web page on a UW Technology site.
>>
>> Please contact he...@u.washington.edu or your local
>> computing support if you have further questions.
>>
>> Warning text added to this message by
>> UW Technology
>> he...@u.washington.edu
>> +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++