<div dir="ltr">Thanks for your input, Stephan,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 12, 2018 at 2:31 PM, Stephan Oepen <span dir="ltr">&lt;<a href="mailto:oe@ifi.uio.no" target="_blank">oe@ifi.uio.no</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">dear all,<br>
<br>
i dimply recall there have been multiple previous discussions of<br>
documentation strings, but so far i could only turn up one such thread<br>
(which appears somewhat inconclusive, but provides some useful<br>
reminders also related to other questions originally raised by mike);<br>
<br>
<a href="http://lists.delph-in.net/archives/developers/2007/000868.html" rel="noreferrer" target="_blank">http://lists.delph-in.net/arch<wbr>ives/developers/2007/000868.ht<wbr>ml</a><br>
<br></blockquote><div><div><br></div><div>Thanks for linking this. This is the thread I referenced in my first 
message, but I should have linked it then and saved you the trouble 
of searching. I&#39;ve added it to my list of discussions at the bottom of 
the TdlRfc wiki.</div></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
personally, i would think that there is complete freedom in how to<br>
order the various types of statements in TDL conjunctions, including<br>
repetition, e.g.<br>
<br>
foo := [ FOO + ] &amp; bar &amp; [ BAR - ] &amp; baz.<br></blockquote><div><br></div><div>This is a different takeaway than I had from Ann&#39;s 2004 email on that thread, where she argued that supertypes have special status on types, unlike entries/instances, where they are not in fact supertypes (as Guy brought up in an earlier post). From p106 of Copestake 2002, discussing an example `a := b &amp; c.`:</div><div><br></div><div>&gt; Elsewhere in the TDL description language, `&amp;` can be taken as equivalent to unification, but here it is understood as defining part of the type hierarchy. It follows from this type definition that the constraint on `a` will be the unification of the constraints on type `b` and type `c`, but [...] we need to know what the type hierarchy is before we can talk about unification, so the statement about the hierarchy is logically prior.</div><div><br></div><div>Thus, allowing supertypes and constraints to mix freely obfuscates the distinct role in hierarchy creation that the list of supertypes has. That is, it&#39;s a human-comprehensibility issue, not a technical one. But maybe her perspective has shifted in the last 14 years?<br></div><div><br></div><div>In any case, I think the current implementations allow for your definition of `foo`, and it&#39;s only convention that the supertypes appear first.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ann in that historic thread points out that it can be sensible to have<br>
instance definitions without explicit mention of the type; and i<br>
imagine the same could in principle also apply to type definitions<br>
(given strict appropriateness and type inference).<br></blockquote><div><br></div><div>Hmm.. I&#39;ll pretend I didn&#39;t read this. :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
so i am tempted to assume there is nothing special about the position<br>
of ‘parent’ types.<br>
<br>
i can see how the triple-double-quote syntax (&quot;&quot;&quot; ... &quot;&quot;&quot;) would be<br>
position-independent, but it would seem to make lexical analysis more<br>
complex: currently, i believe, all TDL operators are single<br>
characters.<br></blockquote><div><br></div><div>Let&#39;s not forget :=, :+, &lt;!, !&gt;, ..., #|, |#, letter-set, wild-card, prefix, and suffix (ok, they aren&#39;t all &quot;operators&quot;, but they are all TDL literals that need to be parsed).</div><div><br></div><div>Also it now occurs to me that the triple-double-quote option is essentially Ann&#39;s (vi): &quot;invent yet another reserved character&quot;, which, to her, was an acceptable option.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
i am wondering: could a simple string ever be part of the top-level<br>
conjunction in a type or instance definition?  if so, how?  if not,<br>
what would speak against treating all top-level TDL strings as<br>
documentation associated with the type or instance definition,<br>
independent of their position relative to other elements of a<br>
top-level conjunction, e.g. any of the following variants<br>
<br>
foo :=<br>
&quot;a silly example&quot; &amp;<br>
bar &amp; [ FOO + ].<br>
<br>
foo := bar &amp;<br>
&quot;a silly example&quot; &amp;<br>
[ FOO + ].<br>
<br>
foo := bar &amp;<br>
[ FOO + ] &amp;<br>
&quot;a silly example&quot;.<br>
<br>
for full generality, one could then either allow a list of<br>
documentation strings associated with each type or instance definition<br>
(and have the addendum operator add to the tail of the list), or<br>
simply concatenate all such strings into one (presumably adding at<br>
least one newline between each pair of strings).<br></blockquote><div><br></div><div>Isn&#39;t this Ann&#39;s option (iii), which was rejected straight away? String literals, I think, are implicitly subtypes of *string-type*, and even if they never unify with, say, *avm*, I don&#39;t think that means it&#39;s uncharted territory yet to be defined, but that they should, simply, always fail to unify. Otherwise people may be confused why this won&#39;t work:</div><div><br></div><div>foo := bar &amp;</div><div>[ FOO &quot;inner-docstring&quot; &amp; + ].</div><div><br></div><div>(note: I&#39;m not proposing we start allowing docstrings inside structures)<br></div><div><br></div><div>However, I can imagine defining &quot;&quot;&quot;...&quot;&quot;&quot; as a syntax for something like [ DOC ... ] ( just as &lt; stands for [ FIRST ..., REST *list* ]) which then can unify with the &amp; operator, if we don&#39;t mind documentation being included in the feature structures (will this take a toll on memory usage during parsing?).<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
—mike, many thanks for your work towards an up-to-date and<br>
consolidated definition of TDL syntax!<br>
<br>
oe<br>
<div class="m_2601664728461544901m_-7431151817236439039HOEnZb"><div class="m_2601664728461544901m_-7431151817236439039h5"><br>
<br>
On Thu, Jul 12, 2018 at 7:15 AM, Michael Wayne Goodman &lt;<a href="mailto:goodmami@uw.edu" target="_blank">goodmami@uw.edu</a>&gt; wrote:<br>
&gt; On Wed, Jul 11, 2018 at 7:59 PM, Francis Bond &lt;<a href="mailto:bond@ieee.org" target="_blank">bond@ieee.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On my phone so forgive the brevity, but in Paris we agreed that the<br>
&gt;&gt; docstring will start and end with three &quot;.   I think this is what pet now<br>
&gt;&gt; supports, Dan has a patch for the lkb, and I suspect I was meant to ask<br>
&gt;&gt; Woodley to add out to ACE.<br>
&gt;<br>
&gt;<br>
&gt; Sorry I missed out on all the fun this year :(<br>
&gt;<br>
&gt; I see what you describe mentioned in the LTDB presentation:<br>
&gt; <a href="http://users.sussex.ac.uk/~johnca/summit-2018/ltdb-update.pdf" rel="noreferrer" target="_blank">http://users.sussex.ac.uk/~joh<wbr>nca/summit-2018/ltdb-update.pd<wbr>f</a><br>
&gt;<br>
&gt; It seems the changes to PET are not yet merged in. Also I think Glenn would<br>
&gt; also like to know about the agreement.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; Comments anywhere would be great.<br>
&gt;&gt;<br>
&gt;&gt; Thanks for pushing this forward Michael.<br>
&gt;&gt;<br>
&gt;&gt; On Thu, 12 Jul 2018, 12:34 Michael Wayne Goodman, &lt;<a href="mailto:goodmami@uw.edu" target="_blank">goodmami@uw.edu</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Wed, Jul 11, 2018, 19:24 Woodley Packard &lt;<a href="mailto:sweaglesw@sweaglesw.org" target="_blank">sweaglesw@sweaglesw.org</a>&gt;<br>
&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; 2 cents worth...<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; 1. I think the logical behavior for an addendum with a doc string is<br>
&gt;&gt;&gt;&gt; concatenation, not replacement.  The doc string on the addendum should<br>
&gt;&gt;&gt;&gt; document what the addendum adds to the type, not the whole type.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Hmm, good point. I guess the addendum can only add constraints, so the<br>
&gt;&gt;&gt; old docstring wouldn&#39;t necessarily become invalid. I was comparing to method<br>
&gt;&gt;&gt; overrides in Python classes, but that&#39;s not a useful comparison.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; 2. ACE (I believe) allows comments just about anywhere in TDL.  I find<br>
&gt;&gt;&gt;&gt; this very useful when editing TDL, e.g. annotating changes on a fine grained<br>
&gt;&gt;&gt;&gt; level or disabling certain constraints temporarily without deleting them.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Yes, it&#39;s definitely more useful to allow comments almost anywhere, and<br>
&gt;&gt;&gt; not really hard to parse, either.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Regards,<br>
&gt;&gt;&gt;&gt; Woodley<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Jul 11, 2018, at 5:00 PM, Michael Wayne Goodman &lt;<a href="mailto:goodmami@uw.edu" target="_blank">goodmami@uw.edu</a>&gt;<br>
&gt;&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Thank you, Bernd, for the feedback. But I&#39;m not having success parsing<br>
&gt;&gt;&gt;&gt; types with docstrings using PET. E.g., I changed sign-min in the ERG like<br>
&gt;&gt;&gt;&gt; this:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;     sign_min := *avm* &amp;<br>
&gt;&gt;&gt;&gt;       &quot;doc&quot;<br>
&gt;&gt;&gt;&gt;       [ SYNSEM synsem_min,<br>
&gt;&gt;&gt;&gt;         KEY-ARG bool ].<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; But flop doesn&#39;t like it:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;     goodmami@tpy:~/grammars/erg$ flop english.tdl<br>
&gt;&gt;&gt;&gt;     reading `Version.lsp&#39;...<br>
&gt;&gt;&gt;&gt;     converting `english.tdl&#39; (ERG (1214)) into `english.grm&#39; ...<br>
&gt;&gt;&gt;&gt;     loading `english.tdl&#39;... including `fundamentals.tdl&#39;...<br>
&gt;&gt;&gt;&gt; fundamentals.tdl:21:3: error: (syntax) - got `                   [&#39;,<br>
&gt;&gt;&gt;&gt; expecting `.&#39; at end of type definition<br>
&gt;&gt;&gt;&gt;     [...]<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I get similar errors no matter where I put it (before :=, directly after<br>
&gt;&gt;&gt;&gt; :=, after ]). It&#39;s syntactically valid if I have ... *avm* &amp; &quot;doc&quot; &amp; ...,<br>
&gt;&gt;&gt;&gt; but then it has trouble unifying (as expected).<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; It does, however, seem to be happy having a comment there (both ; and #|<br>
&gt;&gt;&gt;&gt; styles) instead of a doc string.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I&#39;m using flop version 0.99.14svn_cm from the LOGON distribution.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; On Wed, Jul 11, 2018 at 7:00 AM, Bernd Kiefer &lt;<a href="mailto:Bernd.Kiefer@dfki.de" target="_blank">Bernd.Kiefer@dfki.de</a>&gt;<br>
&gt;&gt;&gt;&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Concerning question 3, at least in TDL and PET there was no such<br>
&gt;&gt;&gt;&gt;&gt; restriction,<br>
&gt;&gt;&gt;&gt;&gt; but that could make the definition of docstrings easier.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Best,<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; Bernd<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; On 11.07.2018 03:01, Michael Wayne Goodman wrote:<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; I attempted to define a BNF-like description of TDL syntax on the wiki:<br>
&gt;&gt;&gt;&gt;&gt; <a href="http://moin.delph-in.net/TdlRfc" rel="noreferrer" target="_blank">http://moin.delph-in.net/TdlRf<wbr>c</a><br>
&gt;&gt;&gt;&gt;&gt; I tried to follow the partial BNF in the LKB source and often referred<br>
&gt;&gt;&gt;&gt;&gt; to the lisp code itself in order to fill out the rest of the description.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; My 3 questions above are concisely repeated at the bottom of the wiki<br>
&gt;&gt;&gt;&gt;&gt; along with some others.<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; I welcome corrections and discussion (here or on the wiki) from any TDL<br>
&gt;&gt;&gt;&gt;&gt; nerds or authorities (especially if you&#39;ve written a TDL parser).<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; On Mon, Jul 9, 2018 at 12:49 PM, Michael Wayne Goodman<br>
&gt;&gt;&gt;&gt;&gt; &lt;<a href="mailto:goodmami@uw.edu" target="_blank">goodmami@uw.edu</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Hi developers,<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; I&#39;m taking a closer look at the syntax of TDL files and the situation<br>
&gt;&gt;&gt;&gt;&gt;&gt; is a bit of a mess. Can anyone help me clarify some things? (I&#39;ll restrict<br>
&gt;&gt;&gt;&gt;&gt;&gt; myself to 3 questions for now)<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; The Copestake 2002 reference (Implementing TFS Grammars) has a BNF for<br>
&gt;&gt;&gt;&gt;&gt;&gt; TDL, but it&#39;s a bit out of date and, according to comments in the LKB source<br>
&gt;&gt;&gt;&gt;&gt;&gt; code, incorrect in parts. The LKB source comments are scattered, incomplete,<br>
&gt;&gt;&gt;&gt;&gt;&gt; inconsistent, and also a bit outdated. There is not much on the wiki. There<br>
&gt;&gt;&gt;&gt;&gt;&gt; is some discussion in the mailing list archives (much from before my time in<br>
&gt;&gt;&gt;&gt;&gt;&gt; DELPH-IN), but it&#39;s not clear how current those descriptions are.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Q1: Are supertypes special in a definition?<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; The BNF (in the LKB source) says this:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;     Type-def -&gt; Type { Avm-def | Subtype-def} . |<br>
&gt;&gt;&gt;&gt;&gt;&gt;                          Type { Avm-def | Subtype-def}.<br>
&gt;&gt;&gt;&gt;&gt;&gt;     Avm-def -&gt; := Conjunction | Comment Conjunction<br>
&gt;&gt;&gt;&gt;&gt;&gt;     Conjunction -&gt; Term { &amp; Term } *<br>
&gt;&gt;&gt;&gt;&gt;&gt;     Term -&gt; Type | Feature-term | Diff-list | List | Coreference<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; That makes it sound like I could do this:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;     mytype := [ FEAT val ] &amp; supertype.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; or even:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;     mytype := &lt;! diff list.. !&gt; &amp; #coref &amp; supertype.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; But elsewhere it seems like a list of parents is special and appears<br>
&gt;&gt;&gt;&gt;&gt;&gt; before the rest of the conjunction. E.g., at read-tdl-avm-def of<br>
&gt;&gt;&gt;&gt;&gt;&gt; lingo/lkb/src/io-tdl/tdltypein<wbr>put.lsp I see this alternate definition of<br>
&gt;&gt;&gt;&gt;&gt;&gt; Avm-def:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;   ;;; Avm-def -&gt; := Parents Conjunction | Parents Comment Conjunction<br>
&gt;&gt;&gt;&gt;&gt;&gt; |<br>
&gt;&gt;&gt;&gt;&gt;&gt;   ;;;               Parents | Parents Comment<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; It seems that both ACE and PET are fine with putting supertypes after<br>
&gt;&gt;&gt;&gt;&gt;&gt; the feature list (and some other variations). I&#39;m fine with this, but I<br>
&gt;&gt;&gt;&gt;&gt;&gt; wonder what it means for docstrings (see Q3 below), which (I think) are<br>
&gt;&gt;&gt;&gt;&gt;&gt; supposed to appear after the list of parents and before the feature list.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Q2: Subtype-def is now just a variant of Avm-def, yes?<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; The BNF still describes subtyping (with the :&lt; operator) as only<br>
&gt;&gt;&gt;&gt;&gt;&gt; taking a single parent:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;     Subtype-def -&gt;  :&lt; type<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; But I believe the consensus is that this is unnecessary (it&#39;s<br>
&gt;&gt;&gt;&gt;&gt;&gt; equivalent to using := with only a supertype), so :&lt; is treated as<br>
&gt;&gt;&gt;&gt;&gt;&gt; equivalent to := (to avoid breaking backward compatibility). Is this<br>
&gt;&gt;&gt;&gt;&gt;&gt; interpretation used by all processors?<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Q3: What&#39;s the final word with type comments / docstrings?<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; I find evidence of 3 proposed variants: (1) a block of &quot;;&quot; comments<br>
&gt;&gt;&gt;&gt;&gt;&gt; before a typename (LTDB-style); (2) a block of &quot;;&quot; comments within a type<br>
&gt;&gt;&gt;&gt;&gt;&gt; description; and (3) a &quot;doc string&quot; within a type description. Furthermore,<br>
&gt;&gt;&gt;&gt;&gt;&gt; there is a question as to whether comments or strings within a type go after<br>
&gt;&gt;&gt;&gt;&gt;&gt; the &quot;:=&quot; or after the list of supertypes. I think #| ... |# comments were<br>
&gt;&gt;&gt;&gt;&gt;&gt; not considered for this purpose.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; My guess is this:<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; * LTDB-style comments (before the type identifier) are processed<br>
&gt;&gt;&gt;&gt;&gt;&gt; separately from TDL-parsing<br>
&gt;&gt;&gt;&gt;&gt;&gt; * type-internal comments can go anywhere but are discarded<br>
&gt;&gt;&gt;&gt;&gt;&gt; * type-internal doc strings must appear after the list of supertypes<br>
&gt;&gt;&gt;&gt;&gt;&gt; and are later available for inspection (they are included as a<br>
&gt;&gt;&gt;&gt;&gt;&gt; non-functional part of a type)<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; ACE seems happy with my assumptions, although PET doesn&#39;t seem to like<br>
&gt;&gt;&gt;&gt;&gt;&gt; doc strings at all.<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; Thanks!<br>
&gt;&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;&gt; --<br>
&gt;&gt;&gt;&gt;&gt;&gt; Michael Wayne Goodman<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; --<br>
&gt;&gt;&gt;&gt;&gt; Michael Wayne Goodman<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;&gt; --<br>
&gt;&gt;&gt;&gt;&gt; ------------------------------<wbr>------------------------------<wbr>----------<br>
&gt;&gt;&gt;&gt;&gt; Bernd Kiefer     DFKI GmbH,  Stuhlsatzenhausweg,  D-66123 Saarbruecken<br>
&gt;&gt;&gt;&gt;&gt; <a href="mailto:kiefer@dfki.de" target="_blank">kiefer@dfki.de</a>   +49-681/85775-5301 (phone)   +49-681/85775-5338 (fax)<br>
&gt;&gt;&gt;&gt;&gt; ------------------------------<wbr>------------------------------<wbr>----------<br>
&gt;&gt;&gt;&gt;&gt; Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH<br>
&gt;&gt;&gt;&gt;&gt; Trippstadter Strasse 122, D-67663 Kaiserslautern, Germany<br>
&gt;&gt;&gt;&gt;&gt; Geschaeftsfuehrung: Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vor-<br>
&gt;&gt;&gt;&gt;&gt;                     sitzender), Dr. Walter Olthoff<br>
&gt;&gt;&gt;&gt;&gt; Vorsitzender des Aufsichtsrats: Prof. Dr. h.c. Hans A. Aukes<br>
&gt;&gt;&gt;&gt;&gt; Amtsgericht Kaiserslautern, HRB 2313<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; --<br>
&gt;&gt;&gt;&gt; Michael Wayne Goodman<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; --<br>
&gt; Michael Wayne Goodman<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="m_2601664728461544901m_-7431151817236439039gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Michael Wayne Goodman</div></div></div></div></div></div>
</div></div></div>