Sunday, January 1, 2012

Let's run down the hierarchy of this graph format

We start with the atom, a triplet which contains all essentials to define its place in a tree.  A tree is a linear stack of triplets, really, all in  nested order, as long as our linkage obeys nested grammar. If the next triplet  is the linear nested order of the entire web, then so be it. Then, with some compromise and minimal work, we map a stack of one or more triplets to a disk page, disk/URL  pages become the tree.  The mapping of the tree and the nested order to be decided, but that's what makes life fun.

What is the optimum format of a page for a web bot. Say a web bot that just wants to go skating on a day off.  I would think smart bots only need a 16 byte key word, so with the predicate and object, we get a 32 byte page size.  If the bot wants to take the short cut, it likely needs two triplets to define the named graph. So make that the 64 byte page.

Making the bots carry payloads
Define the second page type for variable, and large application chunks, which the graph layer knows nothing about, except where a keyword match is desired.

Of course the whole thing hinges on a robust theory of the named graph. I wonder if we can't incorporate the general idea of linkage in with named graph, a specialization of it.  Get enough definition so all the vendors can have a go at it. My tiny brain,  it just barely gets around the details. Hmm... ... But the disk striping and URL jumps, even block jumps within a disk, they all have to obey grammar, merge them all into a special form of the named graph.

No comments: