create edit-mode with a form and for drag and drop

[smurp]

If the user has the right to edit in the current context then...

Expose a toggle (perhaps in the upper left) that looks something like this:

The View mode continues to expose the current behaviour.

When the Edit mode is engaged then a wide single line form is revealed off to the right of the toggle.
The form contains three fields: Subject, Predicate and Object.

Behaviour

• At any time one may type in any of the subject predicate or object fields. When typing autocomplete options are offered, perhaps like https://jqueryui.com/autocomplete/#default
• When a complete triple is filled in then the Save button becomes clickable
• Until a triple has been Saved the new edge appears big, fat and dashed. The subject and object nodes would be highlighted and lablled during this period too (similar to when an edge is being hovered over). Until the predicate is established the edge is grey.
• When a Save happens then the fields are emptied and Save becomes unclickable
• When one starts to drag from a node it will appear as the subject in the form and while one is dragging a new grey line will be visible to represent the new edge being created. The tail of the line will remain at the subject node and its head will follow the cursor, latching when close enough to the possible object node.
• When the mouse is released, if it is on a node then that node becomes the object
• To support the creation of DatatypeProperty triples (ie where the object is a literal string, number or date/time) -- when only the predicate field is set and is set to a predicate which has a range which is a string, date or number datatype then three things happen:
  1. the object field changes to an appropriate widget for that datatype
  2. any node which is subsequently clicked on becomes the subject of the triple
  3. drag operations are disabled until the Clear button is pressed or the predicate is changed to an ObjectProperty
• To support the editing of labels (recognized by predicates such as rdfs:label, foaf:name and so on) -- if a node is merely clicked rather than dragged then that node becomes the subject while any label becomes the value of the object; the value of the label becomes the object and the appropriate predicate is shown. If there are multiple triples which are recognized as being labels then the subject-predicate-object-save-cancel-delete section is multiplied, one per triple.
• To support the high speed creation of triples with the same predicate we could put a checkbox labelled auto under the predicate which would cause Save to happen as soon as a successful drop happens -- whereupon the subject and object would be cleared but the predicate would retain its value. This auto-save behaviour could only be engaged while the predicate field had a value and would only be sensible if the predicate were an ObjectProperty -- meaning that the object must be a resource rather than a literal data value such as a number, date or string.

Expand the Edit Form so it is a 3x3 table where the columns remain subject, predicate and object and the rows are label, uri and type. The behaviour of the contents of each of these 9 cells will have to vary along with the kinds of situations which will arise when using this form. They include:

• connecting existing nodes with an existing predicate
• connecting existing nodes with an predicate not already known in the ontology
• connecting a new node (subject or object) with either a new or known predicate

This obviously does not constitute a sufficient description of the needed subtle behaviours but points at the configuration of a form which should be able to handle most use cases.

For instance:

• typing in the subject-label cell when a subject isn't already selected will search for nodes by label and offer existing nodes as auto-complete choices
• typing in the subject-label cell when a subject has already been selected would be how a user could provide a label for that node (wrt the language indicated in a little adjacent language picker -- eg en vs fr etc)
• respect the subject type box as a way to fill in the blank in subject rdf:type ___ when adding or editing a subject

[smurp]

Here's a strategy for dealing with the need for a pluggable target for saving and editing.

Why a pluggable handler for saving? So each context into which HuViz can provide its own adapter for dealing with saving. Nooron, CWRC and the bare HuViz server are each going to need their own such facility, for example.

So how can this work? Let's pass a new edit_handler arg to HuViz which will be found at: @args.edit_handler by code within the HuViz class and subclasses. The object found there would not have to be an instance of any particular class but would have to provide an interface -- ie it would have a set of methods on it which are needed by the editui facility.

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB

The initial example of such an edit_handler would be an instance of a new coffeescript class which would perhaps use the IndexedDB technology to manage a local persistent database of quads. As we move forward with this design it will connect with the PickOrProvide technology which operates a database of ontologies and datasets to visualize where all of those are URIs and live elsewhere on the web. Presumably the edit_handler will present its available datasets as pickable by PickOrProvide. Likewise it will offer a way to export those datasets as .ttl files.

[smurp]

Let's call these things StorageControllers. This first one -- called IndexedDBStorageController perhaps which is used when HuViz is 'plugged into' the HuViz server rather than CWRC or Nooron or whatever -- should be have the following methods, which all implementers of the StorageController interface should also implement in their own way.

class IndexedDBStorageController
  constructor: (@graph_uri) ->
     # preserves the graph_uri for inclusion in the quads when they are saved
  register(@huviz) ->  
     # called by the HuViz constructor if the `edit_handler` no, no *`storage_controller`*
  assert(subj, pred, obj) ->
     # gets called by the editui whenever Save is clicked
     # calls @huviz.add_quad (so huviz can display it)
     # saves the quad via IndexedDB to an objectStore called `quadstore`
  get_graphs: ->
     # returns the list of graphs from `quadstore` so PickOrProvide can show them for picking

As this thing evolves it will also retrieve all the quads from the quadstore and feed them to HuViz when PickOrProvide chooses one.

[smurp]

see cwrc/HuViz#75