« January 24, 2003 | Main | January 28, 2003 »
January 27, 2003
Representations and URIs
Jon Udell references a discussion that has been raging on what a URI represents. Jon quotes Tim Berner-Lee who summarizes it, succinctly, as follows:
What does "http://www.amazon.com/exec/obidos/ASIN/ 0679600108/qid=1027958807/sr=2-3/ref=sr_2_3/103-4363499-9407855" identify?I find this question fascinating since it takes me back to my formal computer science roots. A long time ago, I was a formal methods researcher. Sherman, fire up the way-back machine:
- A whale
- "Moby Dick or the Whale" by Herman Melville
- A web page on Amazon offering a book for sale
- A URI string
- All the above
In the late 80s there was a huge battle raging in some professional journals and letters to the editor in Communications of the ACM (CACM). (Remember, this was before blogs or even the web.) Demillo, Lipton, and Perlis had published a paper called Social Processes and Proofs of Theorems and Processes. It was followed by a paper in CACM by James Fetzer called "Program Verification: The Very Idea." Fetzer argued that proofs of correctness for programs was ridiculous from the start since the artifact had many properties that the proof could not consider. In 1989. Jon Barwise (who is now dead, unfortunately) wrote an eloquent paper in the Notices of the American Mathematical Society called "Mathematical Proofs of Computer System Correctness". Barwise argued that Demillo, Lipton, Perlis, and, especially, Fetzer had made a critical error by confusing the thing with the mathematical representation of the thing. Sound familiar?
The very essence of Applied Mathematics, and by extension, Computer Science is the notion of representation, naming, and abstraction. Confusion in these issues shows up quite frequently when students are learning about naming in a programming language theory course. (I always like to ask the question "What is '3'?") Confusion in these issues can lead to significant problems as the theory is developed later.
From a formal semantics viewpoint, a URI, like any other name, has to represent the thing that it is bound to and nothing else. That is, the URI represents whatever is returned when the URI is dereferenced. What is returned in the case of a URI is a string of bits. The resource that is returned may represent something else, but the URI is just a name for the resource. It carries no semantics beyond that. The resource is a model of something. The mathematics behind all of this is quite well developed and well thought out. This problem is a classic CS problem, not something that the web invented.
As an example, consider the URI for tracking a package at UPS. The URI is merely a name for the resource. That same resource could have millions of other names that all dereference to the same resource. The resource is a model for a package. That is, its an abstraction, based on properties, of a physical object. We must not confuse the model with its name and we must not ever confuse either of them with the artifact that the model represents.
For those who are interested in this kind of thing, Mike Gordon's The Denotational Description of Programming Languages: An Introduction is a great, readable introduction by one of the luminaries in the field.
10:28 PM | Recommend This | Print This
Semantics for Web Service Description
David Booth, a W3C Fellow, has a picture which I've seen in several talks and wanted to document. The picture shows how a web services description (WSD) is referenced by the client and the server, but, more importantly, how it references semantics. XML semantics has been something of a pet peeve of mine in the past. Here's the picture:
The point that David makes is that the server and the client have to agree on semantics. If they don't, of course, the result is gibberish. The semantics might be in some formal langauge, although not very many people enjoy writing formal semantics of anything. I used to do this; its very time consuming. More likely, the semantics is just in written in English. David wants the semantics to be written and referenced by the WSD so that it can be found and used by the programmer. I think this is an excellent idea. Even a natural language semantics would be very helpful in understanding the WSD and applying it.
David suggests using the "targetNamespace" attribute in WSDL for the reference. I have no idea whether that's a good idea or not. I do know that other people have other ideas about what that attribute should be used for.
07:35 PM | Recommend This | Print This
Superbowl.com
I just noticed a link on Technorati to superbowl.com. I used to own that domain (1994-1996) so it always sparks my interest. I did the Superbowl sites for Superbowl XXIX and XXX in conjunction with the host committees in Miami and Phoenix. In 1996 the NFL sent us a "cease and desist" order and said we'd be in court the next week. They had more lawyers than I knew, so we transfered the domain to them and got out of the Superbowl business.
09:50 AM | Recommend This | Print This
Federal DRM and Web Services
If you're at all interested in what the Federal Government will do with web services, one thing to keep your eye on is the Data and Information Reference Model that's one layer in the Federal Enterprise Architecture. The DRM is important because its the key to transforming government. Application integration is only part of the problem. Fundamental data analysis and modeling is the foundation upon which collaborative applications can be built.
If you follow the link to the web site, you may be disappointed small amount of content there; the DRM is the least developed of the enterprise architecture layers. Still, if you dig around there's plenty of information available on what people are thinking. Here's some of it.
The DRM is:
- Business-focused data standardization.
- Cross-agency information exchanges.
- Federated Registries and Repositories organized according to the Business Reference Model.
- An agile framework for building new cross-agency applications and services.
The DRM will not be:
- A government-wide data model.
- A government-wide markup language.
- Complete!
The last bullet is particularly important. The goal isn't to build a complete data model, but to build the meta-model that data lives in. Probably the best example of collaborative data sharing and collection in government at present is the FedStats web site.
So, what does this have to do with XML and web services? At its core, the DRM is addressing that problem of data sharing and that's what XML is good for. The move seems to be to use XML repositories and registries to build these data models. There are a number of projects around the Federal Government that are being pointed to as "pilots" for DRM efforts. One example is the Global Justice Information Network effort with XML that I've referenced before.. Another example is an IRS Small Business Resource Guide project. It may look like HTML upfront, but underneath its all XML and can be easily repurposed with different views for different users.
09:36 AM | Recommend This | Print This
Email Consolidation
I've heard that the email consolidation project that the Cabinet approved as part of Utah's IT plan will be axed. This doesn't surprise me. If I were still around, I'd have probably let it die as well. The project isn't failing for technology reasons. The project is failing because:
- Agency IT personnel won't cooperate. It was a gamble from the start to take the very people who are running email in the agencies now and ask them to come up with a plan for changing it. They have little motivation to do so since they like the status quo. I didn't attend the meetings, but I understand that some of them were downright hostile.
- ITS is not positioned to make it work. ITS has to be able to take this service over and run it flawlessly for this project to have the desired affect (see below). At one point, a few months ago, the current ITS-run email service was offline for dozens of hours over a period of time, completely unmonitored. No one's going to trust that. At the same time, you'd have a tough time convincing a lot of people in ITS that there's anything wrong. That's a problem.
Some will claim that the ROI just wasn't there, but that's a red herring. The ROI for email consolidation was never the point. The whole point of the exercise was to prove it could be done. Why? Because until you can consolidate email, you've got no hope of consolidating more complicated services like LAN administration and desktops. That's where the ROI is.
The State of Utah spends $10-20 million per year more on IT than it needs to. To see those gains though, IT would have to be organized very differently. The real kicker is that they could not only save the money, but get better service as part of the deal---if its done right. At this point, however, I think the email consolidation failure has shown its going to take a lot more than the Cabinet asking to have it done to make something like this work. My fear is that the legislature will try to force it through cuts without giving the CIO the authority to change the organization. That's what they did last year and it was a disaster.