If what Peter has released has code for a node-arc display, code he
adapted and greatly improved from the project WebQuestMapper, there is
an applet at
http ://www .nexist. org/ wqm/ WQMApplet.html
(paste into a browser and kill the white space). Go there and use
Help:View Help Map to see his code in action.
Jack
Note: that server is running on a dsl line in my living room; the
whole damned apartment building might burn down if slashdot ever got
that URL. (01)
On 1/9/06, Peter P. Jones <ppj@concept67.net> wrote:
> Thanks for the 'ant', Aleks.
>
> OTMB was created for constructing a knowledge representation with
> support for proper nested contexts. I.e. It's for non-monotonic
> representations in a digraph. Topic Maps can be extracted/created from
> the OTM using XSLT (or other means). I supplied an XSLT basis for
> building extractions at
> http://www.concept67.net/openthemic/openthemicmaps/xsl/otm2html_page.xsl
>
> The OTMB-v0.2.2a is restricted in that its interface only builds context
> nesting as a tree (which simplifies some processing), but in principle
> OTM doesn't force the nesting to be tree-like. Nesting could be...erm,
> higher dimensional - like popping into new universes through wormholes,
> but that would require a superior GUI.
>
> W.r.t. to what Eric A. is designing I'm just suggesting that the basic
> mechanics and model of the interface and innards of OTMB could be
> rapidly hacked to supply what he wants to provide a headstart on his
> DIBS. Some of OTMB's machinery was made to do the same things he's
> asking for.
>
> Cheers,
> --
> Peter
>
>
>
> Aleksander Slominski wrote:
> > Peter P. Jones wrote:
> >
> >> [Offlist]
> >>
> >> I'm sending this offlist because I'm not the sort who is capable of
> >> bragging in public, but I think you ought to look at (i.e. compile,
> >> run and play with, view code) the last iteration of my OTMBuilder for
> >> some basic Java code for this DIBS thing.
> >
> >
> >
> >>
>http://www.concept67.net/openthemic/openthemicmaps/otmb_v022a_source-2005-03-19.zip
> >>
> >> (it requires XMLPullParser 3 or higher on the classpath:
> >> http://www.extreme.indiana.edu/xgws/xsoap/xpp/ )
> >
> >
> > to make the process simpler download build.xml[1], put it inot "OTMB1.5"
> > directory and run "ant download run" to see the GUI.
> >
> > now i wonder if there is an example showing how it works (videocast?) -
> > i got completely lost in what it is supposed to do (though i managed to
> > connect two nedoes with an arc ...)
> >
> > best,
> >
> > alek
> >
> > [1] download from
> > http://www.extreme.indiana.edu/~aslom/2006/01_OTM/build.xml
> > or copy and paste:
> >
>------------------------------------------------------------------------------------------
> >
> > <!--
> > This is an ant build file compatible with ant version 1.6.2 (for
> > macrodef and presetdef)
> > All generated files are created under ${build} directory
> > -->
> >
> > <project name="OTM" default="compile" basedir=".">
> >
> >
> > <!-- allow user to override properties with external file-->
> > <property file="build.properties" />
> >
> > <!-- set global properties for this build -->
> > <property environment="env" />
> > <property name="JAVA_HOME" value="${env.JAVA_HOME}" />
> > <property name="PROJECT" value="${ant.project.name}" />
> >
> > <!-- set global properties for this build -->
> >
> > <property name="name" value="OTM"/>
> > <property name="year" value="2006"/>
> > <property name="SPEC_VERSION" value="1.5"/>
> > <property name="VERSION" value="${SPEC_VERSION}"/>
> > <property name="VENDOR" value="org.concept67.otmbuilder"/>
> > <property name="version" value="${VERSION}"/>
> > <property name="otm_version" value="OTM-${version}"/>
> >
> > <property name="debug" value="on"/>
> > <property name="deprecation" value="off"/>
> >
> > <property name="src" value="."/>
> >
> > <property name="build" value="build"/>
> > <property name="build_lib" value="${build}"/>
> > <property name="build_classes" value="${build}/classes"/>
> > <property name="build_samples" value="${build}/samples"/>
> > <property name="build_tests" value="${build}/tests"/>
> >
> > <property name="lib_xpp" value="lib/xpp"/>
> > <property name="xpp_jar" value="xpp3-1.1.3.4.O.jar"/>
> > <property name="xpp_repo"
> > value="http://www.extreme.indiana.edu/dist/java-repository/xpp3/jars"/>
> >
> > <property name="jar" value="${build_lib}/${otm_version}.jar"/>
> >
> > <patternset id="all_source_files">
> > <exclude name="**/*-"/>
> > <exclude name="**/*~"/>
> > <exclude name="**/*.cpr"/>
> > <exclude name="**/*.mcp"/>
> > <exclude name="**/*_Data/**"/>
> > </patternset>
> >
> > <!--
> > =================================================================== -->
> > <!-- Preparing build
> > environment -->
> > <!--
> > =================================================================== -->
> > <target name="clean">
> > <delete dir="${build}"/>
> > </target>
> >
> > <target name="prepare">
> > <echo>${ant.project.name} Version: ${version}</echo>
> > <mkdir dir="${build}"/>
> > <mkdir dir="${build_classes}"/>
> > <touch file="${build_classes}/${otm_version}_VERSION"/>
> > <available property="junit_present"
> > classname="junit.framework.TestCase" />
> > <available property="dom2_present" classname="org.w3c.dom.Document" />
> > <available property="sax2_present" classname="org.xml.sax.XMLReader" />
> > <uptodate property="build_notRequired" targetfile="${jar}">
> > <srcfiles dir="${src}" includes="**/*.java"/>
> > </uptodate>
> > </target>
> >
> > <target name="check_junit" unless="junit_present" depends="prepare">
> > <echo message="Warning: JUnit dependencies were not resolved."/>
> > </target>
> >
> > <target name="get_jvm"> <!--
> > http://www.jguru.com/faq/view.jsp?EID=557952 -->
> > <condition property="jvm5_ok">
> > <not>
> > <or>
> > <equals arg1="${ant.java.version}" arg2="1.1"/>
> > <equals arg1="${ant.java.version}" arg2="1.2"/>
> > <equals arg1="${ant.java.version}" arg2="1.3"/>
> > <equals arg1="${ant.java.version}" arg2="1.4"/>
> > </or>
> > </not>
> > </condition>
> > <condition property="jvm3_ok">
> > <not>
> > <or>
> > <equals arg1="${ant.java.version}" arg2="1.1"/>
> > <equals arg1="${ant.java.version}" arg2="1.2"/>
> > </or>
> > </not>
> > </condition>
> > </target>
> >
> > <target name="check_jvm3" depends="get_jvm" unless="jvm5_ok">
> > <fail message="Minimum JVM 1.5 required but got ${ant.java.version}
> > (java.version=${java.version} and JAVA_HOME=${env.JAVA_HOME})"/>
> > </target>
> >
> > <target name="check_jvm5" depends="get_jvm" unless="jvm5_ok">
> > <fail message="Minimum JVM 1.5 required but got ${ant.java.version}
> > (java.version=${java.version} and JAVA_HOME=${env.JAVA_HOME})"/>
> > </target>
> >
> > <target name="dependencies" depends="prepare,check_jvm3"/>
> >
> > <!-- Use this target to check that all optional dependencies are
> > fulfilled -->
> > <target name="checks" depends="dependencies"/>
> >
> > <!--
> > =================================================================== -->
> > <!-- Download
> > task -->
> > <!--
> > =================================================================== -->
> >
> > <target name="download" depends="prepare">
> > <mkdir dir="${lib_xpp}"/>
> > <get src="${xpp_repo}/${xpp_jar}"
> > dest="${lib_xpp}/${xpp_jar}"
> > verbose="true"
> > usetimestamp="true"/>
> > </target>
> >
> > <!--
> > =================================================================== -->
> > <!-- Compilation
> > tasks -->
> > <!--
> > =================================================================== -->
> >
> > <target name="impl" depends="dependencies">
> > <mkdir dir="${build_classes}"/>
> > <javac debug="${debug}" deprecation="${deprecation}" source="1.3"
> > target="1.3"
> > srcdir="${src}" destdir="${build_classes}"
> > classpath="${build_classes}:${lib_xpp}/${xpp_jar}" />
> > </target>
> >
> > <!-- JAR build -->
> >
> > <target name="jar" unless="build_notRequired" depends="impl">
> > <mkdir dir="${build_lib}"/>
> > <jar jarfile="${jar}">
> > <manifest>
> > <attribute name="Built-By" value="${user.name}"/>
> > <attribute name="Specification-Title" value="OTM"/>
> > <attribute name="Specification-Version" value="${SPEC_VERSION}"/>
> > <attribute name="Specification-Vendor" value="${VENDOR}"/>
> > <attribute name="Implementation-Title" value="OTM"/>
> > <attribute name="Implementation-Version" value="${VERSION}"/>
> > <attribute name="Implementation-Vendor" value="${VENDOR}"/>
> > </manifest>
> > <fileset dir="${build_classes}"/>
> > </jar>
> > </target>
> >
> > <target name="otm" depends="jar"/>
> >
> > <target name="compile" depends="otm"/>
> >
> > <target name="all" depends="clean,compile"/>
> >
> > <target name="run" depends="jar">
> > <java classname="org.concept67.otmbuilder.WQMApplet"
> > fork="true"
> > >
> > <!--arg value="-h" -->
> > <classpath>
> > <pathelement location="${build_classes}"/>
> > <pathelement location="${lib_xpp}/${xpp_jar}"/>
> > <pathelement path="${java.class.path}"/>
> > </classpath>
> > </java>
> > </target>
> >
> > </project>
> >
>------------------------------------------------------------------------------------------
> >
> >
> >>
> >> Jack and I hacked a Java WebQuestMapper tool that did collaborative
> >> IBIS over Jabber, it didn't have the interface depth mechanism of OTM
> >> though - it was only one diagram deep, though we did discuss a
> >> mechanism like OTM has. But we did manage to get a collaborative
> >> session working just by passing move, create, delete, edit signals for
> >> the graph back and forth in very simple terms.
> >> I have that WQM code on a backup CD somewhere...
> >> Combining the two might give you a lot of what you want, minus the
> >> rules for correct DIBS graphs.
> >>
> >> Cheers,
> >> Peter
> >>
> >> Eric Armstrong wrote:
> >>
> >>> Thanks for the comments, John.
> >>> I understand that you need to force yourself
> >>> to be out of the loop a while. This stuff is
> >>> seductive. There's nothing I'd rather be working
> >>> on, so I spent yesterday putting the article
> >>> together instead of getting my work done! (I
> >>> can only afford so much of that. :_)
> >>>
> >>> A few short responses:
> >>> * Question-Asking Process
> >>> * Typo
> >>> * Refinements
> >>> * Evaluation Strategy
> >>> * Node Types
> >>> * Extensions
> >>>
> >>> Question-Asking Process
> >>> -----------------------
> >>> You are right about needing a process that helps
> >>> you to "ask the right question". That's the kind
> >>> of problem that facilitated IBIS excels at.
> >>>
> >>> The trick is carry on those discussions online,
> >>> reach an agreement, and then *bury* the dialog, with
> >>> a link to it so the reasons can be examined when
> >>> desired.
> >>>
> >>> That's one aspect of the problem that is glossed
> >>> over in the current version of the tutorial.
> >>>
> >>> Typo
> >>> ----
> >>> Thanks for the catch:
> >>> >
> >>> > because the system doesn't __allow_ "illegal"
> >>> > states , even temporarily.
> >>> >
> >>>
> >>> Refinements
> >>> -----------
> >>> Thanks for the other ideas, as well. Would that we
> >>> had the system in operation, so we could capture
> >>> them in context as alternatives the ideas I've proposed!
> >>>
> >>> The most important thing for the design, though, is
> >>> that you've suggested some refinements and alternatives
> >>> that I would have a hard time capturing in the system,
> >>> as currently spec'd.
> >>>
> >>> It's part of the "reaching agreement" issue,
> >>> because your suggestions bring into question features
> >>> of the proposal. More accurately, they bring to
> >>> light questions that should have been asked in the
> >>> original version.
> >>>
> >>> It's the moral of the IBIS story: Any "answer" (statement)
> >>> is in reality an "alternative"--one of potentially many
> >>> possible answers to a question that was never asked.
> >>> IBIS makes sure that the question gets asked, as you
> >>> have done here.
> >>>
> >>> I've got to think about two things:
> >>>
> >>> a) How to integrate your suggestions into the
> >>> proposal, and
> >>>
> >>> b) How to modify the design so they have a
> >>> "natural home".
> >>>
> >>> Evaluation Strategy
> >>> -------------------
> >>> My initial reaction is that the kind of evaluation
> >>> strategy you suggest is something that should
> >>> operate outside the system--which would allow
> >>> other strategies to be plugged in and used.
> >>>
> >>> That's an off-the-cuff reaction, though. We
> >>> definitely need more discussion of the pros and
> >>> cons.
> >>>
> >>> Node Types
> >>> ----------
> >>> A node should definitely be limited to a single
> >>> idea. It was the observation that a paragraph is
> >>> supposed to represent a single idea that led to
> >>> the concept of "NodeIDs", where each "node" is a
> >>> heading or paragraph in a purplized document.
> >>>
> >>> I like your outline of node types and some of the
> >>> additions you've made. They bring up the idea of
> >>> extensions (next). It's something I was thinking
> >>> about when writing the spec, but neglected to
> >>> mention.
> >>>
> >>> Extensions
> >>> ----------
> >>> The DITA spec has done a nice job of defining an
> >>> extensible system. You can add tags, but only by
> >>> extending existing tags. So a tool that's built
> >>> to operate on the basic tags will also do something
> >>> reasonable with the extended versions--until and
> >>> unless you custom the tool to handle special tags
> >>> differently.
> >>>
> >>> That's a hell of an achievement, in my mind. They
> >>> use XML tags, but the tags represent objects, and
> >>> there is an inheritance hierarchy at work when the
> >>> tags are processed. I don't know exactly how they
> >>> achieved that goal, but it's a model for the way
> >>> the system needs to be designed.
> >>>
> >>> Thinking in terms of a the "challenge" type that
> >>> I plan to add tonight:
> >>>
> >>> * One /challenge/ for the system is the ability
> >>> to define a usable /core system/ that can be
> >>> extended for particular applications.
> >>>
> >>> --/Proof/ that it can be done is exhibited
> >>> by DITA--an information-typing architecture.
> >>>
> >>> John Sechrest wrote:
> >>>
> >>>>
> >>>> Eric Armstrong <Eric.Armstrong@Sun.COM> writes:
> >>>>
> >>>> A very nice article. Thank you. It has helped me a lot.
> >>>> Here are some small comments.
> >>>> % REQ: Maintain a stable temperature that supports
> >>>> % life on earth.
> >>>>
> >>>>
> >>>> The process of choosing the question is vitally important.
> >>>> Sometimes questions are generated that have the prefered
> >>>> answer already embedded in them.
> >>>>
> >>>> The difficulty with this "right question" discussion
> >>>> is the same problem with many philosophical discussions.
> >>>> You end up meta discussing the question, and defining terms
> >>>> and never really ever getting to answering the question.
> >>>>
> >>>> But suppose that instead of the REQ above, we ask the question:
> >>>>
> >>>> REQ: How should Humans life on the earth?
> >>>>
> >>>> This becomes a deeply religious discussion quickly. And yet.
> >>>> The first question is directly related to this one. So at
> >>>> some level you have to ask:
> >>>>
> >>>> What is the process for asking the right
> >>>> question? % l) A drawback statement is /invalid/ if
> >>>> it is not
> >>>> % yet linked to a requirement--but it can still
> >>>> % be present in the system.
> >>>>
> >>>> % It seems small but this is another big deal. People
> >>>> % generally dislike structured authoring systems for
> >>>> % two reasons: (a) they're forced to choose a type
> >>>> % when they don't yet know how to categorize what they
> >>>> % want to say and (b) they're forced to do things in an
> >>>> % uncomfortable sequence because the system doesn't
> >>>> % "illegal" states (like a drawback without a requirement
> >>>> % to link to), even temporarily.
> >>>>
> >>>> this last sentence does not have a verb.... What is the verb?
> >>>>
> >>>> -> because the system doesn't _____ "illegal" states , even
> >>>> temporarily.
> >>>>
> >>>>
> >>>>
> >>>> % At this point, the mechanism for choosing among viable
> >>>> % alternatives is undecided. It could (and probably
> >>>> % should) operate completely outside of the design system.
> >>>> % Choices could be made by voting, by personal whim, or
> >>>> % by any other mechanism.
> >>>> I had an idea here. I have an alternative evaluation methodology
> >>>> which involves weighting and evaluating each of the nodes.
> >>>> If you do a weighted sum of all the nodes, then you basically
> >>>> are doing a decision tree evaluation.
> >>>>
> >>>> So allow each of the participants to a) Define the possible states
> >>>> of a node (1-5)
> >>>> - 1 Bad (what does it look like to do bad)
> >>>> - 2 poor
> >>>> - 3 OK
> >>>> - 4 good
> >>>> - 5 Great (what does it look like to do great)
> >>>>
> >>>> b) choose on a per person basis what state they thing this
> >>>> node is at
> >>>>
> >>>> c) Define the wieght about how important this node is to what they
> >>>> consider important.
> >>>> Then you can do (for each node ( node-list) {sum(state($node) *
> >>>> weight($node))})
> >>>> which then gives you an ordered list of proposals.
> >>>>
> >>>> % I'm not sure it matters. As
> >>>> % long as we're choosing from a collection of viable
> >>>> % alternatives, things will be heck of lot better than
> >>>> % they might otherwise have been.
> >>>>
> >>>> It does matter. It matters a lot. Because the minor drawbacks for some
> >>>> will be major drawbacks for others. And the choice need to not be
> >>>> made on whose baby is getting gored.
> >>>>
> >>>>
> >>>> ... % Maybe the only really important task left at this stage
> >>>> % of the process is to come up with a catchy name. We
> >>>> % could simply add a D: DIBS? IBIDS? BIDS? SPID?
> >>>> % Or maybe it could be named after a noted problem solver
> >>>> % or peacemaker. (Buckminster? Bucky? Wright Stuff?)
> >>>>
> >>>> % Any other ideas?
> >>>>
> >>>> Thank you. That was very helpful.
> >>>>
> >>>> I think that there are several places where things are needed.
> >>>> I am still tumbling down the tuple path that jack pushed me down
> >>>> some time ago. This is a representation issue, but I can see how
> >>>> to use it to drive a system like this.
> >>>>
> >>>> The nodes of discussion need to have limited size. As a way to keep
> >>>> the focus on one issue. The problem with many of the "discussion"
> >>>> processes is that they let each node support many different
> >>>> types of objects and to refer to many different issues/ideas/drawbacks
> >>>> all at once.
> >>>>
> >>>> Having "articles" written, which put forth material, should not be
> >>>> the core of the IBIS decision process. But should be base material
> >>>> that is referenced (linked to), but should not be the core of the
> >>>> IBIS nodes.
> >>>> Each node should have just one thing. An idea. which it then
> >>>> references other stuff from. If this is done tightly enough,
> >>>> then the node can have other attributes, like weight and score etc.
> >>>> There are many user interface issues around what you are talking
> >>>> about.
> >>>> And that would be a good thing to deal with as well. But I will put
> >>>> off that set of commentary except to say, that people should
> >>>> be able to indicate how they feel about the discussion. And that
> >>>> you should
> >>>> be able to put timelines into the system.
> >>>>
> >>>> You mentioned that you conflated time line and desirability. This is
> >>>> a problem. Urgency versus importance is a key problem that most people
> >>>> get caught on. You need to be able to represent both independently.
> >>>> I think this is a great outline. I think the next step is to find
> >>>> all the
> >>>> node types and all the things they depend on:
> >>>>
> >>>>
> >>>>
> >>>> Q: Question
> >>>> A: Alternative / Answer
> >>>> P: Pro
> >>>> C: Con
> >>>>
> >>>> REQ: Requirement
> >>>> IMP: Importance Level 1: Immediate Need
> >>>> -> Major Requirement Level 2: Important , but not so
> >>>> -> Minor Requirement
> >>>> Level 3: Nice, but not vital
> >>>> Level 4: Low level of importance
> >>>> Level 5: Not important at all
> >>>> URG: Urgency QUAL: Quality
> >>>> Weight:
> >>>> ISS: Issue
> >>>> PROP: Proposal
> >>>> State (complete, incomplete,sound,viable)
> >>>> (must have link to Requirements)
> >>>> (must have links to advantages)
> >>>> (must have links to drawbacks)
> >>>> A proposal is /incomplete/ if it has:
> >>>> * invalid drawbacks
> >>>> * invalid advantages
> >>>> * major unaddressed requirements
> >>>>
> >>>> (addresses, violates,fails to address ) a requirement.
> >>>>
> >>>>
> >>>> COMP: Component
> >>>> VERS: Component version
> >>>>
> >>>> DRAW: Drawback (must have link to requirement)
> >>>> State: (Valid, invalid)
> >>>> A drawback statement is /invalid/ if it is not
> >>>> yet linked to a requirement--but it can still
> >>>> be present in the system.
> >>>>
> >>>>
> >>>> ADV: Advantage (must have link to requirement)
> >>>>
> >>>> REASON: reasons/evidence State: (asserted,
> >>>> withdrawn, retracted)
> >>>> OBJECTION: Objection
> >>>> State: (asserted, withdrawn, retracted)
> >>>>
> >>>>
> >>>>
> >>>> Clarification
> >>>> Correction
> >>>> Restatement
> >>>> Question
> >>>> (The details still need to be worked out.)
> >>>>
> >>>>
> >>>>
> >>>> Tool features:
> >>>> * *Tagged* so that a proposal is distinguished from
> >>>> an objection, and so that a schema can enforce
> >>>> the structure.
> >>>>
> >>>> * *Threaded* so that people can respond within the
> >>>> context of a proposal, as when quoting an email
> >>>> --but without having to quote and re-re-quote
> >>>> material so that it winds up duplicated in every post
> >>>> in the thread. (Part of the reason for implementing
> >>>> purple numbers in the Yak email archive was to permit
> >>>> operations of that kind in the future, and to at least
> >>>> allow for granular linking in the meantime.)
> >>>>
> >>>> * *Attributed* so that the author of any particular
> >>>> statement can be identified. (Important, since only
> >>>> the author of a statement and the all-powerful
> >>>> /editor/ (sys op) can retract a statement.)
> >>>>
> >>>>
> >>>> * *Indenting*. The original text will have indentation.
> >>>> Responses from others need to be indented, as well.
> >>>> Some way to distinguish the two kinds of indentation
> >>>> is needed so that, when displayed or printed, the
> >>>> discussion reads like a well-structured dialogue,
> >>>> rather than a linear dialogue (as at Slashdot,
> >>>> for example).
> >>>>
> >>>> * *Highlighting*. Like an RSS aggregator, the tool
> >>>> used to watch and participate in the discussion
> >>>> must make it possible to highlight things you haven't
> >>>> yet read.
> >>>>
> >>>> * *Fast Access* It should also be possible to quickly
> >>>> jump to the next unread passage. It should also be
> >>>> possible to flag a passage, see an index of flags,
> >>>> jump to a passage from the index, and jump from flag
> >>>> to flag.
> >>>>
> >>>> * *Filtering*. Display a proposal without drawbacks,
> >>>> with only drawbacks, with or without objections, etc.
> >>>>
> >>>> * *Collecting and Partitioning*. It should be possible
> >>>> to work on multiple projects in the same workspace,
> >>>> putting them in folders and picking up where you left
> >>>> off when you revisit them. So you may collaborate on
> >>>> project A with X, Y, and Z but collaborate on
> >>>> project B with M, N, and O. You'll only work on one
> >>>> project at any one time, but you should be able to
> >>>> see all of your project folders in a single tree,
> >>>> switch between them rapidly, copy files between them,
> >>>> and possibly share authoring templates and other
> >>>> "personal" (non-collaborative) files between them.
> >>>>
> >>>>
> >>>> ----
> >>>>
> >>>> Any other ideas?
> >>>>
> >>>>
> >>>> Ok. I have to work on a proposal due tuesday, so I will have to leave
> >>>> this discussion. But In a week, I would be glad to take the next
> >>>> step.
> >>>>
> >>>>
> >>>>
> >>>> -----
> >>>> John Sechrest . Helping people use
> >>>> . computers and the Internet
> >>>> . more effectively
> >>>> .
> >>>> . Internet: sechrest@peak.org
> >>>> .
> >>>> .
> >>>> http://www.peak.org/~sechrest
> >>>>
> >>>
> >>
> >
> >
>
> --
> This message is archived at:
>
>
>http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=yak&i=43C23907.2020206@concept67.net
>
> (02)
--
This message is archived at: (03)
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=yak&iQ79aafa0601090616n3e5d87acs580b352290b76d13@mail.gmail.com (04)
|