The Bloj

The New Programming (Part III): Semantic Unit Architecture, Messaging Framework

Posted on August 30th, 2006 by Chris.
Categories: Chris, Programming, Semantic Unit Architecture.

So in the past, I promised that I’d discuss how we’d get these objects to communicate with each other. Exactly how would a user list know how to handle its connection to an instant messaging manager?

Before we do this, we’ll go into a brief interlude to see MS’s solution to this problem.

Google’s Theorem: It’s already been done

After Gas finally figured out what I was doing, he mentioned that MS had already done this sort of semantic architecture:

[00:20] Gas: Microsofts version of the semantic operating system
[00:20] Gas: is the clipboard
[00:20] Gas: (you think i’m joking?)

Gas was correct that the linking system, in many ways, is solving a similar problem to the clipboard. How do you take a piece of data and give it meaning? The Clipboard uses OLE to translate data formats, allowing us to paste, say, an Excel spreadsheet into a Word document and have it be displayable.

This isn’t the only example of being able to plug data into an system and give it meaning. The Semantic Web is based around the idea of being able to attach meanings to data. For example, this page is a blog entry - the Semantic Web would be able to assign meanings to this beyond simple character data, identifying entries, authors, and the like.

Back to the fun

We are not thinking here purely of the Semantic Web, but rather, a Semantic Web Application–architecture that processes this data. This is in some senses a much simpler problem–we need only deal with subsets of data which are viable.

Similarly, we are not dealing purely with an advanced clipboard. Clipboards hold repositories of data and join it together–we are in fact actually processing that data.

Let’s imagine a series of Units that build an Instant Messaging client. We’ll have a LinkToIMNetwork, a UserList, a ConnectionManager, and the Human unit (refer to previous entry).

You’ll notice, if you’re familiar with UML in other object oriented languages, that there is a–surprising? disturbing? exciting?–lack of type definition in the relationships. All of the units are peers, and there is no aggregation, no subclassing, no nothing. Nowhere do we define a list of methods, and nowhere do we have to specify types by hand. This is exactly what we want if we want a chance of giving the average person an ability to understand the architecture.

For every channel in one unit, we’ll notice a matching channel in another. LinkToIMNetwork passes a ListofUsers to UserList. Because these types are defined as output and input in the two units, connecting the two requires no effort on our part–the linking engine will know what to pass a ListOfUsers, and not anything else.

What happens if there’s ambiguity in the connection?

This will be defined behavior. My initial intuition is to do a multicast. For example, if you connect two UserLists to a LinkToIMNetwork, it will pass the ListofUsers to both.

Reversedly, we can imagine UserList accepting multiple ListsofUsers and aggregating them together. We could have LinkToAIMNetwork and LinkToGoogleNetwork, for example, and plug them both in to UserList.

Won’t this demand a lot of functionality on the part of units?

Yes, only programmers are expected to touch the innards of units, for now at least.

You seem to have ignored a lot of important details–you haven’t touched the ConnectionStatus, for example.

Yeah, I did a half-baked job.

This may give the average user an ability to look at the architecture, but how would they manipulate it? There doesn’t appear to be much room for user intervention.

This depends on a lot of factors. Basically, the more units we have, the more effective (by exponential leaps and bounds) will be the use of the FOOP tool. On one level, we could simply upgrade units–proper upgrading of the LinkToIMNetwork might enable file transfers with less effort than might be typically anticipated. On another level, we could attach units in any way that was semantically allowed, and with expansively defined units, we could make disturbingly good applications out of previously unrelated units.

Tune in next time, when we’ll discuss how we might syntactify such a language.

Related Info

http://en.wikipedia.org/wiki/Component_object_model

http://www.w3.org/TR/owl-guide

0 comments.