Sense Atlas Front End

A

About the only time Sense Atlas needs a full page refresh (and even then is debatable) is when a new entity is added through a semantic relation.

Other: Most (if not all?) of the changes that cause full-page round trips could be supplanted by AJAX (or whatever it's called these days).

Add a log in/out widget to the footer (email and "go" button to log in, logout button to log out).

Other: [RESOLVED] Logging in and out of Sense Atlas currently happens out of band.

Add appropriate Cache-Control headers and enable caching on the reverse proxy wrapping Sense Atlas.

Other: Even ordinary page GETs when the graph state has not changed can be slow, particularly the first time a user loads a generated resource.; There turns out to be a bug somewhere in the caching mechanism that causes templates to break when they return 304 Not Modified.

All JavaScript particulars should be fully bootstrappable (and bootstrapped) from RDFa (and subsequent JSON-LD) data.

Other: Establish a consistent architecture for organizing front-end JavaScript code that accounts for RDF(a, JSON-LD) and NPM modules.

All of the instance data currently in the wild is easily accessible and can be manipulated with a single SPARQL query.

Has Broader: Change the main label on IBIS entities from rdf:value to skos:prefLabel and use e.g. skos:definition or dct:description or rdfs:comment for the longer text.
Other: What about the existing instance data that all uses rdf:value?

Almost all Web templating languages allow for broken markup (a major reason we're still using XSLT is because it doesn't).

Other: Survey other templating languages.

Alter the template so that the editing widgets do not show up unless there is a registered user detected.

Has Broader: Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.
Other: [RESOLVED] The editing widgets show up even if there is no current logged-in user.

Always focus the network when you select it or create a new one.

Other: Changing the focus isn't really that big a deal and it can always be changed later.; Do we always want to focus the new network?; Maybe the user just wants to look at the other network (or create one and not switch to it).; Switching the focus without being conspicuous about it could cause the user to make a mistake.

An autofilled text box has an unlimited capacity and is easier to deal with than a dropdown when there are lots of entities.

Other: Implement the network switcher as a an autofilling text box.

An autofilled text box will take up less space.

Other: Implement the network switcher as a an autofilling text box.

Augment the operations over connections between entities (except for adding a brand new entity) and the subsequent update to the graph visualization to avoid a full server round trip.

Has Broader: Write front-end code that hijacks form submissions and supplants them with AJAX (again, or whatever it's called).
Other: Manipulating the properties of the entity itself would be easy enough, but altering the connections entails updating both the layout and the graph.

Augment the remaining form controls that are neither the textareas nor the connections to update without a full round trip.

Has Broader: Write front-end code that hijacks form submissions and supplants them with AJAX (again, or whatever it's called).
Other: Manipulating the properties of the entity itself would be easy enough, but altering the connections entails updating both the layout and the graph.

Autofilled text boxes are implemented inconsistently across browsers.

Other: Implement the network switcher as a an autofilling text box.

Automatically import the node; people can remove it later.

Other: Automatically importing the entity may make sense for creating new networks but could make a mess with existing ones.; What about the IBIS entity in context? Does it get ported to the other network?

Automatically importing the entity may make sense for creating new networks but could make a mess with existing ones.

Other: Automatically import the node; people can remove it later.

The accessors are useful and would be useful with graphs other than those embedded within an RDFViz instance.

Other: Put the RDF accessors in a Store subclass.; Put the RDF accessors in the RDFViz class.

[ADOPTED] Only focus the new network if the user explicitly signals to do so (i.e., through a dedicated button).

Has Narrower: Make sure the UI has a "Set Focus" button.
Other: Do we always want to focus the new network?; Extra buttons are potentially clutter.; The user's intent is always clear.

B

A bunch of useful RDF accessors have accumulated in the generic graph tool script.

Other: Add the graph accessor methods as a mix-in onto Store.; Put the RDF accessors in a Store subclass.; Put the RDF accessors in the RDFViz class.; Refactor the JS such the generic parts are separated from the Sugiyama (and/or ontology-)specific code.; The Sugiyama code also has a bunch of stuff for prefix/namespace mapping, abbreviating/expanding CURIEs, etc.

The backlinks transform is actually extremely goofed and contributing to slow page delivery, which will only get worse if it has to parse more forward links too.

Other: Create a "forward links" transform to attach residual links to opaque (e.g. static) documents, analogous to the backlinks transform.; Fix the backlinks transform so that it only produces non-redundant links, and only for the subject document and any fragments thereof.

C

Change the main label on IBIS entities from rdf:value to skos:prefLabel and use e.g. skos:definition or dct:description or rdfs:comment for the longer text.

Has Narrower: All of the instance data currently in the wild is easily accessible and can be manipulated with a single SPARQL query.
Other: It would be nice to have inline descriptions on IBIS entities for additional text.; What about the existing instance data that all uses rdf:value?

Changing the focus isn't really that big a deal and it can always be changed later.

Other: Always focus the network when you select it or create a new one.

Client wants to use the IBIS tool (Sense Atlas) in everyday operations.

Has Narrower: Plan projects and resources with the use of the Process Model Ontology.; [RESOLVED] Client wants the ability to create multiple IBIS networks.
Other: Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.

Cluster the relationship properties into macro-groups and just assign one colour each: personal, professional, academic, antagonistic, incidental/ephemeral. Something like that.

Other: The relationship ontology has 32 person-to-person properties, and that's not even exhaustive. Way more than we can colour.

Computing the layout on the server side will afford the generation of SVG (and raster derivatives) for clients (e.g. bots) that don't do client-side scripting.

Other: Preemptively compute the Sugiyama layout on the server side (asynchronously, of course) when the subgraph in question is changed, which can be cached and shipped out whole over the wire.

Consider implementing markup transforms on top of SAX rather than DOM where possible.

Other: Markup transforms that have to parse a lot of input and/or generate a lot of output (e.g. backlinks) will necessarily be slower.

Consider putting the entity's class in the initial path segment, e.g. /issue/.

Other: It would be useful if people coming from outside Sense Atlas had a heads-up as to what they were clicking on.; It wouldn't hurt to slice off some of the URL path real estate for certain designated classes (and put the respective catalogues at those addresses).

Contact the authors of the relationship ontology and see if they'll accept a patch.

Has Broader: Create a template for foaf:Person.
Other: The relationship ontology has a lot of weirdnesses around property inheritance and a few properties that would be useful that are missing.

Could we establish that an argument is an argument purely by inference?

Other: Narrowing the search of existing node by type makes it harder to search for existing nodes to connect.; There is no upgrade/downgrade path to go from { issue ↔ argument ↔ goal ↔ target } or { position ↔ task }.

Create (and run) a SPARQL script that does the appropriate surgery to add the forward-links transform to the transform queue.

Has Broader: Create a "forward links" transform to attach residual links to opaque (e.g. static) documents, analogous to the backlinks transform.
Has Narrower: Fix the bug in RDF::LMDB that is preventing the default graph from being selected.
Other: SPARQL should also be selecting the default graph with a `GRAPH ?g` construct, but the quad store isn't doing it.

Create a "forward links" transform to attach residual links to opaque (e.g. static) documents, analogous to the backlinks transform.

Has Broader: Create a one-off front page that promotes Sense Atlas and explains to people what they're looking at.
Has Narrower: Create (and run) a SPARQL script that does the appropriate surgery to add the forward-links transform to the transform queue.; Fix the backlinks transform so that it only produces non-redundant links, and only for the subject document and any fragments thereof.
Other: How do we account for the dynamic elements on the page from the graph?; It is wasteful to extract the graph data out of the RDFa in the document, throw it away, and then extract it again, as it moves through the transformation pipeline.; The backlinks transform is actually extremely goofed and contributing to slow page delivery, which will only get worse if it has to parse more forward links too.

Create a handler that generates an appropriate link preview graphic for IBIS entities.

Has Broader: Use link preview conventions (SDO, OGP) to render robust link previews in various surfaces (Slack, Discord, Teams, chat apps, &c).
Other: It would be valuable to see the topological neighbourhood of a particular IBIS entity (i.e., is it central or is it in the weeds?)

Create a keyboard event handler that submits the form for all forms that only contain a datetime-local widget (as a non-hidden control).

Has Broader: Expand the script that manages the adjacent entity controls so that it also attaches to the "agent" controls.
Other: It turns out that (at least in Firefox) the `datetime-local` input does not let you set a valid ISO8601/W3CDTF time stamp, only a truncated one.; The datetime-local input type does not seem to elicit form submission with the enter key like a text box does (in Firefox).; `Date.prototype.toISOString()` encodes the time zone offset as Zulu (UTC) no matter what it actually is.

Create a Namespace class as a subclass of NamedNode (also wrapped by a Proxy) that is transparent and has the old interface plus an accessor-based one.

Has Broader: Write an NSMap class that cosplays as an Object (via Proxy) that also encapsulates the term abbreviation/expansion code and just smuggle it in there along with the rest of the mix-in.
Other: The reason why this may not have been done already is that RDF.Namespace is a closure, which means you can't see the namespace URI inside it.

Create a new <datalist> for autofilling foaf:Agent entities.

Has Broader: Expand the script that manages the adjacent entity controls so that it also attaches to the "agent" controls.

Create a one-off front page that promotes Sense Atlas and explains to people what they're looking at.

Has Narrower: Create a "forward links" transform to attach residual links to opaque (e.g. static) documents, analogous to the backlinks transform.
Other: How do we account for the dynamic elements on the page from the graph?; The front page of senseatlas.net is also super janky.

Create a pop-up "jump to entity"/"create new unconnected entity" interface.

Has Broader: It would be useful, from the keyboard, to be able to jump to an entity you know is in the graph but not immediately connected.
Other: From the entity UI, there is no mechanism for adding a new entity that is not attached to the current entity.

Create a server-side XSLT transform.

Other: Google has, in fact, committed to eliminating support for XSLT.; We were relying on browser cache to keep XSLT from being intolerably slow.

Create a template for foaf:Person.

Has Narrower: Contact the authors of the relationship ontology and see if they'll accept a patch.; Treat foaf:knows informally as symmetric anyway.
Other: Represent networks of people and their organizational and/or institutional affiliations, as well as their products.; The only person-to-person relation is foaf:knows and it was deliberately made not symmetric.

Create a template for gr:ProductOrService.

Other: Represent networks of people and their organizational and/or institutional affiliations, as well as their products.

Create a template for org:Organization.

Other: Represent networks of people and their organizational and/or institutional affiliations, as well as their products.

Create a template for pm:Target.

Has Broader: Rough out the new classes and try loading them with instance data; take notes for what can be improved.; Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.
Has Narrower: Expand the script that manages the adjacent entity controls so that it also attaches to the "agent" controls.

Create a template for pm:Task.

Has Broader: Rough out the new classes and try loading them with instance data; take notes for what can be improved.; Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.
Has Narrower: Expand the script that manages the adjacent entity controls so that it also attaches to the "agent" controls.
Other: The datetime-local input type does not seem to elicit form submission with the enter key like a text box does (in Firefox).

Create a template for sioct:AddressBook in lieu of a more appropriate collection type.

Other: How do we yoke or group these entities together?

Create ibis:endorsed-by relations widget, i.e. the ability to "like" an entity.

Has Broader: Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.
Other: How do you get the users into the system?

The (coarse-grained) layout for the Sugiyama visualization only has to be computed when the state of the graph (actually, subgraph) changes.

Other: Preemptively compute the Sugiyama layout on the server side (asynchronously, of course) when the subgraph in question is changed, which can be cached and shipped out whole over the wire.; Store layout data computed on the client side in local storage across requests; invalidate and recompute it if the server responds with new data.; The edge-uncrossing algorithm in d3-dag (and Sugiyama in general) is known to run superlinearly (how bad?) to the edges it has to uncross.

The catalogue resources, as well as the concept schemes and issue networks, can get particularly large.

Other: Implement provisional JSON-LD variants for large resources (notably the catalogues) accessed through client-side scripting.; The footer loads all the concept schemes/issue networks in the inventory (for labels?) when it probably doesn't need to.; The time it takes to generate a markup representation of a resource is proportional to the number of statements.

D

Debugging XSLT 1.0 in particular is brutal, due to years of neglect from the browser vendors.

Other: Despite being standard, reliable, and fast to execute, and built into every browser, XSLT 1.0 in particular is really clunky to work with.

Design a Graph Layout Ontology.

Other: A graph layout ontology in RDF would enable shipping an SVG to the client with the layout data (along with the graph data itself) embedded in RDFa.; Precomputing the graph visualization layout will need some kind of intermediate representation.

Design a mechanism for offloading and/or paginating backlinks.

Has Narrower: Make an addressable transform of the form `;backlinks=property,window-start,window-end` —one for each property (that runs long).
Other: It is easy for certain classes of resources (e.g. foaf:Person) to accumulate a large number of backlinks (e.g. dct:creator).; It's possible that more than one individual property can accumulate enough backlinks to cross the pagination barrier, confounding a global window parameter.

Despite being standard, reliable, and fast to execute, and built into every browser, XSLT 1.0 in particular is really clunky to work with.

Other: Debugging XSLT 1.0 in particular is brutal, due to years of neglect from the browser vendors.; The XSLT component kind of sucks.; There is likewise the persistent threat that one of the browser vendors (say Chrome) removes support for XSLT 1.0.; Try messing around with SaxonJS?

Devise a radial clumping algorithm for determining the θ of each node.

Other: Perhaps the ridiculous distances (r) between nodes will resolve itself if the ridiculous radial distance (θ) is fixed.; The math on the hyperbolic sugiyama visualization is wrong; nodes farther down rank are miles apart from each other (both r and θ).

Dispatching templates on the server side would afford getting rid of that clunky and ridiculous client-side dispatcher.

Other: Getting rid of the clunky client-side dispatcher would also get rid of that giant RDF/XML file containing all the vocabs, which isn't used for anything else.; Modify the transform that inserts XSLT processing instructions to match against asserted types (or specific resources).; Use the import precedence native to XSLT.

Do we always want to focus the new network?

Other: Always focus the network when you select it or create a new one.; Do we show the UI to focus the network if it's already focused?; Is the focus a property of the graph, or a property of the user state?; Make some UI that affords creating a new IBIS network (or SKOS concept scheme) from an entity or network overview.; Make some UI that affords switching IBIS networks.; [ADOPTED] Only focus the new network if the user explicitly signals to do so (i.e., through a dedicated button).; [RESOLVED] For writing to the graph, the IBIS tool requires a "focus" node with which to associate new entries. This is associated with a state object, which is in turn associated with the current user.

Do we show the UI to focus the network if it's already focused?

Other: Do we always want to focus the new network?; Keep the focus button and disable it, and change the text to say "Focused".; No, remove the set focus button if the network in question is already focused.; Yes, always show the focus button and make clicking on it a no-op.

Do we want to be able to ascribe a value to the goal specifically, rather than the target—which has a budget?

Other: Rough out the new classes and try loading them with instance data; take notes for what can be improved.

Double-check the behaviour of datetime-local in Chrome and Safari.

Other: The datetime-local input type does not seem to elicit form submission with the enter key like a text box does (in Firefox).

Dropdowns are easy to implement.

Other: Implement the network switcher as a dropdown.; Radio buttons are just as easy to implement (over a small, fixed set of elements) as dropdowns.; Use a dropdown to select between IBIS network and SKOS concept scheme like in the initialization phase.

Dropdowns can get huge and unwieldy.

Other: Implement the network switcher as a dropdown.

Dropdowns hide the available options behind a click.

Other: There is a bigger target to click with radio buttons.; Use a dropdown to select between IBIS network and SKOS concept scheme like in the initialization phase.

The <datalist> elements used to drive the autofills are useless without JavaScript anyway, so could probably be generated more cheaply by JS instead.

Has Broader: The front-end template is almost certainly doing way more work than it needs to.
Other: Move the generation of <datalist> elements, which only get used by JavaScript anyway, from the template to JS, so it can take advantage of the JSON-LD variants.

The datetime-local input type does not seem to elicit form submission with the enter key like a text box does (in Firefox).

Other: Create a keyboard event handler that submits the form for all forms that only contain a datetime-local widget (as a non-hidden control).; Create a template for pm:Task.; Double-check the behaviour of datetime-local in Chrome and Safari.
See Also

[DONE] Create a template for pm:Goal.

Has Broader

[DONE] Put Sense Atlas online so the client can observe its development.

Has Broader: Rough out the new classes and try loading them with instance data; take notes for what can be improved.
Other: Unlike IBIS which is half a century old, the PM ontology has never been road-tested, and will likely require several iterations to get right.

`Date.prototype.toISOString()` encodes the time zone offset as Zulu (UTC) no matter what it actually is.

Other: Create a keyboard event handler that submits the form for all forms that only contain a datetime-local widget (as a non-hidden control).
See Also

E

An eyeball estimate actually suggests the link and backlink transforms (which each scan the document for RDFa) account for the majority of the time it takes to serve the `all-classes` resource.

Other

Editable blocks would also afford elementary markup (bold, italic, monospace, inline links, &c).

Other: Replace the <textarea> elements with editable paragraphs for a quick (?) win.; We haven't determined how we're going to handle rdf:XMLLiteral yet.

Eliminate the need for the template to load (and thus trigger the generation of) every single concept scheme/issue network.

Has Broader: Take immediate provisional measures to speed up Sense Atlas (provided they are non-destructive).
Other: The footer loads all the concept schemes/issue networks in the inventory (for labels?) when it probably doesn't need to.

Establish a consistent architecture for organizing front-end JavaScript code that accounts for RDF(a, JSON-LD) and NPM modules.

Other: All JavaScript particulars should be fully bootstrappable (and bootstrapped) from RDFa (and subsequent JSON-LD) data.

Even once caching is implemented, a full server round-trip for the whole page with every POST is costly and often unnecessary.

Has Broader: Most (if not all?) of the changes that cause full-page round trips could be supplanted by AJAX (or whatever it's called these days).
Other: Implement internal caching.; Override form POST actions with scripting.

Even ordinary page GETs when the graph state has not changed can be slow, particularly the first time a user loads a generated resource.

Has Broader: [RESOLVED] Sense Atlas can sometimes be unusably slow.
Other: Add appropriate Cache-Control headers and enable caching on the reverse proxy wrapping Sense Atlas.; Implement internal caching.; Sense Atlas is particularly slow after POSTs because the RDF store only has a single global modification time (that I had to hack in).; The time it takes to generate a markup representation of a resource is proportional to the number of statements.

Expand the script that manages the adjacent entity controls so that it also attaches to the "agent" controls.

Has Broader: Create a template for pm:Target.; Create a template for pm:Task.; [DONE] Create a template for pm:Goal.
Has Narrower: Create a keyboard event handler that submits the form for all forms that only contain a datetime-local widget (as a non-hidden control).; Create a new <datalist> for autofilling foaf:Agent entities.

Extra buttons are potentially clutter.

Other: [ADOPTED] Only focus the new network if the user explicitly signals to do so (i.e., through a dedicated button).

The edge-uncrossing algorithm in d3-dag (and Sugiyama in general) is known to run superlinearly (how bad?) to the edges it has to uncross.

Has Broader: [RESOLVED] Sense Atlas can sometimes be unusably slow.
Other: Implement the edge-uncrossing portion of the layout algorithm in a faster language (Rust?) that can be compiled to WASM.; Police d3-dag for any obvious implementation flaws that can be optimized out.; The (coarse-grained) layout for the Sugiyama visualization only has to be computed when the state of the graph (actually, subgraph) changes.; While the graph layout is being computed, consider some kind of progress bar or analogous animation to show the user something is happening.
See Also

The effort it takes to map out a set of related issues should be roughly equivalent to composing a thread on Twitter (or descendant), where each entity is analogous to a tweet.

Other

F

Fix the backlinks transform so that it only produces non-redundant links, and only for the subject document and any fragments thereof.

Has Broader: Create a "forward links" transform to attach residual links to opaque (e.g. static) documents, analogous to the backlinks transform.
Other: The backlinks transform is actually extremely goofed and contributing to slow page delivery, which will only get worse if it has to parse more forward links too.

Fix the bug in RDF::LMDB that is preventing the default graph from being selected.

Has Broader: Create (and run) a SPARQL script that does the appropriate surgery to add the forward-links transform to the transform queue.
Other: SPARQL should also be selecting the default graph with a `GRAPH ?g` construct, but the quad store isn't doing it.

From the entity UI, there is no mechanism for adding a new entity that is not attached to the current entity.

Other: Create a pop-up "jump to entity"/"create new unconnected entity" interface.

The focus is confusing but needed to disambiguate which issue network to attach a new entity to.

Other: Is an explicit focus actually necessary though? After using Sense Atlas fairly heavily for a month, it seems like it it isn't needed and just gets in the way.; Why not just attach a new entity to all the issue networks its neighbour is currently in?; [RESOLVED] For writing to the graph, the IBIS tool requires a "focus" node with which to associate new entries. This is associated with a state object, which is in turn associated with the current user.

The footer loads all the concept schemes/issue networks in the inventory (for labels?) when it probably doesn't need to.

Has Broader: The front-end template is almost certainly doing way more work than it needs to.
Other: Eliminate the need for the template to load (and thus trigger the generation of) every single concept scheme/issue network.; The catalogue resources, as well as the concept schemes and issue networks, can get particularly large.

The front page of senseatlas.net is also super janky.

Other: Create a one-off front page that promotes Sense Atlas and explains to people what they're looking at.; The template for ibis:Network (skos:ConceptScheme) is really shabby.

The front-end template is almost certainly doing way more work than it needs to.

Has Broader: [RESOLVED] Sense Atlas can sometimes be unusably slow.
Has Narrower: The <datalist> elements used to drive the autofills are useless without JavaScript anyway, so could probably be generated more cheaply by JS instead.; The footer loads all the concept schemes/issue networks in the inventory (for labels?) when it probably doesn't need to.

G

A graph layout ontology in RDF would enable shipping an SVG to the client with the layout data (along with the graph data itself) embedded in RDFa.

Other: Design a Graph Layout Ontology.

Get rid of the concept of "focus"; just make it so any new entity is added to all participating concept schemes/issue networks at once.

Other: Is an explicit focus actually necessary though? After using Sense Atlas fairly heavily for a month, it seems like it it isn't needed and just gets in the way.; Why not just attach a new entity to all the issue networks its neighbour is currently in?

Getting rid of the clunky client-side dispatcher would also get rid of that giant RDF/XML file containing all the vocabs, which isn't used for anything else.

Other: Dispatching templates on the server side would afford getting rid of that clunky and ridiculous client-side dispatcher.; Use the import precedence native to XSLT.

Google has, in fact, committed to eliminating support for XSLT.

Other: Create a server-side XSLT transform.; There is likewise the persistent threat that one of the browser vendors (say Chrome) removes support for XSLT 1.0.
See Also

Granular modification times would be a byproduct of a full transaction history.

Other

H

How do we account for the dynamic elements on the page from the graph?

Other: Create a "forward links" transform to attach residual links to opaque (e.g. static) documents, analogous to the backlinks transform.; Create a one-off front page that promotes Sense Atlas and explains to people what they're looking at.

How do we match templates to resources?

Other: Modify the transform that inserts XSLT processing instructions to match against asserted types (or specific resources).; Use the import precedence native to XSLT.

How do we select the type of network to be created?

Other: Make some UI that affords creating a new IBIS network (or SKOS concept scheme) from an entity or network overview.; Use a dropdown to select between IBIS network and SKOS concept scheme like in the initialization phase.; Use radio buttons to select between IBIS network and SKOS concept scheme.

How do we yoke or group these entities together?

Other: Create a template for sioct:AddressBook in lieu of a more appropriate collection type.; Represent networks of people and their organizational and/or institutional affiliations, as well as their products.

How do you get the users into the system?

Other: Create ibis:endorsed-by relations widget, i.e. the ability to "like" an entity.; There will need to be some kind of representation of foaf:Person (who can be attached to an authentication principal).

The hierarchical nature of the Sugiyama plot may not be appropriate for representing social networks.

Other: Represent networks of people and their organizational and/or institutional affiliations, as well as their products.; Use the force-directed graph for social networks.

I

If an entity is not immediately connected to the current one, you have to hunt through the visualization or go back to the scheme view to find it.

Other: It would be useful, from the keyboard, to be able to jump to an entity you know is in the graph but not immediately connected.

If every RDF class (and individual resource) that mattered could be assigned its own XSLT transform, then we could have sane defaults for unspecified classes.

Other: Modify the transform that inserts XSLT processing instructions to match against asserted types (or specific resources).

If one of the browser vendors removed support for XSLT 1.0, we could move XSLT processing to the server side.

Other: Part of the reason for client-side template processing is to shift the cost of computing templates to the user, who (usually) has ample such resources to spare.; There is likewise the persistent threat that one of the browser vendors (say Chrome) removes support for XSLT 1.0.

If we navigate to the overview of a network which is not in focus, how do we take focus?

Other: Should the focus button also navigate to the network overview?

Implement a JSON-LD variant for the catalogue index as well.

Has Broader: Implement provisional JSON-LD variants for large resources (notably the catalogues) accessed through client-side scripting.
Other: rdflib.js breaks attempting to parse the transclusion links in the RDFa variant of the catalogue index when fetching.

Implement internal caching.

Other: Even once caching is implemented, a full server round-trip for the whole page with every POST is costly and often unnecessary.; Even ordinary page GETs when the graph state has not changed can be slow, particularly the first time a user loads a generated resource.; The two most robust solutions for speeding up Sense Atlas (plus the visualization layout) are also each fairly significant subprojects.; We were relying on browser cache to keep XSLT from being intolerably slow.

Implement provisional JSON-LD variants for large resources (notably the catalogues) accessed through client-side scripting.

Has Broader: Move the generation of <datalist> elements, which only get used by JavaScript anyway, from the template to JS, so it can take advantage of the JSON-LD variants.
Has Narrower: Implement a JSON-LD variant for the catalogue index as well.
Other: JSON-LD is invariably much cheaper to generate than e.g. (X)HTML+RDFa.; The catalogue resources, as well as the concept schemes and issue networks, can get particularly large.; `RDF::Vocabulary.find` is a major culprit. It is used in `Intertwingler::Resolver#coerce_resource` and does a sequential scan over hundreds of vocabs every time a lookup is done.

Implement the edge-uncrossing portion of the layout algorithm in a faster language (Rust?) that can be compiled to WASM.

Other: The edge-uncrossing algorithm in d3-dag (and Sugiyama in general) is known to run superlinearly (how bad?) to the edges it has to uncross.
See Also

Implement the network switcher as a an autofilling text box.

Has Broader

Implement the network switcher as a dropdown.

Has Broader: Make some UI that affords switching IBIS networks.
Other: Dropdowns are easy to implement.; Dropdowns can get huge and unwieldy.

Importing nodes from one network to another is a pain in the ass.

Other: It will often be quicker to bulk-import a bunch of nodes and then prune out any extraneous ones.; Make it possible to import all of a node's neighbours as well.

Improve the UI for ibis:Network and skos:ConceptScheme.

Has Broader: Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.
Other: The template for ibis:Network (skos:ConceptScheme) is really shabby.

Incidentally the crappy <textarea> elements are a total hangover from the original prototype when a JS-free fallback was still considered feasible.

Other: Replace the <textarea> elements with editable paragraphs for a quick (?) win.; Write front-end code that hijacks form submissions and supplants them with AJAX (again, or whatever it's called).

Is an explicit focus actually necessary though? After using Sense Atlas fairly heavily for a month, it seems like it it isn't needed and just gets in the way.

Other: Get rid of the concept of "focus"; just make it so any new entity is added to all participating concept schemes/issue networks at once.; The focus is confusing but needed to disambiguate which issue network to attach a new entity to.

Is the focus a property of the graph, or a property of the user state?

Other: Do we always want to focus the new network?

It is 100% the RDFa processor adding like ten seconds to the render time of some of those big pages.

Other: An eyeball estimate actually suggests the link and backlink transforms (which each scan the document for RDFa) account for the majority of the time it takes to serve the `all-classes` resource.

It is currently difficult to answer the question, when looking at an issue network, "what still needs to be done?"

Other: It would be handy if active entities could be easily visually differentiated from inactive ones.

It is easy for certain classes of resources (e.g. foaf:Person) to accumulate a large number of backlinks (e.g. dct:creator).

Has Broader: Markup transforms that have to parse a lot of input and/or generate a lot of output (e.g. backlinks) will necessarily be slower.
Other: Design a mechanism for offloading and/or paginating backlinks.

It is wasteful to extract the graph data out of the RDFa in the document, throw it away, and then extract it again, as it moves through the transformation pipeline.

Other: Create a "forward links" transform to attach residual links to opaque (e.g. static) documents, analogous to the backlinks transform.; Update the faux-monad Intertwingler::Representation::Nokogiri to reference a subclass of Nokogiri that has an accessor for the RDF.

It turns out that (at least in Firefox) the `datetime-local` input does not let you set a valid ISO8601/W3CDTF time stamp, only a truncated one.

Other: Create a keyboard event handler that submits the form for all forms that only contain a datetime-local widget (as a non-hidden control).
See Also

It turns out the Store already has some kind of prefix map but it apparently only contains strings as values, not Namespace factories.

Other

It will often be quicker to bulk-import a bunch of nodes and then prune out any extraneous ones.

Other: Importing nodes from one network to another is a pain in the ass.; Make it possible to import all of a node's neighbours as well.

It would be handy if active entities could be easily visually differentiated from inactive ones.

Other: It is currently difficult to answer the question, when looking at an issue network, "what still needs to be done?"; Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.; Use the saturation to differentiate active from inactive entities.

It would be nice to have inline descriptions on IBIS entities for additional text.

Other: Change the main label on IBIS entities from rdf:value to skos:prefLabel and use e.g. skos:definition or dct:description or rdfs:comment for the longer text.

It would be useful if people coming from outside Sense Atlas had a heads-up as to what they were clicking on.

Other: Consider putting the entity's class in the initial path segment, e.g. /issue/.; Use link preview conventions (SDO, OGP) to render robust link previews in various surfaces (Slack, Discord, Teams, chat apps, &c).

It would be useful, from the keyboard, to be able to jump to an entity you know is in the graph but not immediately connected.

Has Narrower: Create a pop-up "jump to entity"/"create new unconnected entity" interface.
Other: If an entity is not immediately connected to the current one, you have to hunt through the visualization or go back to the scheme view to find it.

It would be valuable for people to be able to see the status of an IBIS/PM entity from a link preview.

Other: Use link preview conventions (SDO, OGP) to render robust link previews in various surfaces (Slack, Discord, Teams, chat apps, &c).

It would be valuable to see the topological neighbourhood of a particular IBIS entity (i.e., is it central or is it in the weeds?)

Other: Create a handler that generates an appropriate link preview graphic for IBIS entities.; Use link preview conventions (SDO, OGP) to render robust link previews in various surfaces (Slack, Discord, Teams, chat apps, &c).

It wouldn't hurt to slice off some of the URL path real estate for certain designated classes (and put the respective catalogues at those addresses).

Other: Consider putting the entity's class in the initial path segment, e.g. /issue/.

It's okay to reconcile with SDO terms but don't use them for authoritative representations of data.

Other: Schema.org has been deliberately designed to be incompatible with RDF Schema and OWL.

It's possible that more than one individual property can accumulate enough backlinks to cross the pagination barrier, confounding a global window parameter.

Other: Design a mechanism for offloading and/or paginating backlinks.; Make an addressable transform of the form `;backlinks=property,window-start,window-end` —one for each property (that runs long).

The issue/position/argument type toggle widget is a vestige from the original 2013 prototype and never actually made any sense.

Other: Replace the type toggle widget with an upgrade/downgrade widget in either type vertical.; Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.

J

JSON-LD is invariably much cheaper to generate than e.g. (X)HTML+RDFa.

Other: Implement provisional JSON-LD variants for large resources (notably the catalogues) accessed through client-side scripting.

K

Keep the focus button and disable it, and change the text to say "Focused".

Other: Do we show the UI to focus the network if it's already focused?

M

Make a field in the UI for (re)setting the network's name.

Has Broader: Make a unified UI for switching and/or creating new IBIS networks, SKOS concept schemes.
Other: What about the ability to rename a network?

Make a toggle for whether the node should be included.

Other: There appears to be a general issue of getting nodes into networks.; What about the IBIS entity in context? Does it get ported to the other network?

Make a unified UI for switching and/or creating new IBIS networks, SKOS concept schemes.

Has Narrower: Make a field in the UI for (re)setting the network's name.; Make some UI that affords creating a new IBIS network (or SKOS concept scheme) from an entity or network overview.; Make some UI that affords switching IBIS networks.
Other: [RESOLVED] Client wants the ability to create multiple IBIS networks.

Make an addressable transform of the form `;backlinks=property,window-start,window-end` —one for each property (that runs long).

Has Broader: Design a mechanism for offloading and/or paginating backlinks.
Other: It's possible that more than one individual property can accumulate enough backlinks to cross the pagination barrier, confounding a global window parameter.; There is no reason why an addressable transform can't completely replace a response body, rather than just manipulate it.

Make it possible to import all of a node's neighbours as well.

Other: Importing nodes from one network to another is a pain in the ass.; It will often be quicker to bulk-import a bunch of nodes and then prune out any extraneous ones.

Make it possible to query the RDF store for the modification times of specific resources and/or statements.

Other: Granular modification times would be a byproduct of a full transaction history.; Sense Atlas is particularly slow after POSTs because the RDF store only has a single global modification time (that I had to hack in).; The two most robust solutions for speeding up Sense Atlas (plus the visualization layout) are also each fairly significant subprojects.

Make some UI that affords creating a new IBIS network (or SKOS concept scheme) from an entity or network overview.

Has Broader: Make a unified UI for switching and/or creating new IBIS networks, SKOS concept schemes.
Other: Do we always want to focus the new network?; How do we select the type of network to be created?; What about the IBIS entity in context? Does it get ported to the other network?; What about the ability to rename a network?

Make some UI that affords switching IBIS networks.

Has Broader: Make a unified UI for switching and/or creating new IBIS networks, SKOS concept schemes.
Has Narrower: Implement the network switcher as a an autofilling text box.; Implement the network switcher as a dropdown.; Make sure the UI has a "Set Focus" button.
Other: Do we always want to focus the new network?; What about the IBIS entity in context? Does it get ported to the other network?

Make sure the UI has a "Set Focus" button.

Has Broader: Make some UI that affords switching IBIS networks.; [ADOPTED] Only focus the new network if the user explicitly signals to do so (i.e., through a dedicated button).

Manipulating the properties of the entity itself would be easy enough, but altering the connections entails updating both the layout and the graph.

Other: Augment the operations over connections between entities (except for adding a brand new entity) and the subsequent update to the graph visualization to avoid a full server round trip.; Augment the remaining form controls that are neither the textareas nor the connections to update without a full round trip.; Replace the <textarea> elements with editable paragraphs for a quick (?) win.; Write front-end code that hijacks form submissions and supplants them with AJAX (again, or whatever it's called).

Markup transforms that have to parse a lot of input and/or generate a lot of output (e.g. backlinks) will necessarily be slower.

Has Narrower: It is easy for certain classes of resources (e.g. foaf:Person) to accumulate a large number of backlinks (e.g. dct:creator).
Other: An eyeball estimate actually suggests the link and backlink transforms (which each scan the document for RDFa) account for the majority of the time it takes to serve the `all-classes` resource.; Consider implementing markup transforms on top of SAX rather than DOM where possible.; The time it takes to generate a markup representation of a resource is proportional to the number of statements.

Maybe the user just wants to look at the other network (or create one and not switch to it).

Other: Always focus the network when you select it or create a new one.

Modify the content inventory vocab to include a new class and properties to represent a template.

Has Broader: Modify the transform that inserts XSLT processing instructions to match against asserted types (or specific resources).

Modify the transform that inserts XSLT processing instructions to match against asserted types (or specific resources).

Has Broader: Use the import precedence native to XSLT.
Has Narrower: Modify the content inventory vocab to include a new class and properties to represent a template.
Other: Dispatching templates on the server side would afford getting rid of that clunky and ridiculous client-side dispatcher.; How do we match templates to resources?; If every RDF class (and individual resource) that mattered could be assigned its own XSLT transform, then we could have sane defaults for unspecified classes.

Most (if not all?) of the changes that cause full-page round trips could be supplanted by AJAX (or whatever it's called these days).

Has Broader: [RESOLVED] Sense Atlas can sometimes be unusably slow.
Has Narrower: Even once caching is implemented, a full server round-trip for the whole page with every POST is costly and often unnecessary.
Other: About the only time Sense Atlas needs a full page refresh (and even then is debatable) is when a new entity is added through a semantic relation.; Write front-end code that hijacks form submissions and supplants them with AJAX (again, or whatever it's called).

Move the generation of <datalist> elements, which only get used by JavaScript anyway, from the template to JS, so it can take advantage of the JSON-LD variants.

Has Broader: Take immediate provisional measures to speed up Sense Atlas (provided they are non-destructive).
Has Narrower: Implement provisional JSON-LD variants for large resources (notably the catalogues) accessed through client-side scripting.
Other: The <datalist> elements used to drive the autofills are useless without JavaScript anyway, so could probably be generated more cheaply by JS instead.; rdflib.js breaks attempting to parse the transclusion links in the RDFa variant of the catalogue index when fetching.

The math on the hyperbolic sugiyama visualization is wrong; nodes farther down rank are miles apart from each other (both r and θ).

Other: Devise a radial clumping algorithm for determining the θ of each node.

N

Narrowing the search of existing node by type makes it harder to search for existing nodes to connect.

Other: Could we establish that an argument is an argument purely by inference?; Upgrade the node type on a connection to an existing node if the user selects a more specific subclass.

No, remove the set focus button if the network in question is already focused.

Other: Do we show the UI to focus the network if it's already focused?

No, stay where you are. Use a dedicated "Go" button to navigate.

Other: Should the focus button also navigate to the network overview?

Note that an entity can be an ibis:Argument and an pm:Goal/Task at the same time.

Other: Replace the type toggle widget with an upgrade/downgrade widget in either type vertical.; There is no upgrade/downgrade path to go from { issue ↔ argument ↔ goal ↔ target } or { position ↔ task }.

O

Only show the nodes in an unfocused network that are immediately adjacent to the ones in the focused network (and do so at half opacity), like is already done with skos:Concept.

Other: When a node is in more than one issue network, the visualization shows the amalgamation of all the networks.

Override form POST actions with scripting.

Has Narrower: Write front-end code that hijacks form submissions and supplants them with AJAX (again, or whatever it's called).
Other: Even once caching is implemented, a full server round-trip for the whole page with every POST is costly and often unnecessary.

The only person-to-person relation is foaf:knows and it was deliberately made not symmetric.

Other: Create a template for foaf:Person.; Treat foaf:knows informally as symmetric anyway.; Use schema.org.; Use the relationship ontology for additional person-to-person relations.

P

Part of the reason for client-side template processing is to shift the cost of computing templates to the user, who (usually) has ample such resources to spare.

Other: If one of the browser vendors removed support for XSLT 1.0, we could move XSLT processing to the server side.; Try messing around with SaxonJS?

Perhaps the ridiculous distances (r) between nodes will resolve itself if the ridiculous radial distance (θ) is fixed.

Other: Devise a radial clumping algorithm for determining the θ of each node.

Plan projects and resources with the use of the Process Model Ontology.

Has Broader: Client wants to use the IBIS tool (Sense Atlas) in everyday operations.
Other: Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.; Unlike IBIS which is half a century old, the PM ontology has never been road-tested, and will likely require several iterations to get right.
See Also

Police d3-dag for any obvious implementation flaws that can be optimized out.

Other

Precomputing the graph visualization layout will need some kind of intermediate representation.

Other

Preemptively compute the Sugiyama layout on the server side (asynchronously, of course) when the subgraph in question is changed, which can be cached and shipped out whole over the wire.

Other: Computing the layout on the server side will afford the generation of SVG (and raster derivatives) for clients (e.g. bots) that don't do client-side scripting.; Precomputing the graph visualization layout will need some kind of intermediate representation.; The (coarse-grained) layout for the Sugiyama visualization only has to be computed when the state of the graph (actually, subgraph) changes.; There will need to be some kind of event handler somewhere that watches for changes to the subgraph in question and triggers the update.

Put a link in the footer back to the "top".

Other: [RESOLVED] It is currently not possible to navigate to the "top" cgto:Space from either an entity or a network.

Put the RDF accessors in a Store subclass.

Other: A bunch of useful RDF accessors have accumulated in the generic graph tool script.; The Store is a superclass that other subclasses inherit from, and there is no multiple inheritance.; The accessors are useful and would be useful with graphs other than those embedded within an RDFViz instance.

Put the RDF accessors in the RDFViz class.

Has Broader: Refactor the JS such the generic parts are separated from the Sugiyama (and/or ontology-)specific code.
Other: A bunch of useful RDF accessors have accumulated in the generic graph tool script.; Putting the custom accessors into RDFViz is simpler than trying to stitch them into the graph class.; The accessors are useful and would be useful with graphs other than those embedded within an RDFViz instance.

Put the type icons in the adjacent node elements.

Other: Adjacent nodes in the left-side lozenge UI can be kind of ambiguous.

Putting the custom accessors into RDFViz is simpler than trying to stitch them into the graph class.

Other: Put the RDF accessors in the RDFViz class.

R

Radio buttons are just as easy to implement (over a small, fixed set of elements) as dropdowns.

Other: Dropdowns are easy to implement.; Use radio buttons to select between IBIS network and SKOS concept scheme.

rdflib.js breaks attempting to parse the transclusion links in the RDFa variant of the catalogue index when fetching.

Other: Implement a JSON-LD variant for the catalogue index as well.; Move the generation of <datalist> elements, which only get used by JavaScript anyway, from the template to JS, so it can take advantage of the JSON-LD variants.
See Also

Refactor the JS such the generic parts are separated from the Sugiyama (and/or ontology-)specific code.

Has Narrower

Replace the <textarea> elements with editable paragraphs for a quick (?) win.

Has Broader: Write front-end code that hijacks form submissions and supplants them with AJAX (again, or whatever it's called).
Other: Editable blocks would also afford elementary markup (bold, italic, monospace, inline links, &c).; Incidentally the crappy <textarea> elements are a total hangover from the original prototype when a JS-free fallback was still considered feasible.; Manipulating the properties of the entity itself would be easy enough, but altering the connections entails updating both the layout and the graph.

Replace the type toggle widget with an upgrade/downgrade widget in either type vertical.

Has Broader: Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.
Other: Note that an entity can be an ibis:Argument and an pm:Goal/Task at the same time.; The issue/position/argument type toggle widget is a vestige from the original 2013 prototype and never actually made any sense.; There is no upgrade/downgrade path to go from { issue ↔ argument ↔ goal ↔ target } or { position ↔ task }.

Represent networks of people and their organizational and/or institutional affiliations, as well as their products.

Other: Create a template for foaf:Person.; Create a template for gr:ProductOrService.; Create a template for org:Organization.; How do we yoke or group these entities together?; Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.; The hierarchical nature of the Sugiyama plot may not be appropriate for representing social networks.

Rescanning the document (which we assume to be altered from the previous transform) may be the only reliable way to ensure that it matches the content.

Other: Update the faux-monad Intertwingler::Representation::Nokogiri to reference a subclass of Nokogiri that has an accessor for the RDF.

Rough out the new classes and try loading them with instance data; take notes for what can be improved.

Has Narrower: Create a template for pm:Target.; Create a template for pm:Task.; [DONE] Create a template for pm:Goal.; [DONE] Put Sense Atlas online so the client can observe its development.
Other: Do we want to be able to ascribe a value to the goal specifically, rather than the target—which has a budget?; Unlike IBIS which is half a century old, the PM ontology has never been road-tested, and will likely require several iterations to get right.

The reason why this may not have been done already is that RDF.Namespace is a closure, which means you can't see the namespace URI inside it.

Other: Create a Namespace class as a subclass of NamedNode (also wrapped by a Proxy) that is transparent and has the old interface plus an accessor-based one.; Write an NSMap class that cosplays as an Object (via Proxy) that also encapsulates the term abbreviation/expansion code and just smuggle it in there along with the rest of the mix-in.

The relationship ontology has 32 person-to-person properties, and that's not even exhaustive. Way more than we can colour.

Other: Cluster the relationship properties into macro-groups and just assign one colour each: personal, professional, academic, antagonistic, incidental/ephemeral. Something like that.; Use the relationship ontology for additional person-to-person relations.

The relationship ontology has a lot of weirdnesses around property inheritance and a few properties that would be useful that are missing.

Other: Contact the authors of the relationship ontology and see if they'll accept a patch.; Use the relationship ontology for additional person-to-person relations.

The round trips won't matter as much if they take a lot less time.

Other: Write front-end code that hijacks form submissions and supplants them with AJAX (again, or whatever it's called).

[RESOLVED(ish)] The display is still goofed on a mobile screen.

Other: Solve for mobile.

[RESOLVED] Client wants the ability to create multiple IBIS networks.

Has Broader: Client wants to use the IBIS tool (Sense Atlas) in everyday operations.
Has Narrower: What about the ability to rename a network?
Other: Make a unified UI for switching and/or creating new IBIS networks, SKOS concept schemes.; [RESOLVED] For writing to the graph, the IBIS tool requires a "focus" node with which to associate new entries. This is associated with a state object, which is in turn associated with the current user.

[RESOLVED] For writing to the graph, the IBIS tool requires a "focus" node with which to associate new entries. This is associated with a state object, which is in turn associated with the current user.

Other: Do we always want to focus the new network?; Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.; The focus is confusing but needed to disambiguate which issue network to attach a new entity to.; [RESOLVED] Client wants the ability to create multiple IBIS networks.
See Also

[RESOLVED] It is currently not possible to navigate to the "top" cgto:Space from either an entity or a network.

Other

[RESOLVED] Logging in and out of Sense Atlas currently happens out of band.

Other: Add a log in/out widget to the footer (email and "go" button to log in, logout button to log out).

[RESOLVED] Sense Atlas can sometimes be unusably slow.

Has Narrower: Even ordinary page GETs when the graph state has not changed can be slow, particularly the first time a user loads a generated resource.; Most (if not all?) of the changes that cause full-page round trips could be supplanted by AJAX (or whatever it's called these days).; Sense Atlas is particularly slow after POSTs because the RDF store only has a single global modification time (that I had to hack in).; The edge-uncrossing algorithm in d3-dag (and Sugiyama in general) is known to run superlinearly (how bad?) to the edges it has to uncross.; The front-end template is almost certainly doing way more work than it needs to.
Other: The effort it takes to map out a set of related issues should be roughly equivalent to composing a thread on Twitter (or descendant), where each entity is analogous to a tweet.; The two most robust solutions for speeding up Sense Atlas (plus the visualization layout) are also each fairly significant subprojects.

[RESOLVED] The editing widgets show up even if there is no current logged-in user.

Other: Alter the template so that the editing widgets do not show up unless there is a registered user detected.; Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.

[RESOLVED] The unlink button appears to be broken (again?) for ibis:suggested-by.

Other: Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.

`RDF::Vocabulary.find` is a major culprit. It is used in `Intertwingler::Resolver#coerce_resource` and does a sequential scan over hundreds of vocabs every time a lookup is done.

Other: Implement provisional JSON-LD variants for large resources (notably the catalogues) accessed through client-side scripting.

S

Schema.org has been deliberately designed to be incompatible with RDF Schema and OWL.

Other: It's okay to reconcile with SDO terms but don't use them for authoritative representations of data.; Use schema.org.

Sense Atlas is particularly slow after POSTs because the RDF store only has a single global modification time (that I had to hack in).

Has Broader: [RESOLVED] Sense Atlas can sometimes be unusably slow.
Other: Even ordinary page GETs when the graph state has not changed can be slow, particularly the first time a user loads a generated resource.; Make it possible to query the RDF store for the modification times of specific resources and/or statements.

Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.

Has Broader: Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.
Has Narrower: Alter the template so that the editing widgets do not show up unless there is a registered user detected.; Create a template for pm:Target.; Create a template for pm:Task.; Create ibis:endorsed-by relations widget, i.e. the ability to "like" an entity.; Improve the UI for ibis:Network and skos:ConceptScheme.; Replace the type toggle widget with an upgrade/downgrade widget in either type vertical.; Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.; [DONE] Create a template for pm:Goal.
Other: Adjacent nodes in the left-side lozenge UI can be kind of ambiguous.; Client wants to use the IBIS tool (Sense Atlas) in everyday operations.; It would be handy if active entities could be easily visually differentiated from inactive ones.; Plan projects and resources with the use of the Process Model Ontology.; Represent networks of people and their organizational and/or institutional affiliations, as well as their products.; The UI for adding and connecting adjacents messes up in annoying and data-destructive ways.; The XSLT component kind of sucks.; The issue/position/argument type toggle widget is a vestige from the original 2013 prototype and never actually made any sense.; The template for ibis:Network (skos:ConceptScheme) is really shabby.; There is no upgrade/downgrade path to go from { issue ↔ argument ↔ goal ↔ target } or { position ↔ task }.; There is still no capability to use ibis:replaces effectively.; [RESOLVED] For writing to the graph, the IBIS tool requires a "focus" node with which to associate new entries. This is associated with a state object, which is in turn associated with the current user.; [RESOLVED] The editing widgets show up even if there is no current logged-in user.; [RESOLVED] The unlink button appears to be broken (again?) for ibis:suggested-by.

Should the focus button also navigate to the network overview?

Other: If we navigate to the overview of a network which is not in focus, how do we take focus?; No, stay where you are. Use a dedicated "Go" button to navigate.; Yes, always show the focus button and make clicking on it a no-op.; Yes, focusing the network should also go to it.

Solve for mobile.

Other: [RESOLVED(ish)] The display is still goofed on a mobile screen.

SPARQL should also be selecting the default graph with a `GRAPH ?g` construct, but the quad store isn't doing it.

Other: Create (and run) a SPARQL script that does the appropriate surgery to add the forward-links transform to the transform queue.; Fix the bug in RDF::LMDB that is preventing the default graph from being selected.

Store layout data computed on the client side in local storage across requests; invalidate and recompute it if the server responds with new data.

Other: Precomputing the graph visualization layout will need some kind of intermediate representation.; The (coarse-grained) layout for the Sugiyama visualization only has to be computed when the state of the graph (actually, subgraph) changes.

Survey other templating languages.

Other: Almost all Web templating languages allow for broken markup (a major reason we're still using XSLT is because it doesn't).; The XSLT component kind of sucks.

Switching the focus without being conspicuous about it could cause the user to make a mistake.

Other: Always focus the network when you select it or create a new one.

The Store is a superclass that other subclasses inherit from, and there is no multiple inheritance.

Other: Add the graph accessor methods as a mix-in onto Store.; Put the RDF accessors in a Store subclass.

The Sugiyama code also has a bunch of stuff for prefix/namespace mapping, abbreviating/expanding CURIEs, etc.

Other: A bunch of useful RDF accessors have accumulated in the generic graph tool script.; Add the namespace code to Store mix-in as well.

T

Take immediate provisional measures to speed up Sense Atlas (provided they are non-destructive).

Has Narrower: Eliminate the need for the template to load (and thus trigger the generation of) every single concept scheme/issue network.; Move the generation of <datalist> elements, which only get used by JavaScript anyway, from the template to JS, so it can take advantage of the JSON-LD variants.; Write front-end code that hijacks form submissions and supplants them with AJAX (again, or whatever it's called).
Other: The two most robust solutions for speeding up Sense Atlas (plus the visualization layout) are also each fairly significant subprojects.

The template for ibis:Network (skos:ConceptScheme) is really shabby.

Other: Improve the UI for ibis:Network and skos:ConceptScheme.; Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.; The front page of senseatlas.net is also super janky.

The time it takes to generate a markup representation of a resource is proportional to the number of statements.

Other: Even ordinary page GETs when the graph state has not changed can be slow, particularly the first time a user loads a generated resource.; Markup transforms that have to parse a lot of input and/or generate a lot of output (e.g. backlinks) will necessarily be slower.; The catalogue resources, as well as the concept schemes and issue networks, can get particularly large.

The two most robust solutions for speeding up Sense Atlas (plus the visualization layout) are also each fairly significant subprojects.

Other: Implement internal caching.; Make it possible to query the RDF store for the modification times of specific resources and/or statements.; Take immediate provisional measures to speed up Sense Atlas (provided they are non-destructive).; [RESOLVED] Sense Atlas can sometimes be unusably slow.

There appears to be a general issue of getting nodes into networks.

Other: Make a toggle for whether the node should be included.; What about getting nodes out of networks? How do you remove an IBIS entity (SKOS concept) from a network (concept scheme)?

There are only two choices: IBIS network and SKOS concept scheme.

Other: Use radio buttons to select between IBIS network and SKOS concept scheme.

There is a bigger target to click with radio buttons.

Other: Dropdowns hide the available options behind a click.; Use radio buttons to select between IBIS network and SKOS concept scheme.

There is a bunch of JavaScript mixed in with the Sugiyama tuning for the graph tool.

Other: Refactor the JS such the generic parts are separated from the Sugiyama (and/or ontology-)specific code.; Use the force-directed graph for social networks.

There is likewise the persistent threat that one of the browser vendors (say Chrome) removes support for XSLT 1.0.

Other: Despite being standard, reliable, and fast to execute, and built into every browser, XSLT 1.0 in particular is really clunky to work with.; Google has, in fact, committed to eliminating support for XSLT.; If one of the browser vendors removed support for XSLT 1.0, we could move XSLT processing to the server side.

There is no reason why an addressable transform can't completely replace a response body, rather than just manipulate it.

Other: Make an addressable transform of the form `;backlinks=property,window-start,window-end` —one for each property (that runs long).

There is no upgrade/downgrade path to go from { issue ↔ argument ↔ goal ↔ target } or { position ↔ task }.

Other: Could we establish that an argument is an argument purely by inference?; Note that an entity can be an ibis:Argument and an pm:Goal/Task at the same time.; Replace the type toggle widget with an upgrade/downgrade widget in either type vertical.; Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.

There is still no capability to use ibis:replaces effectively.

Other: Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.

There turns out to be a bug somewhere in the caching mechanism that causes templates to break when they return 304 Not Modified.

Other: Add appropriate Cache-Control headers and enable caching on the reverse proxy wrapping Sense Atlas.

There will be an ambiguity with the intent of typing in a value not found in the autofill: are you renaming the current network or making a new one?

Other: Implement the network switcher as a an autofilling text box.

There will need to be some kind of event handler somewhere that watches for changes to the subgraph in question and triggers the update.

Other: Preemptively compute the Sugiyama layout on the server side (asynchronously, of course) when the subgraph in question is changed, which can be cached and shipped out whole over the wire.

There will need to be some kind of representation of foaf:Person (who can be attached to an authentication principal).

Other: How do you get the users into the system?

Treat foaf:knows informally as symmetric anyway.

Has Broader: Create a template for foaf:Person.
Other: The only person-to-person relation is foaf:knows and it was deliberately made not symmetric.

Try messing around with SaxonJS?

Other: Despite being standard, reliable, and fast to execute, and built into every browser, XSLT 1.0 in particular is really clunky to work with.; Part of the reason for client-side template processing is to shift the cost of computing templates to the user, who (usually) has ample such resources to spare.
See Also

U

The UI for adding and connecting adjacents messes up in annoying and data-destructive ways.

Other

The user's intent is always clear.

Other: [ADOPTED] Only focus the new network if the user explicitly signals to do so (i.e., through a dedicated button).

Unlike IBIS which is half a century old, the PM ontology has never been road-tested, and will likely require several iterations to get right.

Other: Plan projects and resources with the use of the Process Model Ontology.; Rough out the new classes and try loading them with instance data; take notes for what can be improved.; [DONE] Put Sense Atlas online so the client can observe its development.

Update the faux-monad Intertwingler::Representation::Nokogiri to reference a subclass of Nokogiri that has an accessor for the RDF.

Other: It is wasteful to extract the graph data out of the RDFa in the document, throw it away, and then extract it again, as it moves through the transformation pipeline.; Rescanning the document (which we assume to be altered from the previous transform) may be the only reliable way to ensure that it matches the content.

Upgrade the node type on a connection to an existing node if the user selects a more specific subclass.

Other: Narrowing the search of existing node by type makes it harder to search for existing nodes to connect.

Use a dropdown to select between IBIS network and SKOS concept scheme like in the initialization phase.

Other: Dropdowns are easy to implement.; Dropdowns hide the available options behind a click.; How do we select the type of network to be created?

Use link preview conventions (SDO, OGP) to render robust link previews in various surfaces (Slack, Discord, Teams, chat apps, &c).

Has Narrower: Create a handler that generates an appropriate link preview graphic for IBIS entities.
Other: It would be useful if people coming from outside Sense Atlas had a heads-up as to what they were clicking on.; It would be valuable for people to be able to see the status of an IBIS/PM entity from a link preview.; It would be valuable to see the topological neighbourhood of a particular IBIS entity (i.e., is it central or is it in the weeds?); We have all the relevant data already, but we don't keep it in OGP/SDO.
See Also

Use radio buttons to select between IBIS network and SKOS concept scheme.

Other

Use schema.org.

Other: Schema.org has been deliberately designed to be incompatible with RDF Schema and OWL.; The only person-to-person relation is foaf:knows and it was deliberately made not symmetric.

Use the force-directed graph for social networks.

Other: The hierarchical nature of the Sugiyama plot may not be appropriate for representing social networks.; There is a bunch of JavaScript mixed in with the Sugiyama tuning for the graph tool.

Use the import precedence native to XSLT.

Has Narrower: Modify the transform that inserts XSLT processing instructions to match against asserted types (or specific resources).
Other: Dispatching templates on the server side would afford getting rid of that clunky and ridiculous client-side dispatcher.; Getting rid of the clunky client-side dispatcher would also get rid of that giant RDF/XML file containing all the vocabs, which isn't used for anything else.; How do we match templates to resources?; The way the template "inheritance" currently works is extremely messy.

Use the relationship ontology for additional person-to-person relations.

Other: The only person-to-person relation is foaf:knows and it was deliberately made not symmetric.; The relationship ontology has 32 person-to-person properties, and that's not even exhaustive. Way more than we can colour.; The relationship ontology has a lot of weirdnesses around property inheritance and a few properties that would be useful that are missing.
See Also

Use the saturation to differentiate active from inactive entities.

Other

W

The way the template "inheritance" currently works is extremely messy.

Other: The XSLT component kind of sucks.; Use the import precedence native to XSLT.

We have all the relevant data already, but we don't keep it in OGP/SDO.

Other: Use link preview conventions (SDO, OGP) to render robust link previews in various surfaces (Slack, Discord, Teams, chat apps, &c).

We haven't determined how we're going to handle rdf:XMLLiteral yet.

Other: Editable blocks would also afford elementary markup (bold, italic, monospace, inline links, &c).

We were relying on browser cache to keep XSLT from being intolerably slow.

Other: Create a server-side XSLT transform.; Implement internal caching.

What about getting nodes out of networks? How do you remove an IBIS entity (SKOS concept) from a network (concept scheme)?

Other: There appears to be a general issue of getting nodes into networks.

What about the ability to rename a network?

Has Broader: [RESOLVED] Client wants the ability to create multiple IBIS networks.
Other: Make a field in the UI for (re)setting the network's name.; Make some UI that affords creating a new IBIS network (or SKOS concept scheme) from an entity or network overview.

What about the existing instance data that all uses rdf:value?

Other: All of the instance data currently in the wild is easily accessible and can be manipulated with a single SPARQL query.; Change the main label on IBIS entities from rdf:value to skos:prefLabel and use e.g. skos:definition or dct:description or rdfs:comment for the longer text.

What about the IBIS entity in context? Does it get ported to the other network?

Other: Automatically import the node; people can remove it later.; Make a toggle for whether the node should be included.; Make some UI that affords creating a new IBIS network (or SKOS concept scheme) from an entity or network overview.; Make some UI that affords switching IBIS networks.

When a node is in more than one issue network, the visualization shows the amalgamation of all the networks.

Other: Only show the nodes in an unfocused network that are immediately adjacent to the ones in the focused network (and do so at half opacity), like is already done with skos:Concept.

While the graph layout is being computed, consider some kind of progress bar or analogous animation to show the user something is happening.

Other: The edge-uncrossing algorithm in d3-dag (and Sugiyama in general) is known to run superlinearly (how bad?) to the edges it has to uncross.

Why not just attach a new entity to all the issue networks its neighbour is currently in?

Other: Get rid of the concept of "focus"; just make it so any new entity is added to all participating concept schemes/issue networks at once.; The focus is confusing but needed to disambiguate which issue network to attach a new entity to.

Write an NSMap class that cosplays as an Object (via Proxy) that also encapsulates the term abbreviation/expansion code and just smuggle it in there along with the rest of the mix-in.

Has Broader: Add the graph accessor methods as a mix-in onto Store.
Has Narrower: Create a Namespace class as a subclass of NamedNode (also wrapped by a Proxy) that is transparent and has the old interface plus an accessor-based one.
Other: It turns out the Store already has some kind of prefix map but it apparently only contains strings as values, not Namespace factories.; The reason why this may not have been done already is that RDF.Namespace is a closure, which means you can't see the namespace URI inside it.
See Also

Write front-end code that hijacks form submissions and supplants them with AJAX (again, or whatever it's called).

Has Broader

X

The XSLT component kind of sucks.

Other: Despite being standard, reliable, and fast to execute, and built into every browser, XSLT 1.0 in particular is really clunky to work with.; Ship a front end with interfaces for IBIS, PM, and a rudimentary FOAF/ORG editor.; Survey other templating languages.; The way the template "inheritance" currently works is extremely messy.

Y

Yes, always show the focus button and make clicking on it a no-op.

Other: Do we show the UI to focus the network if it's already focused?; Should the focus button also navigate to the network overview?

Yes, focusing the network should also go to it.

Other: Should the focus button also navigate to the network overview?

A

About the only time Sense Atlas needs a full page refresh (and even then is debatable) is when a new entity is added through a semantic relation.

Add a log in/out widget to the footer (email and "go" button to log in, logout button to log out).

Add appropriate Cache-Control headers and enable caching on the reverse proxy wrapping Sense Atlas.

Add the graph accessor methods as a mix-in onto Store.

Add the namespace code to Store mix-in as well.

Adjacent nodes in the left-side lozenge UI can be kind of ambiguous.

All JavaScript particulars should be fully bootstrappable (and bootstrapped) from RDFa (and subsequent JSON-LD) data.

All of the instance data currently in the wild is easily accessible and can be manipulated with a single SPARQL query.

Almost all Web templating languages allow for broken markup (a major reason we're still using XSLT is because it doesn't).

Alter the template so that the editing widgets do not show up unless there is a registered user detected.

Always focus the network when you select it or create a new one.

An autofilled text box has an unlimited capacity and is easier to deal with than a dropdown when there are lots of entities.

An autofilled text box will take up less space.

Augment the operations over connections between entities (except for adding a brand new entity) and the subsequent update to the graph visualization to avoid a full server round trip.

Augment the remaining form controls that are neither the textareas nor the connections to update without a full round trip.

Autofilled text boxes are implemented inconsistently across browsers.

Automatically import the node; people can remove it later.

Automatically importing the entity may make sense for creating new networks but could make a mess with existing ones.

The accessors are useful and would be useful with graphs other than those embedded within an RDFViz instance.

[ADOPTED] Only focus the new network if the user explicitly signals to do so (i.e., through a dedicated button).

B

A bunch of useful RDF accessors have accumulated in the generic graph tool script.

The backlinks transform is actually extremely goofed and contributing to slow page delivery, which will only get worse if it has to parse more forward links too.

C

Change the main label on IBIS entities from rdf:value to skos:prefLabel and use e.g. skos:definition or dct:description or rdfs:comment for the longer text.

Changing the focus isn't really that big a deal and it can always be changed later.

Client wants to use the IBIS tool (Sense Atlas) in everyday operations.

Cluster the relationship properties into macro-groups and just assign one colour each: personal, professional, academic, antagonistic, incidental/ephemeral. Something like that.

Computing the layout on the server side will afford the generation of SVG (and raster derivatives) for clients (e.g. bots) that don't do client-side scripting.

Consider implementing markup transforms on top of SAX rather than DOM where possible.

Consider putting the entity's class in the initial path segment, e.g. /issue/.

Contact the authors of the relationship ontology and see if they'll accept a patch.

Could we establish that an argument is an argument purely by inference?

Create (and run) a SPARQL script that does the appropriate surgery to add the forward-links transform to the transform queue.

Create a "forward links" transform to attach residual links to opaque (e.g. static) documents, analogous to the backlinks transform.

Create a handler that generates an appropriate link preview graphic for IBIS entities.

Create a keyboard event handler that submits the form for all forms that only contain a datetime-local widget (as a non-hidden control).

Create a Namespace class as a subclass of NamedNode (also wrapped by a Proxy) that is transparent and has the old interface plus an accessor-based one.

Create a new <datalist> for autofilling foaf:Agent entities.

Create a one-off front page that promotes Sense Atlas and explains to people what they're looking at.

Create a pop-up "jump to entity"/"create new unconnected entity" interface.

Create a server-side XSLT transform.

Create a template for foaf:Person.

Create a template for gr:ProductOrService.

Create a template for org:Organization.

Create a template for pm:Target.

Create a template for pm:Task.

Create a template for sioct:AddressBook in lieu of a more appropriate collection type.

Create ibis:endorsed-by relations widget, i.e. the ability to "like" an entity.

The (coarse-grained) layout for the Sugiyama visualization only has to be computed when the state of the graph (actually, subgraph) changes.

The catalogue resources, as well as the concept schemes and issue networks, can get particularly large.

D

Debugging XSLT 1.0 in particular is brutal, due to years of neglect from the browser vendors.

Design a Graph Layout Ontology.

Design a mechanism for offloading and/or paginating backlinks.

Despite being standard, reliable, and fast to execute, and built into every browser, XSLT 1.0 in particular is really clunky to work with.

Devise a radial clumping algorithm for determining the θ of each node.

Dispatching templates on the server side would afford getting rid of that clunky and ridiculous client-side dispatcher.

Do we always want to focus the new network?

Do we show the UI to focus the network if it's already focused?

Do we want to be able to ascribe a value to the goal specifically, rather than the target—which has a budget?

Double-check the behaviour of datetime-local in Chrome and Safari.

Dropdowns are easy to implement.

Dropdowns can get huge and unwieldy.

Dropdowns hide the available options behind a click.

The <datalist> elements used to drive the autofills are useless without JavaScript anyway, so could probably be generated more cheaply by JS instead.

The datetime-local input type does not seem to elicit form submission with the enter key like a text box does (in Firefox).

[DONE] Create a template for pm:Goal.

[DONE] Put Sense Atlas online so the client can observe its development.

`Date.prototype.toISOString()` encodes the time zone offset as Zulu (UTC) no matter what it actually is.

E

An eyeball estimate actually suggests the link and backlink transforms (which each scan the document for RDFa) account for the majority of the time it takes to serve the `all-classes` resource.

Editable blocks would also afford elementary markup (bold, italic, monospace, inline links, &c).

Eliminate the need for the template to load (and thus trigger the generation of) every single concept scheme/issue network.

Establish a consistent architecture for organizing front-end JavaScript code that accounts for RDF(a, JSON-LD) and NPM modules.

Even once caching is implemented, a full server round-trip for the whole page with every POST is costly and often unnecessary.

Even ordinary page GETs when the graph state has not changed can be slow, particularly the first time a user loads a generated resource.

Expand the script that manages the adjacent entity controls so that it also attaches to the "agent" controls.

Extra buttons are potentially clutter.