Tuesday, June 24, 2008
XML Fever
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
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
Wednesday, June 18, 2008
Service Systems in Taiwan and Taiwan as a Service System
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:
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
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
Friday, May 30, 2008
Post-It "Signatures" Aren’t Signatures
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
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
Wednesday, May 21, 2008
Unleashing the Masters of Information
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
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
Sunday, May 11, 2008
Document Engineering and User Experience Design
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
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
Sunday, April 27, 2008
Whining About Wine and Champagne
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
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
Sunday, April 20, 2008
Document Engineering for Microfinance in Developing Countries
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
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
Labels: DocumentEngineering, ICTD, Microfinance
