From: general-digest-list-request@onemodel.org Subject: general-digest-list Digest V00 #2 X-Loop: general-digest-list@onemodel.org X-Mailing-List: archive/volume00/2 Precedence: list MIME-Version: 1.0 Content-Type: multipart/digest; boundary="----------------------------" To: general-digest-list@onemodel.org Reply-To: general-list@onemodel.org ------------------------------ Content-Type: text/plain general-digest-list Digest Volume 00 : Issue 2 Today's Topics: Re: our software project (and, diges [ Luke Call ] development strategy for OneModel [ Luke Call ] TimeLine Re: our software project (a [ "Tom and other Packers" ] ------------------------------ Date: Sat, 05 Aug 2000 21:00:28 -0600 From: Luke Call To: general-list@onemodel.org Subject: Re: our software project (and, digest list is available) Message-ID: <398CD4CC.4060201@onemodel.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Everyone, The digest list is available, the address is on the web site now, including how to get previous messages out of the archive (I haven't tested it). Tom and Everyone, I can get a list of subscribers any time--right now it's me, you, Mark, Lee, and Greg Harness (a friend of mine from work). I thought one other person (a friend of yours--Chris Angell? sp?) had also subscribed but I don't see him in there now. I don't think there's any way but to ask me--which you can do any time you like. With a reminder I could post the number of subscribers every month or something. We should also assume that anything we say in the list is public--anyone who wants should be able to retrieve the archived messages from the digest list. Also related to the list, since all our quoted email replies will be included in the digest, in addition to the original message that is being quoted, it might be best if we start a practice when replying of quoting only the minimum necessary original text, so the digest doesn't come out having the same message in it so many times. As far as a timeline, I don't think I can commit to deadlines for anything still, just to doing what I can, so I couldn't ask anyone else for deadlines. But I do have an suggestion for a development outline that I'll send in the next email. I think we can just work on it as we are able. Hopefully we'll get to a point soon enough where each person can have as much to do as they want to keep them busy on it. At least, once there is a development outline with clear agreement on what we're looking for, design, etc., anyone can set forward an implementation or a module if they get tired of waiting for others. I hope. How does that sound? Luke ------------------------------ Date: Sat, 05 Aug 2000 21:00:41 -0600 From: Luke Call To: general-list@onemodel.org Subject: development strategy for OneModel Message-ID: <398CD4D9.7080802@onemodel.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit In the large, here is a possible approach to building our system. Could take years but still worthwhile. Here are possible phases: 1 - Build a simple system with a simple text interface to handle modeling nouns and their relationships and attributes to other nouns (things as they are). Each datum or concept is independent of its names and could have many names (or none), but probably has relationships. This phase includes modeling key abstractions for the system that we will build on. Manual input only, single-user at this point? 1.x - Do very simple queries. 2 - Add a way to include or link to pictures or other data types and files/documents? (so you can store family photos in the personal organizer we made in previous step?) At this point, is the system fully capable of storing family history data, to the extent of what is in one's paper filing cabinet or specialized family history software? What portion of the "time" stuff from later phases is needed for genealogy, now? 3 - Make the system multiuser, with considerations for access, performance, storage, and security. (Look into concepts behind Jini, JavaSpaces [Linda], distributed storage systems, etc. to see what helps.) 4 - Look at issues of import/export (including genealogy), branch (for someone who disagrees or wants different security or emphasis) and merge of data sets. Export XML (or later). 5 - Tackle "context"--how to use (or query for, or even guess or deduce based on available data) the names for things used in a given context (time, geography, family, personal, language, subject area)? (Tom: does linguistics go here somehow? How do you see this working?) 6 - Handle verbs, issues of time/chronology (things as they were and as they are to come), possibility of running simulations or what-if scenarios with available data. 7 - Make it support more interesting queries. Come up with faster, more efficient input methods (automated? text processing, even if human-assisted?). Consider these relative to other system requirements, including interface issues. That's a first stab at it. What does everyone think--how would you change the above? I'm sure there will be corrections, or that priorities will change as we go. This an excellent time to review the requirements list and your idea of what the system can become. We want to address first the requirements that have high technological risk (can it be done?) or that have a high architectural impact. Of course we'll have to do some revising as we go, but hopefully not to re-architect too often. Also, if there are things that can be done but we don't personally have experience in it (like simulation software, distributed storage), that can be figured out when needed. Once we have a good enough consensus on the overall approach, we can continue with the process. Again, I'm trying to follow roughly the Rational Unified Process, not that it's the ultimate in everything, but because it works, and it seems pretty reasonable to me. I think after we review the above, we could post a development outline to the web site, then start listing the key use cases for phase one (i.e., the features we'll implement at first and how they flow from a user standpoint, what the user input is, what the user expects to see as a result, and what happens in between). Once we have chosen our most critical use cases, we'll detail them down to the point of getting an architecture and some module definitions, technology choices, some interface guidelines, etc. Pretty soon we should get a task list ready for anyone with time to work on. We'd probably want to put the use cases and task list in CVS since they are living documents. (Mark, can we still use your CVS system for that?) Thanks! Luke ------------------------------ Date: Sun, 6 Aug 2000 13:31:22 -0600 From: "Tom and other Packers" To: Subject: TimeLine Re: our software project (and, digest list is available) Message-ID: <006201bfffdc$fec6e980$0106a8c0@oemcomputer> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Luke When I suggested a timeline, I didn't mean deadlines. I meant, and mean, a sequence of steps that we agree is appropriate, with relative time defined, but not absolute time. I want to know what the direction is, and maybe the ultimate destination, not the ETA (estimated time of arrival), nor even "ETA" (exact time of arrival). Question: does it matter if I change the subject line of a message when I reply to something? I imaging that some e-mail dialog software programs would make assumptions of how e-mail letters are connected by the subject lines. Luke, your next message indicates that you agree with this perceived need of a time-line. I will now add my opinions regarding this timeline. About step one: I agree with the way you related nouns and concepts. I'd like to de-emphasise the "noun", and say that we should start building a model based on ideas, not on parts of speech. Maybe this is what you had in mind (since you do say in this paragraph that some ideas do not have names). Manual, single-user input is good here. By the way, when I asked about language being one of the first branches of knowledge which we should test our system on, you seemed to say that I should bring that up later. I think you may have assumed that I mean a full natural language processing system. I actually meant language in a more general sense (although natural language could be useful early on, too), and the motivation for me to look at language immediately is, we would be killing two birds with one stone: the subject of language is useful as a type of knowledge to model, and as a means of making the model itself. I think we should start talking about file formats in step one, and maybe make the user interface and a simple text file format that look the same. Static file format and dynamic operations on data should probably develop in parallel (co-evolve), since they are mutually dependent. After your step 1.x, the first significant operation on the data, we might want to diverge the file format and UI, and the modules used in the conversion of one into the other could be the start of our import/export algorithms. But I think we should develop and preserve multiple file types, especially text-based files formats, on an on-going basis, and add translators as we add file types. At this first divergence of UI and file type, we might want to develop an efficient binary file format on which to perform all the major algorithms thereafter. The other steps are too distant for me to comment on yet. Some of the sequencing is arbitrary. Maybe we could simplify the process of outlining the process of making our system by writing or drawing up a static graph of what the final product will look like, and link each component with "dependency" relations, and add some sort of "check mark" to each module to indicate what has been accomplished. This could be a picture (graph) "picture", or it could be a serialised textual "picture" of what the final product will contain. This way, anyone wanting to help can look at the components needed, and choose whatever he is most interested in helping with, almost without regard to what everyone else is working on, or has finished. He will also know by the check-marks and the dependency links what is most useful to everybody else at any given time, and what the programmer would find easier or harder to work on (considering what modules his module is dependent on, and if any or all of them have already been made). What do you think? By the way, what is the name of our "system"? OM? ciao, tomp ----- Original Message ----- From: Luke Call To: Sent: Saturday, August 05, 2000 9:00 PM Subject: Re: our software project (and, digest list is available) ... As far as a timeline, I don't think I can commit to deadlines for anything still, just to doing what I can, so I couldn't ask anyone else for deadlines. ... Luke ------------------------------ Date: Mon, 07 Aug 2000 06:48:12 -0600 From: Luke Call To: gelernter-david@yale.edu, general-list@onemodel.org Subject: your "second coming - a manifesto" article Message-ID: <398EB00C.2080407@onemodel.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I read your "manitesto" article with great interest, because some friends and I have been thinking a lot about the subject for some years, and are beginning work on a related project. I'm a software engineer at a major semiconductor company, doing this in my spare time. As background, I refer you to our web site at www.onemodel.org. For brevity I won't insert all the same material here. (The site will soon also have our development outline and some initial use cases for our analysis/design phase. It also needs a better intro document, as the "proposal" one is two years old.) As our two projects relate, we agree on all points in your article, up to about #38, where I would respectfully replace your emphasis on documents and chronology with a consideration that those are just other aspects to be modeled, along with all else in a complete system. The reason is this: My goal is to store all available knowledge in one bucket (as per the requirements list at our web site). To do that, we consider: what is knowledge at an atomic level? If I mention a word to you, like "printer", you may immediately think of many concrete things, dimensions, etc., because in your mind is a mental model of what a "printer" is, and of your experiences with them. When we communicate about such concepts in human languages we are required to translate between our understanding and our human language, with effort. The listener must do the reverse translation in order to understand (or at least I do). I hypothesize that knowledge, at an atomic, most fundamental level, consists of something like an object model, with classes of objects, defined in varying degrees of precision or ambiguity, with attendant measurable properties & behaviors. And so it is conceivable to create a system to programatically create a full object model of all we know. Documents and chronology are just a part of that. Virtual reality interfaces and Star-Trek-like queries would be nice but that will have to come later. For now, we have to tackle architectural issues basic to the system, and a simple enough proof of concept. The proof of concept we're shooting for will be just a personal organizer built upon these ideas, with a text-based interface. Once we've gone over the use cases, we'll build a domain model, and start development, loosely following the Rational Unified Process plus the examples of other GPL efforts. We largely share the same vision, and your knowledge and experience could save us from big mistakes at times, especially in this design phase. I respect what you could do for something like this. I've read a little about Lifestreams, but our focus is on the model rather than on the chronology. Together (that is, with your input), we will hopefully have an effect on the world so that things like the Library of Congress, the Web, and the knowledge of mankind can be used to their true potential. I hope for a collaboration. I invite you to a dialogue. Yours truly, Luke Call -------------------------------- End of general-digest-list Digest V00 Issue #2 **********************************************