We have been doing a lot of coding work and even some writing/sharing/messaging work over these past months, but haven't made any updates here, and I suppose it's about time (just for the record).

So... obviously you should check our github repo, and also our Ceptr Revelation doc.

I have some good blog posts in progress about Crypto-Currencies too... and why we would implement them differently.

I'm not even sure what pictures are going to show to accompny this post (as I fear we've been delinquent in uploading them), but I want to capture some notes from some JavaScript UI work, some scheming about Scapes, and about the structure/format of messages internal to the VMhost, between VMhosts (CeptrNet) and for synchronizing between accumulators/data-engines for Byzantine Fault Tolerance.

Scapes & interfacing w/ RDF/Semantic web vocabs

RDF Properties (and subclasses) seem easy for us to represent in our semantic trees, but relationships (and membership in collections) seem to be a job of scapes.

The cool thing about this is that it seems like relational data can be more dimensional/topological rather than linguisticly asserted. E.g. intead of "knows" or "friend of" you could have a connection-scape based on actual frequency and/or quality of communications/interactions. This could give you much more powerful graphs in terms of strong/weak ties than the linguistic equivalancy of "friend."

SPARQL - SPARQL Protocol and RDF Query Language) is an RDF query language, that is, a semantic query language... Compatable

variant for planting listeners?

Types of Scapes & Implementation Notes

Relationship within subtree (as we've previously described, basically larger item indexed/ordered/organized by a sub-element)
Smart Scaping? Is there a way to identify queries on unscaped elements which should be scaped to increase query efficiency?
Relationship by new assertion (e.g. Arthur adds Eric as a friend, QIVC adds Eric as a member?, ...) The issue here is this needs to be stored somewhere. It is a new instance of something and we've said scapes are built from instances. So... this seems like a kind of relational structure/symbol that we need to store instances of. But it is of the "linguistic" kind of assertions that RDF triples are, which seems much weaker than creating real relational spaces where we can model the dimensions of variability relevant in a scape/relational space.
In one Relationship case (as described above) it's quite easy. Eric gets added as an address book entry in Arthur's streamscapes, and tagged? friend. Eric is a new instance in Arthur's space or address book. Same could apply for a QIVC space which Eric as added as an instance of a member.
However, in the case of shared space where Arthur and Eric exist (e.g. CouchMatching), it seems we need to add a new relationship (structure) of as a symbol "friend" with a new instance (with Arthur as first-child & Eric as second). This relationship structure could be considered mutual by default or have an inverse label for describing 2->1. (e.g. "maker of" vs. "made by")
Relationship by ad-hoc or on-demand complex computation. E.g. nearby couch-matching hosts, Most frequent contacts, Best authors in my newsfeed (based on my "likes" history, or ratings, or reading frequency or whatever). It would be nice to store this computational data someplace temporarily, but it gets stale and needs to be refreshed. But from a user experience perspective, may take long to calculate on demand the moment I want it. Where/how do we store this semi-ephemeral/relative data? In just that user's client instance? Akin to their transaction chain in a currency? How do we identify how frequently it needs updating? How do we identify how subjective it is (Do values apply reciprocally across the whole range or unilaterally? Meaning: Distance is reciprocal, but author-quality in news-feeds is not.) Do we create good defaults, and let individuals invest how much CPU/storage they want on having results be fast and ready for them when they look?

Nested Tree Mockup

def symbol

label = "Home Location"

latlong

def structure

label = "latlong"

surface

lat

long

process

distance

complicated sphere wrapping formula

EXPECTATION

On HTTP_Request

Expect .*/HOST{value="geekgene.com"}

expr

then

expr

then

some proc tree

else

some other proc tree

else

expr

then

some proc tree

else

some other proc tree

With SessionInitParams

Instance = 48

This is just a quick experiment with the CSS (1 selector with 4 properties). I could probably make it sexier, but it's pretty darn readable from both text and tree perspectives, I think.

Try playing around with the width of the window and watch how the structure adapts. I don't think it's fully cross-browser compatible, but seems fine in Chrome, Firefox and IE 11 (9 and up, I think)

Noteworthy issues to consider when translating typed text to trees:

I don't think we want to require parens when we can use syntactical context.
For many processes, we probably want to have keywords indicate advancing to next branch (almost like parens, but not paired... we could manually pop up by typing a close_paren (or other special key) and not display the paren just change the tree formatting/placement of cursor).

e.g. If {first-child} Then {second-child} Else {third-child}
e.g. On {first-child} Expect {second-child} Do {third-child} With {fourth-child}

In fact, I think we'd want to prepopulate the next child keywords and be able to tab into their slot to type (tab then press {delete} to delete optional ones like ELSE or WITH).
Where/How do we store such keyword sequence associations? Label Table?
It doesn't make a lot of sense to display Symbols as def trees like above. A label table view would be much more useful.
It also seems like we could make a simple def-symbol button or something to generate those kinds of entries.
Similarly, it seems fairly easy to build a Structure Def tool for everything up until the process defs... which is where we switch back to the coding style originally describe above. So "coding" is always for writing processes. We can make a pretty simple UI for def-building so that constructing the semantic trees for content which work slightly differently than code, don't get confused with process trees.

Possible Color Coding Approach for Semantic Tree Background Colors:

First Column (named) colors are for borders, controls, etc.
Second Column nested colors are for recursing tree levels. They need to be darker than expected because 10 steps of 10% opacity <> 100%

Note: We probably want to use the inverted colors (right-most) so that color clarity is higher in the initial levels setting type context clearly. It also makes layering veary easy because you're always adding a new layer of transparent white. Every time you switch symbol contexts (Process, Symbol, Receptor, etc.), you start a new color context layering anew (That's why the inverted colors may make more sense.)

Process: seagreen

1
2
3
4
5
6
7
8
9
10

1
2
3
4
5
6
7
8
9
10
Hand-tuned darker target:
rgba(0,100,0,.1)
Receptor: gold

1
2
3
4
5
6
7
8
9
10

1
2
3
4
5
6
7
8
9
10
Hand-tuned darker target:
rgba(190,175,0,.1)
Protocol: tomato

1
2
3
4
5
6
7
8
9
10

1
2
3
4
5
6
7
8
9
10
Hand-tuned darker target:
rgba(190,110,0,.1)
Semtrex: crimson

1
2
3
4
5
6
7
8
9
10

1
2
3
4
5
6
7
8
9
10
Hand-tuned darker target:
rgba(150,0,0,.1)
Symbol/Label: blueviolet

1
2
3
4
5
6
7
8
9
10

1
2
3
4
5
6
7
8
9
10
Hand-tuned darker target:
rgba(80,0,130,.1)
Value/Literal: royalblue

1
2
3
4
5
6
7
8
9
10

1
2
3
4
5
6
7
8
9
10
Hand-tuned darker target:
rgba(10,40,120,.1)
Def/Structure: sienna

1
2
3
4
5
6
7
8
9
10

1
2
3
4
5
6
7
8
9
10
Hand-tuned darker target:
rgba(90,60,30,.1)

CD_043+dump

Scapes & interfacing w/ RDF/Semantic web vocabs

Nested Tree Mockup

Noteworthy issues to consider when translating typed text to trees:

Possible Color Coding Approach for Semantic Tree Background Colors:

Menu 1