Triples, Quads, Quints?

Bill de hÓra writes about RDF, triples, and quads. I think the point is RDF representa triples (X-Y-Z) but he wants to introduce another party into the relationship, e.g. he wants to distinguish (A-(X-Y-Z)) from (B-(X-Y-Z)). Apparently RDF cannot do this concisely, i.e. you need more than A, B, X, Y, and Z in order to denote that A and B relate to the same triple (X-Y-Z) in each in their own way.

Triples, quads, etc. I have to say I've not used RDF at all explicitly.

I guess "quads" are intended to support the (A-(X-Y-Z)) and (B-(X-Y-Z)) relationships concisely.

But, the engineer in me ignorantly wonders, won't we soon run into a desire for a fifth party in this relationship? Why stop at quads?

Quints, hexes, septs. How many is enough?

I wonder if we need a concise way of representing many occurrences of Many-Many relationships. Something like a Star Schema would simplify bulk Many-Many relationships. Bonus, it implies certain expectations about the contents of the relatonships, i.e. you can speak of measurements, occurrences, hierarchies, allocations, headers / details.

Star schemas can be seen as a shorthand notation for many implied individual RDF triples. Bonus, they are proven to be incredibly scalable and support high performance with fairly simple database implementations. The column-based storage approach goes back at least to the 1970's. Another example is Kdb, although "array based" and columnar, it's not explicitly star schema based.

I'm just thinking RDF triples are probably too primitive, and thinking out loud about what might be more expressive. Mostly I am confused about a triple to quad to (?) progression trying to represent increasingly complex relationships. Star schemas encourage a discipline, style, and simplicity into complex relationships that can scale and evolve.

I'll have to learn more about the triple / quad issue and think about this before I can become more coherent on comparing these modeling approaches.

JINI and JavaSpaces

JINI (and therefore JavaSpaces) in action, not inaction, via Tim Bray...

Jini has the fingerprints of Bill Joy and Jim Waldo all over its architecture, and these are obviously two of the Real Smart Guys. Rob Gingell, another one of them, said “Those who do not use Jini are doomed to re-invent it.”

Jini is not just a theoretical triumph; it’s being deployed in large mission-critical applications at places including Orbitz, Orange (the mobile-phone company), Raytheon, and the U.S. Army.

Must (Try) to Understand This?

Sean McGrath writes about "must understand" rules in loosely coupled message passing...

Whatever about the pros and cons of REST versus SOAP, I think it is abundantly clear that the mustUnderstand model [1] is a key concept in developing loosely coupled systems that can evolve independently.

I need April 2 asap.

One thought this does provoke though, for real, is that a sender probably has no business telling a receiver what it must understand or to what degree. I'm all for ways for receivers to describe, more or less formally, what they will understand and how they will understand it. Senders just send messages and set their expectations as best as possible. Hopefully both senders and receivers have robust fallback capabilities.

They Are Principles

Kent Beck writes...

If we abandon our principles at the first sign of trouble, our principles must not be worth much.

I think integrity and accountability are particularly important in a climate of fear.

Democracy Inaction

John Robb wonders...

What we may end up with as part of this push towards "democracy" in the Middle East is civil war. Lebanon, Iraq, and Palestine are all on the brink of it now. Are we better off with this?

Yeah, I think the next chapter is still being written while people rush to chalk up an "ends must justify the means" scenario for democracy breaking out in the mideast.

There are so many directions this could go. Think of this as a complex system that is not very well understood with more than a few elements of chaos.

This is not a "guzinta-guzoutta" simple equation. And no, Bill Maher. I agree Bush stumbled into something, but a fresh pile of democracy in the mideast is not yet clearly the pile he stepped into.

That's the Way of the World

"That's the Way of the World" has been one of my favorite songs for about 30 years. Not one of EW&F's funkier tunes though. "Shining Star" too. A little bit funkier.

(Blaine Buxton likes funk.)

Hubris

Unfortunately, Truly says, the prevailing wisdom at the Pentagon is that "fuel efficiency is for sissies."

(via John Robb)

Hubris. Marines don't eat granola, they just kick the shit out of haj's. Scary when the stereotypes show up in reality.

What Goes Around

(via John Robb)

The MS 13 sprang up in the late 1980s, created by the children of Salvadoran immigrants who fled to California during a bloody civil war.

Can we not think in terms of systems? Everything is compartmentalized and treated as independent, discrete actions. Not only does every action have a reaction, but the systems we are creators of, and participants in, are far more complex than we ever think about in the moment.

Has science taught us nothing about society?

Know(n)Now as AJAX

From FoRK on the AJAX controversy...

"Yeah, I liked that idea the first time around.
When it was called 'KnowNow'."

See also mod_pubsub.

We Build Our Own

The misunderstanding about XP and "doing the simplest thing" is more often than I'd like taken to absurd extremes. For example I encountered a developer recently repeating a claim that an XP team would not use a framework that had been built to simplify a certain style of software development.

Certainly the XP team would want to understand their experience with the framework, the maturity of the framework, and the nature of the problem's suitability for the framework. But not use it, period?

Gack.

So how far does this go?

"I'm not sure we need a computer for this project, but when we do we'll dig up the coal to forge the steel to make the rack to mount the motherboard."

"I'm not sure we need a high-level programming language. We'll use assembly language and see what patterns emerge, then let the higher-level language evolve."

I think there is a spirit and a letter to the law, and the same goes for XP values. Just work in small pieces with concrete feedback. Avoid too much prediction and too many assumptions. Common sense works wonders.

Whence Dynamic Languages

Ryan Tomayko projects what might be necessary to get better late-bound languages acceptance in early-bound organizations...

I think we need something to break through on one of the VMs if we're ever going to move this into the enterprise. There's no way I could bring Python into my place of business on any serious level. This really comes down to it not being blessed as Enterprise Class (blech!) by Sun. It seems we need the VM to get in the door and then maybe we can just move quietly toward CPython with a Java/CLR bridge?

Maybe. The IT industry seems kind of in a "standardization" phase still, following the irrational exhuberence of the "anything goes" phase of the dot.com days. That can translate into the desire to choose one language to standardize on developer resources. I'm not sure getting CPython in would be any more difficult than Jython or IronPython.

We used to have these things called skunkworks. Do such things exist anymore where you can demonstrate value before being judged prematurely on cost? I think maybe but you may need radar detectors along the way.

Frameworks and Plug-ins and Loose Coupling

From ACM Queue about frameworks and plug-ins...

This article identifies some of the concepts around the foundation of pure plug-in architectures and how they affect various stakeholders when taking a plug-in approach. The intention is to discuss the general issues involved, but the article also presents some lessons learned from Eclipse (www.eclipse.org) to better illustrate some of the concepts.

The main problem with a framework like Eclipse is that so many unnecessary dependencies are forced on plug-in developers. You have to buy the full Eclipse approach to get even half the benefits.

What lessons have we learned in the last 15 years of building frameworks like this? Are we having trouble understanding what is important, what has been learned already in the software industry?

Why build a framework like Eclipse in the 21st century when you could build a framework like FIELD which was built in the 1980s? Certainly the full benefits of Eclipse could be built *using* an approach like FIELD's. Plug-ins that did not or could not support the full benefits of Eclipse would then have fall-back positions. New approaches could evolve that stretch beyond the imaginary boundaries of the current Eclipse framework.

What is it about FIELD? Well FIELD is based on integrated components loosely coupled via asynchronous message passing.

That may ring a bell for 21st century programmers.

Reconciling Modal Web Apps and Rest

Mark Baker comments on how continuation-based modal web applications fit the REST style...

"This is how most web applications work.". Actually, it isn't. Most Web applications are stateless. Of those that aren't, the vast majority are only stateful for authentication purposes.

Here's how I've started to view the relationship of the modal web app style and the REST style:

• Work-in-pogress interactions seem to be programmed AJAX-style, GOTO-style, Modal-style, or "richer-client" style.
• Modal web applications simplify programming controllers for work-in-progress over HTTP.
• Continuation-based interactions are not necessarily RESTful.
• As work-in-progress is "published" those pieces of work become resources with various representations, etc.
• Publishing (perhaps partially as a "proposal") completed work as resources can be RESTful.
• Accessing (perhaps partially) completed work as resources can be RESTful.

So I think modal and RESTful can be seen as somewhat complementary styles or at least aimed at different purposes. Perhaps they don't have to be completely unified if they meet their purposes with little risk of interference between implementations.

Extreme Refactoring

Again Keith Ray, this time on design, refactoring, and language choice...

Brian Button decided to explore refactoring by taking the Video Store example from Martin Fowler's book and refactoring it into methods one line long, no private methods, and aggressively removing all duplication, particularly duplication of iteration over containers.

His starting point (and Fowler's ending point) is the class named "Customer", containing a list of rentals. It has private methods for calculating rental cost and "frequent renter points", and a large method for printing the customer's statement. Brian's ending point is seven classes: Customer, RentalStatement, RentalCollection, Collector, LineItemPrinter, FrequentPointsTotaller, RentalCostTotaller.

If he had been programming in Ruby or Smalltalk instead of C#, he probably could have met his goals with only first two classes. Blocks and iteration methods built into Smalltalk/Ruby collection classes would have eliminated the need to create the other five classes.

Agile Data

Keith Ray writes about agile data...

He asked audience members to raise their hands if they could make a simple change (like renaming a column of a table) and re-deploy their database and associated apps in the same day. Only one guy, in a large room filled with database people, raised his hand (I bet that guy worked at Yahoo, Amazon, or Google.) That guy's DB had terabytes of data and 37 apps depending on it, but he could deploy a change in less than one day.

Ambler also asked audience members to raise their hands if their database and associated apps had extensive automated testing. The same guy raised his hand, and maybe one other.

Bill Maher

I saw Bill Maher live last night. He was recording an HBO special and DVD in Portland. Maher is a good observer and funny commentator of American politics, religion, and culture. He is irreverent and holds nothing back. He's more of a traditional humorist like Mark Twain or Woody Guthrie than Jon Stewart. But he goes beyond Stewart and Lewis Black topically and stylistically. (I missed seeing Black on stage when he was in Portland a few months ago.)

These three along with Harry Shearer are four people worth listening to for insight into the state of the union with varying degrees of subtlety and style.

Boo and IronPython

Edd Dumbill tried IronPython and now prefers Boo. Another Python friend was thinking of trying Boo too. The problem I have with that is I'd rather the bulk of my code not be tied to a specific platform, which Boo seems to do. Boo runs on MSFT dotnet as well as Mono, but still requires the CLR platform.

Edd raises significant concerns about IronPython. Rather than a somewhat handcuffed Boo, I would think a Python programmer would be very well off with regular CPython and bridging to dotnet via the Python.Net dll's.

Attitudes Toward SISC and Continuations

Chris Double used SISC running in the JVM to build a continuation-based modal web server. He wrote of the manager's and developers' experiences...

This approach has worked well for me and the performance is quite usable. Although I do get constant requests from the project manager to find a way to rewrite things in Java as he never was a fan of using Scheme and is concerned it may put customers of the system off it. The developers on the other hand seem to have enjoyed learning Scheme and consider it an advantage over Java.

Listen.

The Secret Sauce

(via Blaine Buxton) Eliot Miranda divulges...

VisualWorks and VW/GemStone combinations are used in sectors such as cpu manufacture, container shipping and derivatives trading on a world scale (i.e. they handle a substantial fraction of the world's activities in these sectors). But for nearly two decades the corporations who have built these applications have viewed their use of Smalltalk as a strategic advantage, and hence prevented the vendors from using the applications in marketing material.