Cross-platform client and server JavaScript library, with a concentration on Solr, graphs, utilities, and convenience methods.
License: BSD 3-Clause "New" or "Revised" License
Generic repository, README, and scratch space for the Berkeley BOP.
If an input field value is null, it blows up:
js> bbop.core.get_assemble({"defType": "edismax", "qt": "standard", "indent": "on", "wt": "json", "rows": 10, "start": 0, "fl": "*,score", "facet": "true", "facet.mincount": 1, "facet.sort": "count", "json.nl": "arrarr", "facet.limit": 25, "personality": null, "sfq": {"document_category": ["annotation"]}})
We have the GO regexp floating around in the amigo code, so that could maybe be pulled in as an option--nice and not GO-specific. However, it would make the linker a bit more complicated. If too unpleasant, it might end up being a bad idea.
Using the current bbop_term_ac personality, having a q=GO:002200 returns a reduced set of results, none of which are related to GO:0022008. having a q=GO:0022008 returns the correct results at the top, but includes the previous set's nonsense results:
I'm adding this as a C rather than a B since this is a marginal use case.
We're currently on jQuery UI, but
There is some hilariously bad old code floating around in core.js and test.js. This ticket is a reminder that we need to move to a more solid base using underscore.js for the primitives, and hopefully built around npm tools, mocha, gulp, etc.
When the connection is slow on the search pane, it is difficult to know when a button has been pressed. A spinner (maybe autocomplete's) should be added to give a visual clue that action has started or is taking place.
This same spinner should also be visible during the initial search.
This is a bit opaque
Checked exclusive: GO:0006520 && GO:0006310 (3)
ERROR : exclusive count of 3 on: GO:0006520;GO:0006310
From:
The URL in the report is long, ugly and yields a warning.
This form works just as well:
When your search is pinned using IDs you can't see the labels for the IDs. I realize the way this works makes it a bit trickier to show the labels here, but I think we need to work on this.
In the above page with two closure terms pinned, there are 3 matching bioentities. They match because two terms in the list of direct annotations are in the closure of both search terms. We should be able to see which ones.
It would be nice to have a built-in elimination search for widgets that build long lists of items for people to search through. Think along the lines jQuery mobile.
http://jquerymobile.com/demos/1.2.1/docs/lists/lists-search.html
It would be nice to have the YAML descriptions appear in the column headers. Probably pretty easy with a span.
Counts that are the same number of returned documents does /not/ imply that the facet bears no information; think of closures on different paths--they might look the same (same counts) but clicking on them can get you different sets.
Even assuming the above, in Solr it's hard to eliminate facets--we have a lower limit, but not an upper one. without getting way more facets than we need, it's not knowable how many we would have to order to get 25 back. Might be doable with pivots in Solr 4.+?
We have triaged all of the above with mentioning a little about the redundancy in the accordion itself.
The progress bar in the filter shield is static and unhelpful. It should be replaced by a spinner since we cannot get progress in this case.
Remove/update dead modules like ringo http https etc. They are causing upstream problems when the bbop libraries are imported
yui-compressor isn't available on macports. Is there a quick workaround? I'm sure it wouldn't be hard to build from http://developer.yahoo.com/yui/compressor/ but I'm lazy...
This boils down to the use of bbop.logic to replace strings in fqs. This is on the map.
This starts getting a little harder since we'll be needing actual logic functioning in the fqs as their default functionality is flat and AND.
This will take a rewrite of some of the fundamental manager stuff. Probably not horrible, but will take a little effort.
Request from Ed.
Allow an optional function to filter the final results in autocomplete dropdowns.
Either pretty easy or fighting the way jQuery wants to do it.
This issue comes from table widget reuse in monarch-initiative/monarch-app#687.
Essentially, they cannot uniquely calculate a link from the ID and incoming field name, and need to probe another document field to make a correct calculation.
While not devastating for the linker itself in some formulations, the code around the linker at least needs access to more information to hint the linker properly. Which in turn means that the table cell needs to be able to access more than the local "bits", but rather the whole document at that moment, which we do not currently have.
Thus, the ability to access the larger context should be added to bbop-js functions to increase the general applicability; however, it would be an incompatible (although not earth shaking) API break. I think it would then be best handled by 1) allowing the _process_entry function to be overridden and/or 2) making the handler dispatch pass more information by default.
Yes, we are limiting this in scope to the handlers and the table cell drawing mechanisms for the BS3 table render at this point. This may cause API breaks elsewhere in AmiGO that will need to be fixed as we run into them.
The win for this item is that BBOP/AmiGO widgets can see wider reuse (e.g. Monarch).
From email thread with @cmungall and david
regulation heart g| (gives response because there /are/ free-floating "g"s)
regulation heart gr| (no response--not a lot of "gr"s)
regulation heart gro|* (wildcard added and "gro*" gives response)
A better method would be to only invoke the three character limit when the "last token" is the only token. This should give the desired behavior.
Labels (while real) like regulates_closure should be replaced, or at least modified, with a user label. Like how the accordion uses nice titles rather than internal strings.
While there is an argument to me made that it helps education, debugging, and training people for gannet, we might want to consider a change here.
The TransitivityGraph page mentions this but it isn't defined.
A computed relationship (or inferred relationship) is a relationship that is inferred through the application of a set of rules. For example, if P is declared transitive, then given path
x P y P z
There is a computed relationship x P z.
Implementations may differ in how this is performed, but as a general rule the rules should be specified in OWL, and the implementation should be complete w.r.t the EL++ subset of OWL. This allows for property chains, e.g.
Given
P o Q -> R
And a path
x P y Q z
Then there is an inferred relationship x R z
If we have a path
x P y Q z
And there are no property chains connecting P and Q, then the path between x and z cannot be reduced any further than a computed relationship
x (P o Q) z
For now we only allow primitive relations between nodes; thus the path between x and z would be discarded. In future we may make this configurable[??]
There is at least one computed edge for every asserted edge. Thus if the graph contains
x R y
Then it is valid to call 'x R y' a computed edge
We currently use the OWLGraphWrapper implementation
For filters that have graph structure associated with them (likely another special ending), have a display that operates more like a tree browser.
Unlikely to have any progress until #16, and would need some loader support (but see below).
Another way to do it would be to piggyback on #29 and have it as a pop-out. That might be the easiest and could be done with the current framework.
It would be nice to either extend the autocomplete (on ontologies) widget, or make a complementary widget that:
Tangentially requested by Paul T for Noctua functionality.
As stated, there should be a visual indication when there are more results than those seen in the autocomplete/search_box pop-up.
I am unaware of the best practice of supplying minified js files for libraries that may be used on the client, but this would be useful for Monarch while we implement bundling of js and css files.
With the accordion as a separate widget, not only would it make the code cleaner, we could apply the widget to other use cases such as reimplementing the tree-based annotation count (from AmiGO 1.x) and outside uses such as PAINT column filtering.
There needs to be a new widget/shield that allows the user to select all/group individuals of current filter set. This should then be added to the buttons of AmiGO 2.
Continuing from #33
My understanding is that the plan is to deprecate this library and replace it with other libraries. I'd like to make sure we don't lose any documentation when doing this. I can help move the graph docs over to bbop-graph, and updating them in the process. I don't want to start making PRs or wiki edits to bbop-graph yet til I'm sure of the plan.
goes fine with 25
and 100
10000 is a bit much
Not sure how important this is. May be bumped in favor of a selectable download widget.
While this issue affects usability, it is in a peripheral module when used in an extreme way.
There are just so many useful things to do with it...
Most immediately, I'd like to be able to coordinate a single spinner during action with sets of widgets in geneontology/amigo#104 for geneontology/amigo#69.
There are many uses for the new features, including items like searching facets, facet filtering.
To allow better interoperability, and to pave the way for rhino/ringo/node uses of bbop-js and amigo (easy opensearch, no more parallel implementations in perl and JS), we should commit to following the CommonJS spec.
I've already done some experimental packaging of bbop.js in a CommonJS-style container and it seems that while the rewriting of the namespaced calls will be annoying, there is little that would have to be changed otherwise. Looks easy, but requires a little elbow grease--image going back through the unit tests.
It might be good to revisit bookmarks and the search pane with an eye on getting the UI as well as the manager into the right state with a single call and a bookmark argument.
Currently, a large portion of the bookmark mechanism is left to the "user", so there is a lot of sanity and recall coding running around (think first call issues as well) that would probably be a better fit inside the search_pane itself.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.