If you select a relation type in "Create new" and switch to "Connect existing" or vice versa, the relations are forgotten. Created 2019-10-12 Connect existing Create new Generalizes Specializes Suggests Suggested by Questions Questioned by Has Response Suggested by Questions Suggests Suggested by Questions Questioned by Issue Position Argument urn:uuid:e5f65f04-73be-4c49-abb7-55a358d94e5c A big impediment to working with { RDF, Linked Data, Semantic Web } is that you have to plan your URL layout before you can begin to write down any data. Circos plots, being circular, create a considerable amount of wasted whitespace around them. Designing and implementing the protocol was painless enough, but what RDF vocabulary should we use to test it? Entering ad-hoc RDF data is tedious enough when it's HTTP(S) URLs, but UUIDs make it an EXTREMELY slow-going task. Great idea. How? How are we going to actually get the RDF data into storage on the server side? In the standard hexagonal HSV colour model, green is twice as bright as red, and six times as bright as blue. It turns out, after some use, that Arguments are really a special kind of Issue. It turns out, after some use, that "Questioned by" is a stronger form of "Suggests". It turns out Circos plots have their own problems, but they're good enough for now! Sometimes we need to be able to disconnect the connections between two subjects that were made by accident. Sometimes we want to enter new subjects, and sometimes we want to connect existing ones. So we can get the data into the app, and we know what data we want to represent, but now we need an interface to navigate through it. SVG+RDFa sounds like a plan. What should the graphic look like? The number of CSS rules explodes in size when you multiply the number of classes and properties by the number of variants and states (background, hover, etc.). Two nearly-identical HTML forms on the page is unacceptable UI. We need the UI to be able to differentiate between classes of subject, as well as the different semantic relations. We need to be able to be able to get a sense of the topological situation of a subject (page in context) beyond its immediate neighbourhood. Write a quick and dirty web application to abridge the process of entering RDF data. Add a "disconnect" button to each of the connections. Create two forms: one to add new elements and one to connect existing ones. Design a simple protocol for representing RDF graph diffs in plain HTML form keys. Embed the semantic content into RDFa. Force-directed is always a popular. Have each page in the web app correspond to a subject in the semantic graph. Monitor changes in selected relation types in JavaScript and communicate them across forms. Normalize (the inverse relations) of the immediate neighbours of the subject being represented so they're all pointing the same way, link to them, and group them in lists by predicate. NOW we bring in JavaScript: toggle the visibility of one form over another with some kind of master switch. Open up the Circos plot, mitigating the wasted space on one side. Render the subgraph in SVG+RDFa. Update the IBIS vocabulary to represent ibis:Argument as a subclass of ibis:Issue. Make the appropriate changes in the app semantics. Update the IBIS vocabulary to represent ibis:questioned-by to be a subproperty of ibis:suggests, as well as their respective inverses. Use a Krzywinski Circos Plot. Use a Krzywinski Hive Plot. Use a Sugiyama-based plot. Use CSS to colour-code the different classes and properties, connecting to the embedded RDFa. Use JavaScript to construct RDF statement diffs and send them over with AJAX. Use SASS to manage the complexity of the CSS. Use something like D3 to visualize the subgraph. Use the HSLuv colour palette to equalize the brightness across all hues. Use the IBIS vocabulary you wrote back in 2012. Use UUIDs (or some other easily-generated identifier) to name RDF nodes. Visualize a patch in the graph (a partial spanning tree) centred around the subject. An embedding protocol is a much simpler idea; we can trot the JavaScript in later, when the app is more mature. Force-directed graph drawing algorithms are not stable and will not produce identical (geometric) output across runs. Force-directed (i.e. hairball) graphs get pretty hairy pretty quickly. It turns out people really, REALLY hate the Circos plot. It turns out that hive plots are not good for dynamic data: as the contents change, their aspect ratio changes dramatically, making it impossible to wrangle them into a larger graphic design. Plus they look weird. JavaScript is certainly dirty, but it isn't clear that it's quick: in particular, the extra fragility of developing client-side and server-side code at the same time. Krzywinski also has a design called Circos which doesn't have the aspect ratio problem. Other information systems will be able to link directly to the subject. Situating the user "at" a given subject gives a sense of position and orientation in hypermedia space. That takes care of the palette problem. Then we're going to have to decide how to feed data to D3. Then we're going to have to decide how to transmit the palette to D3. These plots are easy to implement in a few hundred lines of code. Users arriving from outside the system will therefore land "at" a particular element. Using (e.g.) UUIDs for node identifiers means you can separate the problem of recording information from the problem of naming it. We can pick up the RDFa from CSS or JavaScript and use it to further manipulate the UI. Writing an IBIS app will provide an opportunity to kick the tires on the vocabulary. The result might actually be useful! Generalizes Specializes Suggests Suggested by Questions Questioned by Has Response Suggested by Questions Suggests Suggested by Questions Questioned by Issue Position Argument