Fwd: follow up from our talk / responce to your paper

[Aaron J. Seigo]

On Wednesday 20 October 2004 06:55, Scott Wheeler wrote:
> Hi folks -- I'm now back from my vacation in Chile.

Hope you had fun and got in a large dose of relaxation =)

here's some ramblings and thoughts. they are probably more familiar to Scott 
than others on this list, but each time i go through it in my mind or in 
words it seems to become a bit clearer and more definite.

> I'm working at a higher level and looking at what can be bolted onto the
> current HFS structures that will make contextual navigation and search more
> natural.

the Attribute-Centric Data Systems (A-CDS) paper noted that "HFS's are valid 
as an internal storage mechanism for operating systems, but the user need not 
be aware of them." i think this is similar to what klink is aiming for. of 
course an HFS location would simply be another entry in the klink graph, 
creating a cross-map between the two systems.

> Because I'm working with a web analogy -- represented as a graph -- there's
> also the notion of domains, called a NodeGroup in the current API, that
> represents a similar construct.

> I think our current representations of Domains (or for us NodeGroups) solve
> similar problems -- the represent logical groupings of information -- we've
> introduced them to solve things like mime-type associations or other
> information that's necessary, but I've already been wondering if the need
> for such is indicative of weaknesses elsewhere in the framework.

the concept of a NodeGroup or Domain is really just making explicit and 
implicit feature of the Graph. being little more than views projected on the 
Graph, they do not really "exist" outside of being viewpoints on the graph. 
they are well-defined searches.

IMO both the Attributes and Values of all metadata can be represented as nodes 
on the Graph and there need be no specific difference between an "Attribute" 
and a "Value", except that values will tend to be leaf nodes and attributes 
will tend to be trunk nodes. thus Attributes naturally emerge, and Values may 
transition to be Attributes as one changes the viewpoint taken on the graph.

for instance, "Music Information" may be an Attribute that maps to, among 
other things: "Artist", "Song Title", "Song Length", "Album", "Album Length", 
"Publish Date", "Composer", "Producer", "Album Art", "Genre" etc.... in this 
view "Artist" is a Value. however, "Artist" becomes an Attribute when one 
graphs out from there to various artists, for instance "Leonard Cohen".

in the case of "Artist" > "Leonard Cohen", we will find that there are links 
to "Music" as well as "Writing" if we were to look at artistic achievements. 
what's interesting is that both "Music" > "Bird on the Wire" and "Writing" > 
"First We Take Manhatten" have "Publish Date", "Composer", "Genre" and 
"Artist" Attributes (among others, probably).

so the question becomes: what is the Domain or NodeGroup? Leonard Cohen? 
Music? A specific year? A given genre?

i posit that it depends completely on context.

a music player may chart out a view of the Graph that uses "Music Information" 
as its root attribute and references from "Song Title" out. an eBook reader 
may start with "Genre" and move out from there along "Writing". a biography 
application may start with "Artists" and move out in 'all' directions. none 
of these are a more canonical a view of the graph, and each view may be 
transposed into any of the others quite easily with very little change in 
which nodes on the Graph are utilized.

then there are users: a user may decide to search on any "Attribute" value, 
thereby defining domains dynamically (as covered in A-CDS paper) but the fact 
that the user searches for "Leonard Cohen" does not imply any specific 
Attribute / Value pair.  if we are in search of an Attribute, it is in this 
case "Leonard Cohen". but if the user searches for "Poets" then "Leonard 
Cohen" becomes a Value! therefore there is no meaningful disparity between 
Attribute and Value without Context, and there is no such thing as a Domain 
or a NodeGroup until given a trunk Attribute and a mapping direction on the 
Graph.

if we surrender notions of Attribute, Value, Domain and NodeGroup the question 
to answer is: given a specific context how do we locate Nodes to use as 
Trunks and pathways along the Graph from there? Attributes, Values and 
Domains will become emergent qualities that the user perceives to exist but 
which do NOT exist explicitly in the system itself in a meaningful way.

> === Domains & Documents vs. Objects =======================
>
> Another thing that I wondered about in your paper was that given the
> starting point -- that everything could be thrown out -- and the desire to
> move away from arbitrary constructs why there was still the inclusion of a
> separation between documents and domains.

i don't thinks this is particularly necessary, save as a final step between 
mapping a Node on the Graph to a unique string in the HFS.

writing that just made me realize something, actually: some Nodes will have 
direct mappings to data, some will mappings only to other Nodes, and some 
will have both. i think this is significant.

> === Lack of Addressability ================================

> Well, the first thing that was missing was an idea of resource
> addressability. We needed some way to point from a specific place in one
> resource to a specific place in another.

which resolves everything into a relative addressing scheme where there are no 
absolutes, only the illusion of it by traversing the Graph in similar ways 
repeatedly.

our current methods of addressability is to freeze the map in place so its the 
same tomorrow as it is today: /etc/passwd is always found at /etc/passwd. 
this requires users, as A-CDS notes, to rely on memories of past events. this 
also leads to fragilities, such as "broken links" on the web. with a 
NodeGraph, the distribution of Nodes in the Graph (it's "shape") can change 
but the addressing remain constant _and_ robust since it's the links between 
nodes that are the address rather than node itself.

> Now, going back to the original point of this section -- it seems that the
> idea of addressability is missing in your paper. 

as i read it, addressability is (erm) addressed by organizing things into 
Domains or other views that are organized enough that the user can 
concentrate on a specific point in the total cloud of data and be assured 
that all relevant matches are within their sensory horizon. it seems it 
relies heavily on A) the user being able to complete the "addressing" by 
harnessing our built in capability to scan a cloud of options and sort them 
out as long as that cloud is related and small enough and B) these clouds 
being static and topical enough to lend some stasis. it's almost 
anti-addressability, in that its saying that being able to locate something 
isn't as important as being able to find it ;-)

> One of the things that I think is a problem with both of our systems -- at
> least as I see them is how to deal with networks and moving resources
> across networks without destroying the context that they typically exist
> in.

this is one of the issues i don't have the foggiest idea about at the moment. 
intuitively, i feel that once that concepts of linkage are well understood 
that solutions for network-ability will become possible to find.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43