KLink::Group

Aaron J. Seigo aseigo at kde.org
Mon Nov 15 18:56:46 CET 2004


On Sunday 14 November 2004 07:36, Scott Wheeler wrote:
> Responding to myself here --

sorry ... i've been occupied with house guests and little coughing boys.

> Node groups aren't interesting.  Link groups are.  Unless we want to have
> links to links (which I think is kind of nasty) we're back to the idea of
> link groups.
>
> Most of the things in my last mail weren't nodes -- really they're links.
>
> "Bob Dylan" isn't an artist in our scheme, fundamentally.  It's just a
> phrase. It's only when it's in relation to a music file that it becomes an
> artist. Specifically it'll probably be both the ID3v2 and the ID3v1 artist
> name for a given mp3.

well, the graph that says "Bob Dylan is a musical artist" may actually look 
like:

Audio Meta -> Artist -> Bob Dylan <- Knocking on Heaven's Door <- Audio File

which means one could come to "Bob Dylan is a musical artist" two different 
ways (at least) ... 

but yes, it's the linkage ...

> id3v1 is a group of links, not a group of nodes.  Mimetype I think would
> probably actually be a node group.  But something like the textual
> description of a mimetype would be a link group (word to file mapping).

> So, we're back to "What do we do about link groups?"  I think they probably
> still need to be there, but I may have changed my mind by tomorrow.  Aaron?

in the actual data representation, the links are implicitly grouped (by 
arriving at or leaving from the same node (or set of nodes?))...

in the API it would be useful to give the programmer easy access to this group 
of links that extend from a node for traversal, as this is certainly a way to 
show the implicit structure in the graph.

we're starting to get into "how do we show the concept of a graph via the 
API?" i'd really like to see a class that represents a "star" datatype (node 
with multiple radiating, directional links) that supports the following 
things:

	o link enumeration/iteration ("let's list our links")
	o traversal ("move along this link")

 this is a logical extension of  a Node, really. and i think the first point 
above (along with the Graph class below) may be what you are looking for when 
it comes to link groups?

and a collection class that manages a collection of these things that 
supports, call it perhaps Graph:

	o transparent node loading ("i'm going to extend the graph in the direction 
you are traversing, so you can keep traversing in that direction")
	o frame shifting, where a frame is defined as having a "trunk" node (an 
arbitrary, and even temporary, distinction) and the links/nodes around it, 
allowing one to move the subgraph by traversing

Node "iterators" that operate on a Graph, and an ABC that provides the basis 
for operations on graphs which takes a Graph and does things to it, e.g. 
maximal flow or fingerprinting.

thoughts? 

eventually we may want to add the frills of a NodeCache and reference counted 
Nodes, opportunistic loading in Graphs, etc.. but that's all completely 
unnecessary to the initial goal, just something to keep in mind (or in the 
archives so i can remember after i forget)

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/klink/attachments/20041115/e3e3ffe0/attachment.pgp


More information about the Klink mailing list