Hot Laundry

New Technology Fetish

I am suddenly struck by the concept of Trigeneration:  Power, heat, and cold from a single plant!

Current Open Source Infotech Favs (math, semweb, AI, java)

Some current favorite technologies are listed below.  Please send me 10 netbooks optimized to sweetly
sing this software stack, and I will send you $10 each plus the cost of the netbooks. 

And hey, if you make it all work under Linux on JDK 1.6 you get $11 each.  That's my opening bid!

Open Source Java unless otherwise noted:

1. Jena - teh awesome.  Really, people.  Call off the grubvython imperative wankfest and use teh RDF. 
   I'm sorry, I just don't know how to be nice about this anymore.  (Ahem, this is called joking). 
   Everyone not using RDF is just farting code methane, for RDF is the kangaroo of information
   technologies!  (Except for yer regular high volume ordered collections, e.g. large dense matrices as
   opposed to sparse ones, which you are welcome to still keep in SQL / CSV.  After all, I'm not crazy,
   right?).  For storage we use Jena's SDB, (with MySQL or other), our own simple Peruser Quad layer,
   and lots of files in Turtle and RDF/XML.  We are looking for a chance to catch up with the Mulgara
   native RDF store project, after some positive experience with Kowari many years back.
2. Protege ontology editor - have I mentioned this tool before?  Oh, I have a few times here and there? 
   Alright, then.  'Nuff said.  If you like the Eclipse GUI plugin approach, then use commercial TopBraid
   instead; it's powerful.
3. Scala -  Need scalable computation?    Oh, you do!   Well, then use this deeply integrated functional
   extension to java.  Everything you love about Java and the JVM, plus:
   
   1. Function literals, closures, currying, and partially applied functions.
   2. Strong typing enforced at compile time, but types are inferred by compiler whenever possible,
      (thus sparing us the turgid Java syntax used to instantiate generics, e.g. List<Thing> x = new ArrayList<Thing>();)
   3. Powerful "match" keyword matches on both type and value, somewhat similar to a Horn clause.
   4. Keywords identify variables+fields as mutable or immutable.
   5. Multiple (implementation) inheritance via traits.
   6. All scopes (package, class, function) are completely nestable and flexible.
   7. Singletons are represented cleanly, other static methods become explicit functions.
   8. XML is directly embeddable in program code (thus turning the tables on the JSP monstrosity)
   9. Concurrent actors provide message based threading at language level
   Works well under Netbeans and deploys cleanly inside regular JVM - no additional runtime config! 
   So, it has the same (low) impact as using a java jar, but you're programming in a higher level
   language.  Odersky, Spoon, Venners Programming in Scala is a groovin introduction, focusing
   on practical use and leaving theory mostly implied.
4. JBOSS Drools 5 - expert system impl. with forward chaining RETE algorithm for java-centric BPI. 
   We really prefer RDF inference (Jena, Pellet, etc.) but for object diehards in soft-realtime ping-pong
   decision environments, the Drools is next best.  Warning:  documentation of the DRL rule language
   itself is gappy.  One must experiment to learn the ropes.    I hope to contribute to those docs at
   some point.  Tangentially related:  We are evaluating J-ActR for some upcoming work.
5. JScience and Javolution - Snazzy approach to firmly grounded full performance computation for
   realtime and scientific computing in Java + native code where needed.  The Polynomial  (combined
   with Apache Commons Math optimizer, because ojalgo is incomplete) and Struct + Union classes
   (Java class == C struct!) are my favs.
6. R (native code) - statistical computing suite - one of very few non-Java tools that we embrace. 
   Open source, of  course.  GNU Octave (native code) is free Matlab-esque tool, otherwise in the
   same category as R but with smaller community, AFAIK, and we use it less than we use R. 
   Our big design choice these days is often a variation on "bridge to R/Octave or push forward with
   the java math approach in #5 above?").   Some java math/simulation environments like Repast,
   MASON, NetLogo, JMathLib offer bridges to R or Octave.   
7. Flex 3 - Our WebGUI tool of choice for the last 18 months or so. We code MXML + actionscript
   directly, without Flex Builder.  Has replaced OpenLaszlo for us, but we still give props to those
   dudes.  The JavaFX thing just hasn't grabbed me yet.    Should it?   But hey, if you really want to
   get all crazy with the signal-processing video animation, then you can use Processing!
8. Pentaho Data Integration (kettle, pan, kitchen) - sweet data integration design/coding/execution
   tool.  Part of the comprehensive Pentaho open source BI stack:  Mondrian OLAP, data mining, 
   Weka machine learning integration.
9. Saxonica - XSLT 2.0 implementation, running nicely under both Pentaho and Cocoon.
10. Cocoon - Still in use for most of our production web pipelines.  Now Spring based, yippee!  We would
    like to help move towards compliance with XProc XML Pipeline spec.
11. eXist - Still our favorite XQuery database, still integrates nicely with Cocoon.  Shazam!  Would like to
    play with MonetDB and Sedna (both native code XQuery impls) sometime, probably when we are
    stranded on a island of Java haters, perhaps as part of a TV show.
12. Metro - Web Services stack.  We use it inside Tomcat, and it is part of Glassfish, which is nifty
    enough, along with OpenESB.   Apache Axis is still fine, too, and interoperates reasonably well with Metro.
13. XStream - flexible serialization of Java to/from XML.
14. Netbeans 6 -  first Java IDE I've ever liked.  For me it's much better than Eclipse.  Nice integration
    with JavaDB (i.e. Apache Derby) and Glassfish .
15. MySQL desktop tools - (native code) the Query Browser is pretty darn awesome.
16. Stylus Studio - The only commercially licensed tool I still use (butcept windoze), because I got a free
    promotional license through XML Austin.  Half the time I just use JEdit or vim for XML, anyway.  I am
    just not an emacs guy.  Deal with it!
17. Cygwin, PuTTY, OpenOffice, Firefox, Thunderbird, (all native code) a few open security tools,

...and of course our own Peruser stack.   Finally, Virtuoso, Prova, and OpenCyc are all still close to my
heart, but sadly haven't been in the mix lately.  Would like to play with sometime.

There you have it.  Everything runs great on a commodity $600 windoze laptop (hint:  We need 2G of
high speed RAM before we even consider the CPU specs), or on a linux server (except the GUIs, natch),
with zero additional cost and zero proprietary code (except the Stylus Studio in #15, which is an Editor/IDE,
and not part of the deployed runtime).

Finally, since I am in the mood to list my favorite everything, and at the risk of an unnecessarily brutal
frankness, I feel I should also say that Achewood, Wonkette, The Poor Man, and Sadly No, are all simply
grand, just grand.  And lo, here's a promising new comedy blog, Indigulous.  We like the cut of its jib!

What the heck, people?

It seems that for a while there, I temporarily stopped producing the hormone that causes one to write
things on the interwebs. Since this here Hot Laundry is supposed to be my professional blog, I feel
remiss in my duties towards my collegial colleagues in not recounting my recent exploits.  Hence
the following uncharacteristically short post:

In the past two years, I have spent huge gobs of time on two semantic system client projects, which
are both very worthwhile and exciting, but have unfortunately been competing for the time of everyone
on my team.  Thankfully both have now entered major QA/release processes, meaning that our
millibars are reducing just a wee bit going into the fall.  Enough for me to write this post, anyway.
Hooray!

As for why I seemed to fall down a hole:  We had a significant setback in spring 2008 involving adding a
big new customer at the same time that a promising new employee chose to leave us.   Together these
events, both for the best in the long term, made our deadline pressure for the last year unusually
intense.  So, it seems the year has left me a bit grayer, but with a lot of good work done.  Now I
am starting to mellow out and smell the flowers in Montana, where I've come for the summer. 
Happy Times!  Mountain hikes and  bikes, splashing in rivers and lakes, digging the views and (once
a week) pioneer western style nightlife  (drinkin', cussin', and scrappin'), workin' on that "core strength"
deal, with attention my posture is improving a bit, and I am feeling a sense of balance, adjustment and
belonging that I suppose comes with an iota of  maturity.   In other joyful news, I fixed up a free bike the
other day and rode it home from this place:

Missoula Freecycles   It's an actual open bike shop, not the general local freecycling thing, which is also
very groovy of course.   Bicycling engineers will love this place : a huge greasy cache of free bike parts,
organized by type, with tools and stands to work on the bikes.   In addition to the parts are bikes and
sub-bikes, in every state of repair.   Bikes that are mostly already working are available for loan with a
requested donation of $5 per week.  I did that in June, and last week I went back hoping to do the
same.   Well, no dice, but I found a "junk" mountain bike in my size, which is spray painted matte red,
yellow, and green (including the rims and tires) and looks like it's been to Burning Man say 3 or 4 times.  
Decent components, good (colorful!) tires, missing tube on front tire, back wheel out of true, chain
is dry.  That's it.  30 minutes of work and the bike is ridable.  15 minutes more and it's starting to be
a nice bike.  Boom!  I donated $20 in the can (noone asked or even noticed that I did this - all honor
system DIY) and rode it home.   5 days later, the tires are still both holding air.  Shifters work and
brakes are OK.   Pow!

My new favorite band?  Zeppo!

Went to the big ti...I mean, the Grands Tetons mountains a few weeks back.  Glorioso!

Other than that, it's 10 hrs a day working still, for now.  Robots, education, finance, and consumer
decision support [sooper seekrit!].  

I will probably be in Texas in October or so, not sure for how long.  Drop me a line if you want to connect
and compare notes.

Alrighty then.  We are caught up.  Whata Ta, my dilly daimies !

Peruser 2.1.1 released!

A few weeks back we quietly released the first snapshot of the current generation of the Peruser framework.

There's still lots of work to be done, but it's coming along nicely.  It is quite usable today for basic SPARQL queries under Cocoon.  To set up more complex queries (including dumps of taxonomy trees, using the Projector module), you will have to wade through some incomplete documentation and probably look at the code.

During development of this code over the last few years, one of the things we discovered mid-stream is the potency of the Jena Assembler framework.   We have been weighing the costs and benefits of dumping some Peruser configuration features in favor of using this framework. 

We are also trying to generate some public discussion of the best way to structure the relationship
between Assembler (and other RDF) artifacts and Cocoon artifacts in this new discussion group,
which y'all are invited to join: Cocoon as a Semantic Platform

Well, the Daisy CMS and eXist XQuery DB *are* both coccon apps...

In a post entitled "Column Stores". Bruno Dumon considers switching database platforms for the
cocoon-based Daisy CMS repository (which we have used for several years now at scrutable).
http://brunodumon.wordpress.com/2007/10/07/column-stores/

He mentions some different XQuery offerings such as MonetDB (which looks cool), and there are
several comments from Bruno's readers suggesting other XQuery implementations.
But, regardless of how great MonetDB or Sedna or other open source XQuery implementations
are, I'm pretty sure they're not integrated with cocoon out of the box.
As someone who uses Daisy, cocoon, and eXist, it seems to me that the best Daisy repository
forward migration is onto the (somewhat unfortunately named, google-wise)

eXist DB

http://exist.sourceforge.net/

Why? because

    1) Both Daisy and eXist use Apache Cocoon (which of course is pure java).

    2) One of eXist's strengths is its GUI remote-admin client, which allows us to easily manage and query
    documents and collections in what I think is a highly daisy-compatible way.  (It allows me to manage
    and query documents in my home-grown apps better than in my CMS - daisy - and I want to fix that!).

    3) eXist offers a multitude of other interfaces (java API, REST, XMLRPC, SOAP, WebDAV, REST).

So, I see a golden opportunity for a clean, lightweight integration of the two apps.   I recognize that
Daisy currently uses a lot of other infrastructure besides cocoon, such as messaging and BPM stuff in
ActiveMQ, but from practical experience I think that at least the option of a lighter Daisy deployment
would be a good thing.  Personally, I see the BPM/workflow as an almost entirely a separate app from
the CMS, which should only need to be turned on for "enterprise daisy", but others may see things
differently.

Also, there is a whole discussion here to be had around the relationship between metadata and
content, XML and RDF and SQL, etc., but I don't want to get bogged down in that just now.

My point is that I would love to be able to run daisy-lite and eXist in a single JVM, configured using
little more than the two cocoon sitemaps, probably deployed inside the same cocoon instance
(eventually, I suppose, as cocoon "blocks", which the eXist project already delivers).
Any required enterprise messaging/BPM infrastructure could be bolted on to the same JVM, or run in
a separate process (ActiveMQ, Mule, whatever).  Application components shouldn't care what container
they are running in - SOA basics, right?

(Details of how I would approach this migration task are behind the cut).

If achieved, then in the simple let's-get-started use-case for Daisy+eXist, there's
only one OS process to (re)start to run both projects (the servlet container under which
the cocoon apps run).  This single process yields a pure-java, XQuery-compliant content
management system that provides interfaces for remote editing (through Daisy Wiki),
remote management (through eXist java admin client), and remote query (through XQuery
on eXist + any chosen bonus metadata storage/query infrastructure).   And hey, eXist also
supports WebDAV, which would be a nice way to move Daisy documents around, too.

IJust as important as all that out-of-the-box functionality, that hypothetical CMS+repository
is straightforward to extend and integrate in the web tier, using cocoon.

Finally, the uniting of the Daisy and eXist apps as closer cousins in the cocoon family would, I think,
strengthen the cocoon platform and help to justify increased investment and sponsorship for all three
projects.  Thoughts?

Buscando para Las Casitas Escondidas y Barratas en Austin

Here is a pretty good Austin map-based real estate searcher.  It takes the Austin MLS (which is
the big real-estate database used for most conventional real-estate searches) and plots all the
houses/condos/etc. on a map that's zoomable and scrollable [via separate nav window, not quite
as nice as the google maps dragging interface].

Cool part - when you mouse over properties, it promptly shows you a photo with the price.

http://www.escapesomewhere.com/realestate_searchthemls.html

Their GUI is pretty good, but there are bugs in the way they categorize listings, so for
now you pretty much have to make sure you have nothing excluded.   For example, if you turn on
"single family" to look for houses only (not condos), it misses some houses and still displays
some condos (ewwww).   Also, as with every Austin MLS I've tried, the search by "amount of land" is
very buggy and not sufficiently granular.

But we're getting there...and these are interesting times for an investor in anything, eh?  That's
because information technology is maturing and commoditizing to the point where anyone can
do fairly sophisticated domain analysis.  The next step I see is a tantalizing one, towards truly
broad and flexible evaluation models at the disposal of anyone with the savvy to use them.  That
trend will be a truly significant one economically, as well as technologically.  Why? 

Well, investment decisions are based on estimated current and future values of tradable entities. 
Those values are based on a number of factors, which it is reasonable to view as a conditional,
weighted scoring process, based on models which take into account a number of stochastic
variables.  The output score is itself a stochastic variable which we estimate with some kind
of statistical confidence model.  For example the output of a scoring process could be -
"5 years from today, that land will be worth between $195,000 and $205,000 ; 6 times out of 10".

I've given a range of the stochastic variable, and a confidence in my estimate.  If I want more
confidence, I will have to broaden the range of my estimate:
"5 years from today, that land will be worth between $192,000 and $209,000 ; 7 times out of 10".

Now, the correctness of these estimates is based on the correctness of a large set of assumptions,
the assumptions both explicit and implicit in our estimation process.  We try to assess the quality
of our assumptions in evaluating the confidence of the estimate, but we are always subject to errors
in judgement. (Improvement here is possible given honesty, experience, and attention to measurability,
among other things).   Broadly, it should be clear that with more (warranted) confidence in tighter
estimated score ranges, we can make better investment decisions and thus have an advantage in
the marketplace. 

This quest for solid estimates is the domain of financial intelligence, which involves
information gathering, analysis, and presentation to decision makers.   Computerized tools have
important roles to play in supporting these operations, of course, but the automation aspect is
something which must be kept in perspective.   For example, sifting, categorization, and note-taking
by analysts and decision makers are crucial processes which can be supported by tools, but the
tools will not soon supplant the primary human role in the intelligence process. 

Underlying the scoring process are the models.  To estimate a value V for some asset X at time T,
you must have some model of the world in which X is valued, including some model of the currency
(e.g.dollars) or commodity (e.g. gold) in which the value is estimated.    Let's call the entire set
of models which describe the world, it's currencies, the asset X, and so on the "master model for
evaluation of X":  M(X).

M is a model which represents all of the intelligence and world-view that we want to apply to the
evaluation of X.   Now, why have I brought us all this way?  Because the model M is in fact a
stochastic ontological model to which we must apply maximum conceptual leverage in order
to have an effective valuation process for X.    And now, as an excercise, let us consider the
value of Xi = X-imperative, which is the set of imperative software artifacts  (that is, .java files and
the like) in use at a particular financial intelligence operation whose real business is to evaluate
Xf = X-financial.   Now, the fundamental question is this:  Is Xi being used to define M(Xf) directly?   
Or is Xi being used to enable a process in which M(Xf) is defined by the users of the software Xi
implements?

The answer has fundamental implications for the value of Xi  (according to my M(Xi )), and hence
should be a determining factor in the way that an organization spends money to create and maintain
Xi.

Now, eventually, the decision makers in most orgs will figure out that they need to ask this
question.  It is probably being asked at some levels in many orgs today.   But the convergence
of mainstream financial consciousness to the understanding and articulation of this question
may take quite a while.  Perhaps, in fact, it will always be a highbrow kind of question.  What do
you think?

Back from STC06, back on prova

I went and it was cool.  Good vibes.  More on that later.

There's some more pages in the Prova Wiki now.  But they're still all by me, except for the builtins page Alex K wrote.  Over the years now, I have put up a lot of wikis and websites and software and stuff, and it's surprising how few people are usually willing to participate, comment, give feedback, support, encouragement and so on.  (Online, anyway.  In person, people are often more willing to engage).  Or, maybe it's not surprising, because I guess I'm pretty stingy with my time, too.  But I do make a point of sending some signals to people working on projects that I like and use over a period of time.   So there.

For the fans!

Been dumping all the fresh baskets into papers and examples for these upcoming gigs, both based
on chapters from forthcoming LogicU textbook with working title:  Enterprise Logical Reform.

2006 S.T.C. - San Jose, Cali - March 6-9. Topic: Semantic Testing: Verification and The Knowledge System.

2006 DAMA/Metadata - Denver on April 23-27. Topic: Semantic Seeds: Maintainable Configuration Dataload using Ontologies.

The glossy brochures for both confs are pretty snazzy.  Get one from me or using teh internets.

Let's see, any other news?

Alex K and I have created TWO pages in the Prova Wiki, which you must sign up to use (sorry):
prova.mostfiles.com

We got one page on the builtins and one on the SQL integration.  Come
help us fill out some more pages in there - it's a party, yo?  Also looks like prova is almost ready for a
1.9 release.  What's up with the Pellet folks?  No updates since November.   Maybe they're writing
papers too...freakin academics!

What prova needs is better documentation, some code cleanup, a few new tweaky features.
Then you combine that with Pellet and eXist, and Peruser "Canonical XML"(!) and it's game over, folks.

Of course, thanks to Java, you can run this sassy webapp on tomcat, JBOSS, Websphere, or whatever
you want.  (Note that eXist includes Cocoon, which is also used by Peruser).  This is where mom
is supposed to poke her head in and say, "What about Leyenoox?  Does it run on Leenox?"

So yeah, we now do all work within an open source java webapp capable of logical deduction, functional
transformation, and classical imperative execution.  No java code is ncecessary for communication
over most modern message channels.  The purpose is to capture intent of all human participants
in building a knowledge system.  The payoff for organizations is a distilled set of logical elements,
subject to formal review, from which all software configurations and tests can be derived, in "real time".

UML and Eclipse?  Yeah, thanks so much for playing, but you can go home now.  Because it's all
sitemaps, xqueries, and prova scripts from here.  Oh, and OWL / RDF models.  But custom Java?
Mmmmmmm, no, no thanks.  Don't need that.  Thanks, though!    Put it over there, next to the pile of
languages that start with P, as in P-rogrammer-centric.   (Of course, existing Java / P* systems must
be supported).

Hey, anyone else goin to XML-Prague, June 17-18?

I declare...backward chaining suits me fine!

...that declarative programming has many advantages over imperative programming in the
modern context of creating smarter transaction / query / test / search systems.   My two
favorite declarative tools right now are Pellet and Prova, both of which are open source java
SemWeb tools that are highly compatible with Jena, which recently got a bump to 2.3 with
fairly complete SPARQL support.    Pellet is an implementation of OWL-DL and some related
description logic facilities by the Mindswap guys in Maryland, who have absorbed some of
the l33t Kowari/Tucana guys, too (Tucana was recently picked up by Northrop, BTW).   

These three tools, folks, together with Laszlo or AJAX on the client, are a perfectly lovely alternative
we have now and forever to whatever shiny semantic doodads Microsoft dangles in front of our
occasionally less-than-discerning general IT population when the Longbone WinFS triplestore finally
gets its $1B TV commercial next year.   Oh, I'm chafing to know, who will be the spokesmodels? 
I'm hoping it's John Madden and Catherine Zeta Jones, explaining how the semantic future has
arrived through a series of incredibly witty and erotic super bowl spots, maybe punctuated
by Gwen Stefani and Carrot Top in some kind of steamy jungle Shakespeare parody.  Whatever
they do, I  predict M$ will get at least a 6-month Windows-95 "The semantic web is finally here,
because Microsoft says it is!" kind of wave, and tech stocks will run up somewhat on that.   Email
me for other hot stock tips and tomorrow's picks for Golden Gate Fields!

But my big question is: How little if any RDF/OWL compatibility will M$ shoot for?  Perhaps
a winderz-Maven can clue me in.    For those who are married (willingly or shotgun-style)
to Microsoft as a dev platform I will again suggest RDFGateway as a very nifty and highly
standards-compatible native Windows (C or C#) implementation of an RDF+rules portal for
windows (free for personal use, pay for commercial use).    Runs like a dream, though I've
seen the rules engine get slow if you trick its optimizer.    One neat feature is that it will
monitor it's own query performance and draw you a picture of the query plan with performance
annotations.  Schweet!

Back to them big 3 open source java tools (Pellet, Prova, Jena):  While the Jena is a wonderful piece
of code for which HP's SemWeb group deserves a lot of credit, and the Pellet seems to be
coming along nicely and being well received, the Prova is a bit more off the beaten track,
and probably represents a more idiosyncratic choice of tools on our part.    Allow me to esplain.

Prova is a prolog-variant built on top of Mandarax.  It is a very effective and fun medium for scripting
of high-level relationships and operations.   The integration of prolog unification, java types, java
methods, and java exceptions is done very nicely, and yields fine code economy.   There are some
rough edges in the docs, but we are helping to get these worked out in the pretty soon. 

RoR, Cocoon, PiggyBank

Scripting, scripting, scripting.  Programmers love imperative scripting, because it
works for what they want to do, when they want to do it.  Jah bless em.  I script
all the time.  Jah bless me.

Question:  Is the Ruby-on-Rails + AJAX community committed to XML interoperability?

OK, so I believe that RoR beats PHP and JSP+EJB and perl for hand-scripting SQL webapp workflows.

But is there a stronger statement out there that the dynamically typed imperative program removes
the need for robust server VMs with package management and XML interop and WebServices and
ontologies?    How does RoR fit into the space of declarative workflows?  I'm a little shrill about
this because I see people running off to spend time, attention, money on this allegedly "fast and cheap"
approach when they might instead be learning higher order methods and facing the crunchy process
issues that confront their organizations (which is of course what makes ME necessary!  See how my
mind works?).

I enjoyed Tim Bray's "shiny red rock" article on Ruby.

I agree with Stefan's assertion that RoR does not appear to solve the problems addressed by cocoon,
but then I haven't actually tried RoR so maybe I should shut my yap.   

I like Stefan's new(ish) PiggyBank thing at SIMILE, too, though the javascript screenscraper paradigm
is not quite my cup of tea, at least so far.  I did try it out on a non-critical machine and it kinda worked
for  me, but I think my firefox is a little old on that machine.  I'll probably upgrade and try again
sometime.

Back to RoR.  What I'm concerned about is that content and author workflows are mixed, recapturing
process as well as technical ground for the programmers.  Now, it's quite true that if the development team builds a GUI content management application into the application (and manages to keep it
up to date as the application schema changes), then perhaps the workflow mixing can be eliminated,
at the cost of broadened engineering cost and risk.    But my experience is that in today's "agile"
organizations, these authoring needs usually get more lip service than budget.  And when the authoring/engineering distinction for dynamic content is not properly recognized, then the workflows
are almost sure to be mixed, i.e.,

Programmers Own The System!

So, the money question here comes down to:  What kind of workforce and workflow do you want in your
organization?  If you want all dynamic content authoring to flow through your software programmers
who know what block closures are, then it does not seem reasonable to expect
the artifacts they produce to become integrated institutional knowledge for your organization.  Instead,
the knowledge of how your systems behaves will be shared only among the programmers and
recorded definitively only as imperative machine instructions, as has historically has been true in
most organizations, but to a decreasing extent over the years as attempts to broaden the
set of people who can participate in the workflow (i.e. knowledge workers) have progressed.