Updated answer, Re: [sc34wg3] TMRM v6.0 comments
Thu, 28 Jul 2005 08:51:54 -0400
Thank you for trying to help. But...
Per my understanding \what is attempted there is the following:
(I replaced sigma with Sumx, etc. as I do not have Greek characters, and
used "n" instead of "l")
Given two tuples:
S1=Sum j(rj)=Sum j(<v1j,v2j...vnj>)
S2=Sum i(ti)=Sum i(<x1i,x2i...xni>)
r and t denote tuples, v and x denote values.
You arrive at:
S1*S2 = Sum i(ti)* Sum j(rj)
= Sum i(ti) * Sum j(<v1j,v2j...vnj>)
= Sum i(ti) * Sum j(<v1j><v2j...vnj>)
= Sum i(ti) * Sum j(<v1j>)
= Sum j,i(ti<vj>)
1) How is it that
Sum j(<x1j,x2j...xnj>) = <x1j>*Sum j(<x2j...xnj>)?
It is sum, not product, right?
2) Why is <v2j...vnj> ignored?
3) If it is ignorable, why don't you ignore <x2j...xnj> and arrive at even
simple conclusion that:
S1*S2 = Sum j,i(<xi><vj>)
These do not make sense to me so far. Perhaps I do not understand
Have to run...
Sorry I will not be in Montreal...
Wish all to have a very productive meeting.
! -----Original Message-----
! From: email@example.com [mailto:sc34wg3-
! firstname.lastname@example.org] On Behalf Of Patrick Durusau
! Sent: Wednesday, July 27, 2005 6:51 AM
! To: email@example.com
! Subject: Re: Updated answer, Re: [sc34wg3] TMRM v6.0 comments
! Nikita Ogievetsky wrote:
! >Thank you, - how did not I see "l" :-)
! Err, because formal notation is more precise than English? ;-) Had I
! tried to say the same thing in English, the error would have been obvious.
! >However, I still have hard time with these formulas: (9) and (10).
! >It is not clear what is the significance of the result, what did we try
! >prove? It is also not clear how did we arrive from (9) to (10).
! >In any case if it is correct, it means that the product between two tuple
! >sequences (or ordered sets :-)) is not a symmetrical operation, which I
! >really doubt. May be I am just missing something very obvious.
! >I would greatly appreciate if you or Robert could help clarify this
! I would have to ask Robert to be sure but it appears to me that there
! are two separate tuple sequences, I assume a tuple sequence of keys and
! a tuple sequence of values. Since all the operations described thus far
! return tuples and sequences of tuples, the keys and values have to be
! stitched back together.
! Recall that earlier the statement is made: "All tuples in a tuple
! sequence must have the same number of values."
! That is only possible because the tuple sequence is the result of a
! *path expression* being applied to a set of subject proxies.
! In other words, just like an SQL expression, you are either going to get
! a value or NULL for everything asked for in the expression. So, the all
! the tuples in a tuple sequence will always have the same number of
! values by definition.
! Everything in section 4 depends upon that premise that we are working on
! the result of a path expression.
! Hope you are having a great day!
! PS: More replies after I get to Montreal later today. I have to finish
! packing, etc.
! >! -----Original Message-----
! >! From: firstname.lastname@example.org [mailto:sc34wg3-
! >! email@example.com] On Behalf Of Patrick Durusau
! >! Sent: Tuesday, July 26, 2005 10:23 AM
! >! To: firstname.lastname@example.org
! >! Subject: Updated answer, Re: [sc34wg3] TMRM v6.0 comments
! >! Nikita,
! >! An updated answer to your third question:
! >! Nikita Ogievetsky wrote:
! >! > Dear Steve, Patrick, Robert, and all,
! >! >
! >! >
! >! <snip>
! >! > 3) It is not clear what is in (.) between (v1j, v2j,.,v1j) in
! >! > expression (9) on p11
! >! >
! >! Actually not a typo, just poor editorial practice.
! >! Using capital letters will make it plain:
! >! (v1j, v2j,...,vLj)
! >! The text uses a lower case "L" in the last term, which with a fairly
! >! good magnifying glass is different from the number "1" in the subscript
! >! for v at the beginning of the sequence.
! >! Same is true for the second sequence in that equation.
! >! That also happens in expression (12) on page 12, expressions (18),
! >! and (20), on page 13, and expression (21) on page 14.
! >! Note that p_m is used in (13) on page 12, despite P_M being defined as
! >! the set of all path expressions. In (13) it simply marks the last in a
! >! sequence of path expressions.
! >! The usage of p_m is also inconsistent with p_n which you will find in
! >! 4.2, condition #3.
! >! There are others I am sure I have not noticed yet so please feel free
! >! point them out. Consistency and good editorial practice (like not using
! >! graphically similar characters to mean different things) would go a
! >! way to making the formalism easier to read.
! >! Sorry 'bout that!
! >! Hope you are having a great day!
! >! Patrick
! >! --
! >! Patrick Durusau
! >! Patrick@Durusau.net
! >! Chair, V1 - Text Processing: Office and Publishing Systems Interface
! >! Co-Editor, ISO 13250, Topic Maps -- Reference Model
! >! Member, Text Encoding Initiative Board of Directors, 2003-2005
! >! Topic Maps: Human, not artificial, intelligence at work!
! >! _______________________________________________
! >! sc34wg3 mailing list
! >! email@example.com
! >! http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
! >sc34wg3 mailing list
! Patrick Durusau
! Chair, V1 - Text Processing: Office and Publishing Systems Interface
! Co-Editor, ISO 13250, Topic Maps -- Reference Model
! Member, Text Encoding Initiative Board of Directors, 2003-2005
! Topic Maps: Human, not artificial, intelligence at work!
! sc34wg3 mailing list