June 11, 2009
A Modest Proposal
Object-oriented modeling is taking over the world. The interesting thing about "objects" is that it makes sense to talk about "instances" of them. The interesting thing about "instances" of objects is that you can "classify" them. The interesting thing about "classifying" objects is that you can "subclassify" them. But where does classification/subclassification end? In Java, it ends with java.lang.Object. Similarly, Web standards effectively say that classification ends with "resource".
One of the interesting differences between these two ultimate classes is that Web standards allow for direct instantiation of "resource" whereas Java requires you to subclass java.lang.Object before you do so. Java is also nice, compared to say C++, because it restricts multiple inheritance. If the Web had a similar constraint, the Semantic Web would be a whole lot simpler because a singular rdf:type could be required instead of optional or duplicitous.
My modest proposal, then, is to change Java and Web standards ever so slightly. In the case of Java, let's forbid developers from subclassing java.lang.Object and force them to subclass java.lang.Goop or java.lang.Concept instead. My sense is that most experienced developers would proudly choose to subclass java.lang.Concept and would make a genuine effort to justify this claim.
Likewise, in the case of Web standards, let's deny developers the right to directly create HTTP URIs and force them to choose between GOOP and CONCEPT URIs instead. The protocols associated with the identifiers should be identical. Looking around the Web, I suspect we could solve the problem of world hunger by eating Web developers who confuse the two.
6 comments so far
I was with you right up to the point where you said "Goop". Now I fear I might be eaten, so I'll modestly ask that you define the term, please. ;-)
Sure! A GOOP URI identifies an incoherent and/or tightly-coupled concept. The easiest way to tell if you're dealing with a GOOP URI is to do an HTTP GET on it and negotiate for a representation (information resource) that describes the concept. If all the representations are incoherent and/or tightly-coupled, chances are that the concept itself is as well. If the GOOP URI is a hash URI or responds with a 303 See Other redirect, it might be a clue that the concept is not really goop after all, it's Linked Data (i.e. a coherent, loosely-coupled concept) and the programmer used a GOOP URI by mistake. Technically, we should eat these guys too except for the fact that there is a size/weight limit on our catch and so we should throw them back.
If it's any relief, I think that Web developers who use GOOP URIs to identify goop should be allowed to live because they are at least being honest. The really juicy ones are Web developers who create CONCEPT URIs when they should have assigned GOOP URIs instead. :-)
Jeff, does GOOP stand for something? Or, how did it get the name?
Keep in mind that this is all tongue-in-cheek. The best acronyms reflect something that is analogous, which in the case of GOOP is "goop". As a point of trivial, note that the GOOP acronym has some interesting parallels to the HTTP acronym. To illustrate, note that the G in GOOP is one letter away from the H in HTTP, "OO" is somehow reminiscent of "TT", and that the "P" in both stand for "Protocol" despite the fact that HTTP identifiers (and likewise GOOP identifiers) and the HTTP protocol are two different concepts. All that's left to do now is to figure out which words we can choose to match the desired GOOP acronym. I'm tempted to suggest "GOOP is not a protocol", but that would make the acronym GINAP, not GOOP. Damn, so close! Suggestions are welcome!
God Only Observes Properties
Eric,
That is quite excellent! What I learned after I posted this, though, is that GOOP already stands for Graphical Object Oriented Programming. I've decided I need to dust off my thesaurus and start looking for another acronym that only has one dimension of irony. ;-)
Jeff