Thursday, 11 October 2007, from 3:00pm to 5:00pm EDT.
Location: Stata G451, MIT.
The Stata Center is the huge Gehry building at the corner of Vassar
and Main in Cambridge.
G451 is on the 4th floor very close to the east (= Gates = Main St)
elevator bank. From the elevators go short distances straight, left,
right, right, straight; see floor plan at
http://www.csail.mit.edu/resources/maps/4G/G451.gif .
We'll discuss the relations between BioPAX, the semantic web, and OBO
(especially OBI and OBO Foundry).
Thanks
-=MIchel=-
On Oct 9, 10:48 am, "jonathan.r...@gmail.com"
Jonathan
On Oct 10, 9:13 am, Michel Dumontier <michel.dumont...@gmail.com>
wrote:
The "attitudes" in this paper seem most relevant to our planned
discussion, and I believe they point us toward 3 excellent avenues
for BioPAX's evolution and growth.
http://www.webont.org/owled/2006/acceptedLong/submission_26.pdf
I hope all those meeting tomorrow will have read about them.
Dan
Tensions between "record" and "domain" attitudes in BioPAX.org have
slowed the growth of the BioPAX standard. The attitudes compete to
influence a single, monolithic, over-controlled "next release", but
they are so much at odds that little happens. [2] identifies and
names the attitudes, which alone will encourage some resolution.
It may come if BioPAX standards by policy shift into a more open,
modular form, in which "attitudes" can be independently expressed
and formalized within smaller sub-schema. Authored and released by
sub-groups, each could then be selectively re-integrated as BioPAX
end-users saw fit, not unlike modules in a programming library.
Modularizing release standards requires "statement" attitudes and
concepts. They get ignored in BioPAX 2.0, as they arise (gasp) in
NLP work. Yet they can advance interoperability, not merely among
competing BioPAX modules, but among open sets of ontologies from
many sources - each seen as the competing statement that it is.
A way forward: adopt modular release policies plus the "statement"
design patterns, concepts, and support tools they require. An old
proposal on this exists, but would benefit from some updating:
[5] http://biopaxwiki.org/cgi-bin/moin.cgi/ReleaseToolsProposal
regards,
Dan Corwin
Michel Dumontier wrote:
> There are several relevant papers wrt to our discussion
>
> [1] - Joanne's paper: http://www.biomedcentral.com/1471-2105/8?issue=S3
> [2] - Alan's paper:
> http://www.webont.org/owled/2006/acceptedLong/submission_26.pdf
> [3] - Lena's paper:
> http://bioinformatics.oxfordjournals.org/cgi/content/abstract/21/24/4401
> [4] - Kei's paper: http://tinyurl.com/yqghun
>
> I think [1] clearly identifies several important issues in using BioPAX
> as it stands now. **Dan, can you elaborate on what 3 avenues for BioPAX