[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xdi] Change Request toward B4 (was Re: [xdi] XDI Grapher)
Hello Drummond, let me answer in a reverse order: point 3): 'creates' is probably not the right word, but 'describes' is. According to http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel The $has metagraph predicate describes the relationship between a node and an outgoing arc in the XDI RDF graph. The subject of a $has statement is the XRI of the node from which the arc originates, and the object is the XRI of the arc. therefore, =Markus+parking/$has/+slot describes an outgoing arc +slot from =Markus+parking. Furthermore, the subject =Markus+parking, is a reification of =Markus/+parking, i.e. there is a node =Markus with an outgoing arc +parking. The model is then not correct. The correct model is described ONLY by =Markus/$has/+parking+slot. point 2): sorry but this argumentation cannot be used, as you're starting supposing the correcness of what you want the associativity of $has to work. > In my message I explain how all the following XDI statements therefore you get that conclusion. point 1): You seems to suggest that parenthesis are used to create reification. The only example of reification we discussed right now is +a+b, which is considered equivalent to (+a/+b). The semantics of parenthesis is used here as a reification to avoid confusion with +a/+b. But, when dealing with only one subject, like +a, what's the meaning of reification around the single subject? I Anyway, talk with you in few minutes... Kind Regards, Giovanni Def. Quota "Drummond Reed" <drummond.reed@xdi.org>: > Giovanni, > > > > Several points: > > > > 1) You say, “[the fact that] +b+c and (+b+c) are NOT equivalent, in my > opinion this is not a problem for XDI, as long as they could be resolved to > the same CONCEPT”. > > > > They do not resolve to the same concept. There is no way semantically that > we can assert that any XRI and the reification of that same XRI resolve to > the same concept. To use an analogy, this would be like saying that a number > and the absolute value of that number are always the same number. For > example, +3 and |+3| represent the same number, but -3 and |-3| DO NOT > represent the same number. (Again, this is just an analogy, I’m not saying > reification and absolute numbers are the same thing.) > > > > My point is, from a pure XDI standpoint, +a and (+a) are two different XRIs > representing two different nodes in the XDI graph. The only statement I > believe we can say is that (+a) identifies the XDI context containing the > XDI subject +a. But that is NOT the same as saying (+a) and +a are either: > a) equivalent, or b) represent the same concept. > > > > 2) You say that full associativity, as opposed to left or right > associativity, conflicts with the $is$a semantics of the $has operator. I > believe the exact opposite is true, i.e., ONLY full associativity is > consistent with the $is$a semantics of the $has operator. > > > > Let’s first illustrate this with +a+b+c, and then with “Markus parking > slot”. > > > > In my message I explain how all the following XDI statements… > > > > (+a/+b)/$has/+c > > +a+b/$has/+c > ((+a/+b)/+c) > (+a+b/+c) > +a/$has/(+b/+c) > > +a/$has/+b+c > (+a/(+b/+c)) > (+a/+b+c) > > > > …are equivalent because they all reduce to the same XDI statement: > > > +a+b+c > > > > So, picking out two of the statements above, we have: > > > > +a+b/$has/+c > +a/$has/+b+c > > > > These infer two $is$a statements: > > > > +a+b+c/$is$a/+c > > +a+b+c/$is$a/+b+c > > These are both logically consistent. Let’s now apply them to “Markus parking > slot”: > > > > Markus parking slot is a slot. > > Markus parking slot is a parking slot. > > > > Both statements are true and logically consistent. > > > > 3) Thirdly – and this may be the ultimate source of the confusion – you say > that, for > > > > Markus parking slot > > “you are creating an outgoing arc from the node ‘Markus parking’, which is > ‘slot’.” > > > > In fact, $has statements, when translated to RDF statements, DO NOT CREATE > OUTGOING ARCS. They only create new XDI subject nodes. Only a $has$a > statement creates an outgoing arc. > > > > This also answers Bill’s question about why the parentheses (reification) > around the middle of the two transforms for a $has statement: > > > > +a/$has/+b <==> (+a/+b) <==> +a+b > > > > The parentheses create the reification of +a/+b into a new XDI subject – a > single node. So once again, when translated to an RDF graph, an XDI $has > statement does NOT produce an outgoing arc. It only produces a new XDI > subject. That’s why $has statements cannot have cardinality. > > > > The XDI statement that produces an outgoing arc in an RDF graph is a $has$a > statement. > > > > +a/$has$a/+b <==> +a/+b > > > > (Note there are no parentheses around +a/+b.) > > > We'll discuss all this further on today's call. > > > > =Drummond > > > On Thu, Jan 7, 2010 at 5:08 AM, Giovanni Bartolomeo < > giovanni.bartolomeo@uniroma2.it> wrote: > >> Hello Drummond, >> >> I think we are very close to the core of the matter. >> >> Actually there are examples where you can split terms on the left or right >> side and ones which do not allow this. >> House door keyhole and almost all the ones you quoted right now belong to >> the first case; whereas Markus parking slot and contract Markus' signature >> to the second one. >> >> The reason why $has cannot be associative in the meaning you pointed out, >> but only LEFT ASSOCIATIVE, resides in one important implication we have in >> the semantics of the $has operator: >> >> +a/$has/+b implies +a+b/$is$a/+b >> >> this creates a dissimetry between the right and the left operands, which >> reflects in the semantic (RDF) model underlying the whole XDI specs. In >> fact, if you take >> >> Markus parking slot >> >> you are assigning a property, (attribute, member,... whatever you want to >> call it), to Markus. The outgoing arc from markus is parking slot, which is >> an instance of slot. >> >> But if you split this differently >> >> Markus parking slot >> >> you are saying something different, twice: first you are creating an >> outgoing arc from the node Markus parking, which is slot. This is not >> correct as do not reflect what we wanted to say (not only Markus parking but >> every parking has slots). Second, Markus parking itself is an RDF expression >> which keep Markus as node and parking as an outgoing arc. Therefore you are >> asserting a second fact, that Markus has a property called PARKING, whereas >> the original statement said only that Markus has a PARKING SLOT! >> >> Syntactically, the only way I know to tell a parser that +parking+slot, a >> kind of +slot, is a property of =Markus is to forbid that +parking can be >> attached to =Markus, and force to attach it to +slot. In matemathics this >> happens using parenthesis, but, if my understanding is correct, also XRI >> parsers work the same way, i.e. resolving first what is inside the cross >> reference and then the rest. >> >> Finally coming to your point about syntax: even if, SYNTACTICALLY, "+b+c >> and (+b+c) are NOT equivalent", in my opinion this is not a problem for XDI, >> as long as they could be resolved to the same CONCEPT. Please note that also >> in mathematics we can use different syntaxes to resolve to the same result: >> +7 = (+7) = ((+7)) = (((+7))),... it is not the syntax, but the semantics >> which cares. >> >> Kind Regards, >> Giovanni >> >> Def. Quota "Drummond Reed" <drummond.reed@xdi.org>: >> >> Giovanni, >>> >>> >>> >>> Thank you for writing such a clear message about what you perceive the >>> problem is. This same issue became clear to me when working on the box >>> graphing (which I propose to rename to “cell graphing” because it’s a >>> better >>> metaphor for dealing with data relationships). >>> >>> >>> >>> Unfortunately I believe that defining $has relations to be strictly left >>> associative actually introduces a logical inconsistency for which I know >>> of >>> no solution, and which would be fatal to our goal of making sure XDI is >>> logically consistent. However, the alternative of defining $has relations >>> as >>> neither left nor right associative, but just associative (per the >>> definition >>> from Wikipedia below) avoids this logical inconsistency, thereby solving >>> this problem and keeping XDI semantics consistent. >>> >>> >>> >>> Let me first provide the definition of associativity from Wikipedia, then >>> explain my reasoning in more detail. >>> >>> >>> >>> ***** FROM http://en.wikipedia.org/wiki/Associative ******* >>> >>> Formally, a binary operation [image: *\!\!\!]on a >>> set<http://en.wikipedia.org/wiki/Set_%28mathematics%29> >>> *S* is called *associative* if it satisfies the *associative law*: >>> >>> >>> [image: (x * y) * z=x * (y * z)\qquad\mbox{for all }x,y,z\in S.] >>> >>> *Using * to denote a binary >>> operation<http://en.wikipedia.org/wiki/Binary_operation>performed on a >>> >>> set >>> * >>> >>> [image: (xy)z=x(yz) = xyz \qquad\mbox{for all }x,y,z\in S.] >>> >>> *An example of multiplicative associativity* >>> >>> The evaluation order does not affect the value of such expressions, and it >>> can be shown that the same holds for expressions containing *any* >>> number of [image: >>> *\!\!\!]operations. Thus, when [image: *\!\!\!]is associative, the >>> evaluation order can therefore be left unspecified without causing >>> ambiguity, by omitting the parentheses and writing simply: >>> >>> *xyz*, >>> >>> However, it is important to remember that changing the order of operations >>> does not involve or permit moving the operands around within the >>> expression; >>> the sequence of operands is always unchanged. >>> >>> A very different perspective is obtained by rephrasing associativity using >>> functional notation: *f*(*f*(*x*,*y*),*z*) = *f*(*x*,*f*(*y*,*z*)): when >>> expressed in this form, associativity becomes less obvious. >>> >>> Associativity can be generalized to n-ary >>> operations<http://en.wikipedia.org/wiki/Arity>. >>> >>> Ternary associativity is (abc)de = a(bcd)e = ab(cde), i.e. the string >>> abcde >>> with any three adjacent elements bracketed. N-ary associativity is a >>> string >>> of length n+(n-1) with any n adjacent elements >>> bracketed[1]<http://en.wikipedia.org/wiki/Associative#cite_note-0> >>> >>> . >>> >>> ******** END WIKIPEDIA EXCERPT ******** >>> >>> >>> >>> What I am proposing is that the definition of $has relations in the spec >>> (i.e., the definition currently at >>> http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel#A.24hasand.24is.24has >>> ) >>> should be clarified to be just associative as defined above, and NOT >>> either >>> left associative or right associative. The rest of this message explains >>> why. >>> >>> >>> >>> First, let me explain the logical inconsistency that either left or right >>> associativity introduces. I’ll start by saying that I believe the source >>> of >>> misunderstanding in this area is the XDI use of parentheses (XRI >>> cross-references). The problem is that in mathematics, parenthese are only >>> used to group mathematical operations. Other than precedence, *they have >>> no >>> other meaning*. >>> >>> >>> >>> In both XRI and XDI, however, parentheses are 100% significant. They are >>> *part >>> of the identifier*. Only in XDI do we define equivalence rules between XDI >>> addresses that specify that certain XDI addresses that include parentheses >>> are equivalent to others that do not. In fact these rules apply ONLY to >>> $has >>> statements, and they follow these very strict equivalence rules: >>> >>> >>> >>> +a/$has/+b <==> (+a/+b) <==> +a+b >>> >>> >>> >>> Again, it’s very important to clarify that the parentheses in the center >>> XDI >>> statement above are NOT OPTIONAL. They are required or else the >>> equivalence >>> is broken. In other words, +a/$has/+b is NOT equivalent to +a/+b and +a/+b >>> is NOT equivalent to +a+b. >>> >>> >>> >>> So, let’s now turn to your example: >>> >>> >>> >>> ******* EXCERPT FROM GIOVANNI’S MESSAGE ******** >>> >>> >>> >>> I think the only reason of considering +a/$has/+b+c and +a+b/$has/+c as >>> producing the same statement +a+b+c was that it was not very clear how the >>> $has operator work. But after our last phc we agreed that $has is a LEFT >>> associative operator. This is enough to tell a parser that when a >>> +a+b/$has/+c is encountered, the a+b+c statement is produced. Whereas when >>> it finds +a/$has/+b+c, then the +a(+b+c) statement must be produced. >>> >>> >>> >>> ******* END EXCERPT ****** >>> >>> >>> >>> Here’s why it is impossible for +a/$has/+b+c to produce (i.e., be >>> equivalent >>> to) +a(+b+c). Following our own rules for $has statements, +a(+b+c) >>> expands >>> (is equivalent to): >>> >>> >>> >>> +a/$has/(+b+c) <==> (+a/(+b+c)) <==> +a(+b+c) >>> >>> >>> >>> If that is true, and you are saying at the same time that… >>> >>> >>> >>> +a/$has/+b+c <==> (+a/(+b+c)) <==> +a(+b+c) >>> >>> >>> >>> …then it would follow that… >>> >>> >>> >>> +a/$has/+b+c <==> +a/$has/(+b+c) >>> >>> >>> >>> …which, as I explained above, is a complete contradiction, since +b+c and >>> (+b+c) are NOT equivalent. >>> >>> >>> >>> This is why example B4 in the box graphing examples that you refer to >>> asserts that all of the following XDI statements are equivalent: >>> >>> >>> >>> (+a/+b)/$has/+c >>> >>> +a+b/$has/+c >>> ((+a/+b)/+c) >>> (+a+b/+c) >>> +a/$has/(+b/+c) >>> >>> +a/$has/+b+c >>> (+a/(+b/+c)) >>> (+a/+b+c) >>> +a+b+c >>> >>> >>> >>> The reason they are all equivalent is that if you apply these two simple >>> transformation rules… >>> >>> >>> >>> 1) All XDI statements *[x1]/$has/[x2]* TRANSFORM TO *([x1]/[x2])* >>> >>> 2) All XDI statements (*[x1]/[x2])* TRANSFORM TO *[x1][x2]* >>> >>> >>> >>> …to all nine XDI statements above, then all nine reduce to: >>> >>> >>> >>> +a+b+c >>> >>> >>> >>> To me, this is logically consistent with full associativity. For example, >>> in >>> the following sequence of numbers related by addition…. >>> >>> >>> >>> 7 + 8 + 3 + 4 >>> >>> >>> >>> ….you get the same result no matter where you place parentheses, or how >>> many >>> parentheses you add. That’s because the addition operation is not left >>> associative, or right associative, but fully associative. >>> >>> >>> >>> >>> >>> I also believe it is graphically consistent. By this I mean that if you >>> picture each $has relation as creating a directed path… >>> >>> >>> >>> +a -----> +b -----> +c -----> +d >>> >>> >>> >>> …then, just like the addition operation above, any way you group the >>> segments of this path while maintaining the same overall order, once you >>> put >>> these groups back together, you end out with the same overall path. >>> >>> >>> >>> Now, with all that said, let me finally turn to your point about English >>> language analogies. You suggest that the statement “Markus parking slot” >>> only follows from asserting “Markus parking has a slot” and NOT from >>> “Markus >>> has a parking slot”. >>> >>> >>> >>> In English, I would assert that phrase resulting from a logical sequence >>> of >>> three or more nouns, where each noun describes the next, is full >>> associative, meaning that like the set of numbers being added above, it >>> can >>> be grouped in any set of sequences, each of which makes its own logical >>> unit, that when fully combined in the same sequence, creates the same >>> final >>> logical unit. >>> >>> >>> >>> So, to be clear, I am not asserting that the individual logical unit >>> groupings are identical, only the final result is identical. Here are >>> three >>> examples: >>> >>> >>> >>> Markus ball cover >>> >>> Markus ball cover >>> >>> Markus ball cover >>> >>> >>> >>> car engine fan blade >>> >>> car engine fan blade >>> >>> car engine fan blade >>> >>> car engine fan blade >>> >>> >>> >>> Asia continent >>> jetstream >>> direction indicator >>> >>> Asia continent jetstream direction >>> indicator >>> >>> Asia continent jetstream direction indicator >>> >>> Asia continent jetstream direction indicator >>> >>> Asia continent jetstream direction indicator >>> >>> >>> >>> I would assert that the relationship between two nouns in the English >>> language – without any special punctuation – is the same as the $has >>> relation in XDI. And that the addition of quotes grouping two or more of >>> the >>> above words is roughly the equivalent of what parentheses do in XDI. For >>> example… >>> >>> >>> >>> Asia “continent jetstream” direction indicator >>> >>> >>> >>> …can only be parsed into: >>> >>> >>> >>> Asia >>> “continent >>> jetstream” direction indicator >>> >>> Asia “continent jetstream” direction >>> indicator >>> >>> Asia “continent jetstream” direction indicator >>> >>> Asia “continent jetstream” direction indicator >>> >>> >>> >>> This illustrates that in English, as in XDI, the addition of quotes to the >>> sequence of words changes the semantics, i.e., the same sequence of >>> English >>> words with and without the quotes are NOT equivalent. >>> >>> >>> >>> I hope this helps. It is such an important point that we’ll make it the >>> first agenda item in tomorrow’s telecon (I’m sending the agenda next). >>> >>> >>> >>> =Drummond >>> >>> >>> >>> ******* BELOW IS GIOVANNI’S ORIGINAL MESSAGE ******** >>> >>> >>> >>> On Wed, Jan 6, 2010 at 12:50 AM, Giovanni Bartolomeo < >>> giovanni.bartolomeo@uniroma2.it> wrote: >>> >>> Dear Drummond, Markus, >>> >>> I want to come back on point B4. >>> >>> I think the answer is whether or not the XRI can be simplified by >>> contracting $has statements. >>> >>> In B4, all of the following statements simplify to the same maximally >>> contracted XRI: +a+b+c . >>> >>> (+a/+b)/$has/+c >>> ((+a/+b)/+c) >>> (+a+b/+c) >>> +a/$has/(+b/+c) >>> (+a/(+b/+c)) >>> (+a/+b+c) >>> +a+b+c >>> >>> >>> To me, this is a risk because it creates inconsistency in the semantic >>> model. >>> As you know, I've highlighted this in a previous email: >>> >>> Consider now: contract markus' signature >>> >>> 1) contract Markus has signature: you are asserting that a "specific" >>> MARKUS (contract Markus) has a signature >>> 2) contract has Markus' signature: you are asserting that CONTRACT has a >>> specific SIGNATURE (Markus' signature) >>> >>> only 2) seems to make sense to me. >>> >>> Drummond answered that: >>> >>> Now, in this case, you added particulr punctuation used in the English >>> language: the possessive apostrophe. The use of that punctuation creates a >>> conjunction between "markus" and "signature" that cannot be broker apart. >>> This has a direct analog in XDI RDF - using a cross-reference to bind the >>> two XRIs into one. In other words, instead of saying +a+b+c which is three >>> XRI subsegments, you are saying +a(+b+c) which is two XRI subsegments. >>> >>> >>> I was not sure of this, as in other cases, when the possessive statement >>> appears as subject-predicate, like "Drummond's friend", we do not use at >>> all >>> cross references and we simply express this using the $has statement: >>> =drummond+friend >>> >>> But, the very argument is that this may happen also in other kind of >>> statements, not necessarily involving the possessive apostrophe. >>> >>> Condider the following example where: >>> >>> +a is =Markus >>> +b is +parking >>> +c is +slot >>> >>> 1. (+a/(+b/+c)) (=Markus/(+parking/+slot)) (=Markus/+parking+slot) >>> =Markus/$has/+parking+slot, +parking/$has/+slot >>> >>> 2. ((+a/+b)/+c) ((=Markus/+parking)/+slot) (=Markus+parking/+slot) >>> =Markus/$has/+parking, =Markus+parking/$has/+slot >>> >>> Despite they look similar, they are asserting DIFFERENT concepts. >>> Bullet 1. says that markus owns a parking slot. Furthermore it asserts >>> that >>> a parking has a slot. >>> Bullet 2. says that markus owns a whole parking, not a parking slot. >>> Furthermore it is saying that Markus's parking (i.e. one specific parking) >>> has a slot. >>> >>> I think the only reason of considering +a/$has/+b+c and +a+b/$has/+c as >>> producing the same statement +a+b+c was that it was not very clear how the >>> $has operator work. But after our last phc we agreed that $has is a LEFT >>> associative operator. This is enought to tell a parser that when a >>> +a+b/$has/+c is encountered, the a+b+c statement is produced. Whereas when >>> it finds +a/$has/+b+c, then the +a(+b+c) statement must be produced. >>> >>> I propose an AP for a CR on example B4 and consequently on the definition >>> of >>> $has given in: >>> >>> http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel#A.24hasand.24is.24has >>> >>> Kind Regards, >>> Giovanni >>> >>> PS: Markus's visual tool is great! Congratulation, Markus! :-) >>> >>> >>> >>> >>> >>> On Wed, Jan 6, 2010 at 12:50 AM, Giovanni Bartolomeo < >>> giovanni.bartolomeo@uniroma2.it> wrote: >>> >>> Dear Drummond, Markus, >>>> >>>> I want to come back on point B4. >>>> >>>> I think the answer is whether or not the XRI can be simplified by >>>> >>>>> contracting $has statements. >>>>> >>>>> In B4, all of the following statements simplify to the same maximally >>>>> contracted XRI: +a+b+c . >>>>> >>>>> (+a/+b)/$has/+c >>>>> ((+a/+b)/+c) >>>>> (+a+b/+c) >>>>> +a/$has/(+b/+c) >>>>> (+a/(+b/+c)) >>>>> (+a/+b+c) >>>>> +a+b+c >>>>> >>>>> >>>>> To me, this is a risk because it creates inconsistency in the semantic >>>> model. >>>> As you know, I've highlighted this in a previous email: >>>> >>>> Consider now: contract markus' signature >>>> >>>> 1) contract Markus has signature: you are asserting that a "specific" >>>> MARKUS (contract Markus) has a signature >>>> 2) contract has Markus' signature: you are asserting that CONTRACT has >>>> a >>>> specific SIGNATURE (Markus' signature) >>>> >>>> only 2) seems to make sense to me. >>>> >>>> Drummond answered that: >>>> >>>> Now, in this case, you added particulr punctuation used in the English >>>> >>>>> language: the possessive apostrophe. The use of that punctuation creates >>>>> a >>>>> conjunction between "markus" and "signature" that cannot be broker >>>>> apart. >>>>> This has a direct analog in XDI RDF - using a cross-reference to bind >>>>> the >>>>> two XRIs into one. In other words, instead of saying +a+b+c which is >>>>> three >>>>> XRI subsegments, you are saying +a(+b+c) which is two XRI subsegments. >>>>> >>>>> >>>> I was not sure of this, as in other cases, when the possessive statement >>>> appears as subject-predicate, like "Drummond's friend", we do not use at >>>> all >>>> cross references and we simply express this using the $has statement: >>>> =drummond+friend >>>> >>>> But, the very argument is that this may happen also in other kind of >>>> statements, not necessarily involving the possessive apostrophe. >>>> >>>> Condider the following example where: >>>> >>>> +a is =Markus >>>> +b is +parking >>>> +c is +slot >>>> >>>> 1. (+a/(+b/+c)) (=Markus/(+parking/+slot)) (=Markus/+parking+slot) >>>> =Markus/$has/+parking+slot, +parking/$has/+slot >>>> >>>> 2. ((+a/+b)/+c) ((=Markus/+parking)/+slot) (=Markus+parking/+slot) >>>> =Markus/$has/+parking, =Markus+parking/$has/+slot >>>> >>>> Despite they look similar, they are asserting DIFFERENT concepts. >>>> Bullet 1. says that markus owns a parking slot. Furthermore it asserts >>>> that >>>> a parking has a slot. >>>> Bullet 2. says that markus owns a whole parking, not a parking slot. >>>> Furthermore it is saying that Markus's parking (i.e. one specific >>>> parking) >>>> has a slot. >>>> >>>> I think the only reason of considering +a/$has/+b+c and +a+b/$has/+c as >>>> producing the same statement +a+b+c was that it was not very clear how >>>> the >>>> $has operator work. But after our last phc we agreed that $has is a LEFT >>>> associative operator. This is enought to tell a parser that when a >>>> +a+b/$has/+c is encountered, the a+b+c statement is produced. Whereas >>>> when >>>> it finds +a/$has/+b+c, then the +a(+b+c) statement must be produced. >>>> >>>> I propose an AP for a CR on example B4 and consequently on the definition >>>> of $has given in: >>>> >>>> http://wiki.oasis-open.org/xdi/XdiOne/RdfGraphModel#A.24hasand.24is.24has >>>> >>>> Kind Regards, >>>> Giovanni >>>> >>>> PS: Markus's visual tool is great! Congratulation, Markus! :-) >>>> >>>> ---------------------------------------------------------------- >>>> This message was sent using IMP, the Internet Messaging Program. >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe from this mail list, you must leave the OASIS TC that >>>> generates this mail. Follow this link to all your TCs in OASIS at: >>>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >>>> >>>> >>> >> >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]