The Vision of MAYA
Posted by Kevin Hoffmann
When I joined MAYA in November of 1997, I was excited by the ideas of new challenges, working on all types of user interfaces. I had found myself in previous jobs building user interfaces (a voice response application, an interface to compile large mainframe applications and run regression tests). During my first week I had a meeting with Peter Lucas, one of the founders of MAYA, to gain some insight into what MAYA is and what they were doing with Visage and Interstacks. After a couple of hours of Pete diagramming things on a whiteboard, talking in what seemed like a foreign language (it sounded like English, but with a bunch of odd words like ‘uforms’, ‘repositories’, ‘transducers’, etc.) I went home that night and wondered if I was in over my head.
It takes a little while to comprehend the larger vision of what MAYA is trying to accomplish: designing devices and user interfaces for the age of information liquidity and pervasive computing. During my first three years at MAYA, I was immersed in our VisageLink research project. The goals included experimenting with direct manipulation of data elements (cells in a table, items on a map, etc.) and the ability for two human beings to collaborate by sharing their views of the information in whatever way they each wanted to present it. We also experimented with a visual programming paradigm that made the code segments that could be easily reused and recomposed to perform different functions. We then experimented with taking the PC and breaking it into functional parts: a repository (something that stores information), an executor (something that processes that information), and transducers (something that allows the user to interact with the information). These projects, when taken separately, seem totally unrelated. But if you have the time to talk to Pete about his grand vision, you will soon understand (or at least nod your head and pretend that you understand for a while) that they are all little forays into the various aspects of the pervasive computing arena. And they focus on the challenges that will be present in this new world where computers are all around.
Now I’m in my 9th year of working for MAYA. There are still some things that I don’t fully understand and some things with which I don’t fully agree. There’s a lot of it that make perfect sense, and I can’t understand why people continue using tools that place so many constraints on their ability to visualize and analyze information. Things like uforms infotrons and transducers all make perfect sense now. Working at MAYA has affected the way I think about problems and how I attempt to solve them. The principles and ideas are infectious to all who work at MAYA—especially those of us who have been around for more than a few years. The problem is, it’s not easy. This is why we tackle a little bit at a time, drilling down on a particular problem, hoping to find an answer, and typically ending up with a few more questions.
Few months back, Pete gave a general overview of how the research that MAYA has done for the last 17 years is bearing fruit in various ways, and why MAYA will continue to do research and experiment in the future. The entire content of the talk is now up here on the Foundry, and it is much easier to understand than that first meeting I had with him. It reminded me of all the things that I had forgotten that I didn’t know or believed before I came to MAYA. For me, this was a nostalgic glimpse back at my early days at MAYA. It caused me to remember how much I wondered about what MAYA was trying to do, and I realized again how important it is to continue making progress on our research agendas, regardless of the challenges from the business perspective. We hope this is only the first of many such talks that we will be sharing with you.
But there is something that doesn't feel right. I'm not sure if this is the right place to post this, but I haven't found a better place.
I'm troubled by the u-form architecture. Maybe I'm missing some big problem that you've already figured out, but why did you choose to stuff all of those attribute value pairs into a single construct, the u-form? Why not keep each attribute in a separate "value container" (each with a unique UUID) and then create a "link container" that holds: the name of the attribute, the UUID of the "parent" and the UUID of the value?
It seems like this would make it much easier to handle the concurrent editing of things like collections. Each member of a collection would be in a separate value container, and each value container would be connected to the collection UUID by a link container with: a name of "member", and the UUIDs of the value container, and the "parent" container.
As an added bonus, since the link containers would be separate (with their own UUIDs) you can refer to them by ID. Adding annotations to an attribute would then be possible. For example, you could annotate the individual attributes with authorship, versioning, or conflict information.
Also keeping the links in a separate container allows you to query for incoming links to a UUID. You just search for any links that have a target UUID matching the current object. Although there would be a lot of link containers to search through, each one would be small, and would only contain: name, source UUID, and target UUID.
With u-forms you can look at the values of the attributes to see which contain UUIDs to another u-form, but incoming links would require that you check every attribute value of every other u-form.
If the link containers are separate, they automatically provide for bi-directional navigation. With a u-form, you have to store 2 UUID pointers to get from a -> b and from b -> a. Right?
Again, I love Maya. I'm thrilled about what you are trying to accomplish. I'm just trying to toss in my two cents in case it might help.
What do you think?
Your suggestion in this posting is certainly perceptive, and alludes to a fairly significant point. Since each UUID is globally unique, and each attribute name is unique within a u-form, it follows that each UUID/attribute combination could be regarded as its own unique identifier, a global variable name that contains a particular value. Why bother to bundle these variables together into packages called u-forms, since a logically equivalent approach would just be to have UUIDs and values? After all, if you want to assert that several values should be bundled together, you can make this assertion using the same system, as you correctly state.
The reasons for bundling several attributes together into a single u-form are more practical than strictly logical. It gives information designers something more tangible to work with, and it sometimes helps to be able to work with a whole u-form containing several pieces of information about a single concept. To take a traditional example, to build a library catalogue, it helps to have bibliographic entries that contain the title, author, year, publisher, etc., for each publication, in a single information object. We prefer to think of a u-form as representing something like a single card in a card catalogue - bigger than a single variable, but smaller than a relational table.
This confers some practical benefits. For example, it greatly simplifies the management of digital rights and reading and writing permissions. Attributes that are often considered to be 'metadata' such as the author, digital signature, copyright statement, and date-last-edited, can all be part of each u-form. This prevents a hacker from tampering with a u-form without it being immediately obvious. If you didn't use the u-form idea to collect several attributes, you would have to add things like digital signatures in separate linking containers. The complexity of checking things like copyright and authenticity would increase dramatically. It would require very reliable indexing to implement, and if you want to make rules such as "don't replicate any data unless it contains appropriate copyright statements" (which is a rule we do want to enforce in many cases), you would effectively have to build a system that always gets the rights and permissions for a variable A whenever it also gets A. If all of these separate bits of information are in different places, you have a problem on your hands, starting with the simple observation that you'd have to do a lot more independent disk reads.
In many cases (including the Information Commons Publication Model), we do break contributions up into separate u-forms, because we do want to enable decentralized contribution and distributed authority. To make this work, we have introduced a variety of search structures built out of u-forms, as described in the
Shepherdable Indexes paper. We do have some methods for annotating relations, including something called an annotated collection. In general, this would enable us to create annotated relation hierarchies (e.g., the defendant is one of the participants in a court case). In practice, we have not found this necessary in any of our applications to date, so our approach to this topic is not as formally specified as it is with related approaches such as Conceptual Graphs.
In general, the question of "what is the ideal size for an information bundle such as a u-form?" needs to be considered from a variety of points of view. A u-form is a conceptual unit, it affects the implementation (e.g., you can replicate it separately but you also need to read it from disk separately), a trust unit as described above, and a collaborational unit. For more investigation of this topic, it may be worth reading the paper on
Managing Distributed Collaboration.
So, your question and suggestions are very thought provoking and right on the mark. Our design decisions are generally focussed around tractability and scalability, which we need to optimize, and for this, we're willing to accept that logical correctness may be just satisfactory, not necessarily optimal. Not suggesting for a moment that we've hit upon the unique correct or best design decisions, but we have done well enough so far to keep the grand experiment moving forward!