Semantic Thoughts on Model, View, Controller (MVC)
Semantic Web is a technology family (or, a disparate set of sometimes non-related technologies) that allows computing applications to understand each other. It has the potential of transforming the way we do computing in the very near future... and power to make software developers' lives easier.
I've been having lots of random thoughts about how to connect independent apps to work, talk, and walk together. Several components need to be identified. I call them Actors, Messages, and Translators.
Actors are objects that can perform actions, in the traditional OO sense it has state and behavior. In Java EE or SOA they might be called stateless or stateful session beans. We can consider a web browser and a web server both are actors. The model, view, and controller in an MVC app are all actors.
To communicate with other actors, one sends a Message to each other. Traditional messages don't have any behavior, and I'd rather think not (at least for the moment). Messages are basically data, but to be useful as "information", it has to have content, and language. Examples of "languages" in this sense are Atom and RDF.
It can also have a message header, message envelope, or metadata, or a schema. However, I don't consider those as "language", because languages are identifiable, and can be inferred from message content (with some effort), while a metadata is usually not. For example, given an document, a script can be written to determine if it's in Atom format. However, given a message body, it'd be though to determine its title or creation date if it's not inscribed the message itself (somewhere).
Metadata, headers, and schemas also have languages. Therefore, actors need to understand these languages (as well) in order to process a document/message. In addition, languages themselves need to be know, not necessarily understood. A bit like saying, "I know you're talking in Turkish, but I can't understand what you're saying. But at least I know you use Turkish." Getting an actor to know what language a message is made of is a useful thing, as we'll see later. A kind of universal language identifier is MIME types. If it can be inscribed somewhere of inferred in the message, the actor will at least know the next step of interpreting the message; if not, then it'd be much tougher.
Someone that can make two actors communicate in different languages is needed, Translator. They take a message from one actor, does whatever it takes to get the other party to understand this message. An example of a translator in the computing world is Mule, Apache Synapse, and OpenESB.
Actors need to agree upon use of translators, at least one of the parties and preferably both parties. Security is paramount when using translators. Messages may or may not be translated in full to translators. Partial translation shall be possible, i.e. translating parts of a message that the actor doesn't understand, but not the entire message.
Translator may also gain non-repudiation privileges, and may perform limited set of actions on behalf of the requesting actor. Think of it as your lawyer.
Overall, some kind of cryptosystem is needed between the actors and translators. Otherwise, this kind of distributed knowledge architecture has lots of security holes of varying severities.
So, where do we start?