Domain: networking

So lately I've been delving into programming my router. I lend bandwidth to a neighbor, but they tend to watch Netflix when I want to watch Netflix on the Wii, and the Wii is not a happy camper when it comes to sharing bandwidth.

I run DD-WRT on my router, one of several open-source router firmware products out there these days. That means my router is a Unix box. That means that - given that it runs iptables - technically, I could make it do nearly anything, from logging bandwidth to choking it by specific MAC or even by MAC-and-port combination. Or at least I could do that if I truly understood iptables and networking, which, when you get down to brass tacks, I don't.

For example, there is a dandy little embryonic shell script wrtbwmon.sh that munges your iptables to log bandwidth by MAC address. (Here is a forum post by its author as he was trying to get it working, and here's his announcement on the DD-WRT forum.) It's slick, but as I have a much more capable Unix machine sitting right next to my router, what I'd really like to do is have that machine grab stats on a regular basis, more or less keeping the router running as a ganglion.

OK, so link dump out of the way, here's why I find this relevant to semantics. Note that I said up there that if I understood networking I could make iptables do some cool stuff. What does it really mean to understand networking? Clearly, it means to have a mental model of the network and the router and all the utilities used to work with the network, how packets get handled by iptables, and so on. I have a vague idea of all these, and given patience I can usually manage to get networks running or fix them, but I can hardly call that understanding (although, when you think about it, the notion of a "vague idea" is already pretty intriguing from the standpoint of modeling - after all, if you could give a computer system a "vague idea" you'd already be 90% of the way to intelligence; arguably, vagueness of ideas is the most human ability there is...)

So the domain of networking would have these concepts in some kind of Lexicon (borrowing from my Hoftstadter days), along with utility calls for diagnostics, and a library of C code snippets for writing your own special-case utilities. That sort of thing. I really do have some notion of where I'm going; I wish I could characterize it better.

Yahoo! design pattern library

Not the first time I've run across this, of course, but... it has semantics written all over it, so into the link heap it goes.

The semantic unit

The basic unit of semantics is the unit. Since "unit" is a really overloaded word, I'll call it a semantic unit, or a su or something. A unit is just a box. It can be thought of (loosely) as the meaning behind a single word.

A unit is made up of other units, which all stand in relationship within it. It also stands in relationship with other units within a domain. If you surmise that a unit is itself a domain for its inner units, you are quick. Domains and units are the same kind of thing, sort of.

A unit is associated with other units by dint of its inclusion with them in domains, and by dint of the nature of the structure they all participate in. Semantic nets that draw lines between nodes and assign weights to those lines are explicitly representing those associations; we can think of this as a sort of precalculated index of association values that could be derived from study of the semantic structures of a given domain. But those linear values are dangerous - they change according to context. They're best thought of in the abstract as an approximation.

A unit is also associated with syntax. I'll speak of a unit's "semantic pole" and its "syntactic pole", but I'm not sure how valid those labels are for what I'm doing here. (In case you're wondering, a lot of this is based on the work of Ronald Langacker, whose talk at Indiana University in, um, about 1994 really knocked my socks off. I've been imprinted on his theory of cognitive linguistics ever since.)

Since syntax is ultimately how semantic structures interact with the world - and in the programming context, syntactic structures are what actually does all the work - they're going to be quite important. A "cognitive linguistics parser" will have to be part of any toolset we come up with during this venture.