zepheira / bibframe-scribe Goto Github PK

We originally went with the rdfstore-js library for working with graphs on the server side, but as the author explains in antoniogarrote/rdfstore-js#92, he's opted to move away from server side support to focus on the browser. As such, support for the MongoDB persistence layer is already gone from the latest versions, and the only interface either usage supports is IndexedDB, of which there are very few interface-level implementations (e.g., translating the IndexedDB API to talk to MySQL, or something).

I've started a new branch to use https://github.com/mcollina/levelgraph instead, on the branch levelgraph which is presently at 2e4bd3f. There are some flaws as it exposes a core Node bug nodejs/node-v0.x-archive#5108 (or a level library actually potentially leaks memory) and has some non-trivial incompatibility with the current use of promises, but this is probably the working solution going forward. There's no need to install another component with Level, which seems like a plus for this software.

Obviously it is no longer compatible with earlier versions of Scribe. This can be dealt with by dumping Turtle/N3 from the rdfstore-js dependent versions and importing it into the latest.

Re-use existing authoring UI for editing after resources are made findable (#3).

Multiple subjects can be added to the vinyl record, electronic and print dissertation, and image profiles.

However in the electronic and print bibliography and book profiles, the subject pull-down dims after the first subject is added.

The expected export should include separate works, instances, and holdings depending on which each property is associated with, which requires re-working the underlying model and potentially the UI (so type-ahead brings in a work, or one can start with a work, etc.)

Reduce server load / improve performance by only sending typeahead find requests after a significant enough delay in typing to avoid asking for and receiving incomplete traffic. There's a point at which waiting to send becomes too long to balance against the overly eager send.

Make it easier to extend the services Scribe can query by turning those pieces into plugins. Consider even doing it as configuration, though some level of string manipulation is often taking place that's still probably best to do as code.

Model how a resource's label is resolved client- and server-side so type-ahead is searching the appropriate field for locally created resources.

Make profile-based configuration for client and server the same. Simplify, also resolve how profiles resolve references (currently everything goes into a global context).

Currently the holding (or item) profile refers generically to an Instance as its expected value, but since #15 isn't quite there, this isn't really possible to implement. Until the schema awareness piece is in, this is on hold.

Due to the implementation of the popover widget for #13, apparently the only way to access data is through the use of $parent, which is poor practice and doesn't actually work when pivoting to a create or edit a new resource. Find a way to get past this or implement a popover of our own.

Also, the current popover doesn't allow interaction with the widget and doesn't provide a useful mechanism for modifying the behavior to match our needs.

Find a way to display the full resource (typeahead, or other display) so the user has more information to determine which to use, etc. Make sure the provenance of a resource is also readily at hand (as a typeahead result, etc.)

The interface displays all the properties for instance and work together, but often an instance or a holding does not need the entire set as the more general resource already exists. Possibly provide a way to just catalog an instance given an existing work, but more generally, consult with the BIBFLOW project on user testing for what seems best practice for users.

Pull in several and cache from the server side, pull in more when needed.

Refactor them to be more in line with modern AngularJS best practices, particularly in an attempt to avoid most uses of $scope for state tracking. There is some use of $evalAsync that can't be avoided, but most of it can probably be removed to a service so only service connection logic remains in the controller(s).

Enhance error handling framework to better reflect errors (mostly in configuration, also for network problems).

For resources found via typeahead, allow the user to fork the resource description and edit it for local usage and storage. Possibly as part of #13.

Refactor them to be more in line with AngularJS-style factories.

The "type to search" functionality does not seem to be working with properties that are displayed in modals. When selecting (+), the modal displays a layout and structure per the profile just fine, but the "type to search" on any value displayed in a modal simply spins.

Make all the locally persisted data browsable.

Introduce a level of schema awareness around classes and subclasses so more general references can be made.

Prevent ridiculously wide typeahead selection box by putting full in a title attribute and abbreviating initial display.

Most of the non-network startup time is consumed by building the actual forms based off of profiles and tends to be quite a bit longer than completing network requests, even remotely. Instead of taking up that processing time up front and potentially freezing the browser, build them at need.

Using mappings in the bibfra.me vocabulary, turn the RDF displayed in the current implementation for #13 into something useful for users to look at. Relies on #15 to determine property mappings.

See https://gist.github.com/semiosis/5725311 for an example; should be a service that takes in $resource requests and allows no more than a configurable limit in flight. The current implementation beach balls when too many profiles are requested and parsed at the same time (which also prevents the progress bar from showing anything useful - 0 to 100 after some freezing).