Posted on by lhl
Posted on by lhl

Between work and school, it’s been hard to get much else done (I just got home after finishing an animation assignment), but I did want to do some braindumping, spurred partly by some various writing around the web recently, partly by the realization that I haven’t ever really written in-depth on a project that’s consumed quite a lot of free time over the past couple of years, but especially because it’s unlikely that I’m going to get much time to work on this anytime soon(or maybe I need to write this down to better motivate myself to work on this instead of sleeping in the coming monhts).

Those who know me probably know about my longstanding fascination w/ KM, and KBs in particular. I started blogging in earnest in late ’99. Around mid-2000 or so I started giving major thought into how blogs as knowledge capture vector (and how to store/make sense of this info), and have been playing around with ways to do so since. To answer Marc’s comment, my latest exploration has taken me pretty close to full circle. The basic concept is to store micro-content as atomic units within a graph structure, with fragments assembled into multiple, faceted collections (blog posts, categories, pages, etc).

For the past year or so, I’ve been calling this a ‘blikiliner.’ Like others, I’ve been working at this from a wiki base, but for various reasons, this has proven problematic. Here’s some basic qualites that I believe such a system should have:

  • Shared dataset – the idea is that you want to be able to both programmatically and arbitrarily arrange/view datapoints from a single dataset. it wouldn’t be much of a KB without it.
  • Multiple views – blog / wiki-outline (wikiliner) are two obvious separations. there’s the question too of whether comments/discussion threading (also: annotation?) needs to be its own first-class data type (perhaps not necessary as long as the proper metadata is stored). it’s a pickle, but it’s been discussed before
  • Addressing – fragments need to be accessible w/ URIs both abstractly and in context; versioning needs to be taken into account
  • Relationship engine – I’d been playing w/ using the ART-1 algorithm (relationships via vectors) as well as more naive matching models. Recently, when Maciej swung by for Thursday night dinner a few weeks ago, he mentioned using a contextual network graphing algorithm, which is quite interesting. In any case, idea is to augment explicit grouping/organization with emergent structure
  • Realtime editing – this allows easier fragment-locking; requires remote scripting, and also replication of the transcode ruleset on the client-side. There are some weird corner-cases that pop up on that last part, especially when you’re dealing with auto-linking / content-generation
  • Context sensitive input – it seems that the next logical step, and at simple levels would be trivial, being able to easily add pre/post-processing, and input interface based on URLs or other properties; alternatively, may be controlled by arbitrary design rather than programmatically; hinting would be stored
  • Semi-permeable – needs to allow access control, trust rings, preferrably via arbitrary rulesets

I’d include links, but I’m lazy. If I had my search engine up you might be able to find a lot of links pertaining to the subject, but err, yeah, this is a strictly low-tech operation at the moment. (it’s no coincidence that my requirement-set mirrors my particular itches 🙂

Anyway, none of this is particularly new or unique or insightful, although there are a lot of tough design choices to get hung up on. My main surprise is that while discussion on this seems to come up fairly often, no one has put together a system like this yet (specifically the rtediting + shared dataset aspect).

Hopefully I haven’t relegated myself into the talking rather than doing class (although I certainly do more than my share of that already)

Related: online bookmarking, aggregation, infinite caching

Posted on by lhl

I am currently officially slammed. For tonight:

  • watch Graduate for scene analysis
  • write 3 pages of screenplay
  • read Tension + Release for CTPR 521
  • read 6 essays for CTIN 511

I will either be disappearing for a while or posting profusely (and most likely incoherently) over the next few months.

Posted on by lhl

openRTSP – a command-line RTSP client. Doesn’t understand most of the more recent QT payload types, doesn’t talk Real’s proprietary RDT protocol, buut is a good way to see what RTSP (RFC 2326) is up to.

Oh, if you actually want to *save* a stream, try one of these:

Nothing fun for the Mac, sorry.