Blockchain and Byzantium

Establishing authenticity - "single sources of truth" is a really important concept in the real world and in the world of computing.  From title deeds, to contracts, to laws and currencies, we have evolved ways of establishing single sources of truth over many centuries of trial and error.

Knowingly or not, many of the ways of solving the problem rely on the properties of physical objects: clay tablets (Code of Hammurabi), Bronze Plates (The Twelve Tables of Rome), Goat Skin (Celtic Brehon Laws). Typically, this physicality is mixed in with a bit of trust. Trust in institutions. Trust in tamper evidence. Trust in probabilities.

Taken together: the physical scheme aspect, plus the trust aspect, allows the establishment of consensus. It is consensus, at the end of the day, that makes all this stuff work in the world of human affairs. Simply put, if enough of us behave as though X is the authentic deed/deposition/derogation/dollar then X is, ipso facto, for all practical purposes, the real deal.

In the world of digital data, consensus is really tricky because trust becomes really tricky. Take away the physicality of objects and establishing trust in the truth/authenticity of digital objects is hard.

Some folk say that blockchain is slow and inefficient and they are right - if you are comparing it to today's consensus as to what a "database" is.

Blockchain is the way it is because it is trying to solve the trust problem. A big part of that is what is called Byzantine Consensus. Basically how to establish consensus when all sorts of things can go wrong, ranging from honest errors to sabotage attempts.

The problem is hard and also very interesting and important in my opinion. Unfortunately today, many folks see the word "database" associated with blockchain and all they see is the incredible inefficiency and cost per "transaction" compared to, say, a relational database with ACID properties.

Yes, blockchain is a truly dreadful "database" - if your metric for evaluation is the same as the use cases for relational databases.

Blockchain is not designed to be one of those. Blockchain is the way it is because byzantine consensus is hard. Is it perfect? Of course not but a proper evaluation of it requires looking at the problems it is trying to solve. Doing so, requires getting past common associations most people carry around in their heads about what a "database" is and how it should behave/perform.

Given the unfortunate fact that the word "database" has become somewhat synonymous with the term "relational database", I find it amusing that Blockchain has itself become a byzantine consensus problem. Namely, establishing consensus about what words like  "database" and "transaction" and "trust" really mean.

What is Law? - part 14

Previously: What is Law? - part 12a

Mention has been made earlier in this series to the presence of ambiguity in the corpus of law and the profound implications that the presence of ambiguity has on how we need to conceptualize computational law, in my opinion.

In this post, I would like to expand a little on the sources of ambiguity in law. Starting with the linguistic aspects but then moving into law as a process and an activity that plays out over time, as opposed to being a static knowledge object.

In my opinion, ambiguity is intrinsic in any linguistic formalism that is expressive enough to model the complexity of the real world. Since law is attempting to model the complexity of the real world, the ambiguity present in the model is necessary and intrinsic in my opinion. The linguistic nature of law is not something that can be pre-processed away with NLP tools, to yield a mathematically-based corpus of facts and associated inference rules.

An illustrative example of this can be found in the simple sounding concept of legal definitions. In language, definitions are often hermeneutic circles[1] which are formed whenever we define a word/phrase in terms of other words/phrases. These are themselves defined in terms of yet more words/phrases, in a way that creates definitional loops.

For example, imagine a word A that is defined in terms of words B, and C. We then proceed to define both B and C to try to bottom out the definition of A. However, umpteen levels of further definition later, we create a definition which itself depends on A – the very thing we are trying to define - thus creating a definitional loop. These definitional loops are known as hermeneutic circles[1].

Traditional computer science computational methods hate hermeneutic circles. A large part of computing consists of creating a model of data that "bottoms out" to simple data types. I.e. we take the concept of customer and boil it down into a set of strings, dates and numbers. We do not define a customer in terms of some other high level concept such as Person which might, in turn, be defined as a type of customer. To make a model that classical computer science can work on, we need a model that "bottoms out" and is not self-referential in the way hermeneutic circles are.

Another way to think about the definition problem is in term of Saussure's linguistics[2] in which language (or more generically "signs") get their meaning because of how they differ from other signs - not because they "bottom out" into simpler concepts.

Yet another way to think about the definition problem is in terms of what is known as the descriptivist theory of names[3] in which nouns can be though of as just arbitrary short codes for potentially open-ended sets of things which are defined by their descriptions. I.e. a "customer" could be defined as the set of all objects that (a) buy products from us, (b) have addresses we can send invoices to, (c) have given us their VAT number.

The same hermeneutic circle/Sauserrian issue arises here however as we try to take the elements of this description and bottom out the nouns they depend on (e.g., in the above example, "products", "addresses", "invoices" etc.).

For extra fun, we can construct a definition that is inherently paradoxical and sit back as our brains melt out of our ears trying to complete a workable definition. Here is a famous example:

The 'barber' in town X is defined as the person in town X who cuts the hair of anyone in town who do not choose to cut their own hair.

This sounds like a reasonable starting point for a definition of a 'barber', right? Everything is fine until we think about who cuts the barber's hair[4].

The hard facts of the matter are that the real world is full of things we want to make legal statements about but that we cannot formally define, even though we have strong intuitions about what they are. What is a "barber"? What is the color "red"? Is tomato ketchup a vegetable[5]? What is "duty"? What is "ownership"? etc. etc. We all carry around intuitions about these things in our heads, yet we struggle mightily to define them. Even when we can find a route to "bottom out" a definition, the results often seem contrived and inflexible. For example we could define "red" as 620–750 nm on the visible spectrum but are we really ok with 619nm or 751nm being "not red"?

Many examples of computing blips and snafus in the real world can be traced to the tendency of classical computing to put inflexible boundaries around things in order to model them. What does it mean for a fly-by-wire aircraft to be "at low altitude"? What does it mean for an asset to be trading at "fair market value"? The more we attempt to bottom these concepts out into hard numeric ranges - things classical computing can easily work with - the more we risk breaking our own intuitions with the real world versions of these concepts.

If this is all suggesting to you that computational law sounds more like a problem that requires real numbers (continuous variables) and statistical calculations as opposed to natural numbers and linear algebraic calculations, I think that is spot on.

I particularly like the concept of law as a continuous, analog process as it allows a key concept in law to be modeled more readily - namely the impact of the passage of time.

We have touched on the temporal aspects already but here I would like to talk a little about how the temporal aspects impact the ambiguity in the corpus.

As time passes, the process of law will itself change the law. One of the common types of change is a gradual reduction in levels of ambiguity in the corpus. Consider a new law which needs to define a concept. Here is how the process plays out, in summary form.

• A definition is created in natural language. Everybody involves in the drafting knows full well that definitions cannot be fully self-contained and that ambiguity is inevitable. In the interests of being able to actually pass a law before the heat death of the universe, a starter definition is adopted in the law.
• As the new law finds its way into effect, regulations, professional guidance notes etc. are created that refine the definition.
• As the new law/regulations/professional guidance impacts the real world, litigation events may happen which result in the definition being scrutinized. From this scrutiny, new caselaw is produced which further refines the definition, reducing but never completely removing, the amount of ambiguity associated with the defintion.

A closely related process - and a major source of pragmatic, pre-meditated ambiguity in the process of law - is contracts. While drafting a contract, the teams of lawyers on both sides of the contract know that ambiguity is inevitable. It is simply not possible, for all the reasons mentioned above, to bottom out all the ambiguities.

The ambiguity that necessarily will remain in the signed contract is therefore used as a negotiating/bargaining item as the contract is being worked. Sometimes, ambiguity present in a draft contract gives you a contractual advantage so you seek to keep it. Other times, it creates a disadvantage so you seek to have it removed during contract negotiations. Yet other times, the competing teams of lawyers working on a contract with an ambiguity might know full well that it might cause difficulties down the road for both sides. However it might cost so much time and money to reduce the ambiguity now that both sides let it slide and hope it never becomes contentious post contract.

So to summarize, ambiguity in law is present for two main reasons. Firstly there is ambiguity present that is inevitable because of what law is trying to model - i.e. the real world. Secondly, there is ambiguity present that is tactical as lawyers seek to manipulate ambiguities so as to favor their clients.

Next up: Part 15

[1] https://en.wikipedia.org/wiki/Hermeneutic_circle

[2] https://en.wikipedia.org/wiki/Ferdinand_de_Saussure

[3] https://en.wikipedia.org/wiki/Descriptivist_theory_of_names

[4] https://en.wikipedia.org/wiki/Barber_paradox

[5] https://en.wikipedia.org/wiki/Ketchup_as_a_vegetable

What is law - part 12a

Previously: what is law part 12

Perhaps the biggest form of push-back I get from fellow IT people with respect to the world of law relates to the appealing-but-incorrect notion that in the text of the law, there lies a data model and a set of procedural rules for operating on that data model, hidden inside the language.

The only thing stopping us computerizing the law, according to this line of reasoning, is that we just need to get past all the historical baggage of foggy language and extract out the procedural rules (if-this-then-that) and the data model (definition of a motor controlled vehicle, definition of 'theft', etc.). All we need to do is leverage all our computer science knowledge with respect to programming languages and data modelling, combine it with some NLP (natural language processing) so that we can map the legacy linguistic form of law into our shiny new digital model of law.

In previous parts in this series I have presented a variety of technical arguments as to why this is not correct in my opinion. Here I would like to add some more but this time from a more sociological perspective.

The whole point of law, at the end of the day, is to allow society to regulate its own behavior, for the greater good of that society. Humans are not made from diamonds cut at right angles. Neither are the societal structures we make for ourselves, the cities we build, the political systems we create etc. The world and the societal structures we have created on top of it are messy, complex and ineffable. Should we be surprised that the world of law which attempts to model this, is itself, messy, complex and ineffable?

We could all live in cities where all the houses are the same and all the roads are the same and everything is at right angles and fully logical. We could speak perfectly structured languages where all sentences obey a simple set of structural rules. We could all eat the same stuff. Wear the same clothes. Believe in the same stuff...but we do not. We choose not to. We like messy and complex. It suits us. It reflects us.

In any form of digital model, we are seeking the ability to model the important stuff. We need to simplify - that is the purpose of a model after all - but we need to preserve the essence of the thing modeled. In my opinion, a lot of the messy stuff in law is there because law tries to model a messy world. Without the messy stuff, I don't see how a digital model of law can preserve the essence of what law actually is. The only outcome I can imagine from such an endeavor (in the classic formulation of data model + human readable rules) is a model that fails to model the real world.

In my opinion, this is exactly what happened in the Eighties when people got excited about how Expert Systems[1] could be applied to law. In a nutshell, it was discovered that the modelling activity lost so much of the essence of law, that the resultant digital systems were quite limited in practice.

Today, as interest in Artificial Intelligence grows again, I see evidence that the lessons learned back in the Eighties are not being taken into account. Today we have XML and Cloud Computing and better NLP algorithms and these, so the story goes, will fix the problems we had in the Eighties.

I do not believe this is the case. What we do have today, that did not exist in the Eighties, is much much better algorithms for training machines - not programming them  to act intelligently - training them to act intelligently. When I studied AI in the Eighties, we spent about a week on Neural Networks and the rest of the year on expert systems i.e. rules-based approaches. Today's AI courses are the other way around!

Rightly so, in my opinion because there has not been any great breakthrough in the expert systems/business rules space since the Eighties. We tried all the rules-based approaches in the Eighties. A lot of great computer science minds worked on it. It came up short in the real world of law.

When you combine the significant advances in Neural Network approaches with all the compute advantages of cloud and the ready availability of lots and lots of digital data, things get interesting again. This is where we are today. And it is very interesting indeed.

I numbered this blog post "12a", for a reason that is hopefully both humorous and relevant. I know of both legal texts and legal business processes that avoid the number 13. I know of a legal text with so many sub-paragraphs that the number 666 was needed, and 665a was used instead. This kind of thing drives rules-based computing mad but is exactly the kind of human footprint that is literally all over the world of law.

The human touch can be seen in all its splendor in the area of legal fictions[2]. Everything from life insurance claims to resigning from office uses forms of logic that are very foreign to the world of classic computing concepts of rules and data models.

Yet there the are... in all their messy, complex, splendidly human glory. Spend a few moments with the Chiltern Hundreds. It is worth your time [3]. Spend some time thinking about how we humans can both navigate ambiguity when we have to, or when it suits us, and - when it suits us - create new ambiguity. Then read about contra proferentem[4].

Now we can refuse to believe the messy ambiguity and complexity is intrinsic and spend our time trying to remove it with computers - as we did in the Eighties. Or we can take a deep breath, dive in and embrace it.

I recommend the latter. Next up: What is Law? - Part 14.

[1] https://en.wikipedia.org/wiki/Expert_system
[2] https://en.wikipedia.org/wiki/Legal_fiction

[3] https://en.wikipedia.org/wiki/Chiltern_Hundreds

[4] https://en.wikipedia.org/wiki/Contra_proferentem

The Great Inversion in Computing

Methinks we may be witnessing a complete inversion in the computing paradigm that has dominated the world since the Sixties.

In 1968, with Algol68[1] we started treating algorithms as forms of language. Chomsky's famous hierarchy of languages[2] found a huge new audience outside of pure linguistics.

In 1970, relational algebra came along[3] and we started treating data structures as mathematical objects with formal properties and theorems and proofs etc. Set theory/operator theory found a huge new audience outside of pure mathematics.

In 1976, Nicklaus Wirth published "Algorithms + Data Structures =  Programs"[4] crisply asserting that programming is a combination of algorithms and data structures.

The most dominant paradigm since the Sixties maps algorithms to linguistics (Python, Java etc.) and data structures to relational algebra (relational  databases, third normal form etc.).

Todays Deep Learning/AI etc. seems to me to be inverting this mapping. Algorithms are becoming mathematics and data is becoming linguistic e.g. "unstructured" text/documents/images/video etc.

Perhaps we are seeing a move towards "Algorithms (mathematics) + data structures (language) = Programs" and away from "Algorithms (language) + data structures (mathematics) = Programs"

[1] https://en.wikipedia.org/wiki/ALGOL_68
[2] https://en.wikipedia.org/wiki/Chomsky_hierarchy
[3] https://en.wikipedia.org/wiki/Relational_algebra
[4] https://en.wikipedia.org/wiki/Algorithms_%2B_Data_Structures_%3D_Programs

What is law? - part 12

Previously : what is law? - part 11

There are a few odds and ends that I would like to bundle up before proceeding. These are items that have occurred to me since I wrote the first What is Law? post back in March. Items I would have written about earlier in this series, if they had occurred to me. Since I am writing this series as I go, this sort of thing is inevitable I guess. Perhaps if I revisit the material to turn it into an essay at some point, I will fold this new material in at the appropriate places.

Firstly, in the discussion about the complexity of the amendatory cycle in legislation I neglected to mention that it is also possible for a new item of primary legislation to contain amendments to itself. In other words it may be that as soon as a bill becomes and act and is in force, it is immediately necessary to modify it using modifications spelled out in the act itself. Looking at it another way, a single Act can be both a container for new law and a container for amendatory instructions, all in one legal artifact. Why does this happen? Legislation can be crafted over long periods of time and consensus building may proceed piece by piece. In a large piece of legislation, rather than continually amending the whole thing – perhaps thousands of pages – sometimes amendments are treated as additional material tacked on the end so as to avoid re-opening debate – and editorial work - on material already processed through the legislative process. It is a bit of a mind bender. Basically if an Act becomes law at time T then it may instantaneously need to be codified in itself before we can proceed to codify it into the broader corpus.

Secondly, I mentioned that there is no central authority that controls the production of law. This complicates matters for sure but it also has some significant benefits that I would like to touch on briefly as the benefits are significant. Perhaps the biggest benefit of the de-centralized nature of law making is that it does not have a single point of failure. In this respect, it is reminiscent of the distributed packet routing protocol used on the internet. Various parts of the whole system are autonomic resulting in an overall system that is very resilient as there is no easy way to interrupt the entire process.

This distribution-based resilience also extends into the semantic realm where it combine with the textual nature of law to yield a system that is resilient to the presence of errors. Mistakes happen. For example, a law might be passed that requires train passengers to be packaged in wooden crates. (Yes, this happened.). Two laws might be passed in parallel that contradict each other (yes, this has happened many times.) When this sort of thing happens, the law has a way of rectifying itself, leveraging the “common sense” you can get with human decision making. Humans can make logical errors but they have a wonderful ability to process contradictory information in order to fix up inconsistent logic. Also humans possess an inherent, individual interpretation of equity/fairness/justice and the system of law incorporates that, allowing all participants to evaluate the same material in different ways.

Thirdly, I would like to return briefly to the main distinction I see between legal deductive logic and the deductive logic computer science people are more familiar with. When deductive logic is being used (remembering always that it is just one form of legal reasoning and rarely used on its own) in law, the classic “if this then that” form can be identified as well as classical syllogistic logic. However, legal reasoning involves weighing up the various applicable deductive statements using the same sort of dialectic/debate-centric reasoning mentioned earlier. Put another way, deductive logic in law very rarely proceeds from facts to conclusion in some nice tidy decision tree. Given the set of relevant facts (which have themselves to be argued as “the relevant facts”) there may well be multiple applicable deductive logic forms in the corpus of law which, depending on which ones are used and the order they are used, will result in different conclusions.

Again, this is where the real skills of a lawyer manifest. The possible routes through the law at Time T, that can be applied to a set of relevant facts F, is often vast and grows exponentially with the complexity of the facts being considered. Lawyers develop the ability to “prune” the routes down to something manageable in the same way that, say, chess grand masters, prune the set of options in any chess game situation.

This is perhaps the biggest "oops" moment I have seen when IT people first see the “rules” expressed in legal language. They see stuff that looks like it can be turned into classical logic e.g. indicative mood statements and then proceed to the non sequitur that it can be re-expressed in classical mathematical logic forms. What computer science people tend not to see at first is the rhetorical structure that sits underneath the indicative statements. I don't think it is overstating the case to say that every legal question is essentially a debate. You can analyse the corpus to find in favour of any given proposition or against any given proposition. Each line of reasoning can feature chunks of good old fashioned mathematical logic but the final conclusions do not come from the decision trees, they come from the fuzzier process of weighing up the logic on every side of the debate, in order to arrive at a best – but necessarily tentative – answer. As Immanual Kant said, there are no rules for the application of rules.

Nick Szabo (the man who coined the term “smart contracts” which we will be turning to soon), uses the terms “wet code” and “dry code” to describe the difference between legal reasoning and classical computer reasoning. Dry code is the stuff with low representational complexity we can convert into classical computer software. There is some of that in law for sure, but a lot less than you might think. Most of it is “wet code” because of the open textured nature of the text of the law, the unbounded opinion requirement, the extensive use of analogical reasoning and the dialectic nature of the deductive logic in law.

Next: What is law? - part 12a

[1] http://unenumerated.blogspot.ie/2006/11/wet-code-and-dry.html

What is law? - part 11

Previously: what is law? - part 10

Gliding gracefully over all the challenges alluded to earlier with respect to extracting the text level meaning out of the corpus of Law at time T, we now turn to thinking about how it is actually interpreted and utilized by practitioners. To do that, we will continue with our useful invention of an infinitely patient person who has somehow found all of the primary corpus and read it all from the master sources, internalized it, and can now answer our questions about it and feed it back to us on demand.

The first order of business is where to start reading? There are two immediate issues here. Firstly, the corpus is not chronologically accretive. That is, there is no "start date" to the corpus we can work from, even if, in terms of historical events, a foundation date for a state can be identified. The reasons for this have already been discussed. Laws get modified. Laws get repealed. Caselaw gets added. Caselaw gets repealed. New laws get added. I think of it like a vast stormy ocean, constantly ebbing and flowing, constantly adding new content (rainfall, rivers) and constantly loosing content (evaporation) - in an endless cycle. It has no "start point" per se.

In the absence of an obvious start point, some of you may be thinking "the index", which brings us to the second issue. There is no index! There is no master taxonomy that classifies everything into a nice tidy hierarchy. There are some excellent indexes/taxonomies in the secondary corpus produced by legal publishers, but not in the primary corpus.

Why so? Well, if you remember back to the Unbounded Opinion Requirement mentioned previously, creating an index/taxonomy is, necessarily, the creation of an opinion on the "about-ness" of a text in the corpus. This is something the corpus of law stays really quite vague about - on purpose - in order to leave room for interpretation of the circumstances and facts about any individual legal question. Just because a law was originally passed to do with electricity usage in phone lines, does not mean it is not applicable to computer hacking legislation. Just because a law was passed relating to manufacturing processes does not mean it has no relevance to ripening bananas. (Two examples based on real world situations, I have come across by the way.)

So, we have a vast, constantly changing, constantly growing corpus. So big it is literally humanly impossible to read, regardless of the size of your legal team, and there are no finding aids in the primary corpus to help us navigate our way through it....

...Well actually, there is one and it is an incredibly powerful finding aid. The corpus of legal materials is woven together by an amazingly intricate web of citations. Laws invariably cite other laws. Regulations cite laws. Regulations cite regulations. Caselaw cites law and regulations and other caselaw....creating a layer that computer people would call a network graph[1]. Understanding the network graph is key to understanding how practitioners navigate the corpus of law. The don't go page-by-page, or date-by-date, they go citation-by-citation.

The usefulness of this citation network in law cannot be overstated. The citation network helps practitioners to find related materials, acting as a human-generated recommender algorithm for practitioners. The citation networks not only establish related-ness, they also establish meaning, especially in the caselaw corpus. We talked earlier about the open-textured nature of the legal corpus. It is not big on black an white definitions of things. Everything related to meaning is fluid on purpose. The closest thing in law to true meaning is arguably established in the caselaw. In a sense, the caselaw is the only source of information on meaning that really matters because at the end of the day, it does not matter what you or I or anyone else might think a part of the corpus means. What really matters is what the courts say it means. Caselaw is the place you go to find that out.

"But", I hear you say, "graphs do not necessarily have a start point either!". True. But this is where one of the real skills of a lawyer manifests itself. Legal reasoning, is, for the most part (UK/US style), reasoning by analogy. For any given case, a lawyer looks to take the facts, the desired outcome and then seek to make an analogy with a previously adjudicated case so that if the analogy holds up, the desired outcome is achieved by virtue of the over-arching desire of the legal ecosystem to maintain consistency with previous decisions. There is perhaps no other field where formulating the right question is as important as it is in law.

Having constructed an analogy, initial entry points into the corpus of law can be identified and from there, the citation network works it magic to route you through the bottomless seas of content, to the most relevant stuff. The term "most relevant" here is oftentimes signaled by the presence of lots of in-bound citations. I.e. in caselaw, if your analogy brings you to case X and case X has been cited by lots of other cases with the outcome you are looking to achieve, and if case X is still good law (has not been repealed), then case X is a good one to cite in your legal argument.

If this leveraging of the citation network link topology reminds you of Google's original page rank algorithm then you are on the right track. Lawyers, perhaps to the surprise of computer science and math folk, have been leveraging the properties of scale free network graphs[2] for centuries[3].

I said "legal argument" above and this is another critical point in understanding what law actually is and how it works...The corpus of law is not a place you go to find black and white answers to black and white questions. Rather, it is a place you go with an analogy you have formed in order to find arguments for and against your desired outcome from that analogy. It is a form of rhetoric. A form of debate. It is not a form of formulaic application of crisp rules that generate crisp answers.

In short. It is not mathematics in the sense that many computer science folks might initially assume when they hear of talk of "rules" and "decisions" and so on. However it arguably is mathematics in some other ways. Leveraging the citation graph is a very mathematical thing. Weighing up the pros and cons of legal argument strategies often exhibits properties familiar from optimization problems and game theory.

It is in these latter senses of "mathematical" that most of the recent surge in interest in computational law have arisen. In particular, machine learning and neural network-centric approaches to artificial intelligence are re-igniting interest in computational law after an overall disappointing outcome in the Eighties. Back then, rule-centric approaches prevailed and although there have been some noticeable successes in areas such as income tax calculation, rules-based approaches have largely run out of steam in my opinion.

The citation network - and in particular - how the citation network changed over time, is, in my opinion, the key to unlocking computational law. I do not think it is stretching things to state that the citation network is the underlying DNA that holds the world of law together. Rather that seek to replace this DNA - in all its magnificent power and complexity - with nice tidy lego-bricks of conditional logic and data objects, we need to embrace it. Of course it has its flaws. Nothing is perfect. But it is the way it is, for the most part, for good reasons. We will make progress in computational law faster if more computing folk understand the world of law for what it is - as opposed to what they might initially think it is at a high level, or perhaps wish it to be.

I hope this series of blog posts has helped in some small way, to show what it really is. At least, from my perspective which of course, is just one persons opinion. As we have seen in this series of posts on law - "opinion" is as good as it gets in law. Again, finally, this not a bug. It is a feature...In my opinion:-)

Next: what is law? - part 12

[1] https://en.wikipedia.org/wiki/Graph_theory

[2] https://en.wikipedia.org/wiki/Citator#History

[3] http://mathinsight.org/scale_free_network

Zen and the art of motorcycle....manuals

I heard the sad news about Robert Pirsig passing.

His book : Zen and the art of motorcycle maintenance was a big influence on me and piqued my interest in philosophy.

While writing the book his day job was writing computer manuals.

About 15 years ago, I wrote an article for ITWorld about data modelling with XML called Zen and the art of motorcycle manuals, inspired in part by Pirsig's book and his meditations on how the qualities in objects such as motorcycles are more than just the sum of the parts that make up the motorcycle.

So it is with data modelling. For any given modelling problem there are many ways to do it that are all "correct" at some level. Endlessly seeking to bottom out the search and find the "correct" model is a pointless exercise. At the end of the day "correctness" for any data model is not  a function of the data itself. It is a function of what you are planning to do with the data.

This makes some folks uncomfortable. Especially proponents of top-down software development methodologies who like to conceptualize analysis as an activity that starts and ends before any prototyping/coding begins.

Maybe somewhere out there Robert Pirsig is talking with Bill Kent - author of another big influence on my thinking : Data and Reality.

Maybe they are discussing how best to model a bishop :-)