Yesterday Paul Miller wrote a blog post called “Does Linked Data need RDF?” In the comments I said something in support of Paul’s question which I want to expand upon here. My comment was not directly related to the topic (linked data), but rather the format in which it was asked. Let me trim it down to this:
“Could we do ${solution} without ${component}?”
What I am thinking is this…. as system architects or software engineers this is a critical question to ask not only during design, but also as our solutions age over time. When asked this way it challenges us to think about dependencies from a different perspective. Instead of “are things working? If so, add new feature“, we should equally be looking for ways to remove, replace, or consolidate components for the benefits of efficiency, simplicity and performance. Sounds simple right, then why is it so hard to do?
I don’t think we go through this exercise often enough because politically it can be a very difficult. The sheer inertia of a large project can prevent people from even thinking about the question. The thing is that writing code, choosing a framework, establishing an API…. these are all sunk costs. We often attach emotional value to the time and effort that went into doing the work, and have a hard time imagining what things would look like without them.
It’s certainly a challenge, but to build better systems we need to be able to let things go, to scrap code, and to replace components without emotions or personal bias.
Oh and for the record, I do think RDF and Linked Data are the right combination to build the Web of Data. I just hope that we can keep asking questions, challenging assumptions, and continue to have constructive debates about the future of the Web like the one which took place yesterday on Paul’s website. Great stuff.
Had a great conversation with @cks earlier about the dichotomy between ORM and RDF/OWL when modeling enterprise data. His position was that with a pure ORM model you are more likely to have consistent data throughout your applications because the rules & constraints have laid out before the user ever touches the keyboard. Where he felt RDF/OWL was at odds with the ORM model is that by giving people the ability to create relationships that trigger additional inferences you must trust them to understand the implications of their actions.
A simple example….
:trees :madeOf :wood
:trees :need :water
Now someone comes along and creates this:
:table :madeOf :wood
At this point it’s incumbent upon all dependent applications to understand that “:table” does not in fact need water. Again, the key is that every application must be aware of and apply the same rules or data integrity suffers. It’s not that tradtional ORM and RDF/OWL can’t coexist, in some companies it may be an integrated process. Where @cks was concerned is that the inferences inherent to RDF/OWL introduces issues with consistency and integration because it’s so easy for new rules to simply pop up.
I agree with everything up to this point, but where I would argue we need to be headed with enterprise apps is a hybrid model that blends the consistency & predictability of ORM, with the freedom of RDF/OWL.
First let’s quickly take a moment to talk about freedom. When I hear a programmer use the phrase “never trust the user” I scratch my head. Sure you should sanitize application input for the sake of security but let’s be realistic about it, business users do not intentionally inject crap into the system. They use software to get things done. Humans will make mistakes, but so do the software applications that were written by… well, humans.
The user is the most important component of software development. If that sounds obvious, then why don’t we trust them more? My hope is that developers begin putting more trust in the user with a focus on creating software that learns from the users instead of limiting them.
So back to the hybrid model. I picture RDF/OWL as the essential meta layer above the ORM. By abstracting it with interfaces that are usable to non-techies it becomes an engine for collecting knowledge about the relationships and attributes of the business across all dimensions. We shouldn’t be concerned with modeling absolute and irrefutable truths, because tomorrow there will be an exception. That’s the problem with strict models in the enterprise, there will always be exceptions. Next, the ORM layer follows on as an application specific module where you can extract pieces of the meta layer to digest, analyze, and make use of the data at a domain level.
It’s about putting a higher priority on the collection of information than on enforcing rules on the information. The principle reminds me of the great quote from Jon Postel.
“be conservative in what you send, be liberal in what you receive”
Postel is of course referring to the Transmission Control Protocol, a language that computers use to speak to each other over the internet. To me however these words have a more universal meaning in the world of software development which I’d categorize like this:
