RFC30 Comments
Michal Galdzicki
This RFC is really helpful. I appreciate the direction it gives for
definitions of data formats and your support of RDF/OWL for this
purpose. Below I detail some nit-picky comments that came up while
reading. I have also included a paragraph which fits as a conclusion.
I will consider RFC30 while drafting RFC 31, and that may result in
some more comments.
5.2 Page 5
"Whenever appropriate, extension authors SHOULD re-use definitions
from well supported other RDF ontologies"
Consider :
"Whenever appropriate, extension authors SHOULD re-use definitions
from well established RDF/OWL ontologies, as they constitute
standards for other domains science."
5.3 Page 6
"In any case, a owl:sameAs link SHOULD connect the new standard back
to the RDF document of the original proposal."
Consider that owl:sameAs will be interpreted to mean sameAs reciprocally.
Consider another versioning scheme, self defined (active research area
I believe)
5.4 Page 6
"The data documents SHOULD be serialized to XML but, depending on the
situation, other formats, like Turtle/N3 or JSON MAY be preferred."
Consider adding:
" If another serialization is used the format chosen MUST NOT lose or
leave out information in the conversion from the original XML
serialization."
5.6 Page 8
"That means a simple HTTP GET MUST serve the document just as it would
serve an html formatted
web page about it. That also means data access SHALL NOT require the
initialization of web services or any other kind of remote procedure
calls."
Potentially a technical contradiction
HTTP GET may be technically considered a web service it self. "SHALL
NOT require" phrase lacks recommended actions that I should take when
interpreting the RFC document. Personally, I agree with the
sentiment that I think you are expressing; as a first choice data
should be served in a way everyone can use it.
5.6 Page 8
"Software that consumes Synthetic Biology data records MUST be able to
open, parse and interpret RDF documents. The software SHOULD, at
least, parse XML-formatted RDF documents. Support of more specialised
and readable formats like turtle/N3 is RECOMMENDED."
This is a little confusing:
1. MUST parse RDF (at least one serialization)
a. SHOULD parse XML-RDF
b. RECOMMENDED Turtle / N3
According to RFC 0 'The word "SHOULD" or the adjective "RECOMMENDED"
mean that there may exist valid reasons in particular circumstances to
ignore a particular item, but the full implications must be understood
and care-fully weighed before choosing a different course.'
Therefore a = b in objective terms therefore you are not recommending
one over the other.
One solution, change to: MUST parse RDF-XML
Another solution, change to say: MAY support Turtle/N3
5.6 Page 8
"At least in the long term, data stores are also RECOMMENDED to
support the SPARQL W3C standard for more complex queries."
SPARQL endpoints are web services, as far as I understand.
http://semanticweb.org/wiki/SPARQL_endpoint
Refers back to confusion that may arise from "SHALL NOT require the
initialization of web services"
6.1 page 10
"Soap"
Change to
SOAP
Benefits of the approach proposed
The guidelines described here form a framework which aims to support
the philosophy of open participation in the use, creation, and
development of BioBricks™ standards. The specification of a core data
model will establish a shared common ground for the purpose of
electronic communication of data. This approach could benefit the
community in reducing ambiguity about information in the Synthetic
Biology domain and contribute by helping define the criteria for
standardization of biological parts. Additionally, creation of an
extensible, yet syntactically consistent, data model and environment
gives the freedom to researchers to explore new ideas. The freedom to
extend with a low overhead in effort needed to participate will
encourage testing, critique, and rejection of poor ideas and promotion
of those deemed useful. Eventually the lessons from the evolution of
the data model could help to refine the theories about biological
parts. By promoting a common defined and documented electronic format
this RFC hopes to reduce the effort needed to exchange information
within the Synthetic Biology community. The structure of the format
and supporting information unambiguously define the data recorded
using these conventions. Moreover, the recommendation of protocols
for electronic transmission reduces the number of agreements needed to
successfully publish data useful to others. The nature of RDF
supports the interlinking of data elements allowing for the
expressivity needed to capture the complexity of biological part
information. This same choice is also leveraged to create timely
access over the network for synchronization in an ever changing
knowledge base. Adoption of these recommendations will directly
contribute to progress in development of software supporting Synthetic
Biology research.
Thanks,
mike
Michal Galdzicki
Biomedical and Health Informatics, PhD Student
Medical Education and Biomedical Informatics
University of Washington School of Medicine
Seattle, WA 98195-7240
http://students.washington.edu/mgaldzic/
Michal Galdzicki
To clarify a detail mistake: I worked with the April 23, 2009 version
of the RFC 30 document. I see the one you have here is dated April
24, 2009 there will be discrepancies in page numbers, possibly some of
these have been already fixed sorry for causing confusion.
have a good weekend,
mike
Raik Gruenberg
Reshma suggested to write a replacement RFC rather than silently
replacing the existing file. So, I've posted your comments to the
official comment section:
http://openwetware.org/wiki/BBF_RFC_30
Agreed to all apart perhaps from the sameAs which, the way I meant it,
can be reciprocal... see my inline counter-comment.
We can wait for other comments (not too long, though ;-) and once all
are in, adapt the text and publish it together as a replacement RFC.
Greetings!
Raik
Michal Galdzicki
in terms of sameAs and versioning inRFC30, sounds like we need to
explain it more, so its clear.
I'm pushing on RFC31 myself, i got some stuff done on the weekend, but
I need more before I send it to the list. You set the bar high Raik!
later,
mike
Douglas Densmore
general, I am on board. Mainly I just wanted to capture my initial
thoughts and concerns.
Doug
On Apr 27, 9:54 am, Michal Galdzicki <mgald...@gmail.com> wrote:
> Sounds good,
> in terms of sameAs and versioning inRFC30, sounds like we need to
> explain it more, so its clear.
>
> I'm pushing on RFC31 myself, i got some stuff done on the weekend, but
> I need more before I send it to the list. You set the bar high Raik!
>
> later,
> mike
>
> On Sat, Apr 25, 2009 at 5:57 AM, Raik Gruenberg
>
>
> > Hi Michal,
>
> > Reshma suggested to write a replacement RFC rather than silently
> > replacing the existing file. So, I've posted your comments to the
> > official comment section:
> >http://openwetware.org/wiki/BBF_RFC_30
>
> > Agreed to all apart perhaps from the sameAs which, the way I meant it,
> > can be reciprocal... see my inline counter-comment.
>
> > We can wait for other comments (not too long, though ;-) and once all
> > are in, adapt the text and publish it together as a replacement RFC.
>
> > Greetings!
> > Raik
>
>
> >> uuuu
> >> To clarify a detail mistake: I worked with the April 23, 2009 version
> >> of the RFC 30 document. I see the one you have here is dated April
> >> 24, 2009 there will be discrepancies in page numbers, possibly some of
> >> these have been already fixed sorry for causing confusion.
> >> have a good weekend,
> >> mike
>
Raik Gruenberg
>
> Sounds good,
> in terms of sameAs and versioning inRFC30, sounds like we need to
> explain it more, so its clear.
>
> I'm pushing on RFC31 myself, i got some stuff done on the weekend, but
> I need more before I send it to the list. You set the bar high Raik!
writing? Well, don't take mine as an example for the length of an rfc.
Shorter would be better... and we can use your (and Doug's?)
experience from the data model formulation and adjust requirements in
the follow up rfc.
Greetings,
Raik