Issue 13802: SBVR Issue: What is a fact type form (sbvr-rtf) Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov) Nature: Uncategorized Issue Severity: Summary: Title: What is a fact type form? Specification: SBVR Version: 1.0 Source: Ed Barkmeyer, NIST, edbark@nist.gov Summary: In SBVR, clause 8.3.4, 'fact type form' has the definition: "representation of a fact type by a pattern or template of expressions based on the fact type". According to clause 8.3(.0), 'representation' is "actuality that a given expression represents a given meaning". Is "a pattern or template of expressions" an "expression"? According to 8.2, a 'signifier' is "expression that is a linguistic unit or pattern [of sounds or symbols]". So apparently there are expressions that are patterns and they can be signifiers. Per 8.3.1, designation is the "representation of a concept by a sign", and a fact type is a concept, so it may have a representation that is a designation. But the UML diagram shows that a fact type form is not a designation. So presumably a 'pattern or template of expressions' is not a 'sign'. But a signifier, which is a pattern, must be a 'sign', because it is the expression that participates in a designation. But the expression of a fact type form is apparently not a signifier, since only designations have a 'signifier' role, and a fact type form is not a designation. The inconsistency in the terminology, and the failure to make clear parallels and distinctions, is very confusing. It seems that the idea here is that an 'expression' can be a structure of individual sub-expressions, and that, in representing a fact type, the structure and the sub-expressions play distinct roles in the "actuality" of representing the fact type. This means that at least this idea of structured expressions should be described in clause 8.2, as a kind of expression more interesting than "text". It appears to be the intent that a fact type form expression always has a structure with representation sub-behaviors. Is that what distinguishes a fact-type form from a designation? The text is completely silent as to what the delimiting characteristic is. The remaining question then is: what kind of representation is exemplified in a terminological entry for a fact type in the SBVR vocabulary itself? E.g., is "designation has signifier" a designation for a fact type or a fact type form for it? (According to the UML diagram it cannot possibly be both.) And if the latter, does an SBVR fact type not actually have a designation? More confusion. Recommendation: 1. Define the concept that is "pattern or template of expressions" in 8.2 2. Use these structure concepts to define the nature of a fact type form in 8.3.4. For example, a placeholder is a sub-expression. 3. Specify the distinguishing characteristic of a fact-type form that makes it different from a designation. 4. Specify what the vocabulary entries for fact types are: fact-type forms or fact-type designations. Resolution: Revised Text: Actions taken: March 18, 2009: received issue Discussion: End of Annotations:===== te: Wed, 18 Mar 2009 18:59:55 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) To: issues@omg.org CC: SBVR RTF Subject: SBVR Issue: What is a fact type form X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n2IMxuOM011964 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1238021997.6187@JkPx0jybX4/oX3y0fAp/tQ X-Spam-Status: No Title: What is a fact type form? Specification: SBVR Version: 1.0 Source: Ed Barkmeyer, NIST, edbark@nist.gov Summary: In SBVR, clause 8.3.4, 'fact type form' has the definition: "representation of a fact type by a pattern or template of expressions based on the fact type". According to clause 8.3(.0), 'representation' is "actuality that a given expression represents a given meaning". Is "a pattern or template of expressions" an "expression"? According to 8.2, a 'signifier' is "expression that is a linguistic unit or pattern [of sounds or symbols]". So apparently there are expressions that are patterns and they can be signifiers. Per 8.3.1, designation is the "representation of a concept by a sign", and a fact type is a concept, so it may have a representation that is a designation. But the UML diagram shows that a fact type form is not a designation. So presumably a 'pattern or template of expressions' is not a 'sign'. But a signifier, which is a pattern, must be a 'sign', because it is the expression that participates in a designation. But the expression of a fact type form is apparently not a signifier, since only designations have a 'signifier' role, and a fact type form is not a designation. The inconsistency in the terminology, and the failure to make clear parallels and distinctions, is very confusing. It seems that the idea here is that an 'expression' can be a structure of individual sub-expressions, and that, in representing a fact type, the structure and the sub-expressions play distinct roles in the "actuality" of representing the fact type. This means that at least this idea of structured expressions should be described in clause 8.2, as a kind of expression more interesting than "text". It appears to be the intent that a fact type form expression always has a structure with representation sub-behaviors. Is that what distinguishes a fact-type form from a designation? The text is completely silent as to what the delimiting characteristic is. The remaining question then is: what kind of representation is exemplified in a terminological entry for a fact type in the SBVR vocabulary itself? E.g., is "designation has signifier" a designation for a fact type or a fact type form for it? (According to the UML diagram it cannot possibly be both.) And if the latter, does an SBVR fact type not actually have a designation? More confusion. Recommendation: 1. Define the concept that is "pattern or template of expressions" in 8.2 2. Use these structure concepts to define the nature of a fact type form in 8.3.4. For example, a placeholder is a sub-expression. 3. Specify the distinguishing characteristic of a fact-type form that makes it different from a designation. 4. Specify what the vocabulary entries for fact types are: fact-type forms or fact-type designations. -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 From: Don Baisley To: "edbark@nist.gov" , "issues@omg.org" CC: SBVR RTF Date: Wed, 18 Mar 2009 18:55:46 -0700 Subject: RE: SBVR Issue: What is a fact type form Thread-Topic: SBVR Issue: What is a fact type form Thread-Index: AcmoHX9/1sgeXzHwQG2oLswEwOMmewAFzm3A Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Ed asked: > ... does an SBVR fact type not actually have a designation? More confusion. Fact types often have designations. The fact type with the fact type form 'person eats' has a designation that has the signifier "eats". That designation is the actuality that the signifier "eats" represents the fact type, which it does in the statement "George eats." The fact type form 'person eats' demonstrates that designation (that actuality that "eats" represents the fact type). Best regards, Don -----Original Message----- From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Wednesday, March 18, 2009 4:00 PM To: issues@omg.org Cc: SBVR RTF Subject: SBVR Issue: What is a fact type form Title: What is a fact type form? Specification: SBVR Version: 1.0 Source: Ed Barkmeyer, NIST, edbark@nist.gov Summary: In SBVR, clause 8.3.4, 'fact type form' has the definition: "representation of a fact type by a pattern or template of expressions based on the fact type". According to clause 8.3(.0), 'representation' is "actuality that a given expression represents a given meaning". Is "a pattern or template of expressions" an "expression"? According to 8.2, a 'signifier' is "expression that is a linguistic unit or pattern [of sounds or symbols]". So apparently there are expressions that are patterns and they can be signifiers. Per 8.3.1, designation is the "representation of a concept by a sign", and a fact type is a concept, so it may have a representation that is a designation. But the UML diagram shows that a fact type form is not a designation. So presumably a 'pattern or template of expressions' is not a 'sign'. But a signifier, which is a pattern, must be a 'sign', because it is the expression that participates in a designation. But the expression of a fact type form is apparently not a signifier, since only designations have a 'signifier' role, and a fact type form is not a designation. The inconsistency in the terminology, and the failure to make clear parallels and distinctions, is very confusing. It seems that the idea here is that an 'expression' can be a structure of individual sub-expressions, and that, in representing a fact type, the structure and the sub-expressions play distinct roles in the "actuality" of representing the fact type. This means that at least this idea of structured expressions should be described in clause 8.2, as a kind of expression more interesting than "text". It appears to be the intent that a fact type form expression always has a structure with representation sub-behaviors. Is that what distinguishes a fact-type form from a designation? The text is completely silent as to what the delimiting characteristic is. The remaining question then is: what kind of representation is exemplified in a terminological entry for a fact type in the SBVR vocabulary itself? E.g., is "designation has signifier" a designation for a fact type or a fact type form for it? (According to the UML diagram it cannot possibly be both.) And if the latter, does an SBVR fact type not actually have a designation? More confusion. Recommendation: 1. Define the concept that is "pattern or template of expressions" in 8.2 2. Use these structure concepts to define the nature of a fact type form in 8.3.4. For example, a placeholder is a sub-expression. 3. Specify the distinguishing characteristic of a fact-type form that makes it different from a designation. 4. Specify what the vocabulary entries for fact types are: fact-type forms or fact-type designations. -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 Date: Wed, 08 Apr 2009 17:59:10 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: SBVR RTF Subject: Issue 13802 (fact type form) Seeking guidance X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n38LxFvP012368 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1239832758.73453@/9lJJt15TKC3UFPptghC/Q X-Spam-Status: No In the RTF meeting, we agreed that Don and I would come up with a draft for the resolution of Issue 13802: What is a fact type form? We all agree that a fact type form is an abstract syntax model of some unspecified surface syntax used to represent a fact type, and we can say that. The current model says that a fact type is a kind of representation, and it involves a designation for the fact type and a designation for each fact type role (in the context of the fact type form). The problem is that we have no kind of expression that has a structure. The current text envisages a structure that is a character string in which we can talk about substrings by naming their starting character position (but not the end, we just assume the existence of a syntactic delimiter like space). This is not an abstract model, and not a general model of expressions. One general/abstract model of expression is a LISP "list": a sequence of subexpressions each of which is an "atom" or a "list". In our case, an "atom" is a Text or some other undefined thing, which might be called a "Symbol" (in a graphical language). In a graphical language like UML, a fact type form represents a fact type as a "list" that includes 3 sublists. The first sublist is an "association" comprising two atoms, one of which is a text designating the fact type and the other is a "symbol" -- a wire connecting two boxes. Each of the second and third sublists is two atoms, one of which is an "association end label" -- a text placeholder, a signifier for a role; and the other is a symbol -- the connection of the wire to a concept box that is the range of the role. (And that is, in effect, the model we use in the UML diagrams in the SBVR specification.) It is easy to see that an ORM model of a fact type can be similarly described. I was originally thinking that some such concepts -- list and symbol, and 'list contains expression in position' -- should be added to the SBVR model, and that is what the Issue text recommends. But I have strong reservations: (1) SBVR is not really about modeling the surface language. (2) Any model of surface syntax for an actual language will have its own concepts and wouldn't use the general model, at least not by preference. (3) Adding such a feature to SBVR seems to be beyond what an RTF should do. It would probably change the representation of fact type forms in the XML. (Of course, the current specification doesn't support any representation in UML or ORM.) And it would also permit a definition to be represented by such a structure. (And the SBVR marked-up definitions suggest that such a representation would even be desirable.) But then any conforming implementation would also have to support receiving definitions and fact type forms in that form. And that seems like a significant burden on implementors. The intention of the current text seems to be that a fact type form is a kind of Representation in which we are not in fact modeling, or exchanging, the Expression of the representation AT ALL! We are assuming that the Expression is not to be considered Text and we don't know what it might actually look like. Instead we are modeling the fact type form (actuality) as comprising other actualities: a designation of the fact type by a Text (the verb phrase), and the designation of each role by a Text and(/or?) by a Position. In that view, a designation for a concept is always considered to be an "atomic" expression, and a fact type form is considered never to be atomic, and that is the difference. A definition is not atomic, either, and that is why we have the strange fact type 'definition is used as designation', which is a contradiction and really means it is used instead of. If everyone agrees that the approach described in these last two paragraphs is what we should be writing as the resolution, we can do that. If we don't have consensus on something like this, then Don and I should not start writing -- it remains unresolved. So, are we OK with the latter view? -Ed P.S. A further note: we should be clear on the fact that a Text expression does not contain XML markup, while some other kind of expression may. The receiving tool should be assured that a Text expression can be presented verbatim to a business user. But that may be a separate issue. -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." From: Don Baisley To: "'SBVR RTF'" Subject: SBVR Issue 13802 Thread-Topic: SBVR Issue 13802 Thread-Index: Aco78bx8XKAuTXEuQC+dj9Iw7mfLLw== Date: Wed, 23 Sep 2009 02:01:16 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Here is the 13802 resolution document requested from me in last week.s RTF meeting. It is based a document prepared by Ed and reviewed by Mark and me. I think it captures our agreed conclusions. Best regards, Don Issue 13802.doc Subject: Re: SBVR Issue 13802 X-KeepSent: 49E9FF13:5EB2890C-8525763A:005AAABE; type=4; name=$KeepSent To: "'SBVR RTF'" X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Wed, 23 Sep 2009 12:49:45 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.2FP1 ZOS802FP1HF3|June 25, 2009) at 09/23/2009 12:49:52 Don, Regarding the 2nd reference scheme for "designation": the existing reference scheme is "the signifier of the designation and the concept that is represented by the designation ". This makes sense and applies to all kinds of concepts, so why remove it? How does the proposed replacement "A fact type form that demonstrates the designation" address the potential uses of the current reference scheme for other kinds of concepts? Maybe you mean to add a new reference scheme, but remember that many fact type forms may demonstrate the same designation. This note seems clumsy and hard to understand: "Note: A fact type form is not a designation for a fact type but is a syntactic structure of expressions that is a pattern of using a designation of the fact type in definitions and statements." How about shortening it to: "Note: A fact type form is not a designation but instead is a syntactic structure that incorporates signifiers of designations of the fact type form and of placeholders. This syntactic structure is used in definitions and statements." -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Don Baisley ---09/22/2009 10:03:22 PM---Here is the 13802 resolution document requested from me in last week..s RTF meeting. It is based a document prepared by Ed and Don Baisley 09/22/2009 10:01 PM To "'SBVR RTF'" cc Subject SBVR Issue 13802 Here is the 13802 resolution document requested from me in last week..s RTF meeting. It is based a document prepared by Ed and reviewed by Mark and me. I think it captures our agreed conclusions. Best regards, Don[attachment "Issue 13802.doc" deleted by Mark H Linehan/Watson/IBM] pic32225.gif From: Don Baisley To: "'SBVR RTF'" Subject: RE: SBVR Issue 13802 Thread-Topic: SBVR Issue 13802 Thread-Index: Aco78bx8XKAuTXEuQC+dj9Iw7mfLLwAtsp6AAA5hD5A= Date: Wed, 23 Sep 2009 17:03:48 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: The attached, updated resolution incorporates both of Mark.s recommended fixes. The new reference scheme is added without replacing anything and Mark.s suggested wording is now used for the note. Thanks, Mark, for the quick review. Best regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Wednesday, September 23, 2009 9:50 AM To: 'SBVR RTF' Subject: Re: SBVR Issue 13802 Don, Regarding the 2nd reference scheme for "designation": the existing reference scheme is "the signifier of the designation and the concept that is represented by the designation ". This makes sense and applies to all kinds of concepts, so why remove it? How does the proposed replacement "A fact type form that demonstrates the designation" address the potential uses of the current reference scheme for other kinds of concepts? Maybe you mean to add a new reference scheme, but remember that many fact type forms may demonstrate the same designation. This note seems clumsy and hard to understand: "Note: A fact type form is not a designation for a fact type but is a syntactic structure of expressions that is a pattern of using a designation of the fact type in definitions and statements." How about shortening it to: "Note: A fact type form is not a designation but instead is a syntactic structure that incorporates signifiers of designations of the fact type form and of placeholders. This syntactic structure is used in definitions and statements." -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Don Baisley ---09/22/2009 10:03:22 PM---Here is the 13802 resolution document requested from me in last week.s RTF meeting. It is based a document prepared by Ed and Don Baisley 09/22/2009 10:01 PM To "'SBVR RTF'" cc Subject SBVR Issue 13802 Here is the 13802 resolution document requested from me in last week.s RTF meeting. It is based a document prepared by Ed and reviewed by Mark and me. I think it captures our agreed conclusions. Best regards, Don[attachment "Issue 13802.doc" deleted by Mark H Linehan/Watson/IBM] Issue 138021.doc Date: Wed, 23 Sep 2009 16:02:52 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Don Baisley CC: "'SBVR RTF'" Subject: Re: SBVR Issue 13802 X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n8NK2vYC020057 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1254340983.17992@ILErfZnr/AqHr5dS1wxtOg X-Spam-Status: No Don Baisley wrote: The attached, updated resolution incorporates both of Mark..s recommended fixes. The new reference scheme is added without replacing anything and Mark..s suggested wording is now used for the note. Thanks, Mark, for the quick review. * Change 3, the 2nd Note, as it now stands, reads: Note: A fact type form is not a designation but instead is a syntactic structure that incorporates signifiers of designations of the fact type form and of placeholders. This syntactic structure is used in definitions and statements. In the last draft I saw, it read: Note: A fact type form is not a _designation_ for the fact type. A fact type form is a syntactic structure of expressions that is a pattern for the use of the fact type signifier in definitions and statements. I prefer the latter. Contrary to the proposed text, the syntactic structure of the fact type form is not used directly in definitions and statements; it is a pattern for that usage (which is what the original text of the fact type form definition said). Further, the point of the note is not to explain the structure details. Those are covered by the previous note. The point is to distinguish a "designation" from a "pattern for use", which was the confusion manifested in the Issue. * Change 5 adds another Note to the two Notes that are in Change 3. It should just be incorporated into Change 3, to avoid confusing the editor. (I think this text was originally a change to 'fact has fact type form', which is why it was separate. Putting it under 'fact type form' directly is preferable.) * I think the text in Change 8 is editorially misplaced. The current text makes a statement of fact: "The primary representation of a fact type is a fact type form." It then goes on to describe the details of that representation in the "terminological entry". All of that should stand. In the last draft Don and I had, the rationale was a separate Note following that paragraph. E.g., Note: The primary representation for a fact type is a fact type form rather than a designation, because designations of fact types typically have nonunique signifiers (e.g., ..has.). My editorial preference would be for that change. -Ed P.S. In passing, I would observe that the would-be Note in change 8 means that the ReferenceScheme for 'designation' in clause 8.3.1: Reference Scheme: the signifier of the designation and a namespace that includes the designation does not apply to the designations of fact types! I will not raise this as an issue. I suggest we sweep it under the rug. I said long ago that using 'has' as a fact type designation is just bad practice, and this is one of the reasons why. But this unfortunate choice pervades SBVR. The reference scheme specified in clause 8.3.1 should stand; it is essential to effective vocabulary management. That the SBVR "vocabularies" violate this scheme is one of several disconnects between the form of SBVR and its model of "vocabularies". -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." From: Don Baisley To: "'SBVR RTF'" Subject: RE: SBVR Issue 13802 Thread-Topic: SBVR Issue 13802 Thread-Index: Aco78bx8XKAuTXEuQC+dj9Iw7mfLLwAtsp6AAA5hD5D//8LsAIAAX5Ew Date: Wed, 23 Sep 2009 21:38:24 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: The attached document incorporates Ed's recommended changes. Thanks, Ed, for your review. I agree that the idea of "pattern for use" needs to be in the note, as you pointed out. I restored the previous version of the note. Regards, Don -----Original Message----- From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Wednesday, September 23, 2009 1:03 PM To: Don Baisley Cc: 'SBVR RTF' Subject: Re: SBVR Issue 13802 Don Baisley wrote: > The attached, updated resolution incorporates both of Mark..s recommended fixes. The new reference scheme is added without replacing anything and Mark..s suggested wording is now used for the note. Thanks, Mark, for the quick review. > * Change 3, the 2nd Note, as it now stands, reads: Note: A fact type form is not a designation but instead is a syntactic structure that incorporates signifiers of designations of the fact type form and of placeholders. This syntactic structure is used in definitions and statements. In the last draft I saw, it read: Note: A fact type form is not a _designation_ for the fact type. A fact type form is a syntactic structure of expressions that is a pattern for the use of the fact type signifier in definitions and statements. I prefer the latter. Contrary to the proposed text, the syntactic structure of the fact type form is not used directly in definitions and statements; it is a pattern for that usage (which is what the original text of the fact type form definition said). Further, the point of the note is not to explain the structure details. Those are covered by the previous note. The point is to distinguish a "designation" from a "pattern for use", which was the confusion manifested in the Issue. * Change 5 adds another Note to the two Notes that are in Change 3. It should just be incorporated into Change 3, to avoid confusing the editor. (I think this text was originally a change to 'fact has fact type form', which is why it was separate. Putting it under 'fact type form' directly is preferable.) * I think the text in Change 8 is editorially misplaced. The current text makes a statement of fact: "The primary representation of a fact type is a fact type form." It then goes on to describe the details of that representation in the "terminological entry". All of that should stand. In the last draft Don and I had, the rationale was a separate Note following that paragraph. E.g., Note: The primary representation for a fact type is a fact type form rather than a designation, because designations of fact types typically have nonunique signifiers (e.g., ..has.). My editorial preference would be for that change. -Ed P.S. In passing, I would observe that the would-be Note in change 8 means that the ReferenceScheme for 'designation' in clause 8.3.1: > Reference Scheme: the signifier of the designation and a namespace > that includes the designation does not apply to the designations of fact types! I will not raise this as an issue. I suggest we sweep it under the rug. I said long ago that using 'has' as a fact type designation is just bad practice, and this is one of the reasons why. But this unfortunate choice pervades SBVR. The reference scheme specified in clause 8.3.1 should stand; it is essential to effective vocabulary management. That the SBVR "vocabularies" violate this scheme is one of several disconnects between the form of SBVR and its model of "vocabularies". -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Issue 138022.doc Date: Wed, 23 Sep 2009 18:43:13 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Don Baisley CC: "'SBVR RTF'" Subject: Re: SBVR Issue 13802 X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n8NMhITT002405 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1254350602.79553@GYcx9EG1XsJCsjdKrucwGw X-Spam-Status: No Don Baisley wrote: The attached document incorporates Ed's recommended changes. Thanks, Ed, for your review. I agree that the idea of "pattern for use" needs to be in the note, as you pointed out. I restored the previous version of the note. I attach a very slightly revised version. Following Mark's style, I broke the sentence into two sentences. And I misunderstood the reference to "the existing Note" in the change that I suggested should be grouped into change 3. Since the Notes are not together, you were right, it should be a separate editing direction. Thanks, -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Issue 13802-r4.doc From: Don Baisley To: "'SBVR RTF'" Subject: RE: SBVR Issue 13802 Thread-Topic: SBVR Issue 13802 Thread-Index: Aco78bx8XKAuTXEuQC+dj9Iw7mfLLwAtsp6AAA5hD5D//8LsAIAAX5Ew///NPICAAC4GgA== Date: Thu, 24 Sep 2009 02:59:08 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id n8O2wQU2029669 Ed's changes are fine with me. I think we are done with this one. Don -----Original Message----- From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Wednesday, September 23, 2009 3:43 PM To: Don Baisley Cc: 'SBVR RTF' Subject: Re: SBVR Issue 13802 Don Baisley wrote: > The attached document incorporates Ed's recommended changes. > > Thanks, Ed, for your review. I agree that the idea of "pattern for use" needs to be in the note, as you pointed out. I restored the previous version of the note. I attach a very slightly revised version. Following Mark's style, I broke the sentence into two sentences. And I misunderstood the reference to "the existing Note" in the change that I suggested should be grouped into change 3. Since the Notes are not together, you were right, it should be a separate editing direction. Thanks, -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Subject: RE: SBVR Issue 13802 X-KeepSent: 28B9A362:8D923070-8525763B:0040D744; type=4; name=$KeepSent To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Thu, 24 Sep 2009 07:48:47 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.2FP1 ZOS802FP1HF3|June 25, 2009) at 09/24/2009 07:48:52 I'm also ok with Ed's changes. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Don Baisley ---09/23/2009 11:01:27 PM---Ed's changes are fine with me. I think we are done with this one. Don Baisley 09/23/2009 10:59 PM To "'SBVR RTF'" cc Subject RE: SBVR Issue 13802 Ed's changes are fine with me. I think we are done with this one. Don -----Original Message----- From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Wednesday, September 23, 2009 3:43 PM To: Don Baisley Cc: 'SBVR RTF' Subject: Re: SBVR Issue 13802 Don Baisley wrote: > The attached document incorporates Ed's recommended changes. > > Thanks, Ed, for your review. I agree that the idea of "pattern for use" needs to be in the note, as you pointed out. I restored the previous version of the note. I attach a very slightly revised version. Following Mark's style, I broke the sentence into two sentences. And I misunderstood the reference to "the existing Note" in the change that I suggested should be grouped into change 3. Since the Notes are not together, you were right, it should be a separate editing direction. Thanks, -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694