Doc Or Die

A Vaccination for the Service Science Epidemic

2008-10-29T02:42:00.000-07:00

It is truly astounding to see how fast the idea of "service science" (or "SSME" - for "Service Science, Management and Engineering") is spreading since IBM first started promoting it about five years ago (just as it played a key role in the creation of the computer science discipline a few decades ago). Scores of universities around the world have started or are contemplating new academic degree or certificate programs, new journals and books are coming out, and there are more conferences in more places than you could ever possibly attend.

I've done my share to develop and spread the idea of service science; there are eight posts in my Doc or Die blog tagged with "service science" that refer to my own papers or conference presentations.

Here's some indisputable first-hand evidence that service science has become an epidemic. Six months ago, I was invited to give a keynote speech at a "Joint Workshop of Six Japanese Universities on Service Science" hosted by the University of Tsukuba. When I gave that talk two days ago (27 October 2008), the workshop had been renamed the "Joint Workshop of THIRTEEN Japanese Universities on Service Science."

But there's a little disturbing aspect of this. While I believe and endorse the idea that something like service science is emerging as a discipline, I am concerned that many people and institutions are confusing the design of this discipline with the design of the particular curriculum they offer. I published a paper earlier this year titled "Designing a service science discipline with discipline" in which I contrasted a DISCIPLINE as a "principled model of a coherent body of research and practice" from a CURRICULUM as "a program of study leading to a degree or certificate." No single curriculum can cover the entire discipline, and it shouldn't try! Different universities and their schools have distinct emphases and character, and these differences are inevitable and desirable. They exploit the comparative advantages of each institution and their distinctive faculty composition, student population, industry partnerships and other aspects of the local economy, and so on.

This just seems so obvious to me. Berkeley and Stanford both have economics departments, but they don't specialize in the same subjects. It is preposterous to imagine someone telling the four Nobel Prize winners in Berkeley's department that they need to change the courses they teach so that Berkeley can better conform to some standard curriculum model.

But that seems to be happening with service science. Every presentation from IBM about service science contains diagrams like the two I've posted here – like the one on the top that shows the model of the discipline, and the one below that compares service science curricula against the background of that model. They're using terms like "sweet spot" to suggest that the "right" curriculum precisely balances business, technology, and people/social/organizational topics, which of course is an indirect (and perhaps unintentional) criticism of academic units with different specializations. Maybe IBM doesn't realize that this is the message that they're sending with these diagrams, but it is the message that people are receiving.

I know that if the " Information and Service Design" program that we've developed at the UC Berkeley School of Information were analyzed and plotted on this chart, we'd look "defective" in some ways. But our program is innovative, coherent, and takes better advantage of the people, students, and context we've got than anything else we might do. Are we supposed to feel inadequate about this?

So one of the main themes in my Japan conference keynote and in meetings I had with different groups of service science professors and students was to ignore this mandate to create a cookie cutter curriculum in service science, and to develop programs that built on their core competencies. People said they were relieved to hear it because they felt pressure to do otherwise. IBM, are you listening?

-Bob Glushko

tag me: ServicesScience IBM Education UCBerkeley

Document Design Matters

2008-10-12T11:30:00.000-07:00

A few months ago I wrote about an article titled "XML Fever" that I’d written with my Berkeley ISchool colleague Erik Wilde. We’ve just published another article together called "Document Design Matters" that appears in the October 2008 Communications of the ACM.

We chose the title before we wrote the paper, and under Erik’s forceful leadership of our collaboration the paper evolved in a direction that makes the title less appropriate than it would be if I had been smart enough to be the first author. It would be more apt to title it "Metamodels Matter" but that wouldn’t sound as clever and "metamodel" would probably scare a lot of people away.

Here’s an abbreviated abstract of the paper:

The classical approach to the data aspect of system design distinguishes conceptual, logical, and physical models. Models of each type or level are governed by metamodels that specify the kinds of concepts and constraints that can be used by each model; in most cases metamodels are accompanied by languages for describing models...

In this modeling methodology, there is a single hierarchy of models that rests on the assumption that one data model spans all modeling levels and applies to all the applications in some domain. The one true model approach assumes homogeneity, but this does not work very well for the Web…

Instead of being governed by one true model used by everyone, the underlying assumption of top-down design, Web data and services evolve in an uncoordinated fashion. As a result, a fundamental challenge with Web data and services is matching and mapping local and often partial models that not only are different models of the same application domain, but also differ, implicitly or explicitly, in their associated metamodels.

Wilde and I distinguish the native or "system" data model used by an application or web service from the "exchange" model created when it interacts with another one. Exchange models are most often implemented in XML, and this can cause problems because the tree-based XML metamodel isn’t entirely compatible with the graph-based metamodels of RDF or E-R system models. The solution is probably an XML-oriented conceptual modeling language, but we only sketch what one would have to be like in this short paper.

The citation for this article is Erik Wilde and Robert J. Glushko. Document Design Matters. Communications of the ACM, 51(10):43-49, October 2008.

But you need access to the ACM digital library to find the official version, so we’ve posted (with ACM permission) an "author’s pre-print version" .

-Bob Glushko

An Encouraging Sign in the "Bailout Bill"

2008-09-28T18:10:00.000-07:00

If you're like most people I know, you feel like we're in a "damned if we do, damned if we don't" dilemma with the Wall Street "Bailout Bill." I am philosophically opposed to bailing out people who were greedy or stupid on both ends of the financial pyramid. But this afternoon the text of the proposed bill was published (here's a link to the version hosted by the Wall Street Journal) and on the first page I saw something that made me feel good about the bill.

No, not the content - -I haven't had time to fully think about it. But based on the file name embedded in the pdf of the bill -- O:\AYO\AYO08C04.xml -- at least the people doing the publishing work for the bill are doing their best to save our tax dollars by creating the file using XML for efficient production and revision.

-Bob Glushko

I'm not AWOL - I'm pre-empted

2008-09-28T17:59:00.000-07:00

I haven't posted to this blog in a few weeks, but I have a really good excuse this time for the dry spell. My last post here described "another course blogging experiment" in which the students in my "Information Organization" course at UC Berkeley would be posting to a new course-specific blog rather than post here, which I tried earlier this year.

This has been wildly successful - there's a real blog going on, with several posts a day. But about 1/3 of the time after reading or hearing something in the news that I would normally have written about on "Doc or Die" one of my students pre-empts me by posting to the IO course blog before I got around to posting on my blog.

So if you've been suffering withdrawal from my usually insightful posts.... just sign up for the feed for the course blog and you'll get your fill.

-Bob Glushko

Another Course Blogging Experiment

2008-08-31T08:03:00.000-07:00

In the last few years, as blogs and wikis have become widespread, I've thought a lot about whether or how to employ them in the courses I teach. Last semester, when I taught Document Engineering, any topic in that course would have been an appropriate subject for this "Doc or Die" blog. So instead of setting up a new blog for the course, I had students use this blog as the course blog.

Unfortunately, I think that most of the students felt a little intimidated by the suggestion that they should be posting on their professor's blog. So except for the one time that I made it a course assignment to do so, very few students posted to Doc or Die during the semester.

We've just started up the fall semester at Berkeley, and once again I have the great privilege and responsibility to teach the only course that every student entering the Master's Program in the School of Information has to take this semester. The course is titled "Information Organization and Retrieval," which is the name given to it when the school started over a decade ago, but it is significantly broader in scope that that. Many of the topics that come up in the course would be appropriate for "Doc or Die," but not all of them.

So this time, we've set up a new blog dedicated to the IO & IR course, and the first assignment for students is to post a news story that concerns a topic in the course (I wanted them to start seeing how IO & IR are deeply embedded in the world they live in, and to take a closer look at the course syllabus). This seems to be working – they are busy posting away this weekend. I suspect I'll end up blogging here about posts my students make over there… or would it make more sense just to comment on their posts on their blog rather than on mine? I guess that would be another experiment.

-Bob Glushko

Berkeley Calendar Network wins Innovation Award

2008-08-21T22:07:00.000-07:00

I feel like a proud parent … or perhaps grandparent or great-grandparent is more accurate (I'll explain that in a minute) … because the Berkeley Event Calendar Network has recently won the 2008 Larry L. Sautter Award for Innovation in Information Technology, a UC systemwide honor.

An "event calendar network" is exactly that, and the motivation for it is quite simple. Before the event calendar network existed, there were literally scores of different Web calendars on the berkeley.edu domain, all with incompatible models of "event" so they couldn't share information. If a distinguished visitor was giving a lecture at our School of Information that might appeal to people in computer science or business, we'd have to enter the event in three different Web forms to get it on the relevant calendars (and that always seemed like too much effort). There was no easy way to share, syndicate or subscribe to events, which meant that people missed out on events they would have gone to if they'd only known about them.

Fast forwarding to today -- because of the calendar network, when you submit an event to your "home" calendar (the "master calendar" is this one), if you mark it "public" so it can be shared, other calendars can transparently include it in their calendars. About 50 calendars are in the network, and new ones join all the time. You can easily can sort events by category or change the display, and each calendar has a customizable CSS "skin" so that it can be plugged into the home page of each department / school / organization in the network. This lets a calendar join the network and get the advantages of event syndication without losing its native look and feel.

But like many network-based applications, the event calendar took a while to achieve critical mass, and it has been a long time coming. The reason I feel like the great-grandfather is because I assigned the task of designing an interoperable model of an event for calendars on the Berkeley campus to my Document Engineering class in the Spring of 2003. Yes, 2003 – over 5 years ago.

Four of the students in that class – Allison Bloodworth, Nadine Fiebrich, Myra Liu, and Zhanna Shamis – transformed my little homework assignment into their final project as part of their master's degree requirements at the School of Information. They overachieved big time in that effort as you can see from the hyperdocumented design artifacts on their project website, and it was not a surprise to me as their project advisor when they subsequently won the Chen award for best final project in 2004. After graduation, Allison went to work for the UCB campus, and she slogged hard for a few years to turn this master's degree project into a deployable application.

The graduation award for the project wasn't a fluke. Later that year I co-authored a paper with Allison titled Model-driven Application Design for a Campus Calendar Network, and this received a "best paper" award at the XML 2004 conference, mostly as a result of Allison's engaging presentation.

A year later, when Tim McGrath and I were finishing the writing on our Document Engineering book, we showcased the event calendar as a case study that weaves through the book to illustrate the design techniques and modeling artifacts. We used the calendar as a case study not just because it was convenient, but because the interoperability problems it was designed to overcome are typical of every large organization that struggles with incompatible time sheets, expense reimbursements, registration forms, and other administrative documents.

So as you can tell, I am a very proud (parent^N) of this event calendar network, and it just pleases me immensely to see it get this award. Now if only the School of Information would join the network, so I could avoid making up reasons why it hasn't even though the project was born there over 5 years ago.

-Bob Glushko

A New “Information Systems and Service Design” Course

2008-08-19T12:47:00.000-07:00

For most of my professional career I've designed and deployed information-intensive applications, systems, and services. Almost 30 years ago, when I was one of the first handful of people with a cognitive science background to work at Bell Labs, my work in online documentation and content management systems emphasized the "people parts" or "front stages." Over time, especially when I was part of two Silicon Valley start-ups in electronic publishing (Passage Systems, 1992-1996) and B2B marketplaces (Veo, 1997-1999) my focus shifted toward the "back stage" where information is managed, transformed, and moved within and between business systems.

But recently, as I've helped to shape the emerging discipline of "Service Science," my goal is to develop methods for designing " service systems" that treat the entire network of service components that comprise the back and front stages as complementary and integrated parts. For almost two years I've had a team of graduate students with a mixture of front and back stage design skills thrash with each other and with me to seek some unifying concepts and methods that can overcome the biases and conflicts inherent in their different perspectives.

At the risk of stereotyping, here's how I've contrasted these two design approaches in a paper I wrote with Lindsay Tabas:

Designers with a "front stage mindset" strive to create service experiences that people find enjoyable, unique, and responsive to their needs and preferences. Front stage designers use techniques and tools from the disciplines of human-computer interaction, anthropology, and sociology such as ethnographic research and the user-centered design approach to specify the desired experience for the service customer. They capture and communicate their service designs using modeling artifacts that include personas, scenarios, service blueprints, and interactive prototypes.

In contrast, service designers with a "back stage mindset" typically follow different goals and techniques. They strive for efficiency, robustness, scalability, and standardization. Even though some back stage activities are carried out by people, and others carried out by automated processes or applications, the back stage mindset tends to treat people as abstract actors. So instead of modeling the preferences and interactions of people, back stage designers identify and analyze information requirements, information flows and dependencies, and feedback loops. They use concepts and techniques from information architecture, document engineering, data and process modeling, industrial engineering, and software development. Their typical artifacts include use cases, process models, class diagrams, XML schemas, queuing and simulation models, and working software.

The usual approach for resolving the typical design conflicts and tradeoffs between front and back designers is to create multidisciplinary design teams that explicitly include designers with front and back stage biases. But this is a necessary but insufficient remedy, because what often happens is that each tribe of designers is so convinced of its intellectual and moral correctness that it tries to beat the other side into submission rather than make reasoned tradeoffs. I think this is especially true of relatively inexperienced usability or HCI designers, who find it difficult to accept that business models, legacy implementation constraints, or backward compatibility should shape what gets built. Likewise, some software developers and business managers discount ethnographic field work because the insights about activities and problems seem obvious, but only in retrospect.

So I've come to think that a good designer needs a more end-to-end perspective and some familiarity with the concepts and design techniques of "the other stage." And that's why we developed a new course called " Information Systems and Service Design: Strategy, Models, and Methods" that I'll teach for the first time this coming semester.

This course covers the entire design process, but rather than teach it from a narrow perspective governed by a single methodology like "user-centered design," it brings together multiple perspectives so that students can learn multiple ways of dealing with the same problem. Many of the topics in the syllabus come in complementary pairs, like "Personas" and "Customer modeling" - where traditional HCI methods get "mashed up" against business/marketing/backend perspectives on the same design problems. Likewise, there are readings on "Ethnography for experience design" (i.e., follow and observe people as they work) with what I call "Ethnography for information system design" (i.e., follow documents and other information objects as they move between people, organizations, and systems). My experience has shown that a combined "document anthropology and archeology" yields much better requirements and insights than either does on its own.

One other key aspect of the course is that it discusses a much broader set of design contexts than the typical UCD or HCI design course does. These courses most often consider the design of "one shot" new applications or services where there are no legacy constraints, integration concerns, or product family roadmaps in which functionality emerges over time over a set of related offerings that have to fit into an environment with existing systems and services.

So in this new course we'll deal with multichannel designs (that exist in both online and physical contexts, like a web store that also has brick-and-mortar locations), composite applications that combine new information resources with existing ones, and "smart" services that are driven by information collected from sensors or from objects as they move through supply chains or distributed systems. Students will work in teams (which we'll put together to have as diverse or contrasting design experiences as we can) to have an end-to-end design experience in one of these three emerging contexts. I think this will give students a more realistic view of what "design in the wild" is really like.

I'll publish my lecture notes on the course syllabus page as the semester progresses if anyone wants to follow along.

-Bob Glushko

"Dude, you're famous" -- Duane Nickull

2008-08-15T16:30:00.000-07:00

I don't get many email messages with subject lines like "Dude, you're famous" and when I do they are almost always from Duane Nickull. He's a "Senior Technology Evangelist" at Adobe, and has been leading the Service Oriented Architecture Reference Model Technical Committee at OASIS (an international standards-making organization where I'm on the Board of Directors). Duane and I met about 10 years ago in the technology standards arena when we were both part of the ebXML effort to develop and harmonize XML and EDI standards for electronic business -- which laid the foundations for web services.

But this description of Duane as a technologist and standards-maker doesn't do him justice and certainly doesn't capture the fact that he's also a brilliant musician, an extreme sports professional, and fun to hang around with. Duane has a fairly traditional blog called "Technoracle," but he also has a radically untraditional show on "Adobe TV" that mixes technology interviews, code writing demos, and indy music.

The reason I am now famous – at least according to Duane – is because he interviewed me for his most recent
"Duane's World" episode on Adobe TV. This episode was recorded at the recent annual "Foo Camp" get-together at the O'Reilly home offices in Sebastopol, California.

In the interview I discuss the motivation and goals for a new course I'm about to start teaching at UC Berkeley called "Information Systems and Service Design" . This is a course that embodies the idea I've talked about here on "bridging the front stage and back stage". When we design and build "information-driven interactions" we should understand how back stage information contributes to the experience, and we shouldn't focus narrowly on the user interface. Duane came up with a perfect example of the problems this front stage bias can produce: he said that he was annoyed recently when he filled out Web forms to submit his Canadian income tax, only to have them corrected by the tax authorities! A "bridging" design method would have pre-populated the form with the known information, leaving the user to confirm rather than provide it.

I'll write something more detailed about that new course soon, and I'll try to make it as entertaining as the interview.

Btw, the episode begins with Duane interviewing Dries Buytaert, the founder of Drupal, followed by a demo on Adobe's Flex Builder tool. And one of the bands whose music appears in my interview is 22ndCentury . I use Drupal and have tried Flex Builder, and I think I'll listen to more of 22ndCentury.

-Bob Glushko

The Dark Side of Knowledge Management

2008-08-09T14:03:00.000-07:00

A couple of days ago I came across a 2006 paper by Steven Alter called "Goals and Tactics on the Dark Side of Knowledge Management," which begins by saying that "the knowledge management literature focuses on the bright side of KM: it barely mentions the dark side, in which knowledge is distorted, suppressed, or misappropriated due to personal or organizational motives."

I was intrigued by the title because I'd just reviewed the Component Content Management Report, which by contrast is certainly about the bright side of content management. I also know Alter, and he's a clever guy (maybe even a bit of a "wise guy") who teaches at the University of San Francisco, across the bridge from Berkeley on the "West Bay."

This could have been a "tongue in cheek" article, but it's not. It is a brilliant analysis of dozens of news stories in which knowledge was suppressed, distorted, or misappropriated during creation, storage and retrieval, or distribution and presentation phases. Alter uses this "lifecycle x dark side goals" framework to organize the various tactics that he extracted from the news stories.

For example, "distortion during knowledge creation" occurs when emergency rooms don't run blood-alcohol tests on patients thought to be intoxicated. Insurers can deny reimbursement to patients who are under the influence, so the emergency room doesn't want to have information that would prevent them from getting paid.

"Suppression during knowledge creation" occurs when school districts put pressure on principals to minimize reported dropout rates.

"Suppression during storage and retrieval" occurs when Morgan Stanley falsely claimed to have lost archived email messages that they were ordered to turn over in a lawsuit.

"Distortion during distribution and presentation"occurs when government agencies produce pre-packaged "news stories" with government employees posing as reporters.

I won't go through all the categories in Alter's framework. But I note that many of the examples reveal a political perspective common in San Francisco (actors in the stories include John Bolton, Dick Cheney, and Donald Rumsfeld), and I'm sure that there are people in red states who would argue that Alter's paper itself is an example of "knowledge distortion during presentation." I'll let you decide for yourself.

-Bob Glushko

Component Content Management Report - Ann Rockley and CMS Watch

2008-07-28T13:29:00.000-07:00

I've just read "The XML and Component Content Management Report 2008" from CMS Watch, an analyst firm whose name seems too narrow -- it watches a lot more than just content management systems. When I learned about this report I was eager to read it for two reasons. First, I've long read and respected Ann Rockley, who wrote the report –- she's probably the most highly regarded content management expert in the world (and she literally "wrote the book" on enterprise content management). Second, in a previous life I worked for a company called Passage Systems that would have been discussed in the report if it were still in business, so I was intrigued to imagine how we would have stacked up in the report.

(Thanks to web search, I was able to easily find an article I wrote in 1996 that says "In 1992 I co-founded Passage Systems, a consulting, software, and data conversion services company that helps companies make the "passage" from print to online publishing.")

I don't often rave about things I've read, but the "XML and Component Content Management Report" is an outstanding piece of work. I've seen many reviews of software products, but none has been as comprehensive and insightful as this one. Most reviews present a checklist without explaining the dimensions that frame the product comparison, leaving it to the reader to determine if the products are being compared against a necessary and sufficient set of attributes. Instead, Rockley spends 60 pages explaining the key concepts of component content management before mentioning any products at all. For example, she analyzes the standards of content management – DocBook, DITA, SCORM, and so on – in terms of their maturity and applicability so that a prospective purchaser of a CCMS can confidently assess vendor claims for standards compliance.

But the nugget in the report that justifies buying it is a set of content management scenarios that are clearly presented and then matrixed against the product comparison checklist. These include "Complex Reuse," "Complex Translation," "Regulatory," "DITA for Technical Documentation," "Enterprise Component Management," and several others. These scenarios take the pragmatic insights of the first 60 pages and apply them in reviews of every content management vendor I'd ever heard of and a dozen more that I hadn't.

This report is indispensable for anyone considering a component content management system. Every page is full of pragmatic best practice wisdom and just oozes an "I've been there, and you can trust what I say" feel. But I didn't expect anything else from Ann Rockley.

- Bob Glushko

UC Berkeley’s "Alice In Wonderland" Semantics for my Parking Ticket

2008-07-14T10:47:00.000-07:00

A while ago I wrote about my experiences with the TSA and began my post this way:

I was enduring the ritual humiliation inflicted by the Transportation Security Administration at the San Francisco airport when I fell, like Alice in Wonderland, into a semantic rabbit-hole where the TSA used words in ways that made no sense.

I just had a similar encounter with the UC Berkeley Parking & Transportation "Service.". On June 23 I received a parking citation for "No Permit for Area" when I parked my car in one of the campus parking lots. But in fact I had left my car with a one-day permit that was appropriate for that particular lot, as you can see in the attached photo here.

So when I returned to my car, you can imagine my reaction – there's just no way I should have a parking ticket, and the citation category "No Permit for Area" just makes no sense.

Then I read a clarification on the citation that said "scratcher not marked" and again, it didn't make sense to me. As you can see, I have certainly "marked" the month, day, and year on the parking pass. I have X'ed the month, day, and year on parking passes like these dozens of times in the 7 years that I have worked at the university, and have never been cited. I have always assumed that the point of crossing or scratching the pass was to prevent the pass from being used more than once, and I certainly have done that. There is no way this pass could be marked again to indicate another day. So it is simply not true that "scratcher not marked" is an accurate description of my parking pass.

But I thought about it some more, and realized that the parking people had apparently chosen to interpret a much narrower and literal view of "scratching" of the parking pass. Maybe the parking enforcement person was having a bad day, or hadn't met his quota, or whatever – but in any case I could now understand that there was an interpretation of "scratching" under which I had not complied with the notice on the pass it is "Only valid on day, month, and year scratched off."

Nevertheless, because I didn't like the idea that my car was being ticketed somewhat arbitrarily, I appealed the citation on the grounds that I'd been "marking but not scratching" for years. So even though I might not have literally complied with the requirement, my marking surely limited my pass to a single use, which was the intent of the scratching rule.

Of course, my appeal was denied, but as a "courtesy" I was given an offer that if I paid an $18 visitor parking fee my "No Permit for Area" citation would be dismissed. I went to the parking office to pay the fee. When I got there I showed the offer letter to the parking clerk, and tried to explain why I thought they should give me a replacement one-day parking pass for the one that I'd marked on June 23. After all, if my pass had been used, I wouldn't have gotten a citation.

Now here's the real Alice in Wonderland part of the story.

Parking clerk: Giving you a replacement pass would be letting you park for free on June 23.

Me: No, I just paid $18 for a visitor parking fee for that day.

Parking clerk: That was a reduced fine. A "No Permit for Area" citation costs $40.

Me: So you're really charging me $30, because I had paid $12 for my one-day pass that you didn't honor.

Parking clerk: No, you've been charged $18.

Me: Well, If my original pass hasn't been used, then can I use it again sometime? This time I will make sure to scratch rather than mark it.

Parking clerk: No, you can't use it because it has been marked already.

At this point it was clear that I was once again in Wonderland talking to Alice, so I gave up.

- Bob Glushko

Is Google Making Us Stupid, And What to Do About It

2008-07-11T10:27:00.000-07:00

It is summertime, and I'm busy rethinking and revising the reading list for my fall course at UC Berkeley (" Information Organization & Retrieval"). Even though the intellectual foundations and themes of this course like conceptual modeling, semantic representation, classification, vocabulary and metadata design, etc. are timeless, technology and business practices continue to evolve. Besides, if I don't revise the syllabus I'll be bored and my teaching will show it, and I can't let that happen.

One article that might make it into my fall syllabus is Nicholas Carr's "Is Google Making Us Stupid?" in the July 2008 Atlantic Monthly. Carr suggests that the downside of the nearly effortless and immediate information access that the web affords us is diminished capacity to read and focus on printed works, especially books. In Carr's view, the style of reading encouraged or even mandated by the web, in which information is organized in hyperlinked fragments, is "chipping away at my capacity for concentration and contemplation."

The title of Carr's article comes from the argument that this fragmentation of reading and thinking is essential to Google's business model, because it and other firms that monetize web use need "the crumbs of data we leave behind as we flit from link to link – the more crumbs, the better… It's in their economic interest to drive us to distraction."

Carr is notorious for provocation (remember the debate he started about whether information technology matters?) and of course his article was meant to bait the defenders and disciples of the web into counterattacks. Sure enough, John Batelle and others took the bait, and with an even more provocative title Batelle lashed back ( "Google: Making Nick Carr Stupid, But It's Made This Guy Smarter." A less rabid reaction came from Jon Udell, who suggested that it is up to each of us to find the right balance of big and little information chunks to consume.

I tend to agree more with Carr than Batelle. Of course the web makes it incredibly easy to find satisficing information -- to find something that minimally meets an information need -- and that's great if I want to check a fact or temperature or stock price where any source with the information will do. But the web makes it much harder to meet the more intellectually important goal of getting your head around some issue, which you can often most easily do by reading a tightly integrated analysis in a book or scholarly article, because these are very difficult to locate using web search.

And this IS partly Google's fault, because Google fundamentally determines relevance by the words that appear on individual web pages. So what you get in results lists are pages that have the search terms, so results listings are cluttered with the blog rants and less comprehensively researched information. Maybe I'm just "old school," but when I need more than facts or news stories I use the California Digital Library to search using the Library of Congress subject headings and other more sophisticated search resources, which enables me to find the long and authoritative chunks of information I'm looking for. Not everything on the web has subject-level metadata that is vastly better at identifying relevant content than mere word occurrences, but of course that's because most stuff on the web doesn't justify the additional effort to create it.

-Bob Glushko

XML Fever

2008-06-24T12:04:00.000-07:00

I've co-authored a paper with my School of Information colleague Erik Wilde titled "XML Fever" that has just come out in the July 2008 "Communications of the ACM."

YOU CAN GET OUR PREPRINT VERSION HERE

Despite the somewhat silly title, which we modeled after a paper by Alex Bell called "Death by UML Fever" in ACM Queue a few years ago, "XML Fever" is a serious paper that analyzes misconceptions and problems with XML.

For example, anyone who's ever heard me rant about why XML isn't self-describing won't be surprised that one of the XML fevers is "Self-description delusion." This causes its victims to assume that the semantics of an XML document are self-evident, openly available just by looking at it and understanding the names. Frequently, this strain of XML fever causes great discomfort when the victims learn that XML does not deal with semantics, and that common understanding has to be established through other mechanisms.

The abstract says:

The Extensible Markup Language (XML), which just celebrated its 10th birthday, is one of the big success stories of the Web. Apart from basic Web technologies (URIs, HTTP, and HTML) and the advanced scripting driving the Web 2.0 wave, XML is by far the most successful and ubiquitous Web technology. With great power, however, comes great responsibility, so while XML's success is well earned as the first truly universal standard for structured data, it must now deal with numerous problems that have grown up around it. These are not entirely the fault of XML itself, but instead can be attributed to exaggerated claims and ideas of what XML is and what it can do.

The introductory paragraph:

This article is about the lessons gleaned from learning XML, from teaching XML, from dealing with overly optimistic assumptions about XML's powers, and from helping XML users in the real world recover from these misconceptions. We frame our observations and the root of the problems along with possible cures in terms of different categories and strains of XML fever. We didn't invent this term, but it embodies many interesting metaphors for understanding the use and abuse of XML, including disease symptoms, infection methods, immunization and preventive measures, and various remedies for treating those suffering from different strains.

The last two paragraphs:

When someone first learns about it, XML may seem like the hammer in the cliché about everything looking like a nail. Those of us who teach XML, write about it, or help others become effective users of it, however, can encourage a more nuanced view of XML tools and technologies that portrays them as a set of hammers of different sizes, with a variety of grips, heads, and claws. We need to point out that not everyone needs a complete set of hammers, but information architects should know how to select the appropriate hammer for the kind of hammering they need to do. And we should always remember that pounding nails is only one of the tasks involved in design and construction.

XML has succeeded beyond the wildest expectations as a convenient format for encoding information in an open and easily computable fashion. But it is just a format, and the difficult work of analysis and modeling information has not and will never go away.

-Bob Glushko

Service Systems in Taiwan and Taiwan as a Service System

2008-06-18T19:21:00.000-07:00

This week I've been in Taiwan at a Service Science Faculty Workshop at the National Tsing Hua University in Taiwan The College of Technology Management there has started a graduate program in service science, as have several other academic units at other Taiwan universities. I gave an invited talk titled "A Systems Approach to Service Science Research" in which I reviewed different definitions and modeling frameworks for "Service systems." I also participated on a panel titled "Old Wine in New Bottles" in which different universities talked about their experiences developing courses and curricula, something I've written and blogged about.

I began my plenary lecture with the example of the service experience at hotel check-in, which I've presented in detail in a paper titled "Designing Service Systems by Bridging the "Front Stage" and "Back Stage" " (and that I've also blogged about before.) One of the key ideas in that paper is that there may be a "moment of truth" when the quality of a service experience becomes apparent, but that quality is enabled or constrained by many other encounters, even though many of these encounters don't involve or are invisible to the customer, and some of them are even invisible to the frontline ervice provider. This kind of "end-to-end" analysis argues that service quality can
best be understood with a systems view of how a service is defined and delivered.

But while "Service System" is an intuitively sensible and appealing idea, it is usually talked about in a generic and qualitative way, as in this definition in a paper titled "Steps toward a science of service systems" by my friends Jim Spohrer and Paul Maglio from IBM research:

A value co-production configuration of people, technology, internal and external service systems connected to other systems by value propositions and shared information.

This definition leaves a lot of fundamental questions unanswered. For example:

If service systems can be composed from other service systems, what
are the primitive components of service systems?

What rules or patterns govern the composition of service systems?

Is the "shared information" explicitly specified? What rules or patterns
govern specifications?

So most of my talk at the Taiwan conference tried to put meat on the bones of the service system concept by showing how different people have tried to model them. Because of the great range and diversity of domains that have been described as service systems, no single modeling approach or descriptive formalism is adequate. The simplest descriptions are value chain or structural models that involve qualitative properties of connectivity and intensity. Other approaches describe the relationships and interactions among the components in the service system in more formal and quantitative ways. These models essentially add "typing" to the links in the network description of the service system and some make the relationships functional ones that enable simulation and optimization. Finally, service systems in "information-intensive domains" can best be described using information flow and exchange models that are the scope of document engineering techniques that I've written and taught about for many years.

The conference was attended by over a hundred professors, students, government officials, and industry people. I'm very impressed by the rapid uptake of service science in Taiwan, and it seems like another example where something that began with a lot of hype and fanfare in the US has been more systematically adopted elsewhere.

Which brings me to the second theme in this post. One of the main points in my lecture about service systems was that the IBM definition was too broad and vague to offer more than qualitative insights – after all, what does it really mean to say as Spohrer and Maglio often do, that a city or a country could be viewed as a service system? But after a few days in Taiwan, I can understand better what they intend. So Jim and Paul, I'll be less hard on you the next time I talk about service systems.

I have been very impressed by how hard Taiwan is working to transform its economy into a knowledge and service one, and it seems profoundly more advanced in just about every way since I was last here about 8 years ago. I took the high speed train from Hsinchu, where the conference was held, to Taipei, and the "service experience" was first rate. The Hsinchu train station is a stunning piece of visual and functional architecture, and the trains go blazingly fast, over 180 miles an hour. We have nothing like them in the US. I stayed at the Ambassador Hotel in both Hsinchu and Taipei, and when I got to the latter I realized how much the service offerings were being tailored to the different customer segments of each hotel: the former, because it was full of Silicon Valley types, felt like a US hotel, while the latter, because it was full of Asian tourists, felt distinctly different in entrance and lobby design, room décor, breakfast menu. Finally, as I was returning from a late dinner, I was amazed to see students of elementary and junior high ages on the streets, and I was told that they were going home after their many hours of after school studies of the English language.

So the "Taiwan service system" is hitting on all cylinders, and while it makes me optimistic for that country's future, it makes me worry about the one I'm heading home to later this week.

-Bob Glushko

Post-It "Signatures" Aren’t Signatures

2008-05-30T10:59:00.000-07:00

On any given day I use credit cards, write checks, request reimbursements, approve time sheets, or complete this or that form. Each of these activities requires me to sign a paper document. When transactions and requests like these are moved online, I no longer sign with pen on paper, but I still am required to produce an electronic signature, perhaps literally with a stylus of some sort or analogically with a login and password. The point is the same – I need to provide irrevocable proof that I am who I claim to be when I authorize some action to be taken on my behalf.

That's why I was astonished this week to read this week (in a 27 May 2008 NY Times article by Carter Dougherty titled "Ex-manager tells of bribery at Siemens") about the scheme allegedly used to approve bribe payments. Over 1.3 billion euros worth of suspicious transactions over the past seven years have been identified (for those of you who haven't been following the collapse of the dollar's value, that's 2.1 billion US). And according to Reinhard Siekaczek, a former Siemens middle manager who faces 58 charges of "breach of trust" and is cooperating with prosecutors, he built up "slush funds" by paying for bogus consulting charges so that bribe payments could be made to win contracts.

But the role of Post-Its in the bribery process defies logic. People signed Post-Its and attached them to the documents needed to carry out the bribes, That way, according to Siekaczek:

The signatories could elegantly remove signs of their involvement if it came to an investigation.

Now I know that languages are living things, and concepts continually evolve. That's why we recognize that a "signature" no longer assumes a quill pen and inkwell, but can also be performed with a ballpoint pen or electronic stylus. But I think that an intrinsic part of any notion of "signature" is that signatures are intended to be permanently embedded or affixed to the documents being signed. There is just no way that anyone at Siemens who ever signed a Post-It could rationalize that this was an appropriate mechanism for authorizing or recording a business transaction, especially one involving such significant amounts of money.

Unless, of course, they had been informed of a new policy at Siemens that established Post-It signatures as equivalent to traditional ones. Given the 270 suspects that prosecutors have identified, including four former members of the top executive group, this new policy would have had to come from high up in Siemens. Would the document describing this new policy have been signed with a Post-It?

-Bob Glushko

Unleashing the Masters of Information

2008-05-21T14:48:00.000-07:00

We've just had our annual commencement at the School of Information at UC Berkeley, which means we are unleashing another class of "masters of information" on the world. I've always thought it was a little odd for us to be called the School of information, but that's the name (and we're not alone). I hope that all schools at Berkeley are schools of information (as opposed to "disinformation"or "misinformation"), but given what we do and teach here if any academic unit on campus were to use that name it could only be us.

Instead of a master's thesis, which is required by many professional degree programs at Berkeley, the ISchool requires a final project, which is almost always a 2-4 person team effort extending over a couple of semesters. This year there were 16 final projects sorted into three categories. The mix of final projects reflects the wonderful intellectual and curricular diversity here, but a handful are especially relevant to the topics I post about on this blog -- so go back and follow the link to the project list.

I'm very proud to say that the two projects that I advised
were singled out by outside judges as prize winners:

MD:Notes was named the best project in the "Information System Implementation" category. The students were Zach Gillen (the Teaching Assistant in my Document Engineering course), Jill Blue Lin, and Kate Ahern.

Our product, MD:Notes, is a prototype for an application that improves the hospitals' processes for creating and retrieving progress notes.

Our primary motivation for the project was to better understand how public hospitals are making the transition from paper to electronic records, and to design a solution that addresses the hospitals' needs. Specifically, we focused on how two public hospitals in the Bay Area work with progress notes.

Progress notes are notes written by a physician to describe the patient's condition during the visit, the physician's assessment and plans for treatment. These notes are an important part of a patient's medical history. Taken as a whole, they tell a rich narrative about a patient's medical past. A progress note is one component of a patient's record consisting of many pieces of clinical documentation.

A Digital Clean Slate received the runner-up project award in the "Information Policy and Management"category. The students were Evynn Testa-Avila and Chris Volz.

When potentially derogatory information is dismissed from a person's record in the court system, the dismissal is not always registered immediately with various Corporate Data Brokers (CDBs) who provide background checks to employers. This means that errors can appear in background checks and jeopardize chances at employment. In this paper, we present the results of a pilot study that looks at the flow of information from public court records to CDBs and then to employers and job applicants. Of particular interest is how and when errors may be introduced into these records and how processes and systems can be improved to avoid or minimize such errors.

Both of these projects did very careful and thoughtful document and process analysis in complex environments -- I've called this "document anthropology and archeology" because it involves an iterative cycle in which documents or other information sources may refer or link to other documents, or to people, who can refer to other people or to other documents, and so on.

It is very rewarding each year to see the really interesting work that students do here and to contribute to it as a teacher and research advisor. But that always gives me mixed emotions, because it makes me look forward to the next class. So congrats to Zach, Jill, Kate, Evynn, Chris and the rest of the class of 2008, but you have to leave now to make room for class of 2010, so be sure to empty out your lockers in the graduate student lounge.

-Bob Glushko

Document Engineering and User Experience Design

2008-05-11T14:00:00.000-07:00

This past week (8 May 2008) at the DocTrainWest conference in Vancouver I gave a keynote talk titled "Document Engineering and User Experience Design."

My talk was based on some evolving ideas I've called "Bridging the Front Stage and Back Stage" in a paper and talks over the last year. The contrast and conflict I've been thinking and talking about is between information system designers with a "user experience" perspective and those with a "back end" or systems and data analysis perspective. People with the UX mindset focus on the interactions or encounters that people have with systems and services, and thus intentionally or unintentionally discount the contribution of the "back stage" work where materials or information needed by the front stage are processed. For example, if you analyze a web shopping experience from the front stage point of view, you emphasize usability and visual design considerations and don't think about the information exchanges between warehouses, shippers, banks and so on who have to work together if what you order is going to arrive on time. A great user experience on the web site doesn't mean squat if this back stage "content choreography" goes wrong.

So I've been saying that it is essential to consider the entire network of services that comprise the back and front stages as complementary parts of a "service system." We need new concepts and methods in service design that recognize how back stage information and processes can improve the front stage experience.

My DocTrain talk didn't say very much that was new, but I adapted my message to the technical writing and content management crowd a bit. I just said that another way to think about the front stage fixation is that it gives too much credit to user interface designers for the user experience, and not enough to people who design (and communicate) the documents and document choreography that are necessary to make the end-to-end system work. I'm not trying to take credit away from user interface designers, but they need to appreciate that the back end folks deserve some too.

This adapted message resonated with the DocTrain crowd. I had MIT Press ship 2 boxes (32 copies) of the paperback edition of my Document Engineering book for me to do a book signing after my talk, and the books sold out with people standing in line. Many of them then went and ordered the book on Amazon, and this jump in sales drove the book to #3000 for a short time (it has now recovered from this hyperstimulation in sales and is much lower now). And I'm flattered to discover today that several people have blogged positively about my DocTrain talk.

Antoine Giraud: "Content Choreographers Unite"

Anne Gentle

Sarah O'Keefe

So thanks for the encouragement. I hope that Scott Abel invites me to talk again at DocTrain.

-Bob Glushko

Whining About Wine and Champagne

2008-04-27T15:20:00.000-07:00

I've written a lot about categorization and naming because they are not just important concerns in document engineering but also in "making sense of the world" more generally. I've discussed these issues as they apply to lobsters, planets, prescription drugs, airport security screening, and other equally diverse subjects precisely because they are such fundamental and ubiquitous concerns. And today I get to write about categorization and naming for wine and champagne, prompted by a story in the 27 April 2008 New York Times titled "Produced in Champagne, but what do you call it?."

The point of today's story is that a village in Switzerland called "Champagne" that has been around for about 1200 years is being beat up by France and the European Union and not allowed to use its name for any of its agricultural products, including wine. So it can't label wine it makes as "wine from Champagne" now, even though even though until 2005 this was allowed.

And there is especially no way that a winemaker from Champagne in Switzerland can call sparkling wine "Champagne," i.e., it can't call any wine "Champagne from Champagne." According to French law, you can only use this name for sparkling wine if you follow a precisely specified production method using grapes from a precisely specified part of the "Champagne Region" about a hundred miles east of Paris.

But this so-called "region" didn't seem like a region to me, because I usually use that word to mean some kind of contiguous geographical area, perhaps defined by explicit features like rivers or mountains or borders. Instead, the "Champagne Region" is defined by enumeration, and it consists of 319 communes (municipalities) in numerous disconnected areas. Being on this list really matters, because CR-designated land is worth 200x as much as adjacent land that is not as lucky to have the CR-label.

So perhaps isn't surprising that there is lots of pressure to expand the size of the Champagne Region, and another New York Times article ("A Tempest in a Champagne Flute" on 27 December 2007) describes the intrigue around a secret plan to add another 40 communes to the lucky CR club. Now I admit that I don't understand all the criteria being applied to decide who wins and who loses, which according to the NY Times are:

Champagne's history, geography, geology, agronomy and an obscure field called phytosociology, the study of plant communities.

Nevertheless, it is a little amusing to imagine that if the debate were really about following the rules or applying scientific principles to the definition of the Champagne Region, wouldn't it be possible that some of the 319 currently lucky communes might be found out as pretenders and kicked out of the CR club? But that doesn't seem to be happening, and the club is getting bigger because global demand for sparkling wine is growing and France's market share is declining. (If you really care about this issue, read Tom Stevenson's Champagne's €6 billion expansion) to see how what's really going on).

Let me end this story about wine naming and categorization with two things closer to home. First, I knew a little bit about the naming rules for champagne because I've visited the Schramsberg Winery in Calistoga California, which bills itself as "America's First House of Sparkling Wine." They don't call what they make "champagne," but they make a point of telling you that they follow the traditional "méthode champenoise" for making it; i.e., "we make it exactly like they do back in France where they call it champagne, so draw your own conclusions." So they want to get you to call it champagne without calling it that themselves.

Finally, in that same Napa Valley town of Calistoga there is another labeling fight going on that involves wine of the regular, non-sparkling variety. There was a story the first week of April in the San Francisco Chronicle ( "Overhaul of labeling rules stirs up wine wars") about a dispute over regional labeling of wines by the origin of their grapes. A famous upscale winery in Calistoga called Chateau Montelena petitioned the federal government to create a Calistoga "American Viticultural Area." However, a less upscale winery called Calistoga Cellars whose grapes aren't exclusively from Calistoga would then be forced to change its name, even though it is located in the town of Calistoga.

I'm not going to take a clear position on this California dispute, because I've been to Chateau Montelena (it is a gorgeous winery, with Japanese water gardens etc. well worth a visit) and like their wine, and I don't want to get on their "watch list" and banned from their tasting room and winery. But we seem to be creating these AVA categories pretty rapidly and capriciously, and even if the Calistoga AVA is created, I don't see why the use of a term like Calistoga to mean "grapes from here" has retroactive priority over the use of the term to mean "our company is from here," especially if Calistoga Cellars makes no false claims about the origin of its grapes. Seems like they are getting the Swiss treatment, and like the village of Champagne, they're getting it from the French, or at least from a winery with a French name.

-Bob Glushko

Document Engineering for Microfinance in Developing Countries

2008-04-20T16:05:00.000-07:00

While I read some papers for my course, ICTD (Information and Communication Technology for Development) reading seminar, I thought of the roles of document engineering for microfinance in developing countries. Microfinance is the provision of financial services, including credit, loans, savings and insurance, to poor and disadvantaged members of society. This has emerged as one of the most effective methods of financial development and poverty alleviation.

For this microfinance, I could find two possible challenges that document engineering could address:

- first, much of microfinance in India is built upon the grassroots group. Individual members in this group deposit money into a common fund, which is in turn lent to other members at a mutually agreed interest rate. This group sometimes forms larger structures by linking with other groups to form a federation to finance much bigger money. Each person, each group, and federation have their own set of complicated ledgers and forms to store and manage financial transactions. However, there are redundant and unnecessary data formats. So, there have been inefficiency in maintaining overlapping documents to exchange information among difference groups, and form a federation. Therefore, there is room for improving this problem by standardizing documents and data format.

- second, there are information asymmetries between groups who are and are not accessible to village banks. Members with easy access can invest in different types of projects with greater returns to scale, which in turn exacerbates polarization even between poor groups. Therefore, equal access to information does really matter. In terms of document engineering, the sharing of information with clear rules and updated news could help eliminate the information asymmetries.

ICTD aims at developing the third world using information and communication technology. So, I think there could be a variety of scenarios, which document engineering can play a role for, as in those two examples of the microfinance.

-Luke Rhee

Paving (only part of) the Cow Path

2008-04-10T11:21:00.000-07:00

I've been teaching process analysis and design in my Document Engineering course at UC Berkeley and I gave my annual admonition against "not paving the cow paths." I'm not sure where this expression comes from, but it is widely used to mean "don't just automate the AS-IS model" and is almost always meant to be a derogatory comment.

…with one exception: I've heard people in the "microformats" club use the cow paths phrase with pride when they create little languages that do nothing more than codify ordinary practice…

But I think that not paving cow paths is essential advice because even though there is usually some benefit to automating previously manual processes, the largest ROI often comes from new business models that were not possible without the automation.

This week I used two case studies to emphasize this point about needing to come up with "TO-BE" models. One was about Intel's use of RosettaNet to increase the efficiency of its component supply chain. The second was about a European supermarket chain's plans for RFID to enable demand-driven consolidation and shipment and replenishment.

So I note with was some amusement that my wife (also a Berkeley professor) recently received some email "Remittance Advice" from the UC Berkeley Disbursements Office, telling her that she was getting an electronic deposit to our checking account as a reimbursement for some expenses. The campus made a big push a few months ago to encourage everyone to sign up for direct deposits with the promise that it would speed up reimbursements, and who could argue with that? But they didn't do anything on the front end of the process, and there is still no way to submit reimbursement requests electronically. So my wife submitted expenses on paper back in November, and for four months they worked their way along the cow path until they finally reached the paving in the disbursement office. What's the point?

The next time I mention cow paths in a lecture I'll emphasize that if all you can do is pave the cow path, at least pave all of it.

-Bob Glushko

Taiwan Missile Myopia – It’s data quality that matters!

2008-03-30T07:20:00.000-07:00

This last week (26 March 2008) the US Department of Defense confessed to making an embarrassing mistake – discovered only recently – that a year and a half ago it sent Taiwan four high-tech electrical fuses for Minuteman missile nose-cone assemblies instead of UH-1 Huey helicopter batteries. Because these missiles carry nuclear warheads, most of the commentary about the story has been concerned with nuclear proliferation in general or on the more specific impact on US relations with China, which views any military support of Taiwan as an intrusion into domestic affairs. But I think that focusing on this specific episode – this "Missile Myopia" – is missing a bigger point.

I recognize that this mix-up has political implications, but it is probably not uncommon for the wrong items to be shipped from supply warehouses. The DOD hasn't said anything specific about the part numbers or classifications for the mixed-up items, but perhaps they are easily confusable – visually similar (1 vs. l [that's "one" and "lowercase L"]), or transpositions (ab vs. ba) or transformations (abba vs. abaa [doubling errors are common typing mistakes]) of each other.

(There is a mini-science about these kinds of confusability and typing errors, and unfortunately it is often exploited by spammers and domain name hijackers [e.g., micorsoft]).

Or perhaps the part numbers for electrical fuses and helicopter batteries are the same (after all, they certainly come from different suppliers, and every supplier creates his own numbering scheme) and the real mistake is that "classified" or "unclassified" parts were put into the same part of the supply warehouse.

By coincidence, less than a month ago in my Document Engineering course we read a short case study article from CIO Magazine called
"Operation Clean Data" that describes several efforts to deal with bad data. The first is dead-on relevant to this current Taiwan Missile Crisis. It concerns the British military's efforts to clean up the information in its supply chain by reconciling 850 different information systems, and integrating three inventory management systems…

To one system, stock number 99 000 1111 was a 24-hour, cold-climate ration pack. To another system, the same number referred to an electronic radio valve. And if hungry troops were sent radio valves instead of rations, the invasion and rebuilding of Iraq wouldn't have gone very far.

The British military isn't helping us much in Iraq any more, but if it still wants to help us win "the global war on terror" maybe it can send us some of their data cleanup people to help us fix our supply warehouse problems.

-Bob Glushko

Turning Your Brand into a Destination

2008-03-26T11:47:00.000-07:00

We are all familiar with places that are named after geophysical features (Land's End, Three Rivers, Spring Mountain Road), after road and highway "architecture" (Five Points, Spaghetti Junction), or after a person with some actual or inspirational relationship to the place (Berkeley, Jefferson City, Tyson's Corner).

(In another post here about naming, I discussed how the FAA has made airplane navigation points more memorable by giving regions distinctive semantic "landmarks." For example, the nav points around Montpelier VT are HAMMM, BURGR, and FRYYS, while the series of points that guide pilots into St Louis include SCRCH, BREAK, FATSS, and QBALL).

Occasionally a place becomes strongly associated with a business establishment and this name supplants the previous name for it (e.g.,the shopping mall called the Metreon is now a more salient place for most San Franciscans than "Yerba Buena Gardens"). But this week I learned of a new twist in assigning names to places to make a business name its original name.

A full-page ad in the 24 March 2008 "Business Week" contains an offer by the Roads and Transit Authority of Dubai Metro titled "turn your brand into a destination" that is described as "the ultimate branding and marketing opportunity."

The ad says that I can put my brand on a Dubai Metro station of my choice, or one of the two lines in the Dubai Metro Network. It would be intriguing to have a "Bob Glushko Station" in the Dubai Metro, but I don't feel like getting into a bidding war with Coke or Price Waterhouse or IBM. I wonder if the RTA would accept a Christian Broadcast Network station (I've sent the RTA an email asking about their terms and conditions... I'll post a follow-up if I hear back).

But what really intrigues me is why a country as wealthy as the UAE, whose foreign currency reserves are in the hundreds of billions of dollars, could possibly need the money from selling off its naming rights. It isn't like poor San Francisco, which has changed the name of its publicly-owned baseball park three times (Candlestick, 3Com, Monster) to raise a few million bucks. And naming rights or no naming rights, everyone here still calls it Candlestick.

(No, I'm not talking about the privately-owned baseball park in San Francisco, which has been officially "branded" by its owners as PacBell Park, SBC Park, and AT&T Park and unofficially branded by a lot of us as "Barry Bonds Park" since Barry is why most of us ever saw a baseball game there).

-Bob Glushko

Congratulations to Covisint

2008-03-13T17:36:00.000-07:00

I was very pleasantly surprised to run across an article in my printed copy of Information Week (25 February 2008) titled "Covisint Drives New Niche in Health Care Exchange Market." The story announced that Covisint will be using its "secure on-demand collaboration platform" to support "the nation's first statewide e-heath network" in Tennessee. But what was the big news to me was that Covisint now hosts exchanges in all sorts of different industries. I had just never noticed, so I want to offer my belated congratulations to Covisint for reasons I'll now explain.

It turns out that I have some very significant history with Covisint. I was in charge of XML architecture and standards at CommerceOne in 1999 when automakers GM, Ford, and Chrysler set up Covisint and chose our "Marketsite" software as the "secure on-demand collaboration platform." A joint approach to e-business for multiple automakers made a lot more sense than going it alone because so many suppliers in the auto industry provide materials and components to more than one OEM. This deal was huge for CommerceOne because it was the first significant vertical or industry-focused exchange we'd won – up to then we'd been selling to telcos setting up horizontal, regional exchanges. The deal happened in the fall of 1999 and caused a huge run up in CommerceOne's stock price that I took full advantage of at the end of December when our 180-day post-IPO "lockup" expired and we were allowed to sell stock. I have always felt grateful to Covisint for their vote of confidence in CommerceOne because of this very direct impact it had on my life since 1999.

But in the following couple of years Covisint just didn't get the traction that everyone hoped and the original automotive B2B exchange more or less fizzled out, and at the same time CommerceOne went into a tailspin like so many other Internet bubble companies. So after I left CommerceOne and started teaching at UC Berkeley in 2002, I didn't pay much attention to Covisint, which by then had been sold and reorganized.

I always had a very abstract notion of the "marketplace" platform we invented at Veo Systems (a start-up CommerceOne acquired in 1998) – you can see this in the patents we filed in 1998 (like this one) that describe how:

A market making node in a network routes machine readable documents to connect businesses with customers, suppliers and trading partners

The self defining electronic documents, such as XML based documents, can be easily understood amongst the partners.

Definitions of these electronic business documents, called business interface definitions, are posted on the Internet, or otherwise communicated to members of the network.

The business interface definitions tell potential trading partners the services the company offers and the documents to use when communicating with such services.

You see — there is no mention of telcos or auto makers or healthcare providers or any specific industry here – it is just a platform on which a market operator hosts services implemented using XML document interfaces. That's what we invented back in 1998, and it is really gratifiying to see how Covisint now embodies this elegant vision as a platform for services in so many different industries.

So congratulations, Covisint.

-Bob Glushko

Open, Configurable Workspace and the “paperless office”

2008-03-12T00:00:00.000-07:00

Our recent class reading about the “Myth of the Paperless Office” and the case of DanTech reminded me of the recently-built CalIT2 building I used to worked in at UC San Diego.

The layout of the building is very similar to the description of DanTech’s new venue given by Sellen & Harper. It has wide, open spaces with highly mobile furniture that allow people to reconfigure their working environment. Each wheeled desk is equipped with a computer, along with a small, wheeled storage unit to hold documents and office supplies. Hallways around the perimeter are lined with large whiteboards and chairs, encouraging impromptu meetings and contributions.

I did not realize the minimal use of paper in my workplace until I reread this piece. As the authors point out, reducing the amount of paper stored at a desk “[breaks] the shackles” or anchors that tie a user to a bounded physical space. In the case of my former workplace, the open spaces and minimal storage areas, along with the work processes, facilitated the reduction in paper use. However, like the DanTech case, paper is not completely absent from the workplace. As the authors point out, there are many affordances that paper lends to users. In my case, paper was used as reminders of recent tasks or upcoming events, and to take specific meeting notes.

I think paper is too useful to disappear completely from the work environment. Unless technology produces something that can provide/emulate the almost-innumerable affordances and uses of paper, I believe it is safe to bet that paper is here to stay.

-Michael Lee

On a related note, here are links to descriptions of my Interactive Cognition Laboratory colleagues’ works on similar topics:

Studying how layout affects work

Context Aware Office

Synchronizing the World of Commerce

2008-03-09T19:15:00.000-07:00

My most recent lecture (2008-03-05) in my Document Engineering course was about the "Co-evolution of business patterns and technology." This lecture marks the transition between the first part of the course in which I teach business model, process, and information patterns to give students some abstract conceptual foundations for the second part, in which I teach analysis and design methods for identifying and applying those patterns.

One of the themes of this co-evolution is that information about goods now has value independent of the value of the goods. That is, information about where products are, who uses them, and when and how they are used can be worth more than the products themselves.

So it was a nice coincidence on the day before my lecture that I was gazing outside my office window and noticed the UPS delivery truck parked in front of South Hall, the home of the School of Information where I work at UC Berkeley. Because of UPS' ubiquitous brown delivery trucks, most people would think that UPS is in the "delivery business." But it isn't. The slogan on the side of the truck is “Synchronizing the World of Commerce," which emphasizes the information about deliveries that UPS captures and manages, not the deliveries themselves. None of my students knew "what business UPS says it is in" when I asked them during my lecture, but they do now.

There have been many other posts here that touch on different aspects and case studies of these "information supply chains." Here are some of them:

Paperless international shipping

Antonio, Your Ships Are Lost -- Don't Borrow from Shylock!

Food Information Services and "Produce Provenance"

RFID May Be Key To Finding Latest Mad Cow Case

-Bob Glushko

Yes, there is a "Biometric Markup Language"

2008-02-25T20:26:00.000-08:00

I need to more strongly impress upon my Document Engineering students that whenever they encounter a case study in which information or messages are buzzing around they should look for an XML specification that defines them. In the recent post about “ Smart Fitness Machines" Michael Lee and Jim Miller write about an interesting application of biometric technology to identify users of fitness equipment so that information about workouts can be easily tracked. Jim optimistically says that “they claim it is "open," and the company, Fitlinxx has agreements with various equipment manufacturers, so they have apparently achieved some degree of interoperability."

I always say that "the best thing about XML is that ease with which you can create a new vocabulary” and that the worst thing “is the same as the best thing: the ease with which you can create a new vocabulary." So it never surprises me to find some XML vocabulary that purports to encode information models in any domain. But I guess my students can't yet imagine this unchecked proliferation of XML and so they didn’t look to find a relevant XML spec after reading about this clever new stuff in the fitness industry.

Two of the stops in the “ Scavenger Hunt" that the students are currently undertaking to get some familiarity with reference models and pattern repositories useful in document engineering are the Cover Pages list of XML applications and OASIS, the global standards organization where a great many of the XML vertical specifications are incubated. I've looked at the former many times, and I'm on the board of directors of the latter, so I'm familiar with the XML spec development underway there. And sure enough, at OASIS there's a Biometric Markup Language standard already in place ("Providing a standard way to describe information that verifies identity based on human characteristics such as DNA, fingerprints, iris scans, and hand geometry") that would be the spec that Fitlinxx would be using if it knew how to make good use of XML.

I'll have to give my "best/worst thing about XML" speech in my lecture this Wednesday when I start talking about “Models of Business Information.”

--Bob Glushko

Smart Fitness Machines

2008-02-25T16:50:00.000-08:00

[Hitachi Fitness Machine Article]

Here's another incantation of a project that Joshua Gomez was considering for the Document Engineering course and I was considering last semester for the XML Foundations course.

I thought XML would be a good way to store people's workout data because workouts plans are usually highly structured. Joshua thought that RFIDs in a person's membership card would be a good way for a machine to keep track of workouts (i.e. weights, reps, etc).

In this case, Hitachi is using a finger-vein scanner for user identification.
It keeps track of a user's progress, displays it on an LCD, and changes the resistance of the weights accordingly, on its own.

I believe the current price tag of $17,000 per unit is too steep for most gyms to adopt this technology readily. This would be especially true for older gyms that already own working equipment. Perhaps another (more cost-effective) approach to this would be to develop some kind of add-on system that allows users to identify themselves (e.g. using RFID technology). An attached monitor would show the user their progress, and allow them to punch in new information. Of course, weights would have to be adjusted manually in this case, but come-on, you are at a gym... you shouldn't really be complaining about moving a pin from one weight to another.

-Michael Lee

D-O-C-U-M-E-N-T vs U-N-C-E-O-M-D-M-D-M-T

2008-02-24T05:57:00.000-08:00

Samuel Driessen recently asked a very sensible question about the D-O-C-U-M-E-N-T checklist that students in my Document Engineering course use to ensure a complete and consistent approach to analyzing case studies:

I was wondering if the order of the checklist mattered? E.g. shouldn't 'user types' be higher up than 'document types'?

The answer is "of course" … but let me explain. I teach Document Engineering as a set of analysis and design phases that yield implementable models of business processes and the documents they produce and consume to carry them out. We depict the sequence of these phases using a diagram that I often call the "snake" because the different activities are portrayed on it as a winding path that takes different modeling perspectives on some domain in order to understand it at conceptual and physical levels.

In practice different phases get more or less emphasis, depending on the management and strategy decisions that shape the project. Top-down or strategic efforts to align business organization and technology make the activities at the beginning of the path more essential. In contrast, bottom-up and more document-driven projects emphasize the phases near the end of the path. But the "snake" is a good view of the generic approach.

1. In the first phase, "Analyzing the Context of Use," business and task analysis techniques establish the context for a Document Engineering effort by identifying the requirements and rules that must be satisfied.

2. In the next phase, "Analyzing Business Processes and Patterns," we apply business process analysis to identify the information exchange patterns needed to carry out the desired processes, collaborations, and transactions in the context of use. These patterns identify documents that are needed, but only generally as the payload of the transactions. The complete specifications for the documents can't be determined without analyzing existing documents and other information sources.

3. During the next phase, "Document Analysis," we identify a representative set of documents or information sources (including people) and analyze them to harvest all the meaningful information components and business rules that apply.

4. In the "Component Assembly" phase we develop a conceptual model that represents the original information sources as well as new sources and arrangements of information required by the people and processes involved in the business.

5. Finally we move from analysis to the task of designing new document models. In the "Document Assembly" phase, we assemble one or more document models from the component model. If possible we reuse conventional or standard patterns to make the model more general and robust.

6. The new conceptual models we have created for processes and documents can be viewed as specifications for generating code or configuring an application that creates or exchanges new documents. These models represent substantial investments in understanding a context and capturing its requirements in a rigorous way, and using these models to implement a solution in an automated or semiautomated manner exploits those investments to bridge the gap between knowing what to do and actually doing it. In the Implementation phase these conceptual models are encoded using a suitable syntax and schema language to support their physical implementation. This is most likely to be XML, but because of the technology-neutrality of the design phase, the document models can easily be implemented as EDI or ASN.1 messages if necessary.

Ideally, the checklist for analyzing case studies would be a mnemonic that would follow the order of activities in the "snake" diagram. But I couldn't think of one. So if we map the D-O-C-U-M-E-N-T checklist to the snake, it looks something like this:

So yes, Samuel, "user types" comes before "document types." But I couldn't think of a word that had U come before D that would help anyone remember that.

Ride the snake!

-Bob Glushko

Health Care Interoperability Dilemma

2008-02-18T19:43:00.000-08:00

I’m currently reading through Dave McComb’s book, “Semantics in business systems” and finding certain chapters particularly meaningful to my master’s degree final project. Especially interesting is the section dealing with ‘Strategies for coping with integration’ on page 229. This is something I have been dealing with in the health care arena for a long time when developing internal applications, or integrating new proprietary systems. McComb discusses five approaches to system integration which include; Manual, big database, direct connect, point to point and message based. I certainly understand the semantic limitations of implementing some of these strategies (manual, big database, direct connect, and point to point), although I’m perplexed at the direction of both organizational and enterprise interoperability in health care given the current proprietary environment.

My final project, involving two other extremely talented iSchool colleagues (Jill Blue Lin and Katherine Ahern), is attempting to build a multi-device, clinical note entry and retrieval system for hospitals. Our focus is on prototyping some new technology involving voice and text menus, along with refining the process for note capture and retrieval. In the past few weeks, as our needs assessment has progressed, we have discovered how many clinical systems are tied into the note collection process. First, you need to have access to all the clinical staff information to associate a physician to a particular note. Then, it’s important to have access to ADT (Admission, Discharge and Transfer) messages, or the patient master table to associate a particular note to a patient. Finally, notes are closely tied to the hospital scheduling system. Administrators will often look at both scheduling and registration to find those patients that never had a note entered while at an outpatient clinic.

Given that all this information is critical in developing an application that’s meaningful to clinical note entry and retrieval, what’s the best way to proceed with integration? The problem with pursuing the majority of solutions discussed by McComb is that you’re duplicating the information that’s already available in a different system. Even the message broker solution (which is accomplished by HL7 engines in health care) provides the same messages to various systems to be stored independently. In addition, some added or edited information might not trigger a message to be generated. For example, a resident finishes a rotation with a particular hospital and is inactivated from the system. Should this edit not trigger and HL7 message and dependent application are not notified, there could be a variety of negative impacts (incorrect billing, compliance issues, etc).

What’s the next step for better integration? How can this issue of repetitive storage and asynchronous information be solved? Will the major vendors within the industry (GE, McKesson, EPIC, Siemens, Cerner, etc.) provide a web service or API for other companies to add value to their platform?

IT's own system of record - ERP4IT

2008-02-06T07:07:00.000-08:00

Article: IT's own system of record - ERP4IT
Related article: EnterpriseResource Planning for IT

ERP4IT is a term used to define a broad-scale integrated management system of IT automation system that enables IT to manage itself. There exist solutions that provide pivotal insights into financials and customers (with ERP and CRM packages) but there is none that delivers an integrated system of record, by which IT (and the CIO) can gain holistic insight into the value, cost and quality of IT services. IT’s own internal systems and processes are often so fragmented, inefficient, and redundant, that there is a strong need to build an ERP system for IT. Enterprise information technology is so highly leveraged that any improvement in its management would have a multiplier effect on the enterprise’s effectiveness.

D-O-C-U-M-E-N-T Checklist:

D -- data types and document types

All services delivered to the business by its IT department.

O -- Organizational transactions and processes

Following are some of the organizational processes that can be automated: Operation, support and maintenance (functional); supporting IT processes (eg. Asset and change management); element management (technical); enterprise architecture.

C -- Context (types of products and services, industry, geography, regulatory considerations).

Out of the major resource areas in an organization, only information (i.e., IT) lacks comprehensively integrated vendor solutions like ERP and CRM. ERP4IT aims to bridge this gap.

The problem is so complex that a common framework is required to seek data about the data and process to manage the processing. Enterprise information technology is so highly leveraged that any improvement in its management should have a multiplier effect on the enterprise’s effectiveness.

U -- User types and special user requirements

The users include all IT personnel in an organization. Further, the CIO of a company stands to benefit strongly from this approach of having an ERP system for IT.

M -- Models, patterns, standards that apply or that are needed.

The Software Portfolio Management Facility, a draft specification by the Object Management Group (OMG) has with great relevance to the ERP for IT problem. However, these specs have taken a backseat in the OMG’s approval process, overshadowed by the current Unified Modeling Language (UML) revisions. Further, there are competing efforts by the Distributed Management Task Force, the Business Process Modeling Language [BPML] effort, and more academic work around ontologies. A standard for IT service management is U.K.’s Information Technology Infrastructure Library (ITIL).

E -- Enterprises and ecosystems (trading communities, standards bodies, other standards that help scope the case study).

Standards in this area are being chartered out by several bodies like the Object Management Group (OMG), the Distributed Management Task Force and UK’s IT Service Management Forum working on ITIL.

N -- The needs (business case) driving the enterprise(s).

IT needs a comprehensive system for IT management, governance and security within an organization. Despite its success building solutions for capabilities such as finance, supply chain, and human resources, IT’s own internal systems and processes often are fragmented, inefficient, and redundant.

Desire for more effective outsourcing in particular is driving the call for ERP4IT. However, no vendor currently offers a comprehensively integrated ERP suite for IT, and this provides an opening for standards-based approaches.

T -- Technology constraints and opportunities.

Managing IT is hard. This is because:

- the concept of information as a resource is relatively new- it is difficult to metamodel the IT problem domain.

- technical challenges such as establishing workable information models for the problem domain .

- IT budgets emphasize hardware and often aren’t directly tied to high-visibility, business-sponsored projects.

Another thing to be cautious about is to avoid making the mistakes that ERP has made in the past.

RFID May Be Key To Finding Latest Mad Cow Case

2008-02-05T21:48:00.000-08:00

[URL]
http://www.informationweek.com/shared/printableArticle.jhtml?articleID=192300040

[Summary]
The Canadian Government has been successful for detecting cows with “mad-cow disease” through the distribution of RFID tags and the management of information on livestock. The US also started to take steps to protect the food supply, and IBM and TekVet launched an RFID system to monitor the health of cattle. Their RFID sensor is attached to the ear of a cow and sends the health data wirelessly to stations on a cattleman’s ranch. Then, a satellite transmits the data to TekVek’s data center hosted by IBM to process the information.

As of 2007, the US Department of Agriculture started to set up a series of databases that allow the livestock industry to track information across the US. Data from birth date to doctor visits and vaccinations for numerous types of livestock, including more than 90 million cows, would reside in those databases. Designing the system also means pulling together a communication infrastructure that allows state and federal health officials to send requests for information through the system in the event of an outbreak. The information will be held by private industry and the government will only have access to the information if something happens.

D-O-C-U-M-E-N-T Checklist:

D -- data types and document types (paying special attention to the former when they are used across the latter as the "glue" to connect processes)

This article shows how to manage data on cows from birth date to doctor visits and vaccinations through RFID tags. Also, in the RFID tags, the result of detecting the change of body status is expressed in a data form (even if there is no specified expression for this data in this article).

O -- organizational transactions and processes (the "business processes", described coarsely like "drop shipment" or precisely like "PIP 3A4")

Processes for this tag system sequentially include storing cow data at the moment when the health status of cows is detected; sending the data to the IBM data center; retrieving the data by the government. This leads to the disappearance of papers and pencils for reporting cow data.

C -- context (types of products or services, industry, geography, regulatory considerations -- the ebXML "context dimensions" described in section 8.2 of Document Engineering)

The success of Canada to find cows with ‘mad-cow disease’ has motivated the US to take step to set up the RFID system. Detection of mad-cow disease is strategically important for the US because it can hold back the export of cows, which has been one of the sources of profit.

U -- user types and special user requirements (these are "people" user types)

The main user of this system would be the government, who has access to the system to monitor if something wrong in the livestock industry happens all over the country.

M -- models, patterns, or standards that apply or that are needed
The information of the RFID system flows from an RFID tag on a cow’s ear through ranch’s station and then a satellite to a data center. Data types on the health status, regardless of what kinds of RFID tags and database systems are, should be standardized in order to collect data with no data integrity problem from all over the country into the database system.

E -- enterprises and eco systems (e.g., trading communities, standards bodies, other frameworks that help scope the case study)

Data production, management and consumption are accomplished by different participants – ranches, private companies and the government (sometimes, ranches) – respectively.

N -- the needs (business case) driving the enterprise(s)

Because the mad-cow disease can give negative impression to customer outside the US as well as within the US, it is important to detect the disease before cows come into the market. Above all, it is the matter of our life, so it is undeniable to track the health information of cows in the most efficient way whatever way it is.

T -- technology constraints and opportunities (legacy or interoperability concerns from existing technologies or implementations; new or improved processes or outcomes enabled by technology)

Data semantic and type standardization are really important to gather data from different cows in different ranches. It would be effective to define and model standard markup language for cattle’s health information based on XML, so that the language can enable data to travel over heterogeneous system environments flawlessly.

Luke Rhee.

Microsoft Joins Data Portability Group To Develop Info-Sharing Standards

2008-02-05T20:13:00.000-08:00

Article

Summary:

Microsoft announced that it joined DataPortability.org to enable web users to move personal data around web sites.

Today's web sites allow users to share data only with sites have direct business relationships. DataPortability.org, however, is suggesting standard rules to integrate existing open standards and protocols so that any web sites following the rules can share data with the data owner's permission. (Security and privacy are of great concerns here.) Other companies joined the working group includes Facebook, Google, and Plaxo.

The Microsoft's motivation is to benefit its 420M active users of Windows Live service by providing seamless foreign services (i.e., other web sites). Microsoft has also made an effort to enable users to move around web sites without entering passwords multiple times through an authentication gateway service called PassPort, though PassPort failed to be an industry standard.

D-O-C-U-M-E-N-T Checklist:

D - data types and document types

The data type the article talks about is virtually all kinds of user data stored in Microsoft's web sites which are not accessible in other web sites.

O - organizational transactions and processes

Almost no business transaction/process have been in this area.
Although Microsoft family web sites may share user data, it has been taken for granted that data stored in one site are not available in different sites. Therefore, users have to move their data explicitly and manually.

C - context

All services implemented in Microsoft's web sites are subject to the change.

U - user types and special user requirements

Every www user using Microsoft's web sites and other web sites joined DataPortability.org can benefit from the change. They will be able to access their data through different web sites.

M - models, patterns, or standards that apply or that are needed

First, web site should be reimplemented to be friendly to DataPortability.org's standard. (The standard should be able to incorporate different application-level protocols on which each site relies)
Secondly, a user authentication system, which can identify different identities in different websites same, is also required.
Third, security and privacy safeguards are essential.

E - enterprises and eco systems

The eco system includes all web sites participating in the DataPortability.org movement.

N - the needs driving the enterprise(s)

It is driven by the account incompatibility issue, which means a user needs to manage different accounts for different services. Therefore, user data stored in a site is not accessible by other sites.

T - technology constraints and opportunities

First, new sites should be implemented under the DataPortability.org's standard. It may restrict the degree of freedom when choosing an engineering technology.
Secondly, existing sites may be reimplemented when the standard is not compatible with the site.
But, there can be a synergy by sharing accounts on different sites. For example, user can reuse photos, which she posted on FaceBook, to print them out rather than upload over and over.

DK Moon

An E-voting Document Exchange Standard

2008-02-05T10:47:00.000-08:00

Article: XML to the E-voting Rescue

The issue of accuracy and trust in election results, most visibly raised in the wake of the 2000 US presidential election, is global in scope, as exampled by the recent upheavals in Kenya. Now, OASIS has announced development of a new XML-based markup language that provides a standard syntax for election data exchanges. EML (Election Markup Language) is designed to handle document transactions at every phase of the election process, from voter registration and authentication to ballot casting, confirmation, tabulation, and auditing. The standard focuses on the interfaces between components of the election systems, but doesn't address system back ends, such as the voting machines themselves. This security issue aside, The EML initiative is a step toward providing open, standardized electronic voting systems.

D-O-C-U-M-E-N-T analysis:

D -- Data types and document types (paying special attention to the former when they are used as the glue across the latter to hold processes together).

There are a number of document types involved in the election process, including the candidates list, voter registration, election role, ballot, result, and audit log. Important data types include the candidate id and voter id, which must pass from one document to the next. The candidate id is part of the final output—the result, but the the voter id must disappear at the point where a ballot instance is created.

O -- Organizational transactions and processes (the business processes described coarsely as drop shipments or precisely as “PIP 3A4”).

There are a number of transactions involved in an election, such as listing nominated candidates on a ballot, registering voters, verifying voter eligibility, recording votes, counting votes, and auditing the results. Developing a single unifying standard that can be applied to a wide variety of elections--local and national, governmental and institutional--strengthens the integrity of elections in general. For example, if an emerging nation is able to say that an election was conducted according to a verifiable international standard, the results of that election gain credibility.

C -- Context (types of products and services, industry, geography, regulatory considerations).

EML was developed in the context of global concern over election auditability and of increasing use of electronic voting machines. Therefore, an important objective of EML was to achieve interoperability with a wide variety of election practices, systems and hardware.

U -- User types and special user requirements (these are “people” user types).

The users of an EML-based voting system are the voters and the election officials. Voters must be identifiable as eligible and allowed to vote only once. In addition, it must be impossible to identify them with their particular votes. Election officials must be able to prove that an election has been conducted properly.

M -- Models, patterns, standards that apply or that are needed.

EML is a standard for building an election process. Creating an election process that uses EML also ensures that it meets the EML standard for validity. An important caveat is that, since EML focuses on data exchange between components of the election system, the internal workings of voting machines are beyond its scope. However, the document exchange process is handled by EML, ensuring that all ballots can be accounted for. This eliminates one source of error or tampering.

E -- Enterprises and ecosystems (trading communities, standards bodies, other standards that help scope the case study).

In developing EML, OASIS has collaborated with hardware and software suppliers, including EDS, IBM, Oracle, and Sun Microsystems, and international government agencies, such as the Council of Europe. Governments have a clear interest in promoting trust in the electoral systems. An important benefit for suppliers is the cost saving achieved through standardization.

N -- The needs (business case) driving the enterprise(s).

Elections are central to democracy and political stability. In recent years, paperless “electronic” voting has emerged as a successor to error-prone paper-based voting systems. However, the possibility of undetectable error or tampering in current “touch screen” voting systems removes the elements of auditability and trust that are crucial to the election process.

T -- Technology constraints and opportunities.

One of the major objections to current electronic voting systems is that their code is proprietary and secret, making audits a challenge. The use of an open standard like XML simplifies election auditing. The fact that XML is human-readable means that the results of an audit are more likely to be trusted.

- Jim Miller

Paperless International Shipping

2008-02-05T02:10:00.000-08:00

Article:

UPS Goes Paperless for Global Shipments and Returns

Summary:

This article describes UPS’s plan to go paperless for global shipments and returns. Besides reducing the 86+ million pieces of paper they go through each year, UPS wants their new system to reduce the work customers need to do to ship something overseas. Customs clearance and international returns are two main problems UPS wants to address.

By automating many of the processes needed to initiate a shipment or return to clear customs, mistakes are reduced and shipments are delivered faster. Furthermore, the number of personnel dedicated to global shipping services can also be reduced – which is great for smaller businesses.

UPS claims that their new service is easy to implement into existing electronic shipping systems. Once installed, the customer has to register their company letterhead and create a digital signature. Third world sites with primitive systems will continue to use printed materials, but should not affect the new system.

D-O-C-U-M-E-N-T Checklist:

D -- data types and document types

This article talks about reducing the paperwork to send shipments overseas and receive customer-return shipments. Since UPS processes more than 86 million piece of paper each year, going paperless will save time and money. They hope that their automated, paperless system will help tackle problems related to customs clearance and international returns.

O -- organizational transactions and processes

The overall processes of getting a shipment from point-A to point-B does not change much. Instead, through automation, transactions are easier to initiate and modify, coupled with improved error-checking. Additionally, the difficulty in creating documents for return shipments is reduced.

C -- context

The context of the article is that shipment overseas is difficult, especially with the documentation needed to get items from one place to another.

In this case, all of UPS international shipments are affected by the new system. UPS claims it will be “relatively easy to install the services” and will “go to customer sites to … [integrate the new system] for them.”

Customers with incompatible, primitive systems will continue to use paper, but should not affect the new system.

U -- user types and special user requirements

The users of the system are the shippers, recipients, and return-shipment customers.

Shippers must have infrastructure that can communicate with electronic shipping systems and be compatible with the UPS system. They must go through an initial registration process to provide a company letterhead and electronic signature.

M -- models, patterns, or standards that apply or that are needed

Since UPS says it will be easy to incorporate the new UPS paperless system into existing electronic shipping systems, there is likely some interoperability involved. It must work with the existing electronic shipping systems, interact with customs information, and provide tracking information.

Since UBL is a rising standard for documents including purchase orders and invoices providing strong data types and validation, it would be a good system to compare to.

E -- enterprises and eco systems

The ecosystem consists of UPS (transportation and distribution), customs, customers/recipients, and the small to large businesses that utilize its service. These groups need to communicate information reliably and efficiently to make sure the package gets to the correct location in a timely manner.

N -- the needs (business case) driving the enterprise(s)

Going to a paperless system (or near paperless system in the case of third world countries) will expedite shipping and delivery since less time will be used to fill out paperwork manually.

Filling out multiple pages of forms can be difficult to ship overseas. Another difficulty is the paperwork associated with return shipments. Automating many of these processes through paperless forms will help to “clear customs, reduce mistakes, and accelerate shipments.”

Improved shipping and returns will lead to more “purchase[s] over the Web.”

T -- technology constraints and opportunities

Constraints may include systems that may be incompatible with the UPS paperless system. Opportunity could include higher sales/shipments because of the reduced time spent on invoicing manually. It would also be easier to get up-to-date status updates and track shipments. Searching through invoices should also be easier since they are all under one system.

-Michael Lee

Electronic Document Management in Government Agencies

2008-02-05T00:21:00.000-08:00

Article: "The Promise of Paperless (The long-promised benefits of document management are coming to fruition)".

This article outlines several recent government initiatives aimed at facilitating the exchange of information and improving collaboration among various government agencies. By converting their paper-based document repositories into electronic format that can be easily queried and shared among multiple users, a number of state and local government organizations have achieved significant improvements in process efficiency and operational costs. In Hillsborough County, Fla., the Planning and Growth Management Department began using an electronic document management system to keep track of all the documents associated with the development of land (e.g., building permits and construction plans). Typically, an application for a new development project has to be reviewed by multiple divisions inside and outside the agency and if a paper document is being reviewed in one division, then another division cannot review the information at the same time. In contrast, applications submitted in electronic format can be easily reviewed by multiple parties simultaneously, which leads to reduced application turnaround time and improved service.

As another example, the Coroner's Office in Kane County, Ill., has recently replaced handwritten and typed documents with an electronic document management infrastructure (COAS). Previously, case information had to be entered manually multiple times on approximately 60 different forms and COAS helped eliminate this redundancy and simplify the data entry process. The organization reports a 50% reduction in the time spent on cases as a direct result of implementing COAS.

D-O-C-U-M-E-N-T Checklist:

D - Data types and document types
Government organizations tend to maintain large collections of documents that pertain to their activities and purpose. Some agencies manage a very broad and diverse set of document types that range from vehicle registration records to construction permits and court transcripts.

O - Organizational transactions and processes
Some familiar examples of “document-heavy” government processes and transactions include processing vehicle registration applications and the oversight of land development projects.

C - Context
Many government agencies are accumulating large volumes of data and are facing increasing challenges in managing and sharing their documents. Electronic document management systems are being implemented to reduce the amount of paperwork, facilitate collaboration, eliminate redundancy, and improve process efficiency.

U - User types and special user requirements
The primary “users” of electronic document management systems are government employees or their respective departments.

M - Models, patterns, or standards that apply or that are needed
A key requirement for an electronic document management is the ability to share information in a way that enables multiple authorized users to access and operate on the data simultaneously. This feature is essential to achieving process efficiency when a document must be reviewed by multiple cooperating departments.

E - Enterprises and eco systems
The ecosystem consists of a large group of government agencies that need to collaborate and exchange information in an efficient, reliable, and secure manner.

N - The needs (business case) driving the enterprise(s)
The push towards paperless document management is primary driven by the need to reduce operational costs and improve efficiency due to budgetary constraints.

T - Technology constraints and opportunities
One important constraint is the issue of migration from legacy systems – all existing documents must be scanned (or imported by other means) into an electronic repository. At the same time, electronic document management enables content-based search, which can be seen as an important opportunity to improve process efficiency.

Andrey Ermolinskiy

Electronic pedigrees coming to California

2008-02-04T06:50:00.000-08:00

Article: RFID Strategy -- Pharmaceutical E-Pedigree -- Biggest Supply Chain Topic of 2008

An e-pedigree is an electronic, auditable chain-of-custody record for pharmaceuticals from the point of manufacture to the point of sale. Paper-based pedigrees have been required since the passage of the Federal Prescription Drug Marketing Act of 1987 (PDMA). Although the FDA requirements for e-pedigree are stalled in federal court, individual states have moved forward with enacting their own legislation for compliance.

California has spearheaded the effort by passing new laws expanding the state standards. Effective January 1, 2009, all pedigrees will be required to include a serialization number. While products are currently identified on a general level by manufacturing lot numbers, the serialization number is unique to the item-level (shipping pallet of aspirin vs. each individual bottle). This is presenting companies with new challenges in maintaining a valid pedigree as the products are transported through the supply chain. Given California's large market size, this legislation may set a precedent for other areas of the nation.

D -- data types and document types

California is requiring each saleable unit to be identified with a unique serial number. Products are currently identified by the pallet-load using the manufacturing lot number, date, and purchase order information.

O -- organizational transactions and processes

The entire supply chain is affected by this change. Each saleable unit must be identified and recorded at every stage as it moves from the supplier to the customer.

C -- context

All pharmaceutical products for sale in California are affected. Companies may choose to adopt the processes developed for all products, regardless of their destination.

U -- user types and special user requirements

Manufacturers must generate serial numbers and make each unit identifiable by any entity which will accept custody of the pharmaceuticals. The California legislation does not specify the exact form of the electronic record or the technology so the data may be stored in RFID, barcodes, or other formats.

M -- models, patterns, or standards that apply or that are needed

One possible solution is to utilize a Global Trade Identification Number (GTIN) mapped into a 96-bit encodable EPC ID number. The global standard developed by EPCglobal, ratified January 5, 2007 contains two XML schemas available: the electronic pedigree format for use with open document-based pedigree laws and the standard electronic envelope format for use in document exchange between supply chain partners.

E -- enterprises and eco systems

EPCglobal is a non-profit consortium developing standards for Electronic Product Codes.

N -- the needs (business case) driving the enterprise(s)

California has mandated January 1, 2009 compliance; companies not in compliance must leave the market. FDA mandated requirements are on hold due to pending lawsuits.

T -- technology constraints and opportunities

Besides compliance with California law, companies will have the opportunity of improving their SCM with increased visibility, velocity of data, and business intelligence. Companies can also benefit during product recalls by returning only the affected units instead of returning a seller's entire inventory.

The California deadline may be pushed back to allow companies more time to implement the new processes. There are numerous technological hurdles including capturing the serial numbers at each point in the supply chain and modifying current systems to record the data.

Yu-Tin

Microsoft's vision on health care

2008-02-03T15:54:00.000-08:00

Related Article: "The vault is open" - Microsoft makes its big move into health care
http://www.economist.com/business/displaystory.cfm?story_id=9916512

Summary: Microsoft outlined a grand vision, Health Vault, an online personal health information database on which doctors can post electronic medical records such as "scans, lab results, test results, visit minute" and people can view all those health records and share information with health care providers and insurance companies. MS is arguing that storing health data on the internet is as secure as storing it in a bank, but there are all kinds of privacy and security questions remaining. Use of this system will be free both for the users, doctors and also for the vendors. In the meantime, MS's business model depends on targeted search.

"D-O-C-U-M-E-N-T" Checklist

D - Customers' health data, ranging from doctors' reports, scans, lab results, test results, visit minutes (these are from doctors) to daily measurements of weight or blood pressure, everything in digital form.

O - Basic idea of 'Health Vault' is to enable users to access to their personal health information records any time, anywhere, via the internet. Both individuals and doctors can post the health data, and by owner's grant, certain people have access to those information, such as an insurance company.

C - It's web-based service. Centralized health database has obvious benefits as well as scary problems. Efforts are underway to develop online patient databases to track physician and hospital performance, and the state could greatly benefit from these, but in order to attract any users in the first place, Microsoft has promised to enforce strict privacy rules. There are concerns over data security and privacy, coupled with difficulty in striking partnership deals.

U - Consumers will be able to post & view information, as well as myriad health care providers and insurance companies. Health care providers (medical offices and hospitals) who signed up for the service could easily send test results in digital form to the vault, and patients could authorize them in turn to have access to various, carefully circumscribed bits of their personal data.

M - Standardization of health-information in digital form is critical for interoperability. Currently, Health Vault's business model centers on advertising, particularly search-related advertising. Use of this system is free both for the individuals that sign up for them and for the vendors and doctors that provide services.

E - Health Vault is the name of MS's new health-information product, storing records online. In conjunction with this, MS is also launching Health Vault Search, a secure version of its health care search engine.

N - It is a general belief that centralized health care information system will lower the overall U.S. healthcare cost, and also that centralized health database represents the single most profitable social media endeavor imaginable, which is why many IT companies are trying (have tried) to this. It's also a blue ocean market since most consumers don't have electronic access to their health records.

T - (Constraint) Storing records online is not secure - nothing is secure on the web. (Opportunity) Health Vault's search engine would work better than those of rival sites if it could examine users' health records and past queries, and thus provide the responses that are most relevant to each individual's situation.

-Eun Kyoung Choe

Scamming an Automated Process

2008-02-01T08:17:00.001-08:00

The first assignment in my Document Engineering course this semester is to analyze a news story or "mini-case study" using the
"D-O-C-U-M-E-N-T" checklist I devised a year ago to ensure consistency and completeness in the review.

I'm going to use the checklist myself to set an example for the students. My story is from last August and concerns a scam by two South Carolina women who took advantage of a US Defense Department automated procurement and payment system to defraud the government out of over 20 million dollars.

The original news story was probably this press release from the Department of Justice but I first read about it in The Economist when it was reported in a story called "Creative Billing."

D -- data types and document types (paying special attention to the former when they are used across the latter as the "glue" to connect processes)

The story revolves around invoices for shipping costs. The invoices were for staggering amounts of money – the article mentions 4 of them, one for $998,798 and three others all greater than $400,000. The goods that were shipped cost almost nothing; the nearly million dollar shipping bill was for sending two 19-cent lock-washers to Iraq.

O -- organizational transactions and processes (the "business processes", described coarsely like "drop shipment" or precisely like "PIP 3A4")

The scam worked because the Defense Department used an automated purchasing and payment system that paid invoices automatically. It isn't a bad process to pay on receipt of the bills once they are reconciled with orders, but there should have been some better auditing of the numbers.

C -- context (types of products or services, industry, geography, regulatory considerations -- the ebXML "context dimensions" described in section 8.2 of Document Engineering)

The context of this story is the war in Afghanistan and Iraq, and the concern that Defense Department bureaucracy might slow the resupply of items needed by the army. The DOD has gotten lots of bad press about soldiers not having the right body armor and equipment (like the famous "Hillbilly Armor" episode when a soldier criticized =Defense Secretary Rumsfeld), and it is easy to understand why the purchasing and payment people at the DOD would try to speed up their processes so they’d not get blamed.

U -- user types and special user requirements (these are "people" user types)

The most central "users" of the system in this story were its "abusers," twin sisters Charlene Corley and Darlene Wooten, whose company committed the fraud by submitting the fake shipping bills totaling $20.5 million. Charlene will be spending 40 years in prison, but not with Darlene as a cellmate because Darlene killed herself when the government was closing in on them.

M -- models, patterns, or standards that apply or that are needed

The story reports that "the Pentagon has tightened its payment procedures in response to the sisters' scam." The business rules that they were following were simply too weak – the disparity between the cost of the goods and their supposed shipping costs should have triggered an audit.

E -- enterprises and eco systems (e.g., trading communities, standards bodies, other frameworks that help scope the case study)

The company had the clever name of “C & D Distributors” because those are Charlene's and Darlene's initials. It is hard to believe that this is the only case of fraud because thousands of firms must have used the Pentagon's purchasing and payment system.

N -- the needs (business case) driving the enterprise(s)

Wars are expensive to fight… and you'd hate to have to stop chasing the bad guys around Falluja because you're out of machine screws and lock washers. But it is more interesting to look at the needs that were driving the twin sisters to steal from the government. Because Charlene and Darlene were from South Carolina, the Economist used the popular Southern phrase that they were in "high cotton" after buying four beach houses, ten cars, boats and lots of jewelry.

T -- technology constraints and opportunities (legacy or interoperability concerns from existing technologies or implementations; new or improved processes or outcomes enabled by technology)

There was little mention of the technology used by the government. It would be great if the Defense Department would follow the lead of the Danish government, which requires all invoices to be submitted electronically using the Universal Business Language standard. That story is in the reading list for my lecture this coming Monday.

-Bob Glushko

Blurring the Blogging Boundary – Inviting My Students to Blog with Me

2008-01-24T18:37:00.000-08:00

As I recently wrote in a "Back to Blogging" post earlier this week, I now realize that I'd stopped blogging because I was too busy with my "real work" – which I'd defined as the teaching and writing and traveling and so on I did in my role as a Berkeley professor. This afternoon I caught myself in the act of building up that boundary again when I started to set up another blog as a discussion forum for my Document Engineering course that started yesterday when I realized that it would be much more sensible and interesting just to have all the students contribute to this blog. Otherwise I'd find myself in the ridiculous position of trying to decide whether a topic I wanted to discuss should be posted on "Doc or Die" or on the "official" course blog.

So I've now got two fellow bloggers here. The first is Zach Gillen, a 2^nd year Master’'s Student at the School of Information, who is the Teaching Assistant for the Document Engineering course. The second author is "Document Engineering Student," a composite identity that all of the students will share (they'll also sign their posts with their real names) simply to avoid the administrative hassles of having them create Google accounts and so on.

I think this will be an interesting experiment.

-Bob Glushko

Tracking Lettuce and Tracking People

2008-01-23T15:12:00.000-08:00

I like to start my Document Engineering course at UC Berkeley with news stories or “mini” case studies of the sorts you find in trade magazines that illustrate the rationale, design, implementation, or deployment of some document-centric or information-intensive application. It’s a good way to get students to see the big ideas of Document Engineering and to start appreciating the idea that there are design patterns for information components and document exchanges that apply across a wide range of industries.

Today I mentioned several of these “Document Engineering in the News” stories. The first one, from the March 13 2007 Wall Street Journal, was titled "Tailing Virulent Veggies” and described the efforts by Dole to use GPS and RFID technologies to improve the tracking of produce from the field to the supermarket. The E. coli contaminations of spinach in late 2006 killed people, but also greatly undermined consumer confidence in the quality of the food supply, costing grocery chains lots of money and customers. People are starting to care a lot more about information transparency in this domain (I wrote about this last year and Jon Udell had an interesting post a couple of weeks ago), but there still isn’t very much of it.

For a second story I chose an article from Hong Kong (mostly to give students the idea that they can find these kinds of stories anywhere) about a tracking program at the airport there “to simplify passenger travel by integrating airport, immigration and airline processes in real time, offering travellers a range of benefits.” I don’t believe that the security at airports has increased enough to justify the costs and intrusions, but that’s not the point of this example. I just wanted to illustrate that “tracking” is a generic information pattern that applied to all sorts of stuff – in these two cases to lettuce and people.

But this led to an interesting discussion in which we compared “tracking heads” for lettuce and people that has kept me thinking long after class ended. For example:

The same head of lettuce only goes through the supply chain once, while a person goes through the airline tracking system over and over. So there’s a tracking history that’s only relevant in the latter, and surely there are tracking analysis systems that are trying to figure out my travel patterns (like why did I make four trips to Boston in the past three months when I usually go there at most once a year?).

The way a head of lettuce feels when it gets to the end of its journey can probably be predicted very well by its travel time, temperature, humidity, and other objective measures of the conditions it encountered along the way. In fact, if Dole isn’t using the RFID and GPS technologies in this manner, it is missing out.

People are affected by these factors too, but not as predictably, because all the lettuce in a shipment travels the same way and some of the people heads get to rest in airport lounges and fly in first class and others don’t.

A head of lettuce doesn’t worry about information privacy.

A head of lettuce doesn’t have a bad attitude about, or doesn’t take it personally if the tracking person is putting out bad karma. A traveling person does, especially if it happens to be me.

-Bob Glushko

Back to Blogging

2008-01-23T15:07:00.000-08:00

It has been a long time since I posted to this blog, and I finally realized that it is because I’ve been acting like writing here was something I did as a kind of recreation in the time cracks between my regular teaching and writing work. But this past semester was especially busy because of some crazy complications in my personal life, and I didn’t have a lot of unfilled cracks, so I’ve made just one post here since August. I had been too busy even to notice this, until I got email asking if I had abandoned my blog. I hadn’t intended to stop posting… I just never posted.

But during that same time period when I had ignored this blog, I wrote about 50 new lectures for my two courses at UC Berkeley ( Information Organization & Retrieval and The Information & Services Economy), wrote two other papers, gave several professional presentations at meetings and conferences, and ran a very interesting research seminar. I estimate that I wrote 2000 emails to students, former students, or other folks, and probably half of them had some interesting information that might have been useful to other people if I’d exposed it here.

So today I’m going to see if I can blur that line between blogging and work, and see if I can use this blog to publish more of what I’m writing and talking and hearing about. Today was the first day of the spring semester, and I’m once again teaching Document Engineering. This will be the 7th time I’ve taught this class, and it will be the last time, and that’s another good reason to spend more time here reflecting about it as the semester progresses.

-Bob Glushko

An Interrogation in Helsinki

2007-11-17T18:10:00.000-08:00

A couple of weeks ago I served as the "opponent" in a Ph.D. dissertation defense by Paavo Kotinurmi of the Department of Computer Science and Engineering of the Helsinki University of Technology. The concept of an outside opponent was new to me – in my own experience getting a PhD from the University of California, San Diego, I had only to survive an examination by a thesis committee comprised of professors from my own academic department with a single "outside" faculty member from the same university. But it seems that outside the US, it is conventional for Ph.D. candidates to undergo a more elaborate and formal ritual with an external examiner playing a critical role. The detailed protocol for dissertation defenses at the HUT specifies numerous details, including the order in which the candidate, his advisor, and the opponent enter the examination room, exact words for opening and closing the session, and of course the dress code. Kotinurmi and his advisor, Professor Matti Hämäläinen, wore black tailcoats with white ties, and I wore my blue and gold academic regalia that indicate my University of California pedigree.

I was invited to be Koitinurmi’s opponent because his dissertation, titled "E-Business Framework Enabled B2B Integration," involved numerous issues that I spent a substantial amount of my professional and academic career thinking about -- the use of electronic documents, and especially document exchanges, in business processes; the role of standards and frameworks in document and business architectures; and the challenges posed when the participating businesses or services differ in the semantics of their documents or processes. In particular, Kotinurmi analyzed several frameworks and specifications for which I had either helped start, helped develop, or managed people who did so, including the eCo Framework, the XML Common Business Library, ebxml, the Universal Business Language, and RosettaNet. Kotinurmi ultimately selected RosettaNet as the framework on which to build an ontology system that would enable the run-time semantic harmonization of the documents being exchanged in supply chains for collaborative design.

Of course, if we completely agreed on everything, there would be no role for me as the thesis opponent. I began the examination by asking Kotinurmi why he sought to close the semantic gap at "run time" rather than at "design time." A design-time approach would have viewed the problem as a one-time cost to transform business documents and processes to achieve interoperability between the participating firms, whereas a run-time approach treats these as recurring costs. The answer, of course, is that treating the problem at "design time" would involve dealing with many business and organizational sociology issues, such as the respective power of the participants in the relationship, and these are not interesting or in scope for a computer scientist.

I followed up this line of questioning with a related one. Kotinurmi's work is grounded in academic discussion of B2B frameworks, standards, and integration approaches, and his literature review is quite thorough (there are 171 citations in his thesis, and I highly recommend it as a good reference source). But I challenged him by telling him that this review was too narrow and that he had equated "nothing is known about this issue" with "I found nothing about this issue in academic journals." We ended up having a good discussion about what he might have learned had he investigated information from vendors or practitioners, such FAQs, product documentation, implementation guides, and discussion lists.

My final line of questioning began by asking what the implications would be if Kotinurmi tried to generalize his work to handle a wider range of document payloads than just the RosettaNet ones. I followed that with questions about the implications of generalizing his work to handle a wider range of business process metamodels. In each case he gave good answers about how he might extend his ontology, but then I asked:

Is there anything inherently different between a process ontology and a document ontology?

There was a long pause. Finally, Kotinurmi said he didn't think so but he didn’t really know. I didn’t know either, and so I thought that this was a good point to end the exam.

We followed the exam with a celebratory reception, and then with a celebratory banquet. And just as there is for the thesis defense, there is a ritual for the celebration party, which goes by the name "Karonkka." This is presumably a Finnish word for "several hours of speeches, toasting, drinking, eating, and so on of the kind you'd want if you’d just survived a 90 minute interrogation about your dissertation from someone you'd met less than 12 hours earlier." During the Karonkka when it was my turn to speak I made a ceremonial gift of an autographed copy of my Document Engineering book and kidded Kotinurmi that if he'd read if before his examination he would have had an easier time.

I enjoyed my brief trip to Helsinki immensely, not just because I'd never been there and found it to be an interesting city, but because it was gratifying to travel 7000 miles and then have an intellectually stimulating discussion with someone with an ease as though we'd worked together for years. I also met several other people from HUT who are working in areas related to my more recent research on service design, and I expect that we will collaborate some. But when I return to Helsinki for a longer visit, it will be in the summertime and it won't be so dark and so damp.

-Bob Glushko

"Individual," "Cultural," and "Institutional" Categorization

2007-08-13T11:16:00.000-07:00

Last week at the annual meeting of the Cognitive Science Society, I organized and led off a symposium titled "Semantics in the Wild" with Paul Maglio (IBM Almaden), Teenie Matlock (UC Merced), and Larry Barsalou (Emory University). Our goal in this set of talks was to challenge the field of cognitive science to take a more comprehensive view of categorization and classification. These fundamental cognitive activities have been thought about for millennia (e.g., Plato vs Aristotle on whether knowledge is objective or empirical) and studied in the psychology laboratory for a few decades (e.g., reaction time measurements on judgments of category membership, like comparing the time to answer "is a robin a bird?" vs "is a penguin a bird?"). The four of us got together for this symposium because our own perspectives on categorization are very different and complementary -- while I have spent many years doing "business semantics" and " "document engineering," Larry has published dozens of papers on categorization studies in his psychology laboratory, Paul has studied how people manage information inside of large organizations, and Teenie has taken a psycholinguistic approach.

Paul, Teenie, Larry and I pointed out that in today's world of ubiquitous computing and ubiquitous information resources, we interact daily as individuals and as participants in organizational processes with a bewildering variety of information types, and we constantly make choices about whether and how to categorize them. So we're proposing to broaden the scope of research on categorization to study the explicit activities by individuals to classify web resources (e.g., flickr, del.icio.us, …) and institutional efforts to define and deploy category systems to achieve business and organizational objectives.

Our fundamental claim is that these different kinds of categorization and classification activities or systems lie in a continuous multidimensional space where we can identify three important regions:

Cultural Categorization Systems

Individual Categorization (aka "Tagging")

Institutional Categorization (aka "Business Semantics")

CULTURAL categorization systems are the traditional subject matter for research. These are acquired implicitly through development via parent-child interactions, language, and experience. Formal education can build on this, but the non-formal cultural system can often dominate.

INDIVIDUAL categorization systems are developed by an individual for organizing a personal domain to aid memory, retrieval, or usage. These can serve social goals to convey information, develop a community, or manage reputation. Individual categorization systems have always existed, but they have exploded with the advent of cyberspace, especially in applications based on "tagging."

INSTITUTIONAL categorization systems involve the explicit construction of a semantic model of a domain to enable more control, robustness, and interoperability than is possible with just the cultural system. They are often the collaborative artifact of many individuals who represent different organizational or business perspectives, and they are usually developed via rigorous and formal processes (e.g., in standards organizations like OASIS, where I'm a member of the Board of Directors). Finally, institutional categorization systems require ongoing governance and maintenance because of continuous changes taking place in related cultural and individual systems.

We frankly admit that our thinking isn't fully developed, but it seems that there are many very interesting and important issues to study when you take this broader view of categorization. In particular, we see a number of dimensions or tradeoffs that define the space of categorization activities, such as:

Explicitness vs implicitness
Semantic rigor
Effort to acquire and use
Individual vs group goals
Amount of reuse of other categorization systems
Nature and rate of change over time

This fall in my Information Organization and Retrieval course at UC Berkeley, I'll be using this new framework, and I think it will help students understand better how tagging by individuals in flickr or del.icio.us compares to the "institutional tagging" of business information in standard product classification systems like the United Nations Standard Products and Services Code (UNSPSC) or business vocabularies like the Universal Business Language (UBL).

- Bob Glushko

Bridging the Front Stage and Back Stage in Service System Design

2007-07-22T14:12:00.000-07:00

A couple of months ago I gave a talk titled "Bridging the 'Front Stage' and 'Back Stage' in Service System Design" at a conference (and wrote about it here). I've now turned that talk into a paper (with my graduate research assistant Lindsay Tabas as co-author). You can download the paper but let me say a few words about it because it represents a milestone in my evolving thinking about information and service design.

For most of my professional career I've designed and deployed information-intensive applications and systems. I wrote a book about Document Engineering and teach courses about it at UC Berkeley. And in the last year or so that I’ve been blogging here, a lot of my posts have been about business informatics, information supply chains, and document automation. In all of this work, writing, and teaching I've generally focused on the "back stage" where information is managed, transformed, and moved within and between business systems, and haven't paid much explicit attention to the "people parts" or "front ends."

But I've now come to recognize that it is essential to consider the entire network of services that comprise the back and front stages as complementary parts of a Service System. This paper is my first attempt to present a methodology for designing service systems that synthesizes (front-stage-oriented) user-centered design techniques with (back-stage) methods like Document Engineering for designing information-intensive applications. The paper briefly sketches the core ideas, especially those that most explicitly concern the interactions and tradeoffs between front and back stage design.

The typical design conflicts and tradeoffs between front and back designers are lessened by a service system perspective. Front stage service providers need capabilities for capturing information about front stage preferences, contexts, and events. This and other back stage information can then be exploited by the front stage to enhance the service experience.

Lindsay and I are working on a longer paper that more fully develops this approach, and I'm also developing a new course tentatively called "Design Models and Methods" that will be a good forum for seeing if a unified methodology is learnable and useful.

-bob glushko

Designing {a, with} Discipline in Service Science

2007-07-10T16:24:00.000-07:00

I’ve just finished writing a paper that will be published in a special issue on Service Science in the IBM Systems Journal in February 2008. This journal doesn’t allow authors to post accepted manuscripts before they are officially published, which strikes me as a bit quaint, but it is OK if I post the abstract and say that the full manuscript is available from me if you ask for it. So here's the abstract, and if you ask for the full paper (glushko at ischool.berkeley.edu), I'll send it to you.

The paper is called Designing {a, with} Discipline in Service Science, which is probably too clever but I like it and if you can't parse the title you probably won't understand the paper anyway. The paper was motivated by the call by IBM and others for universities to train students for new career opportunities in the information and service economy, usually urging the creation of a new discipline called “Service Science” or “Service Science, Management, and Engineering” (SSME).

Several professors at UC Berkeley are interested in topics that potentially fit into an SSME curriculum, and we might simply have declared that the Service Science curriculum consisted of the set of courses we were already teaching, putting old courses in new bottles. But that didn't seem very satisfying. We wanted to design a discipline of service science in a more principled and theoretically motivated way, and the paper explains what we did and why we did it.

Here's the Abstract:

Should we think of service science as a new discipline or simply as a new curriculum? Some might say it doesn’t matter. At the University of California, Berkeley, we cared relatively little about the institutional form that service science might take (i.e., what to call it and how to organize it), but we cared immensely about the intellectual form (i.e., what it would be about). We sought to design a discipline of service science in a more principled and theoretically motivated way – designing a discipline with discipline. Our work began by asking “What questions would a ‘service science’ have to answer?” and from that we developed a new framework for understanding service science. This framework can be visualized as a matrix whose rows are stages in a service lifecycle and whose columns are disciplines that can provide answers to the questions that span the lifecycle. This matrix systematically organizes the issues and challenges of service science and enables us to compare our model of a service science discipline with other definitions and curricula. This analysis identified gaps, overlaps, and opportunities that shaped the design of our curriculum and especially a new survey course which serves as the cornerstone of service science education at UC Berkeley.

If you're not up to reading the entire paper, take a look at the
Information and Services Design program at the School of Information at UC Berkeley.

-Bob Glushko

Interviewed by a Technometrician – Phil Windley

2007-06-26T18:20:00.000-07:00

This week I was flattered to be invited to do a phone interview with Phil Windley, whom many of you know from his Technometria blog, along with Scott Lemon and Ben Galbraith. We talked about the analysis and design techniques from the Document Engineering book and in particular about their application to the design of services and service interfaces. The essence of document engineering is that it provides practical methods for developing robust and interoperable semantics – which is harder than it seems to most people, which is why a lot of interfaces are neither.

Phil, like Jon Udell (with whom I’ve done a couple of podcasts about service design and document engineering), is a good interviewer who does a lot of preparation (he proved it by using lots of jargon from my book). He skillfully led me to rant about some of my favorite topics, like these design continua that many people want to force into binary choices, often in an ideological, good vs evil sort of way:

Data vs documents

Microformats vs Domain-Specific Languages (aka "heavyweight" schemas)

Mashups vs Composite Services

We discussed my new research project at UC Berkeley that I call
Bridging the front stage and back stage in the design of information services. I just wrote a conference paper about this and I'll probably excerpt it for my next post.

We also discussed a new course I'm planning to teach at Berkeley whose title will be "Design Models and Methods," (or "How To Build Stuff that Will Actually Work.") The common theme of the research and course is that we need more integrated approaches to designing interfaces (front ends or front stages) and the information systems and services that enable them or give them something to do (the back ends). This course is based on a research project that I call Project M, to make it sound mysterious and profound.

There’s a funny point in the interview where I am asked about the Glushko Crater on the Moon, a link to which appears on my home page. This is named for VP Glushko a famous Soviet scientist who was an important leader in the Soviet rocket and space programs (and probably a distant relative). But I tell people who don’t look carefully that the crater was named after me to honor the great contributions to mankind made by document engineering.

You can replay the interview as a podcast in the IT Conversations series.

(It has been a long time since my last post here. I spent three weeks in Turkey and got out of the habit).

-Bob Glushko

Catchy Concepts from "The New Software Industry" Conference

2007-05-11T17:00:00.000-07:00

I just took part in a conference on the "New Software Industry" organized by Carnegie-Mellon University's SilconValley campus and UC Berkeley (that was held at Microsoft's Mountain View offices [which were many times larger than I imagined they'd be]). I didn't know what to expect because the conference agenda seemed like a bit of a smorgasbord but it turned out to be more interesting than I'd counted on.

Whenever I attend a conference I try to make note of catchy phrases that I hear and then try to be on the lookout for them to see if they stick. There were quite a few of them.

Ray Lane, now a VC (Kleiner Perkins) and formally a top executive at Oracle talked about No-Man's Land in business models: Where you don't want to be as a software firm, in between nimble start ups and the dominant firms in particular sectors.

Michael Cusamano, a MIT business school professor and hyper-prolific author (I own The Business of Software, Microsoft Secrets, and Competing on Internet Time and that's fewer than half of the books he's written) talked about Sweet and Sour spots in the mix of products and services for software firms. Things are sweet when a firm starts to offer services (because there is plenty of profitable low-hanging fruit) but then profitability suffers until the firm nearly completes the transition to mostly services. Strategy is hard, and it isn't surprising that so many CEOs and firms aren't good at it.

My good friend Paul Maglio from IBM Almaden Services Research (who like me got a PhD in Cognitive Science from UC San Diego) gave a very animated talk about Service systems and everyone was impressed that he could rattle off his definition of them as

"value co-creation configurations of people, technology, internal and external service systems connected by value propositions and shared information"

John Zysman, a Berkeley political science professor was in the same session as Maglio and talked about service stories - because service systems are embedded in social and economic systems, the rules and roles that govern them can be very different depending on who is designing or describing them.

Tim Chou, who headed Oracle's efforts to move to Software as a Service and now has written a book about "The End of Software" (his former boss Larry Ellison probably uses it as a doorstop) talked about the nifty 9 – 9 firms that seem to be making it with SasaS business models. Chou's point is that we need to pay attention to more than just salesforce.com, everyone's poster child for SasaS.

Data lock-in – (from a panel on open source) – the dark secret that you have be wary of lock-in from vendors who can claim compliance with open source and open standards but whose business model depends on keeping your data. Also from that panel was the catchy concept of the open source lever – the tool for putting pressure on your competitors' business models by releasing your own software as open source to undercut them.

Some really great phrases came from a "debate" between Adam Blum (VP of Engineering at Mobio who was a colleague of mine at Commerce One) and Martin Griss. They debated the value of agile software methods, which were described as release, learn, change and systematic lightweight process" in contrast to the ponderous overhead of more rigorous software engineering approaches. I was almost ready to jump onto the agile bandwagon until I heard that it enabled emerging architecture which struck me as a complete oxymoron. Any architecture that emerges rather than exists at the beginning ain't architecture.

Bill Burnham (a VC) had the funniest catch phrase of the event when he said that he gets pitched a lot of hopelessly naïve business plans that follow the same Triple A Business Model of AdSense, AJAX, and Arrogance. I am going to spread this phrase into my students' vocabularies because it so concisely debunks the Web 2.0 hype.

I'll end with the buzzwords from the session that I did with Shelley Evenson of CMU (the mother ship in Pittsburgh) on Bridging the "Front Stage" and "Back Stage" in Service System Design Here's the abstract I wrote to frame the talks that Shelly and I gave:

Many approaches to services design emphasize the "co-production" that takes place in the "front stage" of face-to-face, high intensity interactions between the person providing the service and the one receiving it. But the explosive growth of self-service applications and web-based services has made it apparent that the "back stage" of services, especially those that are information-intensive, is also a critical contributor to service quality. In this session a "front stage" and "back stage" service designer discuss the need for a more comprehensive and end-to-end perspective on service design, what they can offer each other, and what they need to learn from each other.

Those of you who know me well are probably stunned to learn how much I'm reaching out to user interface and "experience design" people. For many years I focused on the information and process modeling parts of system design and didn't teach or talk much about the "front stage" of systems. But now that I'm getting into service design and have bought into the "service system" concept (or as Paul Maglio puts it - "value co-creation configurations of people, technology, internal and external service systems connected by value propositions and shared information") it seems important to recognize that the front stage is a part of it.

-Bob Glushko

Wal-Mart's Healthcare Trojan Horse

2007-04-26T12:49:00.000-07:00

This week Wal-Mart announced that it will significantly expand a program to operate in-store health clinics that it began a couple of years ago. About 80 in-store clinics currently provide routine care for simple non-emergency problems like sore throats and ear aches. They are operated by third-party medical providers who rent space in a Wal-Mart store, just as you often see banks, fast food franchises, and post offices offering services that complement superstore shopping.

Wal-Mart plans to open another few hundred clinics in the next two or three years, and "if current market forces continue, up to 2000 clinics could be in stores in the next five to seven years" -- that's about half of the number of stores that Wal-Mart currently has in the US. Of course Wal-Mart keeps opening stores, but nonetheless, you can easily see that if every second or third Wal-Mart has a clinic it will substantially change the way that people get routine health care.

I don't shop much at Wal-Mart, and I didn't know about the in-store health clinics. But now another Wal-Mart initiative from late last year makes a lot more sense. In "Big Employers Plan Electronic Health Records" they announced along with Intel, BP, and other big employers (between them they have millions of employees) a plan to create an electronic health record standard and store records in a multimillion-dollar-data warehouse linking hospitals, doctors and pharmacies. Wal-Mart's huge purchasing power will drive costs down and mandate the use of bar codes, RFID, and other technologies that improve the end-to-end efficiency of the "healthcare supply chain." So Wal-Mart's gazillion customers as well as its employees (and many of Intel's etc.) will eventually be brought into the EHR system, and the in-store clinics are the perfect "Trojan Horse" to make that happen naturally and painlessly. We might actually end up with a semi-efficient healthcare delivery system in this country thanks to Wal-Mart.

-Bob Glushko

Talking with Jon Udell about "Information and Service Design" at Berkeley

2007-04-15T09:43:00.000-07:00

This past week my UC Berkeley School of Information colleague (and Dean) AnnaLee Saxenian and I did a phone interview with Jon Udell for his "IT Conversations" podcast series. We mostly talked about the new Information and Services Design program. In particular, we discussed the papers and presentations that our graduate students gave at the March 2 Symposium that marked the "birthday party" for the ISD program.

(Jon, like you, is one of the millions of people who avidly read my blog, and that’s how he learned about this…)

I just listened to the podcast, and it is remarkable how much interesting discussion is crammed into a half-hour interview. Jon really did his homework watching the webcast of the Symposium in preparing for our interview because he specifically commented about a half dozen or so of the 11 presentations, and we talked quite a bit about these:

Elizabeth Goodman, "Destination Services: Tourist Media and Networked Places"

Saud Al Shamsi, "Service Quality in the Physical and Virtual Marketplace"

Andrea Moed, "Generative Logging: Product Information Histories as Drivers of Service Ecologies"

Lindsay Tabas, "Developing a New Services Design Methodology"

Listening to the podcast reminded ne how unique our school is, and how personally and professionally enriching it has been the last year or so working with Anno and others to develop our new course on the Information and Services Economy (which I sometimes describe as "from Adam Smith and Karl Marx to web services"), putting on a weekly Service Science lecture series (for which Jon Udell is an upcoming speaker on May 1), and getting this new ISD program off the ground.

We’ve got a great "intellectual mash-up" going on with "service science" here at UC Berkeley, and if I weren’t already part of it, listening to this podcast would make me want to join it.

-Bob Glushko

Food Information Services and "Produce Provenance"

2007-03-15T20:32:00.000-07:00

In my last post I wrote about the new program in "Information and Service Design" that we've started at UC Berkeley and about the Symposium we held on March 2 to mark the ISD "coming out" party. Eleven graduate students in our School of Information presented their research, and every one of their papers is worth reading, so if I felt the need to blog every day I'd probably write about every one of them. But I don't so I probably won't.

Nevertheless, a paper by Jessica Kline titled

The Future of Food Information Services

has turned out to be remarkably prescient, so I've decided to write about it. In her abstract Jessica wrote:

With growing attention to E. coli outbreaks and mad cow disease, consumers are increasingly questioning the food they eat. In response, many in the food industry are beginning to provide both transparent and convenient information regarding a food's history. Many small scale farms recognize this needed service and have created blogs that explain general farming principles, provide photos of the land, animals, and equipment, and portray the daily lives of farmers and their families. This paper describes these current information services provided to consumers and predicts the future direction of these vital services.

And in her presentation at the Symposium, Jessica brought down the house when she said that "I don't just want information about food. I want information about MY food."

I thought these ideas were clever but a little speculative. I've written about "information supply chains" before, but location and temperature tracking of 20-foot containers on huge cargo ships seemed pretty different from tracking food intended for consumers.

However, in the last week I've read a couple of articles and found some web sites that suggest that there really is something pretty revolutionary going on with food information services to enable tracking and tracing of food to specific farms or even to specific parts of a field.

Earlier this week a story in the Wall Street Journal called Tailing Virulent Veggies (13 March 2007) described how Dole Foods has started using RFID tags on boxes of green vegetables to track them from the fields where they were picked all the way through their processing. This was in response to the E. coli contaminated spinach that implicated Dole last fall, but the RFID tags aren't yet economical enough to go on individual bags. However, according to a short article with the smart title of "Produce Provenance" in Business Week, (19 March 2007) Dole has started to put codes on those pesky stickers that clutter individual pieces of fruits. You can enter the code on a web site to link a particular bunch of organic bananas to the farm in Colombia where they come from (like the Don Pedro Farm, code 776 .

So Jessica is on to something, and I'm going to encourage her to do some more thinking about these food information services. I think an important next step will be the development of information and process standards so that applications that use food information can be easily and robustly built. I feel a joke lurking somewhere about "mash-ups" with potato data, but I just can't make it work.

-Bob Glushko

Announcing "Information & Service Design" at UC Berkeley

2007-03-04T17:33:00.000-08:00

This past Friday I moderated a symposium at the School of Information at UC Berkeley to mark the "coming out party" for a new program in "Information & Service Design" that I'm helping to get started.

We are all very aware of the relentless trend for our economies, local, national and global to be increasingly based on information and services. But because of the scope and depth of these transitions, which cut across information and computing science, business strategy, economics, organizational sociology, software design, law, and other specialties -- no single academic discipline is capable of making sense of them to help prepare students to be effective players in this new economy.

So there have been calls to develop a new science of services that can do this. A Berkeley campus-wide initiative is emerging as a joint effort of the engineering, business, and information schools.

But we think that we have a unique configuration of competencies within the School of Information:

• information modeling
• systems analysis and design methods
• implementation of web-based services and information-intensive applications
• Internet business architecture.

These 4 areas broadly span the stack from what some would call "low-level" concerns of information analysis and software architecture all the way up to big strategic concerns about "business architecture" -- how businesses and service network emerge and evolve, covering issues like component business modeling and global sourcing and outsourcing.

We've already had good success at finding synergies across these diverse topics; in particular last semester I co-taught a course immodestly titled "The Information & Services Economy" with AnnaLee Saxenian that started with Adam Smith, Karl Marx, and Frederick Taylor and ended with web services. We also conducted a weekly lecture series with a fascinating set of speakers that included CEO speakers from start-ups and global consulting firms and people doing services research at Google, Fair Isaac, Genentech, Accenture, IBM, and other leading firms. (These weekly lectures are continuing this semester).

These new courses were incredibly stimulating for both us and for the students, and that inspired Anno and me to institutionalize our curricular and research experiments in services into the Information and Services Design program.

The Symposium we held Friday consisted of 11 talks by graduate students based on research and term papers they wrote for one of these new courses on services from the fall semester. Their papers cover a diverse set of topics -- theory of service design, analysis of some design problem or opportunity, even specific case studies. You can download the papers here.

-Bob Glushko

Demand Electronic Filing of Campaign Finance Reports!

2007-02-11T15:28:00.000-08:00

A recent article by Dan Morain in the Los Angeles Times – "Senators move donor disclosures at a snail's pace" (3 February 2007) -- about how US Senators evade timely disclosure of their campaign contributions has gotten me angry. I am in part angry because of the way the story hits my professional persona as a document engineer, but more of my anger comes from how this affects me as a citizen who cares about the democratic process.

There is nothing subtle about what's going on. A so-called Bipartisan Campaign Finance Reform Act (BCRA), which took effect in 2002, requires that all political parties, campaign committees, and the like disclose where their money cames from. And of course every last one of these "reporting entities" uses computers to track their campaign contributors and maintain their required records. And of course, they all meet the filing deadlines for submitting these records to the Federal Election Commission because they want to give the appearance of complying with the law. But senators refuse to submit their quarterly records in electronic form. Instead, they each submit thousands of printed pages to the FEC, which then has to pay over a million dollars a year to get the information back into electronic form so that it can be made accessible.

You don't have to be a document engineer to realize how inefficient and error-prone it is to create information electronically, print it out, and then recreate an electronic form from the printed pages. When Morain"s article was
reprinted in the Baltimore Sun it had a new title that made it sound as stupid as it is: "Bytes to paper to bytes to paper to bytes."

But this isn't about inefficiency in document processing. It is astonishingly negligent, dishonest, arrogant, and ought-to-be-illegal behavior. Senators (and anyone else) who files on paper are saying "screw the BCRA" and "screw the voters” and anyone else who'd like to know where they are getting their campaign contributions.

I contributed a lot of money during the last election cycle. If you have the patience to wait until the keypunchers catch up with the sleazy senators you will be able to look it up. But after this story I'm never going to give another dime to anyone who thumbs his or her nose at the disclosure requirements.

Are you listening, Hillary? Senator Clinton is singled out in Morain's story as being a prime nose thumber.

-Bob Glushko

Document Case Studies With D-O-C-U-M-E-N-T

2007-01-28T11:05:00.000-08:00

I'm once again teaching Document Engineering at UC Berkeley. But this year I decided to begin the course with a few weeks of case studies and news stories to give the students more real-world texture in which to ground the abstract principles and design methods. And in addition, this year I came up with a checklist for understanding and describing the stories to encourage a consistent and complete analysis. I confess it is a little goofy to use the eight letters of DOCUMENT as a mnemonic for eight aspects of a case study, but I still remember these sorts of things from high school and college courses and people believe in mnemonics (See this site for a big collection of them) So here goes.

A CHECKLIST FOR DOCUMENT ENGINEERING CASE STUDIES AND NEWS STORIES

D -- data types and document types

O -- organizational transactions and processes

C -- context (e.g., types of products or services, industry, geography, regulatory considerations)

U -- user types and special user requirements

M -- models, patterns, or standards that apply or that are needed

E -- enterprises and ecosystems (e.g., trading communities, standards bodies)

N -- the needs (business case) driving the enterprise(s)

T -- technology constraints and opportunities

I think the only one of these that might be unfamiliar is the C for context. I'm using it in the sense developed during the ebXML initiative. about 2000. In my Document Engineering book with Tim McGrath we explain "Context" in Chapter 8 this way:

The ebXML project proposed eight context dimensions.

These can be envisioned as defining a multidimensional "8-space" or coordinate classification system in which millions of different contexts would be distinguished by their values on each dimension.

We can best explain this idea with an example. Consider an export broker buying aircraft fuel in Japan for shipment to Korea. The documents required in this situation would need information appropriate for contexts such as:

Business Process = Procurement

Product Classification = Aircraft Fuel

Industry Classification = Petrochemicals

Geopolitical = Japan

Official Constraints = Export

Business Process Role = Buyer

Business Supporting Role = Intermediary

Each of these values would have associated with it sets of rules that satisfy the requirements for that context dimension, and taken together they would form the set of requirements for the unique situation defined by all eight dimensions. The ebXML architecture further envisions a repository in which these sets of rules are stored and from which they can be retrieved to assemble the document definition needed for any context.

I don't think this idea of "context 8-space" is workable, but it is useful to think of a "context" as a cluster or pattern of high-level requirements and that's the sense I'm using it as the C in the case study checklist.

In any case, the first assignment in my Document Engineering course this semester requires the students to analyze a case study or news story using the D-O-C-U-M-E-N-T checklist. So we'll see if it works and I might ask them if I can post some of their stories and analyses here so you too can help decide how useful this mnemonic is.

-Bob Glushko

Antonio, Your Ships Are Lost -- Don't Borrow from Shylock!

2007-01-15T10:16:00.000-08:00

A recent article in the Wall Street Journal (4 January 2007) titled "Global Shippers Play Catch-Up in Information Age" reminded me of Shakespeare's "Merchant of Venice." Antonio is a successful merchant who wants to help his friend Bassanio impress the beautiful and wealthy Portia. Antonio laments that "thou know'st that all my fortunes are at sea" (Act 1, Scene 1, Line 115) and so he borrows money from Shylock to give to Bassanio, but Shylock' terms are a little extreme – if he's not repaid, he will literally take "a pound of flesh" from Antonio.

Antonio's problem, of course, is that even though "he hath an argosy bound to Tropolis, another to the Indies…a third at Mexico, a fourth for England"(Act I, Scene 2, Line 94) he doesn’t know when he borrows the money from Shylock that all his ships have already been lost at sea.

The WSJ article reports that competitive pressures, "just in time" inventory management, and other mandates for efficiency in global supply chains have forced shipping lines to invest heavily in IT and systems for feeding a continuous stream of information about the location and condition of goods to their customers. These tight supply chains can also be brittle, and problems can propagate far from their origin. A ship's late arrival into one port can cause it to miss the high tide, causing another 12-hour delay that affects later deliveries. This might mean that containers of parts needed at a factory two or three ports down the line won't arrive "just in time" and the assembly line shuts down. But with a couple of days notice, the factory can jiggle production to prevent this from happening.

I mentioned some of this tracking technology in a previous posting about "The Box," but this WSJ story added the new twist that customers can now send messages that respond to the alerts coming from ship containers. For example, the color and ripeness of bananas -- which are green and hard when they are loaded on ships -- depends critically on their storage temperature in transit. The banana buyers can remotely adjust the container temperature if necessary to accommodate changes in the delivery schedule.

Poor Antonio -- if his ships had the new IT and systems that are described in the WSJ story, he would have known that he couldn’t repay Shylock and wouldn’t have entered into such a dreadful contract. Of course, we've all made bets and bad choices that better information would have made seem as foolish when we considered them as they did in hindsight.

-Bob Glushko

Disrupting Business Models with Document Assembly

2007-01-10T10:57:00.001-08:00

A recent paper by Darryl Mountain in the International Journal of Law and Information Technology (doi:10.1093/ijlit/eal019) argues that document assembly software has the potential to radically disrupt the business models of law firms.

Document assembly software has been around for a pretty long time because the idea is simple -- if a document type has a defined structure into which variable content is poured, "standard" or "conforming" document instances can be created by eliciting that variable content from the "author."

We're all used to this for transactional document types like order forms, where the "variable content" is highly prescribed yet simple, like the name, address, quantities, and credit card numbers we enter in web shopping forms. So "document assembly" as a product category is usually reserved for narrative document types, where the variable content is more likely to be unstructured text that defines terms and conditions for document types like business contracts, wills, and divorces. Document assembly software contains a rules editor, and the logic in the rules then drive an interactive or wizard-like questionnaire that collects the needed content. Companies like HotDocs and Rapidocs are typical examples.

Mountain points out that the cost of creating a legal document depends on the amount of legal expertise embodied in it, so the additional effort to abstract and formalize the authoring process to enable interactive/automated document assembly wouldn't be justified if the document type weren't used often. But the web changes this tradeoff, because now the document type can be made available to vastly more people. We're in a Google-driven web culture where "good enough" free or low-priced services can quickly drive out services of higher cost and quality (anyone used Lexis-Nexis for tracking news lately? -- it is better than Google news but...).

So there's the disruption -- lawyers who bill by the hour have no incentive to become more efficient. And law firms that invest in document assembly and price legal documents according to their value to clients can radically undercut those that don’t adopt document assembly software.

Mountain points out that the only thing saving the "by the hour" document creators is the lack of client awareness of document assembly technology. We are willing to pay renovation contractors by the hour, but we insist that they use power tools and would never hire one who wanted to do things the old, slow, manual way. Eventually people will figure out that their lawyers ought to use computers to assemble documents and make them discard their yellow pads.

-Bob Glushko

Category Craziness in "Decapod Duels"

2006-12-09T15:36:00.000-08:00

The other day during the end-of-semester review for my Information Organization and Retrieval course at UC Berkeley I reminded my students that every classification scheme is biased. Even when this message is softened by rephrasing it as every classification takes a point of view it doesn’t sit well with people who want to believe in "reality" where categories are based on objective features or characteristics of objects, documents, or other "bibliographic entities" that we want to describe.

A few months ago when Pluto’s "demotion" from the "planet" category was a hot topic I wrote about how poorly people understand the nature of categories and classification systems. Yesterday I ran across another example, this one involving lobsters, which I’ve also written about in the different contexts of logistics and customs documentation.

This new lobster story has been reported on National Public Radio and in the Economist (2 December 2006 print edition, story titled "Dueling Decapods") and concerns a dispute about what can be called a lobster. The state of Maine wants to protect its lobster industry by enforcing some rules about the lobster category.

Maine's first approach is downright silly, branding lobsters as "Certified Maine Lobsters" in a jingoistic attempt to smear lobsters from Nova Scotia or New Hampshire as somehow inferior. This classification is unscientific because it denies the fact that lobsters migrate. If Maine's goal is to classify lobsters by geographic origin, I think it needs to distinguish native ones from those "just passin' through" from Nova Scotia who are visiting their Maine relatives.

And furthermore, 60-70% of the lobsters caught in Maine are exported to Canada for processing, and many of them are then re-exported to the US. So many "Canadian" lobsters are in fact incorrectly classified as "Maine" ones, except for those that were born in Canada and unfortunately caught as tourists "passin' through" Maine's waters.

A second front in the lobster classification war concerns whether a "langostino" can be marketed as lobster. From the perspective of biological taxonomy, both langostinos and lobsters are "decapods," hence the title of the Economist article, but the former isn't a lobster. So this time, instead of denying science to establish a classification scheme, Maine is relying on it. However, the Wikipedia entry for "langostino" says that:

Langostino is a Spanish word for prawn that is commonly used by restaurants to refer to the meat of the "squat lobster," which is neither a true lobster nor a prawn.

So there are some conflicts between scientific classification and "folk" classification. The US FDA sides with the restaurant industry and recognizes that many people think of langostino as a kind of lobster, and so it approved that classification on restaurant menus. But this unscientific classification has outraged Maine's senator Olympia Stowe, and she has asked the FDA to reconsider:

"Permitting this inferior product to be improperly marketed as 'lobster' not only pollutes consumers' appetite for real lobster, but it also exposes consumers who suffer from certain allergies to potentially life-threatening allergic reactions."

Perhaps Maine needs a branch of the “Minutemen” dedicated to securing its borders against illegal lobsters. But their rules of engagement would be complicated. They would want to let migrating lobsters in but then not let them leave in order to let Maine report higher numbers of "Certified Maine Lobsters." But they would want to stop all langostinos at the border.

-Bob Glushko

Teach or Die

2006-11-26T13:02:00.000-08:00

It has been a few weeks since I've posted a message to this "Doc or Die" blog and this still isn't going to be a message about my usual topics. In the past month I've simply been insanely busy with teaching and other responsibilities at UC Berkeley. I finally took some time off this Thanksgiving weekend and it has given me some time to remember why I started this blog and where it fits into my priorities.

Since October I've been giving 4 80-minute lectures a week in two courses, one called "Information Organization and Retrieval" that I taught for the first time last year and another one called "The Information and Services Economy" that is brand-new. I've always put a lot of energy into teaching, and think of each lecture I give as a one-act play that I write and act in, designing some minor parts and the associated choreography for student classroom interaction. Each lecture in a new course takes me a day or two to write, depending on how well I know the topic and the assigned readings, and in the Information and Services Economy course I don't know many of the topics or readings very well at all. The second time I give a lecture (as I'm doing in the IO & IR course) takes almost as much preparation because I have to substantially revise my last year's lecture, because now I know how the lecture can best reinforce the ones that immediately preceded it and best foreshadow the ones to come, things I couldn't have known the first time I gave it.

So the combination of two new lectures and two second-time lectures a week has meant that I spend most of my working hours so I can come out on the right side of "Teach or Die."

It has been suggested to me that I should just blog about my lectures, and if I was trying to be a "professional blogger" and guarantee my vast readership that I'd post something every day I could certainly do that. But my lecture notes are already posted (attached to the course syllabi linked above), and my goal for blogging was to go beyond what I already said in my classroom and make observations that would enhance that experience for my students.

I'm now down to the last two weeks of the semester and (except for a quick trip back to Boston for the XML 2006 conference that I've attended about 15 years in a row) I should start having more time outside of teaching and can put more effort into some research projects that have been limping along.

But I have one more dilemma to deal with. I made a list this morning of interesting topics that I want to blog about, However, I need to develop a final exam for my IO & IR course, and many of the items in my list could be questions that test a student's ability to think across lecture boundaries. So I guess I'll start blogging more frequently again after the final exam on December 12.

-Bob Glushko

TSA's "Alice in Wonderland" Semantics

2006-10-07T07:13:00.000-07:00

I was enduring the ritual humiliation inflicted by the Transportation Security Administration at the San Francisco airport when I fell, like Alice in Wonderland, into a semantic rabbit-hole where the TSA used words in ways that made no sense.

As we were being herded through the inspection lines and approached the scanning machines, one of the TSA martinets instructed us to remove our shoes and any jackets or coats. I was wearing a sleeveless sweater vest ( like the ones here) and the woman in front of me was wearing flip-flops -- not the usual kind but some kind of high-style thong style where the flat part was held on by extremely thin strand of material (like the ones here). I said to her "those aren't shoes" and she smiled in agreement, but the TSA person standing nearby overheard us and said "yes they are -- if you're wearing them on your feet then they are shoes." I was thinking "if I wrapped my feet in clear plastic wrap, maybe that would count as shoes to these people" when the TSA guy interrupted my thoughts and told me I needed to take off my "jacket" and put it through the scanner.

Even a hothead like me knows that there is no way to win a debate with TSA workers because they follow rules by the book, but in my research and teaching I'm very sensitive to what words and categories mean (I've just spent six weeks talking about this in my Information Organization and Retrieval" course at UC Berkeley). I didn't think that the woman's flip flops were shoes and I didn't think that my sleeveless sweater vest was a jacket. But I was pushed over the edge by what happened next.

We all have heard about the alleged plot to blow up airplanes with liquid explosives. In response, the TSA for a time banned all liquids in carry-on bags, but after this hysterical overreaction caused lots of delays and problems, they revised the policy to allow limited amounts. Here's the policy as posted on the United Airlines web site:

Liquids, gels and/or aerosols are now permitted through security checkpoints. Items must fit in one clear, re-sealable quart or liter-sized plastic bag, in containers of 3oz/90ml or less. Examples include: shampoo, suntan lotion, creams, toothpaste, hair gel, hair spray, liquid cosmetics and other items of similar consistency.

I interpreted this to mean that I could take up to 3 ounces of any of these items and so I packed some toothpaste and shampoo in my carry-on bag. I looked at the toothpaste tube when I packed it, noticed that it said its capacity was 4.3 ounces, but since I had used almost all of it and I estimated that the remainder was less than ¼ the length of the full tube I was sure it was OK to take it.

But I'm sure you can predict what I happened next in the alternative semantic universe inhabited by the TSA. They studied my bag as it went through the scanner, and I then I had to endure the violation of my 4th amendment rights while they rummaged through my bag in public to find the offending toothpaste tube.

The TSA worker held up the tube and said "we have to confiscate this tube because it is more than 3 ounces." I said "but it is mostly empty -- is it now illegal to carry empty containers on airplanes?" His reply of course did not address the semantic absurdity of his statement because empty containers don't contain bomb-making ingredients, and keeping these ingredients off planes is the justification for the policy. All he said was "Do you want to talk to my supervisor?"

I muttered something about feeling like Alice in Wonderland and then said "keep the damn toothpaste."

-Bob Glushko

Hugo Chavez, Please Read My Book

2006-09-24T16:23:00.000-07:00

During his recent anti-Bush speech to the UN general assembly, Venezuelan President Hugo Chavez held up a copy of Noam Chomsky’s book called Hegemony or Survival: America’s Quest for Global Dominance and highly recommended it. Since then sales of Chomsky’s book have increased spectacularly, and it even hit #1 at Amazon.com. Not bad for a book that "hasn’t sold particularly well" and whose author "does not write page turners, he writes page stoppers" according to the NY Times article I cited in the first sentence

Dear President Chavez,

About a year ago my co-author Tim McGrath and I published a book titled Document Engineering: Analyzing and Designing Documents for Business Informatics and Web Services that we think you would enjoy reading. Like you, we disagree with many of the traditional views held by capitalists about how businesses are designed and operated and we criticize them for their reactionary reluctance to adopt XML and service-oriented architectures. And like you, we disagree with the Bush administration’s approach for how to get people to adopt your ideas – trust us, we will never invade any country or drop bombs on them to impose the Document Engineering approach.

Unlike your approach, the solutions we propose are not political. Our suggestions in our book are primarily conceptual and methodological. But as we propose new ways to think about how firms can work together to automate processes and services to create new value and efficiencies, we would certainly hope that many of these benefits would flow to ordinary people and not to just the greedy capitalists whose firms adopt our methods.

You surely admire Karl Marx for his insights and visions about economic behavior and no doubt recommend his Manifesto. We think you should know that another famous economic thinker, Hal Varian, describes our book as a "MANIFESTO for the document engineering REVOLUTION" in a "blurb" that appears on the book jacket.

So we are sending you a copy of the book. Let us know the next time you come to the United States (or to Australia) so we can show you around and tell you more about our book.

Sincerely,

Bob Glushko

XML Still Isn’t "Self-Describing"

2006-09-10T20:48:00.000-07:00

A few weeks ago I wrote a post titled "XML isn't self-describing" and I thought I was done with that topic but a comment to my post (thanks, it is nice to know that some people who are not my students are reading what I'm writing) has made me want to resume talking about it. And for my students taking "Information Organization and Retrieval" from me this semester at the UC Berkeley School of Information , I'll refer back to an article we talked about to reinforce some lessons with this response.

The commenter said:

Don't you think that it is possible within "known" problems to create self-describing information with XML?

For example, a known problem such as ordering dinner at a restaurant or a personal address book might be very capably handled by XML. There might be variations, but I think we could agree on a dozen tags that were obvious within the context. I might not be familiar with the < holdpickles/ > tag, but intuitively I would understand given my familiarity with the problem.

This is a very typical rebuttal attempt that acknowledges that XML isn't self-describing in most cases, but argues that in "familiar" domains there is sufficient agreement about what words mean for it to be so. It seems "obvious" that people agree on things like restaurants and addresses but it just isn't true.

There is hard scientific evidence from experimental studies of "statistical semantics" that there is little agreement on the words that people assign as names to common objects or processes. The classic paper, reporting a number of compelling experiments, is "The Vocabulary Problem in Human-System Communication" by George Furnas, Tom Landauer, Louis Gomez, and Sue Dumais in the Communications of the ACM way back in 1987.

In my IO & IR class last Thursday we replicated the basic results with a few things that I grabbed from my office on the way to my lecture (a dollar bill, a coffee cup, a pocket knife, and a photo with me and my wife). I asked students to think of the best one or two word descriptions for these familiar things. For some of them there were four or five different ones (e.g, dollar, bill, buck, greenback; cup, mug, coffee cup, drink; and so on).

This result is pretty surprising to people. When you ask a few dozen people, you get even more different terms suggested as the "best" or "most natural" name for a common object. But because any given person can only think of a few names as "intuitive" fits, they can't imagine that there could be such diversity, and so they greatly overestimate the amount of agreement about names -- and they conclude that the name of something is a reliable description of it.

So the only thing about names being "self-describing" is that they describe the meaning of something to oneself. Just not necessarily for anyone else.

-Bob Glushko

Sorry Pluto… And Some Thoughts About Categorization

2006-08-27T15:18:00.000-07:00

Because semantics and categorization are key themes in document engineering and in the courses I teach, I've been flabbergasted by much of the recent reaction to the "demotion" of Pluto from planethood to the inferior status of "dwarf planet"” by the International Astronomical Union. The IAU recently passed a resolution that defined a planet within our solar system as:

A celestial body that is (a) in orbit around a star, (b) has sufficient mass for its self-gravity to overcome rigid body forces so that it assumes a hydrostatic equilibrium (nearly round) shape, and (c) has cleared the neighbourhood around its orbit.

Because Pluto doesn't satisfy the third requirement, it no longer is classified as a planet. This has generated a great deal of news and caused lots of people to get upset. A typical headline is "Pluto's demotion has schools spinning" -- elementary school science teachers just don't know what to teach. And the widow of the astronomer who discovered Pluto in 1930 says she is all shook up.

But "Pluto's place is safe with astrologers" and that's crucially important to me because apparently Pluto is the most important planet for Scorpios and I am a Scorpio.

These stories are pathetically amusing and that alone makes them interesting, but what really intrigues me is how they illustrate how people understand categories. "Planet" is a category with profound historical and cultural importance, and because of the IAC resolution, we get to witness a very clear and sudden shift in how that category is defined.

For millennia we earthlings have had a notion of planet as a "wandering" celestial object, but because we only knew of planets in our own solar system, we could define "planet" by enumeration. Very few categories can be understood that way, that is, by making an exhaustive list of their members. But once we acknowledge the existence of planets outside our solar system, the set of planets becomes unbounded, and the lack of a definition becomes apparent. Then we can have arguments about the definitions, and hence biases of one kind or another get built into the categorization.

The popular reaction to this new way of understanding "planet" by extensional definition rather than by enumeration suggests that many people are living with the delusion that there is an objective reality in which categories and definitions are objective and unchanging. And it is scary to read that the IAC members gave serious discussion to the likely impact their new definition would have on elementary school science. I thought progress in science, scientific revolutions, creative destruction and all that meant that we should look forward and not worry about the “installed base” of people with a sixth-grade science education.

-Bob Glushko

XML Isn't "Self-Describing"

2006-08-12T18:59:00.000-07:00

I am so sick and tired of reading that XML is “self-describing.” It isn't. I could link to 100 web articles or blog posts that proclaim that it is, and even the popular "Learning XML" book by Eric Ray that I've used to teach XML says it is ("Creating self-describing data" is on the book cover). But I was working with XML for 10 years even before it existed , back when it was a 4-letter word (that's a joke about SGML that I credit to Bob DuCharme), and it wasn't self-describing then and never will be. And that's a feature, not a bug.

Let me try to be charitable, and assume that what people mean when they say XML is "self-describing" they are really saying "compared to something else that clearly isn't." So the least "self-describing" information consists of just a stream of the alphanumeric characters being represented by some text format, as they might be on a punch card. This delimiter-less encoding doesn't even make explicit the tokenization of the characters into meaningful values, so there isn't even any "self" to which any description could be assigned:

850456719990105

The information here has been encoded in a position-sensitive way, and it turns out that there are three different information components that occupy fixed-length fields in the text stream. But we can't begin to describe the information here unless we have some mapping of positions to values. The possibility of description emerges when we separate the values with commas or some other delimiter character, which tells us what information components must be described:

850,4567,20060812

But commas as delimiters provide no clues about what the components mean, do not enable any association of one component to another, and do not enable one component to be contained within another. A text encoding syntax that uses multiple delimiters like EDIFACT is a step closer to self-description, because it can implicitly represent structural or semantic hierarchy among components. XML goes one step further with the syntactic mechanisms of paired text labels to distinguish the information components in a stream of text and quotes to associate one bit of information as an attribute of another. So an XML encoding of this text stream might be:

<xxx yyy="4567">850</xxx>
<zzz>20060812</zzz>

The <, >, and " characters distinguish the information being described from the "markup" that is part of its description. This syntax allows more flexibility in the encoding of the text stream (without positional encoding, we no longer have to assume that the values are of fixed length). But the information isn't described by these syntactic markup mechanisms, and that's all that XML per se is contributing so far.

I suppose that it is the text labels inside of XML's syntactic delimiters that cause most people to think that XML is self-describing. But these tags aren't part of XML, so it isn't XML that is doing the work. But what do these "tags" really contribute anyway? Instead of xxx, yyy, and zzz, I might have encoded the text stream this way:

<TransactionType reference="4567">850</TransactionType>
<Date>20060812</Date>

Using text labels in a language we "understand" might give us a warm feeling that we are describing the text content, but the tags really don’t do that.

Choosing the terms used for tags or naming anything is often a difficult and contentious activity. Everyone naturally creates names that make sense to them, but even when describing exactly the same thing, chances are very good that two people will choose different names for it. And they will often use the same name or tag for different things.

"TransactionType" and "reference" and "Date" might suggest something about the meaning of the content, but "suggesting something" is not enough to make it self-describing. To someone familiar with the ANSI X12 EDI standard, a "TransactionType" with a value of 850 is a Purchase Order, but most people wouldn't have any idea that I used this interpretation to make up this example. Does "Date" mean the date of the purchase order or the date I wrote about it? What about a <Price> tag -- does this tag describe the retail, wholesale, discounted, or FOB Sydney price? Does it describe the price for a single item, a dozen, or a pallet-full? What's the currency? The tag by itself can't possibly distinguish between these different descriptions, so it doesn't make the information self-describing.

To be self-describing the XML syntax and tags would have to simultaneously convey both the specific information they mark up, all the semantic nuance needed to distinguish among synonyms or related concepts, and all the rules that govern relationships to other content – all without any additional information. If XML syntax and tags could magically do that by themselves we wouldn't need schemas or any documentation or other metadata. So as we said at the end of our Geometry proofs, Q.E.D.

Postscript:

What do you suppose the "rating" and "weight" tags mean (from
Google's recommendations to users of its "Google Base" service):

<g:rating>4</g:rating>
<g:weight>5</g:weight>

Make a guess. You will probably be wrong. The tags aren't "self-describing" enough.

-Bob Glushko

Deconstructing the Paperwork Burden

2006-08-06T10:58:00.000-07:00

Every year the "Paperwork Reduction Act" requires that the Office of Management and Budget provide Congress with an estimate of how much time Americans spend filling out government forms. The goal is to "minimize the burden that responding to these collections imposes on the public, while maximizing their public benefit." The 2005 estimate was 8.4 billion hours, so for the 230 million people over age 16 (I assume that kids don’t fill out a lot of government forms) that's an average of 36 hours per person. IRS tax forms account for 80% of this estimate, 30 hours a year.

Even if we factor out homeless people, transients, people in prisons and others who probably don't fill out a lot of government forms, maybe this number goes up some but it doesn't seem like such a big time burden on average. And since I know I spend a lot more time than that dealing with income tax recordkeeping and reporting, most people must be getting off relatively easy.

Nevertheless, a recent review of the OMB's report conducted by the US Government Accountability Office got some news coverage when it came out, and a lot of it wasn't very kind. There were lots of headlines like "Drowning in Paper" or "Buried under paperwork."

I didn't think that this kind of bashing was justified, so I read the complete GAO report, presented to Congress by Linda Koontz, and I was very impressed by it. Most government agencies seem to be taking the PRA very seriously. In particular, the PRA as amended in 1995 presents a checklist against which information collection should be evaluated (included as Table 1 of the GAO report) and OMB provides
careful guidance on the why, when, how of data collection in forms, surveys, and questionnaires.

Most people would identify two kinds of causes for the paperwork burden:

1) Government action. Most of the burden correlates with the extent of data collection mandated by law or regulation, and this is what most critics focus on.

2) Design of the forms or other data collection instruments. The burden is increased by forms that are poorly designed, either from a physical or presentational standpoint (confusing layout, tiny fonts, not enough space) or from a more conceptual or architectural standpoint (ambiguous language, choices or enumerations that don't span the entire range or that are incompatible).

But recent thinking about estimating the paperwork burden is surprisingly sophisticated. Rather than analyzing the burden form-by-form, the IRS is developing a methodology that considers characteristics of taxpayers and the context in which they complete their tax returns. These include the way in which they gather and manage relevant information, any software they use, and whether they work with others (like accountants or tax preparation service). This more complex methodology will make information standards, interoperability, and other document engineering considerations more prominent in the analysis to yield more accurate estimates of the compliance burden and suggest better ways to reduce it. The IRS is also making
significant investments in XML and online filing.

And consider one more thing. At least the government is trying to minimize the burden that collecting information imposes on its "customers" and is very transparent in making the case for what it does. The private sector has no such goals, and consciously misrepresents or obscures its efforts to wring every last bit of information from consumers. For example, when you buy something, did you know that your warranty rights are not in the least bit undermined if you don't fill out product registration cards and the detailed surveys that usually are part of them?

-Bob Glushko

My InfoWorld Podcast with Jon Udell

2006-07-21T17:42:00.000-07:00

This week I did a phone interview with Jon Udell, the InfoWorld columnist and prolific blogger, to talk about Document Engineering {and, or, vs} bottom-up tagging, XML schemas {and, or, vs} microformats, business process and business information patterns, the unique challenges and opportunities of the university computing environment, and lots of other interesting topics…

You can replay the interview as a podcast from here.

The highlight of the interview for me was when Jon volunteered that some people say he’s a Document Engineer. I told him that I agreed, and that maybe we’d give him an honorary degree if he’d only stop saying that XML was self-describing. I think I convinced him -- someone who stresses the importance of metadata (check out the "InfoWorld Metadata Explorer" that he built) -- that if XML were really self-describing you wouldn’t need any of it.

I will probably write about some of the topics that Jon and I talked about. But in the meantime, listen to the podcast.

-Bob Glushko

The Joy of SOX

2006-07-20T15:01:00.000-07:00

I'm writing about a book with this title… and there’s no misspelling here. It will help if I add that the subtitle is "Why Sarbanes-Oxley and Service-Oriented Architecture May Be the Best Thing That Ever Happened to You." Its author is Hugh Taylor, the VP of Marketing at SOA Software, whom I met a couple of months ago at the OASIS Interoperability Conference in San Francisco.

The Sarbanes-Oxley Act was enacted by the US Congress in 2002 to curb corrupt business activities and fraudulent accounting practices like those of Enron and WorldCom. SOX requires firms to implement adequate internal control structures and procedures and attest to their effectiveness. The essence of SOX for someone with my perspective is that a firm needs accurate information about anything that affects its financial statements, and the best way to capture and maintain that information is by automating business activities and internal operations. So that's why I talk about SOX in two of the courses I teach at UC Berkeley's School of Information: Information Organization and Retrieval and Document Engineering and Information Architecture.

Much of the writing about SOX is impenetrable, filled with accounting and business jargon. But "The Joy of SOX" reads almost like a novel, because Taylor has brilliantly written it as a comprehensive case study of a fictitious company’s efforts to deal with SOX. So Taylor's CFO character explains aspects of financial controls and reporting, his CEO and COO characters explain the interdependence of business strategy and controls, and his CIO character explains how computing infrastructure and software development practices shape and are shaped by the controls and strategy.

I especially enjoyed (and so will my students, because now my lectures on SOX will be more concrete) the many examples of how controls, business models, and information technology come together. For example, the case study firm doesn't have a uniform product coding standard, which makes it hard to track inventory and transactions, and this problem is made worse by its practice of buying closeout inventory from suppliers. Another example shows how a good policy for managing employee passwords and access privileges is worthless without policy enforcement and change management processes.

This book enabled me to finally understand some of the arcane details of compliance, just as accountants and business people who read this book will be able to understand service-oriented architecture, enterprise integration, and business process specification languages.

In addition to being hard to read, most of the writing about SOX presents it as a necessary evil to prevent worse evils from being done to unsuspecting investors or other stakeholders in a business. No question that SOX is causing increased spending (some say excessively so) in document and records management, security, business process management and document engineering as companies define, document, and automate the processes that are needed to run the company while enabling auditing and timely reporting. Some of my former students who are working for IT consulting firms are saying that SOX is like "Y2K that won’t go away" or a "full employment act" for them.

Again, here's where The Joy of SOX is unique. Taylor argues against the standard "lose-lose-lose" proposition that most people see in SOX:

If you comply, you may harm your ability to be agile and stay competitive

If you don't comply, you could go out of business (or go to jail)

If you make an empty effort at compliance, you may pass through the process but merely bury company-killing problems (and spend a lot doing so).

Instead, Taylor argues for "agile compliance," urging firms to treat their SOX efforts as an investment. This approach relies on service-oriented architecture, business process specification languages, and so on. He makes a very compelling case.

If you want SOX, buy this book.

-Bob Glushko

Terrorist Threat Markup Language, part 2: The Blame Game and Semantic Illiteracy

2006-07-12T19:50:00.000-07:00

The news about the poor information quality in the "terrorist threat" database of the Department of Homeland Security is producing the expected fallout. States like New York that complied with the specifications and submitted carefully-prepared lists of plausible targets -- and got stiffed as a result when DHS passed out funds -- are complaining about that. And of course, states like Indiana, whose list includes a popcorn factory, a petting zoo and a flea market -- are trying to justify why they deserve disproportionate shares of funds to protect against terrorist acts.

But what interests me is that both New York and Indiana are saying the same thing, and they're both wrong. As I pointed out in my previous post, the DHS provided state and local officials with "Guidelines for Identifying National Level Critical Infrastructure and Key Resources" that included detailed definitions, classification criteria, and requirements for how to describe each asset.

Nevertheless, Rep. Caroline Maloney,a New York congresswoman complained on National Public Radio that the threat database shows her state with only two percent of the nation's banking and financial assets, somewhere between North Dakota and Missouri. Her explanation:

"It appears not to have any standards or definitions of what should be on this list."

And likewise, Peter Beering, Indianapolis "terrorism preparedness coordinator"
blames federal officials for not defining what assets should be protected:

"If you can't define it, if we can't agree on the definition of what a thing is, then we will never be able to count how many we should be worried about."

Another Indianan, Pam Bright (spokeswoman for Indiana's homeland security department), also blames the feds for Indiana’s inclusion of petting zoos and flea markets:

"I don't think there was a clarification as to what assets were, so every state had a different version of what they were supposed to submit."

I can understand why Congresswoman Maloney and other New Yorkers think they got ripped off because the DHS didn't have any rules, but there WERE rules (see Appendices D and E in the already-infamous report)-- they just didn’t enforce them. And the Indiana folks are clearly suffering from semantic illiteracy. They must have convinced themselves that they had a sensible definition of "terrorist threat" when they submitted their lists, and just couldn't imagine that other people might understand it a different way.

The only other possible explanation is that out in Indiana they were scheming to get an unfair amount of taxpayer money from the Homeland Security pork barrel, and that just wouldn't be fair.

-Bob Glushko

Needed: Terrorist Target Markup Language

2006-07-12T10:03:00.000-07:00

The Office of Inspector General for the US Department of Homeland Security has just issued a scathing criticism of the National Asset Database. The NADB is supposed to be a comprehensive list of vital systems or locations whose destruction would have a debilitating impact on security, public health, the economy, or even morale and confidence. Unfortunately, the Inspector General's review shows that the NABD inventory contains many "non-critical assets" and thus can’t support the resource allocation and risk assessment for which it was commissioned.

Many news stories and commentaries, like that on page 1 of the 11 July New York Times, whose title is "U.S. Terror Targets: Petting Zoo and Flea Market?" or in the "Homeland Stupidity" blog have focused on the contents of the NADB:

For example, the inventory includes 4,055 malls, shopping centers, and retail
outlets; 224 racetracks; 539 theme or amusement parks and 163 water parks; 514 religious meeting places; 4,164 educational facilities; 1,305 casinos; 234 retail stores; 127 gas stations; 130 libraries; 335 petroleum pipelines; 217 railroad bridges; 140 defense industrial base assets; 224 national monuments and icons; and 8 wind power plants.

(The NADB also includes 159 cruise ships and 34 Coca Cola bottlers/distributors).

But joking about the contents misses the far more important concern emphasized by CNN that the NADB is too flawed to determine allocation of federal security funds, supporting complaints by New York City, Washington DC and other cities that they are being shortchanged.

And now I am going to look at this news from a Document Engineering and Information Architecture perspective. Why did it happen, and how could we prevent this from happening again?

We wouldn't be surprised that the NADB contained bad information if the DHS hadn't provided state and local governments with any criteria or specifications. But that's not the explanation. Two years ago the DHS Office of Infrastructure Protection provided "Guidelines for Identifying National Level Critical Infrastructure and Key Resource" (included as an Appendix of the recent IG’s report) that included detailed definitions, classification criteria, and requirements for how to describe each asset. The Guidelines include a taxonomy with 17 first-level categories, and scores of subcategories, and also specify the information components needed to describe each asset such as state, address, sector, owner, owner type, phone, local law enforcement POC, and latitude and longitude coordinates.

Here, for example, is some of the guidance about Chemical assets:

CHEMICAL
1. Sites that could cause death or serious injury in the event of a chemical release and have greater than 300,000 persons within a 25-mile radius of the facility.
2. Economic impact of more than one billion dollars per day (e.g., an event impacting multiple sectors and cumulatively cause this amount of economic damage).
NOTE: The term "sites" includes manufacturing plants; rail, maritime, or other transport systems; pipeline and other distribution networks; and storage, stockpile, and supply areas.

Nevertheless, despite this guidance, states and local governments submitted assets that didn't follow the specified formats, were incomplete, were duplicates, and in the case of Puerto Rico, were in Spanish! All of this reflects some mixture of incompetence, negligence, and political calculation to get more than a fair share of Homeland Security funds.

But suppose that the DHS had encoded these narrative specifications in an XML vocabulary called "Terrorist Target Markup Language" and required all asset submissions to conform to it. TTML would have made it possible to detect most of these problems immediately when they were submitted, and the standard organization and format of the data would have enabled additional data mining to detect anomalous information.

This isn't a far-fetched suggestion. There are numerous XML standards activities underway in the homeland security domain, including biometric data exchange, common alerting protocols, and emergency response.

-Bob Glushko

Lobsters in Louisville

2006-07-05T13:14:00.000-07:00

A recent issue of the Economist (15 June 2006) has a collection of interesting articles about logistics (something I’ve posted about before), including one with the statistically improbable title of "Just-in-time Lobsters." The main point of that story is that Clearwater Seafoods, based in Bedford, Nova Scotia, ships 30,000 pounds of live lobsters each week from a warehouse in Louisville, Kentucky. This is an odd location for lobsters but makes perfect logistical sense because Louisville is the main hub for UPS, which ensures that when you buy lobsters on the web they can be anywhere in the world the day after they leave Louisville.

Of course, the lobsters aren’t from Kentucky, they’re from Nova Scotia. So the lobsters have to be first shipped by truck to Louisville, and you might wonder why it is worth the bother to do that. But that’s where document engineering issues come in. Clearwater used to ship live lobsters to the US from Canada, but each package required numerous documents. A truck full of lobsters is essentially a giant package, so Clearwater saves a lot time filling out forms to cross the border.

By the way, the documentation requirements for lobster shipping are pretty simple as things go. My Document Engineering course syllabus includes a report by the Australian government on "Paperless Trading" that has this staggering observation about the ridiculously complex information architecture for international transactions:

According to the United Nations Conference on Trade and Development, the average international transaction involves 27 to 30 different parties, 40 documents, 200 data elements (30 of which are repeated at least 30 times) and the re-keying of 60 to 70 per cent of data at least once.

-Bob Glushko

Tags: DocumentEngineering, Logistics

The Organization of Information about Information Organization

2006-06-30T16:20:00.000-07:00

At the UC Berkeley School of Information I have the great privilege and responsibility of teaching a required course called "Information Organization and Retrieval" to all incoming graduate students in our master’s program. This program attracts a wonderfully diverse set of students, some right out of college with computer science degrees, some with a few years of information industry experience, and some with social science or humanities orientations. But this heterogeneity makes it challenging for the IO&IR course to establish the foundations and framework for the program.

To me it seems natural to teach information organization and information retrieval in a single course because they are inherently interconnected. We organize to enable retrieval, and the more effort we put into organizing information, the more effectively it can be retrieved. Likewise, the more effort we put into retrieving information, the less it needs to be organized first. This is the tradeoff embodied in the contrast between the library’s and Yahoo’s (original) approach of human classification of the web and Google’s computer analysis of its link and text co-occurrence patterns. We can analyze this tradeoff in terms of intellectual or computational investments made and the subsequent allocation of costs and benefits between the information organizer and the information retriever. And of course the relationship between these two parties is critical to the tradeoff, and sometimes they are one and the same, or they belong to the same company or social group, or have no knowledge whatsoever of each other. That’s why this is all such interesting stuff to think about and teach.

A year ago, when I was first getting ready to teach the IO&IR course in Fall 2005 I was a little surprised to learn that there isn’t any textbook that emphasizes this yin and yang of IO {and,or,vs} IR. Instead, there are books that teach IO, and books that teach IR. I guess that’s because the key concepts of IO -- categorization, classification, metadata, modeling, tagging, facet, thesaurus, ontology, information architecture, interoperability, integration … -- are more abstract and conceptual than those of IR, which are more technical -- indexing, weighting, filtering, crawling, clustering... You find IO books targeted for library and information science students and IR books aimed for computer science and computational linguistics students.

So for the IO part of the course last year, the text I used was Arlene Taylor’s
"The Organization of Information." This textbook has been used in our school since 1998, when the IO&IR course was first taught, and it is undoubtedly the definitive text for students in library and information science programs. It emphasizes the foundational concepts and methods of bibliographic description and classification from these disciplines, and I thought that this would give some useful perspective to our students who almost too eagerly embrace new technology as "progress" or who are inadequately appreciative of the value embedded in these traditional approaches. But even though I used the recent 2004 edition, my students generally dismissed the Taylor book as reactionary and with few insights about current topics that most intrigued them, like social organization on the web, digital multimedia, or domain-specific metadata standards.

I’ve now spent nearly a month revising the IO&IR course for Fall 2006, and in particular I’ve been looking for a book to replace Taylor. My first candidate was Peter Morville’s "Ambient Findability," which I had high hopes for because Morville is a library scientist by training who evolved to co-author "Information Architecture for the World Wide Web," the popular O’Reilly "polar bear" book.

Morville says "ambient findability describes a fast emerging world where we can find anyone or anything from anywhere at anytime" and that’s a great theme on which to base a book. It is easy to read and my students would probably have liked it – but I just can’t use it as a textbook. Taylor comes across as tedious in her description of cataloguing and controlled vocabularies, but she’s rigorous and practical. Morville comes across as glib and shallow, with many clever examples but not enough detail to know how to do anything. To be fair, maybe Morville isn’t trying to write a textbook, but I suspect he’s capable of doing it so it is unfortunate that he didn’t.

I then discovered a wonderful and deep little book by Elaine Svenonius called
"The Intellectual Foundation of Information Organization." Svenonius is an emeritus professor of Library and Information Studies at UCLA, and my first thought was that even though the title sounded perfect, the book would just be Taylor in a more theoretical wrapper. But to Svenonius

"much of the literature… is inaccessible to those who have not devoted considerable time to the study of the disciplines of cataloguing, classification, and indexing… It mires what is theoretical interest in a bog of detailed rules... This book is an attempt to synthesize this literature in a language and at a level of generality that makes it understandable to those outside the discipline."

Svenonius takes on the fundamental challenges of determining what to describe, describing it, classifying it, and ensuring that the descriptions and classifications will be comprehensible to others – and pulls it off. Now she’s not as readable as Morville, and as practical as Taylor, but I think that Svenonius is going to be good for our students. Some of them will go on to work for Yahoo and Google and so on, and they will appreciate that they had a chance to think deeply about these challenges about information organization before they faced the hard reality of designing, building and deploying information and applications that have to deal with them.

-Bob Glushko

Tags: BookReview, InformationOrganization, InformationScience, UCBerkeley

Thinking Outside the Box about the Box

2006-06-16T07:53:00.000-07:00

From my house in the Berkeley hills I have a great view across the bay to San Francisco but I like to watch the foreground action in the Port of Oakland where towering Panamax cranes taller than most of the buildings in downtown Oakland load and unload huge container ships.

So when I heard about Marc Levinson’s book called "The Box: How the Shipping Container Made the World Smaller and the World Economy Bigger" I immediately bought a copy.

The shipping container was invented 50 years ago, and Levinson makes a compelling case that by radically shrinking the cost of moving goods the container was a key enabler of globalization. It also completely changed the character of port cities, eliminating most of the work on the waterfront traditionally done by longshoremen and shifting it to places built to exploit containers; for example, Port Newark took over from New York City, and Oakland supplanted San Francisco. The container played a crucial role in the Vietnam War, where the huge buildup of the US forces was enabled through new container ports, and rather than coming back empty, containers were routed through Japan and filled with the "made in Japan" goods to start the import flood from Asia.

I am sure that stories from this book will make it into my courses this coming year on "The Information and Services Economy" and "Document Engineering." The container story is a great example of how technology and business models co-evolve, and while I usually focus more on information technology in that relationship, containers are now a key part of information-centric business models and processes too. You can bundle a battery and satellite transponder into small box that can be attached to a cargo container and report on its location, content, and condition from anywhere, even the middle of the ocean.

-Bob Glushko

Tags: BookReview, BusinessProcess, Logistics

Online Banking Lock-in and the Double WAMU

2006-06-01T11:57:00.000-07:00

Jon Udell's critique of his online banking service was posted just a few minutes after I had a frustrating experience with my own online bank. I have an account with Washington Mutual, but not by choice. WAMU bought the bank that bought the bank that bought the bank I started with 10 years ago when I moved to San Francisco, and it just seemed like too much effort to change banks even though the bigger the bank got the worse service I seemed to get.

And service has gotten worse with online banking. Today I was paying a stack of bills and after I'd entered about 10 payments I needed to check something so I stupidly hit the back arrow on my browser, which erased all my work. A minute after I tediously re-entered my payments the phone rang and I spoke for 10 or 15 minutes, just long enough for WAMU to give me more great online service by logging me off (I guess that's a double WAMU).

I would change banks tomorrow if I could somehow avoid having to re-enter the account and address information for the few dozen payees, because the thought of that wasted effort keeps me locked into a bank I have come to hate. I write and teach extensively about information modeling and interoperability and it just makes me angry to see how so often people get screwed by companies that don't give much thought to either, or that use proprietary data formats to lock them in.

Like Jon's bank, WAMU seems to make changes to its online banking that shift work to its customers. One that is particularly annoying is a recent change to the URL for the login page.

Old URL: https://login.personal.wamu.com/logon/logon.asp
New URL: https://login.personal.wamu.com/IdentityManagement/Logon.asp

So I needed to change the bookmark link. Some directive must have come down from on-high that required the programmers of the online banking system to put more emphasis on Identity Management rather than just logging-in. But couldn't they just use the same login page?

-Bob Glushko

An Insanity Defense for VA Data Theft

2006-06-01T09:18:00.000-07:00

When I first learned about the May 3rd theft of a laptop with personal data on about 26.5 million U.S. military veterans, my first thought was that the Veterans Affairs employee who took the data home was an illiterate idiot who somehow hadn't read any news about all the recent laptop data theft incidents. My second thought was a reminder that personal data had also been stolen last year as a result of employee negligence at my own place of work, the University of California at Berkeley, and I wondered whether these events too often occurred in the public sector where people seem to have less accountability and more employment security than in the private sector. (Breaking news – they've fired some of the responsible people -- it's about time). But I didn't feel compelled to post about the incident because I didn’t feel that I had any unique commentary to offer.

But the latest news about this incident contains a twist that gives me something to rant about. The chief privacy officer of the VA, Mark Whitney, wrote an internal memo on May 5, just two days after the burglary, in which he attempted to downplay the significance of the data loss. His reasoning was that "given the file format used to store the data, the data may not be easily accessible." In other words, because the VA stores information in a proprietary data format, presumably tied to a single application, the thief won’t be able to make much use of it.

But the application that uses the data is probably also on the stolen laptop, or why would the employee have the data there? And in any case, it is pretty easy to find specifications for most statistical data formats (a typical compendium is this one at Carnegie-Mellon University). And lots of us could probably whip up a little script that transforms almost any format into something we could more easily use or sell.

So we have a kind of insanity defense here, or maybe two of them. A VA employee who copies 26.5 million records that he can’t use onto his laptop is clearly insane. But the VA is also insane if it stores information about veterans in multiple proprietary and incompatible formats. I thought it was motherhood and apple pie to "create a single view of your customer."

-Bob Glushko

Computerizing Pupils and Patients

2006-05-15T15:16:00.000-07:00

The 15 May 2006 New York Times has a story titled "States Struggle to Computerize School Records" that reminded me of a post I made here a couple of months ago about electronic health records. Many states are trying to create a composite view of all the information about their public school students, including their courses, grades, test scores, attendance, disciplinary actions – all linked by a unique tracking number. Many of the efforts have failed to meet their functional, performance, usability, or budget requirements and for all the usual reasons.

Most large computerization projects are complex and challenging. But building a data system to collect information from all the schools in a state can be extraordinarily daunting, involving the integration of computer systems used in hundreds of districts, each of which may have multiple databases using distinct operating systems.

The only cause of failure unique to school systems seems to be that many of them simply lack the technological and process maturity to attempt this integration but have been forced to take it on by the No Child Left Behind Act of 2001, which mandates lots of reports from school districts to make them more "accountable" (I won’t get into the heated debate over this goal because it isn’t a document engineering issue).

The déjà vu part of this story is that like the computerized pupil records required by No Child Left Behind, the US government has also called for electronic patient records. Last November the Department of Health and Human Services began funding multi-million dollar pilot projects and even conservative estimators expect that it will take hundreds of billions of dollars to make EHRs happen for everyone in the US.

Maybe we could save ten or twenty billion bucks by recognizing that implementing electronic students and electronic patients have a great deal in common and are also likely to face similar non-technical challenges in their implementation and adoption.

-Bob Glushko

Semantic Illiteracy

2006-05-13T09:52:00.000-07:00

“Analyzing sets of possible values” is an important task in the design of information models and I emphasize it in courses and projects (it is also a section heading in Chapter 12 of my Document Engineering book). Specifying constraints on content is an essential part of specifying what something means and enforcing them is critical to interoperability.

But just as people often assign bad names to things or concepts, they often fail to analyze possible values, they specify them incompletely, or they just get it wrong. You could say that they suffer from semantic illiteracy.

A few weeks ago in the 10 April 2006 New Yorker’s “Talk of the Town” column David Owen wrote about the drop-down list for honorifics in the sign-up form for the Skywards frequent-flier program of Emirates airline. In addition to the usual Mr / Mrs / Ms/ Miss / Dr the article said that there are at least another hundred of them. Some of them are translations of the usual ones (Frau, Senor, etc.), but most are infrequent or even exotic, such as Dowager, King, Midshipman, Shriman, Swami, Sultan, The Very Reverend, Vice Admiral, Viscount, etc. These examples illustrate that honorifics can encode gender, age, occupation, organizational status, and cultural values. Languages and cultures vary a great deal in how they represent this information.

You might wonder whether Kings, Sultans, and Vice Admirals would ever fly on commercial airlines rather than on their private jets, but as a document engineer that’s not what interests me the most. So I made a brief tour of airlines to see how they handle honorifics and it was interesting.

I started with Emirates… and was astonished to see that instead of the long list described in the New Yorker article, the application form drop-down contained only Mr, Ms, Mrs, Miss, and Master. Maybe the Emirates webmaster was embarrassed by the article and changed the list. That might be the end of the story, except that my next stop on the airline tour was British Air, and I found the exact list described in the article. BA might even be the originator of the list, because that would explain all the British military, peerage, and Church of England honorifics on the list.

I then checked United, the airline that I fly the most often and for which I have amassed over a half million miles in the frequent flier program, where I am registered as "Dr Robert J Glushko" but which says "Robert J Glushko" on the plastic card they gave me. United’s drop-down for honorifics lists seven choices in this order: Mr Ms Mrs Miss Dr Hon Prof. I am also a member of US Air’s program, which uses check boxes instead of a drop-down menu on its registration form. US Air’s choices are Mr Mrs Ms Dr, which is both a shorter list (maybe fewer professors fly US Air) but more interestingly has Mrs before Ms, the opposite order than United. Can we infer anything about how United and US Air treat women as employees or customers?

Air France offers forms in French, where the honorific drop-down is a short list (M, Melle, Mme), and also in English (Mr, Miss, Mrs) – the US Air ordering for the two titles for women. Interesting twist for Air France is that you get to these different forms by choosing a country, not a language, and when you choose Canada the form defaults to French.

Singapore Air, which I’ve only flown a couple of times but really enjoyed, has an odd drop-down in its registration form. Its list of choices is Mr, Ms, Mrs, Dr, Miss, Master, Madam, Others -- but choosing Others doesn’t ask or allow you to specify what other title you go by. Does this mean that if I chose Others my plastic card would say "Others Robert J Glushko" -- I feel like joining just to find out.

Asian cultures are very big on honorifics, so I expected Japan Air to have a comprehensive list of honorifics. I was astonished to see none at all, just the simple First Name and Last Name. This was on the English-language site, and since I don’t read Japanese, I couldn’t check what they do on the Japanese site. But maybe the Japan Air forms designers are better document engineers than those working for the other airlines and they understand how tricky the semantics are here.

The New Yorker article tries to say this in a clever way:

Attempts at exhaustivenesss are inherently self-defeating; the longer a list, the more conspicuous its lacunae.

This isn’t the best advice. You should definitely be exhaustive in situations where there are standard code sets like ISO 3166 (Country codes) or ISO 4217 (currency codes). And when you can’t be exhaustive because of the distribution’s "long tail," I’d recommend that you be sensitive to the frequency of the values, cut off the low-frequency tail, and provide an OTHER category.

But I think there’s a larger message here. The heterogeneity of approaches here for what might seem to be a straightforward information modeling task shows that many people just don’t realize how difficult it is to be precise about what something means. We emphasize "computer literacy" (desktop applications and web surfing) but I’ve never heard anyone fret about how poorly people name and define the things and concepts that their computer applications capture and process for them, which seems more important to me. We need "semantic literacy" or maybe even "ontological literacy" but maybe we don’t teach it because it is too hard to explain what they mean.

-Bob Glushko

Disciplining Services Science

2006-04-23T17:31:00.000-07:00

Last week I attended a conference on "Education for Service Innovation" at the National Academy of Sciences in Washington DC. A couple dozen people from academia, industry, and the government met to discuss the emergence of "services science" -- a hybrid academic field that seems to be emerging from the fuzzy intersection of economics, computer science, information technology and systems, document engineering, law, management, industrial engineering, and organizational sociology to provide perspectives on the evolution of the information and services economy and insight about the services lifecycle. (Steve Lohr mentioned this event in a April 18 2006 NY Times article). IBM has been leading the charge -- I recommend their excellent compendium of Services Science Stuff -- but that's not surprising since IBM, like many other technology firms, has seen its revenue mix shift profoundly toward services in recent years.

Several universities are creating courses and curricula on the services economy and on the design, implementation and deployment of services, including UC Berkeley, where I'm part of a small faculty group developing a Services Science, Management, and Engineering (SSME) certificate for master's students in the School of Information, in the College of Engineering, and in the Haas School of Business.

I think that Berkeley and North Carolina State are the only universities with programs that are called "SSME" -- but that's only because some other schools like Penn State, RPI, Maryland and ASU have already been teaching about services in their departments of Industrial Engineering, Decision Sciences, Business, or Management.

I gave a talk about our efforts at Berkeley, and I raised the bigger question about the relationship of a discipline of Services Science to the various curricula that are springing up. A DISCIPLINE is a principled model of a coherent body of research and practice, while a CURRICULUM is a set of courses or program of study leading to a degree or certificate. The distinction seems pretty important, because the SSME programs that emerge are going to be pretty different, reflecting the emphases and character that reflect the history, location, faculty, typical employers for their students, etc. of the universities or departments that create them. I think a model of a discipline can generate many different curricula and can be used to assess and compare their coverage. Without some intellectual foundation and principles that are explicitly shared by all the curricula, their surface differences will make it hard for a Services Science to mean anything.

So what we're doing at Berkeley is somewhat different from the other universities. Instead of starting from any existing curriculum or course, we're asking "What are the key concepts, themes, and challenges that a SSME discipline should encompass" and generating questions that the disciplines that are coming together in Services Science should be able to answer. For example:

How do firms change over time?

What mechanisms does each discipline propose that firms use to seek and maintain advantages?

How does each discipline evaluate the success of innovations or adaptations?

How does each discipline propose that firms encode what they learn in new mechanisms, organizational forms, or information technology?

How does each discipline explain why and how services combine, standardize, and evolve?

How does each discipline propose to evaluate and optimize a service?

We're not quite there yet, but we are developing new courses in Services Science that will be organized around these kinds of questions. We need to discipline ourselves to make this happen by the Fall semester, because we are already scheduled to teach the first of these new courses, one called "The Information and Services Economy."

-Bob Glushko

The Politics of Document Construction

2006-04-16T14:57:00.000-07:00

Some students in my Document Engineering and Information Architecture course have encountered the politics of document type construction in their class project to analyze the processes and document flows involved in faculty reviews and promotions. What looks on the surface to be an interesting but straightforward analysis and redesign of a form is turning out to be anything but that, and in talking to the students I’ve realized how much the construction of documents can embody political and organizational power considerations.

The processes center around a form called the "bio-bib" that every professor has to fill out annually. The stated purpose of the bio-bib is to collect from each faculty the biographical (i.e., key events and accomplishments) and bibliographical (i.e., publications) information that are the fodder on which reviews and promotions are based.

The bio-bib form is extremely broad in its coverage, with sections for Teaching, Publications, Committee Service, Professional Activities, Appointments, Awards, and so on. Each of these sections is highly detailed; for example, the Teaching section distinguishes activities involving undergraduates, master’s students, PhD students, and post-docs; the Publications section distinguishes many varieties of peer-reviewed and non-peer-reviewed articles, books, and patents; and there are even nine subcategories of Professional Activities.

We can’t find "change logs" or design rationale for the bio-bib, but you can imagine that the highly complex and nuanced structure of the form reflects a history of heated debates and complaints about the value of some kind of activity or publishing by a professor. For example, the last sub-category of Professional Activities is "Efforts made in support of the University's Affirmative Action goals."

But the implicit design goal to make the bio-bib fair to everyone has created a form that everyone hates to fill out. No matter how much you accomplished, when you’ve completed your annual bio-bib you feel like a failure because you are staring at a sparse form because there is no way you have something to report in most of the categories.

You might also think that being fair makes it sensible that every professor, regardless of discipline or department, fills out the same form. But this assumes that all the categories mean the same thing for every professor, and that’s not so. For example, while you’d think that publishing in a peer-reviewed journal is always preferable to a non-peer-reviewed one, law professors seek to publish in law reviews, in which their papers are selected by law students. A computer scientist would probably get no credit for publishing an article in a student-edited journal.

In addition, it is hard not to think that every list of subcategories of biographical or bibliographic events is ordered in some principled way that reflects their weighting or value in a professor’s review. Many of things I do are "down at the bottom of the list" in their implied value (for example, "consulting" is many steps below "serving as a reviewer or editor"). So I cheated and listed my service as a member of the OASIS Board of Directors (a standards organization), as "Service to scholarly or professional societies" because the latter is #3 in its category.

I could go on and on here, but I should let my students discover some of this for themselves (and then I could write in my bio-bib that I did a good job mentoring their project).

-Bob Glushko

Mashware

2006-04-02T15:43:00.000-07:00

My Bashing Mash-ups post has itself been bashed by some folks whose opinions matter to me so I need to try another way to express the point I was trying to make. I wasn't bashing the idea of platforms for mashups - i.e, intelligently designed APIs that expose functionality for other people or services to use. I was bashing the notion that people were going to build serious enterprise applications that way (even though the phrase "enterprise mash-up" seems to be well along the hype curve). A huge problem for enterprise applications is getting all the different information sources and silos to make sense to each other, and this semantic integration challenge is simply too difficult to attack with the level of sophistication I've seen implemented so far in most mash-ups. Take a look at any of David Linthicum's books on application integration (or just read his blog called "A CEO's Guide to EAI, SOA, and Business Integration") for war stories. Enterprise applications aren't assembled in a weekend, but that seems to be the typical effort expended in creating a mash-up. So we're at very different points on the continuum.

Of course, maybe my dispute is just about the names of things, and we all know how contentious names are. Perhaps we're just expanding the notion of "mash up" to include any combination / integration of information from multiple sources, and we can dispense with making any distinction between the categories of mapping and transformation tools, integration servers, message-oriented-middleware, process control engines, EAI, etc. and just call it all "mashware." When every use of software-as-a-service is viewed as a mashup, I'll surrender and stop thinking of mashups and enterprise apps or complexly-choreographed web services as being on a continuum, but until then let's not eliminate all nuance in our discussions about building things.

-Bob Glushko

Bashing Mash-ups

2006-03-26T17:48:00.000-08:00

Everyone is talking about “mash-ups” as if the idea of combining two or more web information sources is revolutionary. It isn’t. Granted, thanks to web services and asynchronous JavaScript and XML, it is now possible for people who are not professional programmers to overlay local data to create intriguing applications using Google maps, Flikr, Firefox or other “platforms.” But there’s a continuum with standard XML schemas, WS-* specifications, and composite applications with choreography on one end and microformats (or roll your own tags), REST, and mash-ups on the other. No matter how clever the mashers get, enterprise applications are not going to be built that way. I don't think that SAP or Oracle think they are doomed because of mash-ups. They aren’t going to take over the earth.

I’m not opposed to the idea of mash-ups. Raymond Yee is teaching a new class this semester called "Mixing and Remixing Information” at UC Berkeley’s School of Information (where I also teach), and students seem to be having a great time in it, including those who didn’t enjoy more traditional computing courses. There is definitely great appeal for a user to mash-up in a couple of days an application that might have taken a real programmer weeks or months in the old days. But I guess I’m just “old school” because I still advocate substantially more systematic and analysis-intensive methods for designing and implementing web applications.

And I am truly amused whenever I hear that some mash-up has been acquired for some ridiculously large sum by Google or Yahoo or someone else. It’s like 1999 all over again when an interesting web site or even just the idea for one could pass for a business plan. I still have on the back of my office door one of Hal Varian’s classic monthly “Economic Scene” articles from the NY Times (from February 2001). It is titled “Comparing the NASDAQ bubble to tulipmania is unfair to the flowers” and ends with this:

The Internet was supposed to remove all barriers to entry, encourage competition and create a frictionless market with unlimited access to free content. But, at the same time, it was supposed to offer hugely profitable investment opportunities. You do not have to have a Ph.D. in economics to see that both arguments are rarely true at the same time.

So if a mash-up can be done with almost no effort, then it isn’t going to enable any sustainable business advantage. Smart entrepreneurs will avoid calling their composite applications “mash-ups” if they are looking for investors or acquirers.

-Bob Glushko

Bad Names -> People Die; Good Names -> Pilots Smile

2006-03-21T19:30:00.000-08:00

After bashing the FDA for its lack of transparency in reviewing drug names in my FDA's Naming Police post, I need to balance the score by saying hooray for the FAA's policy of naming navigation points. In the Wall Street Journal (21 March 2006), an article titled "When Pilots Pass the BRBON, They Must be in Kentucky" explains why the FAA changed its policy of giving meaningless five-letter names to navigation points, and that it now assigns memorable names that give regions distinctive semantic "landmarks." For example, the nav points around Montpelier VT are HAMMM, BURGR, and FRYYS, while the series of points that guide pilots into St Louis include SCRCH, BREAK, FATSS, and QBALL.

I don't know much about aviation, but these navigation points (intersections of the radial signals from ground beacons or satellites) are used by pilots to navigate, and if they aren't memorable, a pilot might set autopilots to fly to the wrong locations. When planes fly to the wrong place they might run into each other or to mountains. So poorly designed names could cause people to die.

Nancy Kalinowski is the FAA's Director of Airspace and Aeronautical Information Management, the department that assigns these names. Way to go, Nancy -- and there are some people at the FDA who could probably use a nudge to be more customer-oriented in the name game.

And while it was neat to see two stories about naming in the Wall Street Journal in just a couple of days, too bad they were assigned to different authors. It would have been provocative to contrast the FDA and FAA naming philosophies in a single article.

-Bob Glushko

FDA's Naming Police

2006-03-21T08:26:00.000-08:00

I've often wondered by drug names seem so strange. A March 17 2006 Wall Street Journal article titled "When a Drug Maker Creates a New Pill, Uncle Sam Vets Name" describes a not-very-transparent process by the US government's Food and Drug Administration for reviewing proposed drug names. The FDA rejects names that are too orthographically or phonologically similar to existing drug names (seems reasonable) but also rejects names that are semantically suggestive because they don't want people to think that a drug will do more than it really does. So for example, "Bonviva" is "bon" + "viva" ("good" + "life") and that promised more than a certain osteoporosis drug can deliver, so it ended up as "Boniva." This seems a little misguided to me and also seems pretty arbitrary, and given how much money the drug firms must spend in market research to test drive names like "Bonviva" it almost seems punitive to reject them.

Anyone who works with information models knows how difficult it is to create good names for things and my UC Berkeley course syllabi for Information Organization and Retrieval" and Document Engineering and Information Architecture" include lots of readings and case studies that rigorously demonstrate that. My favorite is a paper called What's in a name" that contains wonderfully deadpan advice about choosing good names:

If one person thinks of a “shipping container” as being a cardboard box and another person thinks of a “shipping container” as being a semi-trailer, some interesting conversations regarding capacity can occur.

So I think it would be great service to our field if the FDA were to publish its "name design rules" or provide access to its name testing software. But I suspect that the rules and software are a little shaky and the FDA is reluctant to make them more transparent.

-Bob Glushko

RPC Engineering?

2006-03-19T12:58:00.000-08:00

At InfoWorld’s SOA Executive Forum in San Francisco this past week Jon Udell moderated a panel about different communication methods used by services. The panelists discussed the range of options from coarse-grained transfer of complete business documents – orders, invoices, and the like – to remote procedure calls with small sets of data. You can make arguments against big document exchanges on the basis of communication efficiency, but you can also make arguments against lots of small information exchanges because of the extra overhead needed to maintain state while all the little exchanges are carried out.

But the best argument for coarse document exchanges is that if you go that way you’ll be making a conscious design choice and almost certainly have invested some effort into designing the document models or evaluating standard document ones. The documents you exchange will more likely be ones that are easy to process because they’ll have unambiguous semantics and use robust code sets and identifiers. They’ll be easier to reuse across a range of related partners and services.

This isn’t to say that fine-grained information exchanges can’t also be well-designed with interoperable semantics. But many proprietary APIs are getting turned into web services by tools that do little more than slap angle brackets around "get" and "set" methods, and you often get what you pay for when you adopt these low-cost “automatic” design techniques.

Of course I’m biased. My book is called Document Engineering, not RPC Engineering.

-Bob Glushko

Standards, Monopoly, and Interoperability

2006-03-15T08:56:00.000-08:00

Jon Udell (not “John”) writes in “An Argument Against Standards” that standards are an inferior solution to the problem of technology monopolization. Open source is said to be a better solution because by abolishing ownership of the core technology, competing implementations are forks that are easily distinguishable from the standard.

That’s partly right, but misses the point that standards don’t just exist to prevent one party from monopoly – they exist to encourage interoperability. By encouraging a thousand flowers to bloom/fork, open source discourages interoperability.

I admit to being biased in favor of standards, having been involved in lots of standards efforts in the last decade (like xCBL, ebXML, and UBL) and am an elected member of the Board of Directors for OASIS, a standards organization. I am also favorably disposed towards open source. OASIS has been trying to establish constructive relationships with the open source community, but the thousand flowers problem is somewhat of a barrier to that. We’d love to set up a meeting with the CEO of open source.

-Bob Glushko

"Unselling" of Generic Drugs to Physicians

2006-03-14T09:45:00.000-08:00

Automated information exchanges between the FDA, drug companies, physicians and pharmacies promise to save money and time and also lots of lives, because lots of people die from errors with prescription drugs (see To Err is Human: Building a Safer Health System."). I've been reading a lot about healthcare automation lately, and I've used the problem of designing a handheld "prescription writer" as a homework assignment in my Document Engineering course at UC Berkeley. I'd like to imagine that physicians would make decisions about what drugs to prescribe on the basis of information from objective sources... but of course that's a little naive.

So a somewhat disturbing article in the Wall Street Journal on 13 March 2005 about how Pennsylvania is trying to reduce its exploding drug costs for state employees by having "unsellers" visit doctors to pitch generic drugs reminds us that some information exchanges may not be completely trustworthy and automatable. Drug firms have long used people called "detailers" to pitch free samples to doctors, and this article reports how seriously the drug companies track each doctor's prescription habits by mining transaction data from pharmacies. These detailers are very effective at getting doctors to prescribe proprietary and hence more profitable drugs. Pennsylvania is now fighting back using the same techniques against the drug companies.

-Bob Glushko

Electronic Health Records... around the corner or over the cliff?

2006-03-14T09:12:00.000-08:00

In my Document Engineering and Information Architecture course at UC Berkeley we recently discussed an August 2005 case study article from the Annals of Internal Medicine called “Electronic Health Records: Just around the corner? Or over the cliff?” Unlike many case studies that strive to present the facts in the best light, this one tells the story of a small medical office’s efforts to adopt electronic health records and other electronic documents with unexpected honesty… maybe naïve honesty. I highly recommend it to anyone considering a document automation effort, especially in healthcare.

Reducing costs and improving efficiencies by automating repetitive document processing within its office and within its “ecosystem” of labs, clinics, pharmacies, and 3^rd party payers were the primary motivations for adopting a system. Unfortunately, the staff and physicians had grossly unrealistic expectations about how easily they could learn to use the system and didn’t count on having to radically redesign “15 years of accumulated workflow” to make it work. Furthermore, much of the pain and productivity loss was self-inflicted. Without evaluating any alternatives, they chose a system that imposes a rigid repertoire of 24 document types that that won’t let any document be filed unless it has been assigned to one of those types. And instead of preparing electronic records for their existing patients ahead of time, the staff waited until patients came for appointments to begin any legacy conversion.

Somehow these folks got it all to work, and they say that they are now better physicians and wouldn’t go back to the paper document processes. But I suspect that the lessons they report in this article will be learned the hard way by many other physicians – maybe because doctors have to be smart, they can’t believe that document automation can be that challenging.

-Bob Glushko