Giter VIP home page Giter VIP logo

bep's Introduction

BEP - BEL Enhancement Proposals

BEL enhancement proposals will be developed and posted here for public consumption. Any changes to the BEL Language or aspects highly pertinent to the BEL language such as BEL Nanopubs need to be proposed here.

The main focus of this is for the BEL Language enhancements or deprecations and community-wide standards such as the BEL Nanopub JSONSchema. It is not necessarily for the BEL.bio API as that is an implementation of a BEL API, though well constructed BEPs detailing enhancements for the BEL.bio API will be appreciated by the BEL.bio maintainers.

Please copy the template provided and fill out the relevant sections. While the BEP is in Draft mode - please add it to the draft directory. When it is approved, it will be moved to the published directory. Rejected or withdrawn BEP's will be moved to the unapproved directory.

If you have questions or need help updating a proposal, please add an issue to this project with your contact information. Someone will contact you to help you write your proposal or edit a proposal. Also, it is helpful to submit an issue with your proposed BEP before starting it to get initial feedback (e.g. has it been proposed before, potentially recommend other people to get involved in creating the BEP, etc).

Anyone can submit a BEP or propose edits to a BEP in DRAFT mode even if you are not the creator of the BEP. The creator of the BEP will decide what edits to include.

After creating the BEP, please announce it on the OpenBEL Discussion Group. Please include a link to the Pull Request you created and also a link to the BEP proposed document in the announcement.

Tutorial

Submitting a BEP Proposal Tutorial

If you are uncomfortable with creating a BEP using Github Pull Requests, you can send the BEP to me whayes at biodati dot com, and I will add it for you.

BEP Types

There are three kinds of BEP:

A Standards Track BEP describes a new feature or implementation for BEL. It may also describe an interoperability standard that will be supported outside the standard BEL functionality. This is for changes to the BEL language (e.g. something that will go into the BEL Specification - new/changed BEL function, relationship, etc).

An Informational BEP describes a BEL design issue, or provides general guidelines or information to the BEL community, but does not propose a new feature. Informational BEPs do not necessarily represent a BEL community consensus or recommendation, so users and implementers are free to ignore Informational BEPs or follow their advice. An example would be how to handle missing namespace values.

A Process BEP describes a process surrounding BEL, or proposes a change to (or an event in) a process. Process BEPs are like Standards Track BEPs but apply to areas other than the BEL language itself. They may propose an implementation, but not to BEL's codebase; they often require community consensus; unlike Informational BEPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in BEL development. Any meta-BEP is also considered a Process BEP. Another example of a process BEP would be how we manage the BEP process (very meta).

Parts of a BEP

Preamble -- Header containing meta-data about the BEP, including the BEP number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc.

Abstract -- a short (~200 word) description of the technical issue being addressed.

Rationale and Goals -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made.

It should clearly explain why the existing language specification is inadequate to address the problem that the BEP solves. BEP submissions without sufficient motivation may be rejected outright. It should also describe alternate designs that were considered and related work.

The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion.

Use Cases -- share how the new language feature will be used. For example, adding a populationAbundance() function would allow capturing population level changes due to environment or treatment. Consumers would be the EPA, Toxicologists, Microbiome biologists, etc.

Specification -- The technical specification should describe the syntax and semantics of any new language feature.

Backwards Compatibility -- All BEPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The BEP must explain how the author proposes to deal with these incompatibilities. BEP submissions without a sufficient backwards compatibility treatise may be rejected outright.

Reference Implementation -- The reference implementation must be completed before any BEP is given status "Final", but it need not be completed before the BEP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of BEL Language and API details.

Administrative Notes

BEP administrators should accept the PR after the BEP Review has decided the BEP outcome (e.g. Approved, Rejected, Withdrawn). The BEP should be moved into the appropriate folder (Approved -> published, Rejected/Withdrawn -> unapproved). A History section right after the title should be added with the link to the Pull Request like the example below:

## History
[Pull Request Discussion for BEP-0002](https://github.com/belbio/bep/pull/4)

Acknowledgements

Thanks to Python and their Python Enhancement Proposal (PEP) process for providing a lot of the ideas behind the BEP process.

bep's People

Contributors

wshayes avatar cthoyt avatar ncatlett avatar vtoure avatar

Stargazers

Scarlett Woodward avatar Michael Steinbaugh avatar Frank D. Evans avatar Kristian Kolpeja avatar  avatar Benjamin M. Gyori avatar JamesLinus avatar

Watchers

 avatar John A. Bachman avatar James Cloos avatar  avatar  avatar  avatar Benjamin M. Gyori avatar Christian Ebeling avatar

bep's Issues

How to encode domains in BEL

Earlier this week, @johnbachman mentioned he wanted to do this. Now, we're working on curating how Tau antibodies are interacting with Tau, and we have the same need. Let's use this issue thread to start collating examples and discussion. CC: @AldisiRana

One idea:

p(HGNC:YFG, domain(start_end))

Also it would be good to show some examples with their equivalences to InterPro terms as well

Schedule November 2018 BEP Review Meeting

Time

How does the second week of November sound? That should give us time to scramble to write and pre-review any remaining BEPs ๐Ÿ˜„

Agenda

Definitely on the docket:

  • BEP-0004 - equivalence relationship (#11)
  • BEP-0005 - regular expression namespaces (#12)
  • BEP-0006 - gene modification syntax (#13)
  • BEP-0007 - numeric annotations (#16)

Still needs BEP:

  • Intake/endocytosis function (#7)
  • Style Guide (#17)

Write BEP for uptake function

Much like secretion() and cellSurfaceExpression() it would be nice to have an intake() function that's syntactic sugar around the translocation() function that represents the opposite direction of movement from secretion().

This would have some nice examples for viruses pulling themselves into cells, for endocytosis of chemicals like neurotransmitters, and for chemicals activating receptors which then get endocytosis-ed as well

BEP for specification of BEL version

BEL documents have either been written in 1.0, 2.0, a mixture of 1.0/2.0, or 2.0.0+

Should BEL documents specify what version they're using? This wouldn't affect 1.0 or 2.0, but would make differentiating future versions with minor/major updates much more easily.

Perhaps with something in the document section of the BEL script like SET BEL = "1.0.0".

Another question: how would we deal with documents that are a mixture of BEL 1.0/BEL 2.0?

Write BEP for partOf relationship

Like the noCorrelation and equivalentTo relationships, a partOf relationship would allow much better expression of the semantics common to other knowledge assemblies. See FamPlex as a good example. Sometimes, partOf has the inverse, but broader semantics as the hasComponent relationship.

We should consider the semantics of partOf and hasPart as described in the Gene Ontology as well:

In BEL 1.0/2.0 this made sense:

complex(FPLX:9_1_1) hasComponent p(HGNC:HUS1)
complex(FPLX:9_1_1) hasComponent p(HGNC:RAD1)
complex(FPLX:9_1_1) hasComponent p(HGNC:RAD9A)

It might be better to write in the other direction:

p(HGNC:HUS1)  partOf complex(FPLX:9_1_1)
p(HGNC:RAD1)  partOf complex(FPLX:9_1_1)
p(HGNC:RAD9A) partOf complex(FPLX:9_1_1) 

Reasoning over part of

Basically, any direct paths containing only partOf and isA imply partOf.

A partOf B and B isA C implies A partOf C

For proteins, this would describe a hierarchy of complexes.

p(X) partOf complex(Y)
complex(Y) isA complex(Z)

# Infer:
p(X) partOf complex(Z)
  • Example
  • Logically consistent

A partOf B and B partOf C implies A partOf C

For proteins, this would describe a complex formed of other complexes.

p(X) partOf complex(Y)
complex(Y) partOf complex(Z)

# Infer:
p(X) partOf complex(Z)
  • Example
  • Logically consistent

Does FamPlex have an example for either of these first two headers (@johnbachman)? I will write a script to check the https://github.com/sorgerlab/famplex/blob/master/relations.csv to see.

A isA B and B partOf C implies A partOf C

p(HGNC:PRKAA1) isA p(FPLX:AMPK_alpha)
p(HGNC:PRKAA2) isA p(FPLX:AMPK_alpha)
p(FPLX:AMPK_alpha) partOf p(FPLX:AMPK)

# Infer:
p(HGNC:PRKAA1) partOf p(FPLX:AMPK)
p(HGNC:PRKAA2) partOf p(FPLX:AMPK)
  • Example
  • Logically consistent

Does this make sense? Should we infer all AMPK complexes have PRKAA1? I don't think that's what FamPlex is trying to say. If p(X1) isA p(X) and p(X2) isA p(X) and p(X) partOf complex(Y) then should we should infer that either X1 or X2 are present in Y?

Add BEP for numeric annotations

I'd like to see numeric/quantitative BEL annotations specifically supported as numbers. Use cases would include filtering knowledge (e.g., edges with 'cohort size' > 20, 'p-value' < 0.01) and potentially weighting edges based on significance or effect size.

In BEL Script 1.0, namespaces and annotations could be defined as a url (pointing to a belns or belanno file), a list of values, or a pattern/regular expression (see https://wiki.openbel.org/display/BLD/Control+Records). To some extent, this representation need is covered by patterns, but the original specification does not specifically cover handing of numeric annotations as numbers.

I am also interested in specifying time annotations, but am not sure if they belong in a separate BEP since units (e.g., minutes, hours, days, years) also need to be considered.

Update openbel.org website

@cebel and @sgebel would like an updated version of the openbel.org site - right now it only shows the BEL 1.0 and 2.0 specifications. We need to make an update to incorporate all 2.1 changes

http://bel.bio/bep is down

Receiving a web page that says:

404 Not Found
Code: NoSuchKey
Message: The specified key does not exist.
Key: bep
RequestId: 32A5B3D108FA8081
HostId: G9Po1vh9BUO0s4Tkw7k4Lb5WsgDmzI26jAm4dEP6AeTSzv/UbQxWzvCHI+nvYPxVPuYRct4RRBY=

Write BEP for regular expression namespace definitions

I'm not absolutely sure if this is a good idea, but defining namespaces by the regular expressions defined by Identifiers.org would be a good way to defer semantic validation for the most tricky namespaces (such as dbSNP)

Write BEP for special EvidenceType annotation

It might be the case that text evidence is not available. Sometimes, it comes from a database or a table that has no text. This would also need some thorough guidelines as well.

Adding new terms to BEL default namespace

  1. We have a specific need to add the modification type Acylation/Acyl to the default namespace. (this general term seems like a good fit to describe acylated Ghrelin, as this is how it is frequently referred to in the literature. (The specific modification appears to be o-octanoylation (MOD_00295) or o-decanoylation (MOD_00390), but many/most papers do not refer to the modification in this way)

  2. We need a mechanism to make additions and other changes to the BEL default namespace. This could be a BEP, but the level of discussion/review and the review and update cycle timing needs may be different.

See also related issue belbio/bel_resources#98

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.