Announcing Andrae

lca: Andrae Muys on RDF "On the first day of linux.conf.au, I ran into Andrae Muys. He hacks Java and RDF for clients who want semantic web hackery done. I have to admit that early Semantic Web hype put me off: it sounded too much like 1970s AI hype. Andrae was interesting, though, and completely free of the wide-eyed uncritical enthusiasm that characterized a lot of my early RDF engagement."

"Andrae runs the Mulgara project, a Java RDF store. His goal is to be able to deal with 1E13 statements (aka tuples, facts, assertions) in three years. It'll do 1E9 right now, next stop is 1E11. He refers to this goal as "3 Ts: three trillion triples". A consortium is forming around Mulgara to make this happen: if it coalesces, Andrae will be the coder to make it happen."

"The next version of Mulgara, 1.3, will ship in February and have this relational mapping in it. A quick Google search shows a lot of RDF-relational mappings going on, but the list of other mappings he had impressed me: Lucene, RSS, mbox, ID3."

"I think it's time I looked again at the world of RDF. They may yet be doing interesting things. I said as much to Andrae and he replied, "I am an engineer. In the early days it was scientists and logicians in RDF. Now the engineers have arrived, and we just want it to work and to scale." Bold claim! If you have a favourite RDF package or practice, let me know in the comments."

Andrae also announced the paper presented at linux.conf.au. Among other things it references David Wood's paper presented in 2004 "Scaling the Kowari Metastore" ("Makepeace" is a good search term).

I Object

A response to some points in, The perils of avoiding heresy (or "What are Design Patterns") and Visitor Pattern and Trees Considered Harmful.

""21 reasons C++ sucks; 1 embarassment; and an Abstract Syntax Tree"...So if the book is predominately a catalogue of unfortunately necessary kludges around the semantic weaknesses of mainstream OO-languages, why do I still highly recommend it to new programmers?"

Design patterns are not reliant on OO, Java, C++ or any particular language or programming paradigm. It's not even reliant on Computer Science. The source of design patterns comes from architecture (Christopher Alexander) and is used in diverse areas such as dating. Grady Booch's Handbook lists 1000s of patterns, so many reasons OO-languages suck.

"Singleton. This is a global variable."

So variables and objects are not the same thing - variables lack behaviour (amongst other things). The Singleton pattern as implemented by IoC containers like Spring, Yan, PicoContainer all use Singleton as configuration on a plain Java object - so again it's not necessarily a concept in code at all.

"In a language with first-class constructors, the Factory Method Pattern consists of factory = MyClass.constructor"

This just shows a misunderstanding of the the Factory pattern - its intention is to decouple object instantiation, especially at runtime. In languages that have first-class constructors, like Ruby, you still use the Factory pattern.

An interesting discussion, Factory and Singleton are false Design Patterns?.

So the old chestnut, the visitor. "The visitor pattern is kludge used by programmers in a language that doesn't support multiple-dispatch to provide themselves with a static version of double-dispatch."

This I agree with. But the rest seems simply a rant against OO.

So Wikipedia says, "...visitor design pattern is a way of separating an algorithm from an object structure. A practical result of this separation is the ability to add new operations to existing object structures without modifying those structures."

So there's no need for multiple if-then-elses or case statements which is what happened in Python as there is no switch statement.

The Visitor pattern is not the ultimate answer to writing a compiler. It's very straight-forward for small languages, simple languages, languages where you might find changing the code and the syntax independently, etc. Having written a C compiler using SableCC I have seen the issue of breaking encapsulation - in fact most compiler implementations I've seen tend to create global state of one sort or another anyway.

The main issue with compiler compilers that I tried before SableCC (which uses the Visitor pattern) is the combination of grammar and Java code. I have similar problems with PL/SQL, JSPs, etc. This combination is also detrimental to tools like debuggers, IDEs etc. (the work that goes into JSP support in IDEs is a good example of how hard it is).

I can't think of a successful combination of the two styles, declarative and imperitive. To me it seems to always end in very poor, unmaintainable code. And through the eyes of a lemming it's much poorer than sticking within the OO paradigm.

A better article is, Translators Should Use Tree Grammars. At the end of article the author writes, "...aspect-oriented specifications as long as we are thinking about putting actions outside of the grammar. Action execution is just an aspect and each phase would be an aspect." which seems very similar to the way things like transactions and context have been implemented in Spring. It might well be that combining AOP and OOP will provide a clean solution to writing compilers.

Northrop Grumman Killing Kowari?

Resignation from Kowari due to Northrop Grumman Letter "It is with sincere regret that I resigned as an administrator and developer of the Kowari Metastore."

"Northrop Grumman's position seems to be that they "purchased all rights associated with the Kowari software", a position not reconcilable with their continued release of the software under the Mozilla Public License, version 1.1."

So it would seem that Northrop, for whatever reason, dislikes Kowari's existence.

To get David and then Tucana (whose IP was eventually sold to Northrop) to start and continue with an open source version of TKS (the closed source version of the RDF database) was my little hobby horse (I fought fairly long and hard you could say). The idea was to get the Semantic Web bootstrapped and to create a value network around Semantic Web technology (I got this originally from "A critical look at object-orientation"). It is deeply disappointing for me to see it (the value network and Kowari) threatened in this way.

Like any OS project it is the ecosystem that is built around Kowari that makes it work. With so many contributions, just how much of the total code does Northrop actually own the copyright to? By accepting changes it isn't following the dual licencing model used by the owners of Berkley DB. To me Kowari was always using open source as a development and distribution model. Already, we have some contributors threatening to pull out their code (more at, "Disturbing News From Kowari").

Having administrators leave due to Northrop's actions is a good way to kill the project. Hopefully, Northrop's bullying will get a lot of interest - it's good to see, for instance, that this has been picked by aggregators like Topix's Aerospace and Defense.

The other posting David W linked to: Is Northrup Grumman Smushing Kowari?, "But I’d like to know what the status of Kowari is going to be, open source or not, because there are clients for whom Kowari might be the right choice, and we won’t bet on a dog that Northrup Grumman seems determined to publicly beat to death.

Relying on Kowari is now not prudent, given our obligation to do our best for our clients; but it’s also bad for Semantic Web uptake in the US federal government, and that’s something Northrup Grumman should think very carefully about."

Update: Paul and Andrae have also added their thoughts.

Update 2: David has published the letter from Northrop's lawyers. Danny posts, "...clearly if the current Kowari is MPL’d they can’t stop other developers working on the system."

New Kowari Soon

Kowari v1.1 Pre-release Feature Peek "The v1.1 release of Kowari will include the following features:

o The addition of Paul Gearon's Krule (pronounced "cruel") rules engine. Paul has fast and scalable RDFS support implementated (with the exception of XSD data typing) and is working on implementing more rules for an OWL subset.

o Rewriting of ConstraintExpressions and ModelExpressions to collapse Resolver-specific constraints that should be evaluated together into compound constraints (query rewriting) and permitting Resolvers to advise query engine of the evaluation order of constraints to ensure binding of required variables (query annotation). These features were added by Andrae Muys and Simon Raboczi and will form the basis for a cleaner query language syntax and cleaner integration of external Resolvers, such as GIS systems.

o The removal of Jena support. Kowari v1.0 implemented a Jena storage backend and included an RDQL query language API. This has caused difficulties in maintenance and support as the two projects have gone in different directions. Kowari will remove (not deprecate) support for Jena as of the v1.1 release.

o Support for compiling Kowari under Java 1.5. The Kowari team will be moving to Java version 1.5 as the canonical build version, replacing Java 1.4.2."

Via, Kowari v1.1 Pre-release Feature Peek.

Also, new MindSwap Kowari Library part of PhotoStuff.

More Working Notes

Andrae is out doing both Paul and I with two blogs: Etymon which has links to papers, interesting articles and the like and Circumlocute which is similar to Working notes.