Issue 13716: Definitions in subsection 11.1.5 (sbvr-rtf) Source: Business Rule Solutions, LLC (Mr. Ron Ross, rross(at)brsolutions.com) Nature: Revision Severity: Significant Summary: A number of the definitions in this subsection are incomprehensible, and not well integrated with the rest of the SBVR vocabulary. These definitions center on: assortment fact type, categorization fact type, is-role-of fact type, and is-facet-of fact type. Also, these concepts are defined as kinds of "fact types", but should actually be defined as kinds of *facts*. Finally, the order of the entries needs adjustment as a result of the above. Resolution: Revised Text: Actions taken: March 12, 2009: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 12 Mar 2009 15:33:02 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Ronald G. Ross Company: Business Rule Solutions, LLC mailFrom: @rross@BRSolutions.com Notification: Yes Specification: Refactoring of Clause 11.1.5 Section: 11.1.5 FormalNumber: SBVR Version: 1.0 RevisionDate: latest Page: 143-147 Nature: Revision Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Comcast Install 1.0; .NET CLR 1.1.4322) Description A number of the definitions in this subsection are incomprehensible, and not well integrated with the rest of the SBVR vocabulary. These definitions center on: assortment fact type, categorization fact type, is-role-of fact type, and is-facet-of fact type. Also, these concepts are defined as kinds of "fact types", but should actually be defined as kinds of *facts*. Finally, the order of the entries needs adjustment as a result of the above. User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Sat, 14 Mar 2009 18:28:19 -1000 Subject: Re: issue 13716 -- SBVR RTF issue From: keri To: "Donald R. Chapin" , SBVR RTF CC: "Ronald G. Ross" , Don Baisley Thread-Topic: issue 13716 -- SBVR RTF issue Thread-Index: AcmlJnePtjuqpREZEd66dAARJM+Cgg== Hi, All, Attached is a proposed response to this Issue. Since the presentation format of the 'from-to' edit instructions makes it a bit difficult to grasp the bigger picture I have also attached a PDF showing the resulting 11.1.5, as a whole. While the focus was to make the corrections Ron calls out . improve understandability and correct some specific errors . a happy side-effect was that the heft of this section was reduced by over 25% (with no loss of meanings). This should be welcome news to all who have felt that the document needs to find ways to 'slim down'. Regards, Keri On 3/12/09 11:11 AM, "Juergen Boldt" wrote: From: webmaster@omg.org Date: 12 Mar 2009 15:33:02 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Ronald G. Ross Company: Business Rule Solutions, LLC mailFrom: @rross@BRSolutions.com Notification: Yes Specification: Refactoring of Clause 11.1.5 Section: 11.1.5 FormalNumber: SBVR Version: 1.0 RevisionDate: latest Page: 143-147 Nature: Revision Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Comcast Install 1.0; .NET CLR 1.1.4322) Description A number of the definitions in this subsection are incomprehensible, and not well integrated with the rest of the SBVR vocabulary. These definitions center on: assortment fact type, categorization fact type, is-role-of fact type, and is-facet-of fact type. Also, these concepts are defined as kinds of "fact types", but should actually be defined as kinds of *facts*. Finally, the order of the entries needs adjustment as a result of the above. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org SBVR Issue 13716.doc SBVR 1.0 ch11.1.5 - AS UPDATED.pdf Subject: Re: issue 13716 -- SBVR RTF issue To: keri Cc: "Donald R. Chapin" , Don Baisley , "Ronald G. Ross" , SBVR RTF X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Mon, 16 Mar 2009 10:18:23 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 03/16/2009 10:18:26 Keri, Generally I'm ok with this. A couple of comments: * "Is-property-of fact type" is defined with respect to the first and second "given concepts" (roles?) of a fact type. This makes the definition language-specific and works only for those fact types that are organized appropriately. Consider whether the example given, "The fact type ..engine size is property of car model.." would still be an is-property-of fact type if written as "The fact type ..car model has engine size.." * The diagram does not match the definition of "fundamental concept": one shows it as a subtype of both "general concept" and "noun concept" while the other says it is a subtype of only "noun concept". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com keri keri 03/15/2009 12:28 AM To "Donald R. Chapin" , SBVR RTF cc "Ronald G. Ross" , Don Baisley Subject Re: issue 13716 -- SBVR RTF issue Hi, All, Attached is a proposed response to this Issue. Since the presentation format of the 'from-to' edit instructions makes it a bit difficult to grasp the bigger picture I have also attached a PDF showing the resulting 11.1.5, as a whole. While the focus was to make the corrections Ron calls out . improve understandability and ccorrect some specific errors . a happy side-effect was tthat the heft of this section was reduced by over 25% (with no loss of meanings). This should be welcome news to all who have felt that the document needs to find ways to 'slim down'. Regards, Keri On 3/12/09 11:11 AM, "Juergen Boldt" wrote: From: webmaster@omg.org Date: 12 Mar 2009 15:33:02 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Ronald G. Ross Company: Business Rule Solutions, LLC mailFrom: @rross@BRSolutions.com Notification: Yes Specification: Refactoring of Clause 11.1.5 Section: 11.1.5 FormalNumber: SBVR Version: 1.0 RevisionDate: latest Page: 143-147 Nature: Revision Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Comcast Install 1.0; .NET CLR 1.1.4322) Description A number of the definitions in this subsection are incomprehensible, and not well integrated with the rest of the SBVR vocabulary. These definitions center on: assortment fact type, categorization fact type, is-role-of fact type, and is-facet-of fact type. Also, these concepts are defined as kinds of "fact types", but should actually be defined as kinds of *facts*. Finally, the order of the entries needs adjustment as a result of the above. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org [attachment "SBVR Issue 13716.doc" deleted by Mark H Linehan/Watson/IBM] [attachment "SBVR 1.0 ch11.1.5 - AS UPDATED.pdf" deleted by Mark H Linehan/Watson/IBM] pic057581.gif User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 18 Mar 2009 08:14:34 -1000 Subject: Re: issue 13716 -- SBVR RTF issue From: keri To: Mark H Linehan CC: "Donald R. Chapin" , Don Baisley , "Ronald G. Ross" , SBVR RTF Thread-Topic: issue 13716 -- SBVR RTF issue Thread-Index: Acmn9WPNophMzhPoEd6LhgARJM+Cgg== Mark, Thanks for the 'eagle-eye' attention. I have attached corrected documents. And, see below. - Keri On 3/16/09 4:18 AM, "Mark H Linehan" wrote: Keri, Generally I'm ok with this. A couple of comments: * "Is-property-of fact type" is defined with respect to the first and second "given concepts" (roles?) of a fact type. This makes the definition language-specific and works only for those fact types that are organized appropriately. Consider whether the example given, "The fact type .engine size is property of car model." would still be an is-property-of fact type if written as "The fact type .car model has engine size." You are right . the wording of the current Example is not good. (This is really old wording from long, long ago when we imagined that "is property of" would/could be the verbiage for this notion.) To better illustrate that this is not about the form or any special verbs called for, I have replaced that Example with two that read: Example: The fact type 'car model has engine size'. Example: The fact type 'appointment is scheduled for date'. (And, no, the definition is not talking about the order of roles in some fact type form -- "first" and "second" are simply reference distinguishers.) * The diagram does not match the definition of "fundamental concept": one shows it as a subtype of both "general concept" and "noun concept" while the other says it is a subtype of only "noun concept". My bad! It looks like I have a flawed "shadow" master that (for reasons I cannot pinpoint) had the lead term in the Definition of "fundamental concept" shown as "noun concept". That's clearly not what the PDF shows. I also see that my shadow was missing the "Concept Type" caption for this entry. Thanks again for the careful reading. Keri SBVR Issue 13716 (v2).doc SBVR Issue 13716 (v2-CT).doc SBVR 1.0 ch11.1.5 - AS UPDATED (v2-CT).pdf Date: Wed, 18 Mar 2009 16:13:32 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) To: SBVR RTF CC: keri , Ron Ross Subject: Re: issue 13716 -- SBVR RTF issue X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n2IKDWjn026038 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1238012017.37937@KChIENG2JdeeuCA75+2AZQ X-Spam-Status: No keri wrote: Attached is a proposed response to this Issue [13716]. I have serious reservations about the changes to 8.1.1, and the newly proposed definition of 'fact type': Definition: _concept_ that is the _meaning_ of a verb phrase that involves one or more _noun concepts_ and that _specializes_ the concept .actuality. 1) editorial: It is not clear whether "and that specializes ..." is parallel to "that involves ..." or parallel to "that is the meaning ...". To avoid the ambiguity, we need to reverse the order: Definition: concept that specializes the concept .actuality. and that is the meaning of a verb phrase that involves one or more noun concepts. 2) quasi-technical: 'meaning' in "meaning of a verb phrase" does not appear to be the SBVR concept _meaning_ and should not be so marked. If it were, it would be the role 'meaning' in a designation, and 'verb phrase' would be a category of 'expression'. Of course, we could actually define 'verb phrase' and make the definition formal. Alternatively, we could invert the definition to say what we really mean: Definition: concept that specializes the concept .actuality. and that is represented by an expression that is a verb phrase that involves one or more placeholders for things. [The point of this last is that we are making a linguistic distinction between fact-types and noun concepts, not a semantic distinction. The semantic distinction would require that the instances of a fact type could not be instances of a noun concept, or that 'fact type' and 'noun concept' are not necessarily disjoint categories of 'concept'. Formal logic models do not make the distinction between noun concept and fact type at all. They are both just 'relations' that can be 'satisfied' by sequences of things. Noun concepts and characteristics (unary fact types) are satisfied by sequences of exactly 1 thing. And the 'instances' of a relation are the sequences of things for which the resulting proposition is true. So formal logic provides no guidance here.] 3) technical, and probably a separate issue: Does a fact type correspond to states of affairs in general, or just to actualities? A 'fact type' is a proto-proposition -- a sentential form/concept with free variables in it. The instances of a fact type are really propositions -- sentential forms with 'things' substituted for the free variables. A proposition "denotes" a 'state of affairs' in the same way that an individual concept "denotes" a 'thing'. But the state of affairs need not be an actuality. It is an actuality only if the proposition is true. On the other hand, the concept "instance of concept" may not be (a synonymous form for) that "denotes" notion. So we might want the definition to read: Definition: concept that specializes the concept .state of affairs. and that is represented by an expression that is a verb phrase that involves one or more placeholders for things. But then I would add: Note: Each fact type is a category of states of affairs, all of which are conceptualized using the same verb concept. There can also be noun concepts whose instances are states of affairs. -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 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 18 Mar 2009 11:07:52 -1000 Subject: Re: issue 13716 -- SBVR RTF issue From: keri To: Ed Barkmeyer , SBVR RTF CC: "Ronald G. Ross" Thread-Topic: issue 13716 -- SBVR RTF issue Thread-Index: AcmoDZl+19z9BBQAEd6NqwARJM+Cgg== On 3/18/09 10:13 AM, "Ed Barkmeyer" wrote: > Of course, we could actually define 'verb phrase' and make the > definition formal. We do have 'fact symbol' (p. 150) ... but 'verb phrase' would certainly be a more natural (more familiar) term . something that would be good in an "SBVR 101" introduction to mere mortals. If there is reluctance to changing the terminology, perhaps a synonym? - Keri Date: Wed, 18 Mar 2009 17:29:29 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) To: keri CC: SBVR RTF , "Ronald G. Ross" Subject: Re: issue 13716 -- SBVR RTF issue X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n2ILTTcD003342 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1238016573.81849@RiLpgBqhWFnrX/Gsm8YGkA X-Spam-Status: No keri wrote: Attached is a proposed response to this Issue. I would have "slimmed down the document by throwing section 11.1.5 away. Most of it is pseudo-definition. That said, I note a few minor problems with the proposed text: 1) Editorial: The first Necessity under classification fact and the first necessity under categorization fact are the meaning of 'specializes'. They can be safely deleted. 2) Philosophical: In general, the idea of defining classification as an operation on individual concepts, as distinct from 'things', is a dubious idea. It makes it necessary to know whether a concept may have more than one instance. Things are classified; concepts (categories) are defined. 3) Philosophical: Why would one have 'is-role-of' facts? The definition of the role must define its 'range'. We introduce the x ranges over y fact type in order to formalize the definitions. Remember that 'role ranges over concept' _restricts_ the range of the role. 4) Editorial: The proposed definition for 'facet' is clumsy and misleading. A facet is a/the collection of characteristics (of arbitrary things) that are important to some viewpoint. Every set of characteristics forms a concept, but the facet is exactly a particular set of characteristics. Why not just: Definition: the set of the characteristics of a thing that are relevant to a given viewpoint. And note, please, that no amount of doubletalk can disguise the fact that a facet can be treated as a kind of general concept and may well be used to classify things. The example of 'concept has facet' says that a rental car is an asset, but the accounting people treat 'asset' as a classification. (The underlying problem here is that categorization is viewpoint-specific: one man's facet is another man's category. From a given viewpoint, there is a hierarchy of essential characteristics that defines my taxonomy, and there are other important characteristics of the things in my taxonomic categories that define facets that are important to other people I have to deal with. But from their viewpoint, their facets are the essential characteristics that define their categories, and my essential characteristics are just facets of my viewpoint. Business people regularly make the mistake of assigning rank to their viewpoint.) 5) Technical: The following Necessity is implied by the UML diagram, but not stated: Necessity: No is-facet-of fact is an is-role-of fact. 6) Technical: There is no given fact type that relates a facet to the viewpoint that defines it. And it is not at all clear how 'concept has facet' is different from 'concept specializes facet'. 7) Technical: It is not clear that 'situation' is anything other than a synonym for 'state of affairs'. The proposed definition of 'situation': Definition: state of affairs that is a set of circumstances that provides the context from which roles played may be understood or assessed. appears to be trying to define 'situation' as a role of a state of affairs in some unspecified fact type. -Ed P.S. You can ignore as much of this as you like. I will Abstain on all changes to 11.1.5. I will only vote Yes on a revision that reads: DELETE Clause 11.1.5. -- 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." Date: Wed, 18 Mar 2009 18:11:07 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) To: keri CC: SBVR RTF , "Ronald G. Ross" Subject: Re: issue 13716 -- SBVR RTF issue X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n2IMB7v9007758 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1238019070.99821@sXLIwAEeFwZolZ8izSrFiA X-Spam-Status: No keri wrote: On 3/18/09 10:13 AM, "Ed Barkmeyer" wrote: Of course, we could actually define 'verb phrase' and make the definition formal. We do have 'fact symbol' (p. 150) Ah. In 11.2.1.2, fact symbol is a kind of 'designation'. I said a verb phrase is a kind of 'expression', because of the issue of including placholders for nouns. But the SBVR notion of 'designation' is not really the actuality of designating; it is rather "the signifier expression understood as designating". (Otherwise, most of 11.2.1.2 makes no sense.) So we could formalize the definition using 'fact symbol' instead of 'verb phrase'. I would recommend that we do this. ... but 'verb phrase' would certainly be a more natural (more familiar) term . something that would be good in an "SBVR 101" introduction to mere mortals. Yes. No business audience will ever read SBVR, I hope. But I'm still trying to identify the audience the specification itself was intended for. If there is reluctance to changing the terminology, perhaps a synonym? That seems like the best solution. But it will force us to define the concept in clause 8 (as a subtype of designation), and to Note its relationship to 'fact type form', which, frankly, is something we should have done anyway. (The definition of fact type form implies that it is not a designation, which calls into question the nature of a Glossary fact type entry.) -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: issue 13716 -- SBVR RTF issue To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Thu, 19 Mar 2009 08:59:03 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 03/19/2009 08:59:05 The existing definition of "fact type" is "concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities ". Both the proposed resolution and Ed's version change the definition to say that a fact type "specializes an actuality" (or a "state of affairs"). To me this is a radical and incompatible change. As Ed says, a fact type is "a proto-proposition -- a ... concept with free variables in it". You have to substitute values into those free variables in order to get a state of affairs. So I don't agree that a state of affairs "specializes a state of affairs". Why is this change proposed at all? Looking further, I see that the old "Fact Type Templating" categorization has been divided into two categorizations: "Fact Type Templating" and "Fact Templating". It seems to me that this division is a mistake; the categories in "Fact Templating" really are kinds of fact types, not kinds of facts. But I do agree with Ed that the concepts of "viewpoint" and "facet" are not necessary. Better to address these ideas with different vocabulary that models concepts from alternate viewpoints. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 19 Mar 2009 10:34:24 -0500 To: edbark@nist.gov, keri From: "Ronald G. Ross" Subject: Re: issue 13716 -- SBVR RTF issue Cc: SBVR RTF At 05:11 PM 3/18/2009, Ed Barkmeyer wrote: keri wrote: On 3/18/09 10:13 AM, "Ed Barkmeyer" wrote: Yes. No business audience will ever read SBVR, I hope. But I'm still trying to identify the audience the specification itself was intended for. Ed, I notice from several of your recent and past e-mails that you have continuing questions in that regard. I don't understand why. But let's not let it become a distraction. Speaking as one of the people involved in the initiation of SBVR ... and the BRG work that preceded it ... and the BRS work that preceded and paralleled that, I can tell you that at least my objective was to make (a) business semantics (standard vocabularies including both nouns and verbs), and (b) business rules written in structured natural language, a reality for business people and business analysts. What's hard about that? I believe that existing (IT) paradigms are simply not adequate (in fact, woefully inadequate) for moving businesses toward a knowledge economy. Section 11.1.5 is key for people like BRG members (including me) to explain and deliver SBVR concepts to the business side. Now it is clear that people like Terry Halpin, Don Baisley and yourself understand that these business-facing concepts can be engineered to enable machine-to-machine communication of semantics. Wonderful. But if that were the central or only focus of SBVR, there's no way I would have devoted my time to it over the years. There is a *huge* business problem that clauses 11 & 12 address. HUGE. It's critical for the productivity of organizations world-wide. I have no doubt whatsoever about that ... or what the real purpose of SBVR is about. I'm exposed to it virtually every day in our professional work. Ron P.S. So please have a little patience with those of who think that section 11.1.5 is actually one of the most important parts of SBVR. We (speaking mainly for myself) are not experts in logic, but we are the ones with actual experience in addressing these problems over the years day-to-day in the work world. User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 19 Mar 2009 06:27:51 -1000 Subject: Re: issue 13716 -- SBVR RTF issue From: keri To: Mark H Linehan , SBVR RTF Thread-Topic: issue 13716 -- SBVR RTF issue Thread-Index: Acmor6W65JV4KBSiEd6woQARJM+Cgg== On 3/19/09 2:59 AM, "Mark H Linehan" wrote: The existing definition of "fact type" is "concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities ". Both the proposed resolution and Ed's version change the definition to say that a fact type "specializes an actuality" (or a "state of affairs"). To me this is a radical and incompatible change. As Ed says, a fact type is "a proto-proposition -- a ... concept with free variables in it". You have to substitute values into those free variables in order to get a state of affairs. So I don't agree that a state of affairs "specializes a state of affairs". Why is this change proposed at all? Mark, To recap . the proposed change is to replace the end of the DEFINITION text: and whose instances are all actualities with: and that specializes the concept .actuality. According to my notes this is proposed because object types should be distinguished, not by what instances they have, but by the characteristics they incorporate. Keri User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 19 Mar 2009 06:49:22 -1000 Subject: Re: issue 13716 -- SBVR RTF issue From: keri To: Mark H Linehan , SBVR RTF Thread-Topic: issue 13716 -- SBVR RTF issue Thread-Index: Acmosqc55bvIOBSlEd6woQARJM+Cgg== On 3/19/09 2:59 AM, "Mark H Linehan" wrote: Looking further, I see that the old "Fact Type Templating" categorization has been divided into two categorizations: "Fact Type Templating" and "Fact Templating". It seems to me that this division is a mistake; the categories in "Fact Templating" really are kinds of fact types, not kinds of facts. The main thrust of this Issue was to correct these items previously (currently) shown as kinds of 'fact type' to be kinds of 'fact'. Here is one simple example that may help. According to the 'fact type' view we might have had these: [A] car manufacturer produces car model [B] car manufacturer specializes organization where [B] is intended to specify that car manufacturer as a 'subtype' of organization. Some facts for the fact type [A] could include: .Toyota produces the Avalon. and .Ford produces the Mustang.. However, if we then try to understand [B] in this same way, facts for the 'fact type' [B] would look like this .Toyota specializes the Boy Scouts of America.. IOW, we would be looking for a particular car manufacturer in one fact type role and some organization in the other. B is understood differently from A. It is not represented as a fact type form, but is meant to be a statement of fact that uses a fact type form from SBVR. We would have a statement of fact, such as: The concept .car manufacturer. specializes the concept .organization.. Keri User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 19 Mar 2009 06:54:49 -1000 Subject: Re: issue 13716 -- SBVR RTF issue From: keri To: Mark H Linehan , SBVR RTF Thread-Topic: issue 13716 -- SBVR RTF issue Thread-Index: Acmos2oiqPMN1RSmEd6woQARJM+Cgg== On 3/19/09 2:59 AM, "Mark H Linehan" wrote: But I do agree with Ed that the concepts of "viewpoint" and "facet" are not necessary. Better to address these ideas with different vocabulary that models concepts from alternate viewpoints. In the section on 'Contextualization' a distinction is being made between 'fundamental' concepts and 'contextualized' concepts. The latter need something as the contextualization 'context'. Situation (for role) and viewpoint (for facet) supply that. (This is not being changed by this proposal, BTW.) Keri Subject: RE: issue 13716 -- SBVR RTF issue Date: Thu, 19 Mar 2009 12:29:10 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 13716 -- SBVR RTF issue Thread-Index: AcmoqKZFjrugDE7ITpaME+GFGRdYKAAH75Sg Priority: Non-Urgent From: "Paul Vincent" To: "Ronald G. Ross" , , "keri" Cc: "SBVR RTF" X-OriginalArrivalTime: 19 Mar 2009 19:28:33.0329 (UTC) FILETIME=[E442FA10:01C9A8C8] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n2JJSAnH013649 I *think* Ed meant "No business audience will ever read the SBVR specification". Personally, I'm hoping for a Dummies Guide to SBVR (or at least SBVR In A Nutshell) :) Paul Vincent +1 650 206 2493 / mobile +44 781 493 7229 > -----Original Message----- > From: Ronald G. Ross [mailto:rross@brsolutions.com] > Sent: 19 March 2009 15:34 > To: edbark@nist.gov; keri > Cc: SBVR RTF > Subject: Re: issue 13716 -- SBVR RTF issue > > At 05:11 PM 3/18/2009, Ed Barkmeyer wrote: > >keri wrote: > >>On 3/18/09 10:13 AM, "Ed Barkmeyer" wrote: > > > >Yes. No business audience will ever read SBVR, I hope. But I'm > >still trying to identify the audience the specification itself was > >intended for. > > Ed, > > I notice from several of your recent and past e-mails that > you have continuing questions in that regard. I don't understand why. > But let's not let it become a distraction. > > Speaking as one of the people involved in the initiation of > SBVR ... and the BRG work that preceded it ... and the BRS work that > preceded and paralleled that, I can tell you that at least my > objective was to make (a) business semantics (standard vocabularies > including both nouns and verbs), and (b) business rules written in > structured natural language, a reality for business people and > business analysts. What's hard about that? I believe that existing > (IT) paradigms are simply not adequate (in fact, woefully inadequate) > for moving businesses toward a knowledge economy. Section 11.1.5 is > key for people like BRG members (including me) to explain and deliver > SBVR concepts to the business side. > > Now it is clear that people like Terry Halpin, Don Baisley > and yourself understand that these business-facing concepts can be > engineered to enable machine-to-machine communication of semantics. > Wonderful. But if that were the central or only focus of SBVR, > there's no way I would have devoted my time to it over the years. > There is a *huge* business problem that clauses 11 & 12 address. > HUGE. It's critical for the productivity of organizations world-wide. > I have no doubt whatsoever about that ... or what the real purpose of > SBVR is about. I'm exposed to it virtually every day in our > professional work. > > Ron > > P.S. So please have a little patience with those of who think that > section 11.1.5 is actually one of the most important parts of SBVR. > We (speaking mainly for myself) are not experts in logic, but we are > the ones with actual experience in addressing these problems over the > years day-to-day in the work world. > X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 19 Mar 2009 14:34:53 -0500 To: "Paul Vincent" , , "keri" From: "Ronald G. Ross" Subject: RE: issue 13716 -- SBVR RTF issue Cc: "SBVR RTF" At 02:29 PM 3/19/2009, Paul Vincent wrote: I *think* Ed meant "No business audience will ever read the SBVR specification". He SAID: "I'm still trying to identify the audience the specification itself was intended for." Personally, I'm hoping for a Dummies Guide to SBVR (or at least SBVR In A Nutshell) :) Sure, but who are the "Dummies"? IMHO, if they are business analysts or business people, it should be based on clauses 11 and 12. Ron Paul Vincent +1 650 206 2493 / mobile +44 781 493 7229 > -----Original Message----- > From: Ronald G. Ross [ mailto:rross@brsolutions.com] > Sent: 19 March 2009 15:34 > To: edbark@nist.gov; keri > Cc: SBVR RTF > Subject: Re: issue 13716 -- SBVR RTF issue > > At 05:11 PM 3/18/2009, Ed Barkmeyer wrote: > >keri wrote: > >>On 3/18/09 10:13 AM, "Ed Barkmeyer" wrote: > > > >Yes. No business audience will ever read SBVR, I hope. But I'm > >still trying to identify the audience the specification itself was > >intended for. > > Ed, > > I notice from several of your recent and past e-mails that > you have continuing questions in that regard. I don't understand why. > But let's not let it become a distraction. > > Speaking as one of the people involved in the initiation of > SBVR ... and the BRG work that preceded it ... and the BRS work that > preceded and paralleled that, I can tell you that at least my > objective was to make (a) business semantics (standard vocabularies > including both nouns and verbs), and (b) business rules written in > structured natural language, a reality for business people and > business analysts. What's hard about that? I believe that existing > (IT) paradigms are simply not adequate (in fact, woefully inadequate) > for moving businesses toward a knowledge economy. Section 11.1.5 is > key for people like BRG members (including me) to explain and deliver > SBVR concepts to the business side. > > Now it is clear that people like Terry Halpin, Don Baisley > and yourself understand that these business-facing concepts can be > engineered to enable machine-to-machine communication of semantics. > Wonderful. But if that were the central or only focus of SBVR, > there's no way I would have devoted my time to it over the years. > There is a *huge* business problem that clauses 11 & 12 address. > HUGE. It's critical for the productivity of organizations world-wide. > I have no doubt whatsoever about that ... or what the real purpose of > SBVR is about. I'm exposed to it virtually every day in our > professional work. > > Ron > > P.S. So please have a little patience with those of who think that > section 11.1.5 is actually one of the most important parts of SBVR. > We (speaking mainly for myself) are not experts in logic, but we are > the ones with actual experience in addressing these problems over the > years day-to-day in the work world. > Date: Thu, 19 Mar 2009 22:00:18 +0000 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) To: "Ronald G. Ross" CC: edbark@nist.gov, keri , SBVR RTF Subject: Re: issue 13716 -- SBVR RTF issue Ed, I agree with Ron. The rationale for 11.1.5 is to describe patterns that you can recognize as you're trying to organize business information when you are getting started with an enterprise - content of documents, interviews and discussions with people in the business, notes from workshops, etc. Fact type templating provides a useful way of categorizing the fact types you find. It is part of methodology, but is not specific to any given methodology. I wouldn't claim that the patterns are universal, but they are very widespread - and recognizable by the business analysts and business rules analysts I know. It will be useful to have tools that can support them. We had this discussion a couple of years ago. I thought you participated in it, and your position was: "Well, if those of you who do this for your living say you need this, it doesn't do any harm to have it in SBVR". Regards, John Ronald G. Ross wrote: At 05:11 PM 3/18/2009, Ed Barkmeyer wrote: keri wrote: On 3/18/09 10:13 AM, "Ed Barkmeyer" wrote: Yes. No business audience will ever read SBVR, I hope. But I'm still trying to identify the audience the specification itself was intended for. Ed, I notice from several of your recent and past e-mails that you have continuing questions in that regard. I don't understand why. But let's not let it become a distraction. Speaking as one of the people involved in the initiation of SBVR ... and the BRG work that preceded it ... and the BRS work that preceded and paralleled that, I can tell you that at least my objective was to make (a) business semantics (standard vocabularies including both nouns and verbs), and (b) business rules written in structured natural language, a reality for business people and business analysts. What's hard about that? I believe that existing (IT) paradigms are simply not adequate (in fact, woefully inadequate) for moving businesses toward a knowledge economy. Section 11.1.5 is key for people like BRG members (including me) to explain and deliver SBVR concepts to the business side. Now it is clear that people like Terry Halpin, Don Baisley and yourself understand that these business-facing concepts can be engineered to enable machine-to-machine communication of semantics. Wonderful. But if that were the central or only focus of SBVR, there's no way I would have devoted my time to it over the years. There is a *huge* business problem that clauses 11 & 12 address. HUGE. It's critical for the productivity of organizations world-wide. I have no doubt whatsoever about that ... or what the real purpose of SBVR is about. I'm exposed to it virtually every day in our professional work. Ron P.S. So please have a little patience with those of who think that section 11.1.5 is actually one of the most important parts of SBVR. We (speaking mainly for myself) are not experts in logic, but we are the ones with actual experience in addressing these problems over the years day-to-day in the work world. Date: Thu, 19 Mar 2009 19:16:49 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: john.hall@modelsys.com CC: "Ronald G. Ross" , keri , SBVR RTF Subject: Re: issue 13716 -- SBVR RTF issue X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n2JNGsEO015184 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1238109419.52208@2XVCgvihyC0NojzcYtqnvQ X-Spam-Status: No John Hall wrote: The rationale for 11.1.5 is to describe patterns that you can recognize as you're trying to organize business information when you are getting started with an enterprise - content of documents, interviews and discussions with people in the business, notes from workshops, etc. Fact type templating provides a useful way of categorizing the fact types you find. It is part of methodology, but is not specific to any given methodology. I wouldn't claim that the patterns are universal, but they are very widespread - and recognizable by the business analysts and business rules analysts I know. It will be useful to have tools that can support them. First, some form of these two paragraphs should be the introduction to 11.1.5. The standard plunges into the details, and the text of many of the entries defies intuition. I assume that it is BRG-speak, a language spoken by 16 people and possibly other experts in ISO TC37. No business analyst that I know from the BAWG even tries to read clause 11.1.5. It demands an unusual variety of erudition. And what you get from toolsmiths like Don is: it is a label on a box whose semantics are of no interest to me; I can provide a box with the label. It appears to me that all you want from the toolsmith is to have predefined boxes with those labels. There is no requirement for the tool to understand the boxes. They could equally well be "manufacturing operations fact-types" and "product engineering fact types". It is just an implication-free taxonomy that some of you want to use. The language is so stilted as to guarantee that the section has no other audience. This is why Paul said he is waiting for "SBVR for Dummies" -- a text that explains these concepts, and their relevance, to "mere mortals". The problem I see is that some important vocabulary management concepts that the tool does need to understand and support got buried in all this packaging-conventions stuff. But that is what Donald is trying to rectify in addressing some other issue. We had this discussion a couple of years ago. I thought you participated in it, and your position was: "Well, if those of you who do this for your living say you need this, it doesn't do any harm to have it in SBVR". Exactly. That is why I promised to abstain on any changes. Voting Yes on a resolution to remove it was tongue-in-cheek. -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." X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 20 Mar 2009 08:47:07 -0500 To: edbark@nist.gov, john.hall@modelsys.com From: "Ronald G. Ross" Subject: Re: issue 13716 -- SBVR RTF issue Cc: keri , SBVR RTF At 06:16 PM 3/19/2009, Ed Barkmeyer wrote: John Hall wrote: The rationale for 11.1.5 is to describe patterns that you can recognize as you're trying to organize business information when you are getting started with an enterprise - content of documents, interviews and discussions with people in the business, notes from workshops, etc. Fact type templating provides a useful way of categorizing the fact types you find. It is part of methodology, but is not specific to any given methodology. I wouldn't claim that the patterns are universal, but they are very widespread - and recognizable by the business analysts and business rules analysts I know. It will be useful to have tools that can support them. First, some form of these two paragraphs should be the introduction to 11.1.5. The standard plunges into the details, and the text of many of the entries defies intuition. FWIW, ALL of clause 11 needs such descriptive introductions. The lack of such is a major barrier to consumability. I have thought about volunteering some straw men from time to time, but marginal sanity quickly reined me in. It was hard enough for clause 12. Ron X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Fri, 20 Mar 2009 11:11:45 -0500 To: edbark@nist.gov, john.hall@modelsys.com From: "Ronald G. Ross" Subject: Re: issue 13716 -- SBVR RTF issue Cc: keri , SBVR RTF At 06:16 PM 3/19/2009, Ed Barkmeyer wrote: John Hall wrote: The rationale for 11.1.5 is to describe patterns that you can recognize as you're trying to organize business information when you are getting started with an enterprise - content of documents, interviews and discussions with people in the business, notes from workshops, etc. Fact type templating provides a useful way of categorizing the fact types you find. It is part of methodology, but is not specific to any given methodology. I wouldn't claim that the patterns are universal, but they are very widespread - and recognizable by the business analysts and business rules analysts I know. It will be useful to have tools that can support them. It appears to me that all you want from the toolsmith is to have predefined boxes with those labels. There is no requirement for the tool to understand the boxes. They could equally well be "manufacturing operations fact-types" and "product engineering fact types". It is just an implication-free taxonomy that some of you want to use. I don't think that is the case. But first let me say this. SBVR is just a vocabulary. It provides vocabulary for developing vocabularies. That vocabulary should be free of artificial IT constructs. No business person ever naturally says "business object", for example. What kind of words do business people use to develop vocabulary? Well they talk about ideas such as "categorization" and "category" (not "subtyping" or "subtypes"). They talk about "classification" (classifying things). It escapes me how we could produce a standard called "Semantics of Business Vocabularies ..." and not include such commonplace ideas?! What kind of guidance would we be giving to people who are not logic whizzes, but simply want to develop vocabularies!? Since these terms seem to be nowhere else in SBVR, clause 11.1.5 introduces them. Clause 11.1.5 introduces other terms (e.g., situational role, situation), including some from ISO 1087 & 704 (e.g., partitive), that we believe are also useful for people wanting to talk about developing and organizing vocabularies. Believe me, it is really, really hard work. People need structural building blocks ("macros" if you like). That brings me back to the labels on the boxes. The intent of the (revised) 11.1.5 definitions is that these business-facing structural ideas can be automatically 'consumed' ('understood') by an SBVR-compliant tool. If not, then they are not to the degree of precision that BRG members intended. The language is so stilted as to guarantee that the section has no other audience. This is why Paul said he is waiting for "SBVR for Dummies" -- a text that explains these concepts, and their relevance, to "mere mortals". The revised definitions are meant to be understandable for experts in semantics and logic, and associated engineers. We have *already* been explaining them to business people (e.g., Keri's presentations and my chapter 4 in Business Rule Concepts). Ron Subject: Re: issue 13716 -- SBVR RTF issue To: SBVR RTF X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Sat, 21 Mar 2009 07:51:07 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 03/21/2009 11:08:57 Yes. 13716 proposes that a fact type should be defined as a kind of actuality. That seems patently wrong. In the existing spec the *instances* of a fact type are actualities. But a fact type itself is not an actuality. I think the specification is correct as it stands. I don't understand your reference to object types. Fact types are not object types and the statement that "this is proposed because object types should be distinguished, not by what instances they have, but by the characteristics they incorporate" doesn't seem to be relevant. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com keri keri 03/19/2009 12:27 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: issue 13716 -- SBVR RTF issue On 3/19/09 2:59 AM, "Mark H Linehan" wrote: The existing definition of "fact type" is "concept that is the meaning of a verb phrase that involves one or more noun concepts and whose instances are all actualities ". Both the proposed resolution and Ed's version change the definition to say that a fact type "specializes an actuality" (or a "state of affairs"). To me this is a radical and incompatible change. As Ed says, a fact type is "a proto-proposition -- a ... concept with free variables in it". You have to substitute values into those free variables in order to get a state of affairs. So I don't agree that a state of affairs "specializes a state of affairs". Why is this change proposed at all? Mark, To recap . the proposed changge is to replace the end of the DEFINITION text: and whose instances are all actualities with: and that specializes the concept ..actuality.. According to my notes this is proposed because object types should be distinguished, not by what instances they have, but by the characteristics they incorporate. Keri pic23212.gif Subject: Re: issue 13716 -- SBVR RTF issue To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Sat, 21 Mar 2009 08:13:55 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 03/21/2009 11:08:57 OK. So for clarity [B] should be given in the way you specify, as "The concept ..car manufacturer.. specializes the concept ..organization..." I see that the proposed text does that. Good. By the way, this is an illustration of the distinction between a conceptual model and a fact model. The SBVR metamodel is a conceptual model. A fact model that is based on the SBVR conceptual model contains the fact "The concept ..car manufacturer.. specializes the concept ..organization..." This fact is an actuality, an instance of the SBVR fact type "concept1 specializes concept2". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com keri keri 03/19/2009 12:49 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: issue 13716 -- SBVR RTF issue On 3/19/09 2:59 AM, "Mark H Linehan" wrote: Looking further, I see that the old "Fact Type Templating" categorization has been divided into two categorizations: "Fact Type Templating" and "Fact Templating". It seems to me that this division is a mistake; the categories in "Fact Templating" really are kinds of fact types, not kinds of facts. The main thrust of this Issue was to correct these items previously (currently) shown as kinds of 'fact type' to be kinds of 'fact'. Here is one simple example that may help. According to the 'fact type' view we might have had these: [A] car manufacturer produces car model [B] car manufacturer specializes organization where [B] is intended to specify that car manufacturer as a 'subtype' of organization. Some facts for the fact type [A] could include: ..Toyota produces the Avalon. and ..Ford produces the Mustang.. However, if we then try to understand [B] in this same way, facts for the 'fact type' [B] would look like this ..Toyota specializes the Boy Scouts of America.. IOW, we would be looking for a particular car manufacturer in one fact type role and some organization in the other. B is understood differently from A. It is not represented as a fact type form, but is meant to be a statement of fact that uses a fact type form from SBVR. We would have a statement of fact, such as: The concept ..car manufacturer.. specializes the concept ..organization... Keri pic03815.gif Subject: Re: issue 13716 -- SBVR RTF issue To: SBVR RTF X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Sat, 21 Mar 2009 08:32:59 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 03/21/2009 11:08:57 Yes, but who chooses a "viewpoint"? My answer: a semantic community. But then, how are the "facets" of a "viewpoint" different from the "fundamental concepts" of another semantic community? My answer: there is no difference except of viewpoint or perspective. Semantic community A will consider semantic community B's fundamental concepts as just facets. And vice-versa, semantic community B will say that community A's fundamental concepts are just facets. What we've done is said that some concepts are "fundamental" and some are second-class. But which are first-class and which are second-class is not fundamental at all, but just a matter of perspective. As an example, we normally classify people by age, gender, graduated, etc. But rental car companies also classify people as "qualified" or not. So we can think of "qualified" either as a concept in a specialized vocabulary used by rental car companies, or we can define a "facet" called "driver" that includes the characteristic "qualified" and perhaps excludes the characteristic "graduated". I think it makes more sense to understand that different vocabularies -- created by different semantic communities -- may have involve the same concepts in different fact types. SBVR already has all the machinery needed for that. "Viewpoint" and "facet" are redundant and should be deleted. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com keri keri 03/19/2009 12:54 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: issue 13716 -- SBVR RTF issue On 3/19/09 2:59 AM, "Mark H Linehan" wrote: But I do agree with Ed that the concepts of "viewpoint" and "facet" are not necessary. Better to address these ideas with different vocabulary that models concepts from alternate viewpoints. In the section on 'Contextualization' a distinction is being made between 'fundamental' concepts and 'contextualized' concepts. The latter need something as the contextualization 'context'. Situation (for role) and viewpoint (for facet) supply that. (This is not being changed by this proposal, BTW.) Keri pic31099.gif Subject: Re: issue 13716 -- SBVR RTF issue To: SBVR RTF X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Sun, 22 Mar 2009 21:54:32 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 03/22/2009 21:54:37 Yes, I think it is a mistake to ask a community to rank its concepts. When that community needs to integrate its concepts with another community, the question of which categorizations are "fundamental" and which are not will get in the way. Better to just admit that there are multiple ways to conceptualize things without declaring that some are fundamental and some not. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com keri keri 03/21/2009 06:08 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: issue 13716 -- SBVR RTF issue On 3/21/09 10:34 AM, "Mark H Linehan" wrote: No, I am not interpreting "fundamental" as "universal". I am saying that a better way to treat "viewpoints" is just to have an alternative categorization. Rather than having a semantic community say "we pick this categorization as 'fundamental' and that other one as a 'viewpoint' " -- instead just have the semantic community define two categorizations. This approach will simplify semantic integration when two semantic communities -- each picking different fundamental conceptualizations -- get together. Instead of the two communities having to decide which categorization is *really* fundamental, they can just agree on as many categorizations as are needed. Mark, I am still not grasping your point. Let's set "viewpoint" aside for a minute and take things a step at a time . say we want to divide a community's concepts into 'fundamental concept' and 'not-fundamental concept'. Is this what you disagreeing with? Keri pic175153.gif Subject: Re: issue 13716 -- SBVR RTF issue To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Sun, 22 Mar 2009 22:02:04 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 03/22/2009 22:02:09 Keri, I agree that the proposed definition says that: [a] fact type is [a] concept that is [a thing that] ... specializes the concept 'actuality' The problem with this definition is that it is not true. A fact type does not specialize the concept 'actuality'. Let's take an example, the fact type "driver drives car", where 'driver' and 'car' are placeholders for roles of the same names, and 'drives' is the fact symbol. In this case, the fact type itself is the "concept" that is the "thing" referenced in the definition. This thing is NOT a kind of actuality. An instance of the fact type -- where a particular driver and a particular car are specified -- would be an actuality. But the fact type itself is not an actuality. Take a look at the diagram at the start of clause 8.1. "Fact type" is NOT shown as a kind of "actuality" in this diagram. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com keri keri 03/21/2009 06:02 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: issue 13716 -- SBVR RTF issue On 3/21/09 10:26 AM, "Mark H Linehan" wrote: Thanks for your explanation of your second paragraph. Now I understand what you are trying to achieve. However, the proposed wording clearly says that "fact type" is a "concept ... that specializes the concept 'actuality'" -- which is not what you intend. Actually, if you follow along in Annex C when it explains how to write/interpret this kind of Definition, it is saying that: [a] fact type is [a] concept that is [a thing that] ... specializes the concept 'actuality' something along those lines. The underlying problem is that we are trying to have a definition that mixes modeling levels in one statement. It wants to talk about both a fact type and the instances of a fact type at the same time. That is the way we do it for all Definitions. It's likely that I am not explaining this precisely enough, so I defer to others who might want to give it a shot. That is always awkward. So here's a question: why do we need the text about actualities at all? Why isn't it sufficient to say simply that a fact type is a "concept that is the meaning of a verb phrase that involves one or more noun concepts". What other concept would erroneously fall under this definition? That would make me happy (i.e., much easier to explain to our mere mortals). But since this is Clause 8 Don (and those who are the tenders there) would need to answer this. Keri pic057582.gif Date: Sun, 22 Mar 2009 23:41:35 -0400 From: John Hall Reply-To: john.hall@modelsys.com Organization: Model Systems User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: Mark H Linehan CC: SBVR RTF Subject: Re: issue 13716 -- SBVR RTF issue Hello Mark, When a semantic community declares which noun concepts are fundamental it is defining the scope of its conceptual model. The fundamental noun concepts are those at the boundary, at the top of the categorization hierarchies. For example, if the body of shared meanings were of EU-Rent.s loyalty club, the .member. concept might start from club member or rental customer or driver or person or primate or mammal or animal or living thing or thing. Fundamental noun concepts are those that are not defined in terms of any other noun concepts in the model. They are defined in three ways: As implicitly understood from the terms used for them By adoption from external authorities Informally, within the body of shared meanings. If one BOSM is adopted into another, there may well be scoping issues. Sometimes these require: Redefining some noun concepts that were fundamental in one BOSM in terms of noun concepts defined in the other Introducing a common generalization for noun concepts that were fundamental in both BOSMs Recognizing the fundamental noun concepts in each model is the starting point for integrating the adopted BOSM into the adopting BOSM. Regards John Mark H Linehan wrote: Yes, I think it is a mistake to ask a community to rank its concepts. When that community needs to integrate its concepts with another community, the question of which categorizations are "fundamental" and which are not will get in the way. Better to just admit that there are multiple ways to conceptualize things without declaring that some are fundamental and some not. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com keri keri 03/21/2009 06:08 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: issue 13716 -- SBVR RTF issue On 3/21/09 10:34 AM, "Mark H Linehan" wrote: No, I am not interpreting "fundamental" as "universal". I am saying that a better way to treat "viewpoints" is just to have an alternative categorization. Rather than having a semantic community say "we pick this categorization as 'fundamental' and that other one as a 'viewpoint' " -- instead just have the semantic community define two categorizations. This approach will simplify semantic integration when two semantic communities -- each picking different fundamental conceptualizations -- get together. Instead of the two communities having to decide which categorization is *really* fundamental, they can just agree on as many categorizations as are needed. Mark, I am still not grasping your point. Let's set "viewpoint" aside for a minute and take things a step at a time . say we want to divide a community's concepts into 'fundamental concept' and 'not-fundamental concept'. Is this what you disagreeing with? Keri Subject: Re: issue 13716 -- SBVR RTF issue To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Mon, 23 Mar 2009 09:26:16 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 03/23/2009 09:26:20 Yes, but its not unusual that there can be multiple ways to organize the categorization hierarchies. The current SBVR scheme implies that some ways to organize the categorization hierarchies are "fundamental" and other ways are just "viewpoints" that define "facets". So it implies that some ways to organize the categorization hierarchies are more significant than others. This is not so bad if confined to a single semantic community. But I think it will generate unnecessary conflict when two semantic communities try to get together if they have chosen different categorization hierarchies. So my question is, rather than have "viewpoints" and "facets" why not simply provide for multiple categorization hierarchies? And then use "concept1 is coextensive with concept2" to say that two concepts from different hierarchies reference the same extensions. Then concept1 and concept2 are functtonally equivalent to two facets, and each categorization hierarchy is equivalent to a viewpoint. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com John Hall John Hall 03/22/2009 11:41 PM Please respond to john.hall@modelsys.com To Mark H Linehan/Watson/IBM@IBMUS cc SBVR RTF Subject Re: issue 13716 -- SBVR RTF issue Hello Mark, When a semantic community declares which noun concepts are fundamental it is defining the scope of its conceptual model. The fundamental noun concepts are those at the boundary, at the top of the categorization hierarchies. For example, if the body of shared meanings were of EU-Rent..s loyalty club, the ..member.. concept might start from club member or rental customer or driver or person or primate or mammal or animal or living thing or thing. Fundamental noun concepts are those that are not defined in terms of any other noun concepts in the model. They are defined in three ways: 1. As implicitly understood from the terms used for them 2. By adoption from external authorities 3. Informally, within the body of shared meanings. If one BOSM is adopted into another, there may well be scoping issues. Sometimes these require: 1. Redefining some noun concepts that were fundamental in one BOSM in terms of noun concepts defined in the other 2. Introducing a common generalization for noun concepts that were fundamental in both BOSMs Recognizing the fundamental noun concepts in each model is the starting point for integrating the adopted BOSM into the adopting BOSM. Regards John Mark H Linehan wrote: Yes, I think it is a mistake to ask a community to rank its concepts. When that community needs to integrate its concepts with another community, the question of which categorizations are "fundamental" and which are not will get in the way. Better to just admit that there are multiple ways to conceptualize things without declaring that some are fundamental and some not. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com keri keri 03/21/2009 06:08 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: issue 13716 -- SBVR RTF issue On 3/21/09 10:34 AM, "Mark H Linehan" wrote: No, I am not interpreting "fundamental" as "universal". I am saying that a better way to treat "viewpoints" is just to have an alternative categorization. Rather than having a semantic community say "we pick this categorization as 'fundamental' and that other one as a 'viewpoint' " -- instead just have the semantic community define two categorizations. This approach will simplify semantic integration when two semantic communities -- each picking different fundamental conceptualizations -- get together. Instead of the two communities having to decide which categorization is *really* fundamental, they can just agree on as many categorizations as are needed. Mark, I am still not grasping your point. Let's set "viewpoint" aside for a minute and take things a step at a time . say we want to divvide a community's concepts into 'fundamental concept' and 'not-fundamental concept'. Is this what you disagreeing with? Keri pic10113.gif X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 468850.35514.bm@omp403.mail.mud.yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1237820352; bh=y7x0CY1CY8KA2lM1Oz6X1jwJ+nmNz4ET7Bhool5iRZc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=us+qyrcXJ8NPQfFPnvGeGaP2rd2Z6JPtxfpnypSGzs9U8TKued4B/S2WRtUDDl6LA1jqQu+9mQhf1bKOiU53EYcp2JoC4fAaWiM1qwkNgOV4jYinCoSO1NtQT341cjgHO2QkUHUOe3sEKGReES3sarkDqP03RldZOmLt12b1W+Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=nIS2czXGcmPBh8mCfQ+CQFHIqdhG3w9NvP1Y8RNPAZ9duypH/viBk3KaweDhNJXesps2ekOhgQmn/S1ToUExpumJc6eE4L2Ms4ej2fx0IFIl9Hhu8okh1SIF8IBAHFZoCIH2cNeGSA/PG+zOqLdwSus7R1p9HHkxOGrVvUzwXtU=; X-YMail-OSG: q7YWf1QVM1lrxOvi7Ce3jzuDLYe0N7M3mdplIV5KR2Wrkn2JrgtOl0WKMHf_p.qi5nDWUtnWFalvw3ajiknh0ilwilinrhXotJNp4DMlSrgqRUz4bYpTS_Nmp9d94Yj.pIWtPQ0o8P4qbyVH8HKDrqwQLKNCUvI3Zo4KRIyDSiEYly3QLT5usQBFVP5i69JmKTDk97ZMB8fMF_0xltg5XwxmUcai6LdPfZf.RgihU1pmRXZnIf.J93Md.C0OQWpor8V0YO4aMi9dgQEcmL5dTvtJRhinQ1W. X-Mailer: YahooMailRC/1277.32 YahooMailWebService/0.7.289.1 Date: Mon, 23 Mar 2009 07:59:12 -0700 (PDT) From: Allan Kolber Subject: Re: issue 13716 -- SBVR RTF issue To: sbvr-rtf@omg.org Cc: Mark H Linehan , John Hall Yes, it will generate conflict, but not unnecesary conflict. In fact, it has been one of the most important values of the whole SBVR effort over the last 10 years that SBVR will provide a (or even "the") basic tool for doing that reconciliation and furthermore provides a tool for assisting in the merging of businesses, as in M&A activities. In fact, some enterprises don't realize that this effort is needed, thinking that they are from the same semantic community (e.g. same industry) when their semantic communities merely overlap. SBVR should help in pointing out the differences (by comparing the fundamentals) and justify the effort to prepare for a merger by first merging the semantics as found in their respective enterprise conceptual (i..e. semantic) data (and perhaps process and event) models. Allan B. Kolber 732-613-1538 (home) 732-672-3691 (cell) -------------------------------------------------------------------------------- From: Mark H Linehan To: sbvr-rtf@omg.org Sent: Monday, March 23, 2009 9:26:16 AM Subject: Re: issue 13716 -- SBVR RTF issue Yes, but its not unusual that there can be multiple ways to organize the categorization hierarchies. The current SBVR scheme implies that some ways to organize the categorization hierarchies are "fundamental" and other ways are just "viewpoints" that define "facets". So it implies that some ways to organize the categorization hierarchies are more significant than others. This is not so bad if confined to a single semantic community. But I think it will generate unnecessary conflict when two semantic communities try to get together if they have chosen different categorization hierarchies.. So my question is, rather than have "viewpoints" and "facets" why not simply provide for multiple categorization hierarchies? And then use "concept1 is coextensive with concept2" to say that two concepts from different hierarchies reference the same extensions. Then concept1 and concept2 are functtonally equivalent to two facets, and each categorization hierarchy is equivalent to a viewpoint. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com John Hall John Hall 03/22/2009 11:41 PM Please respond to john.hall@modelsys.com To Mark H Linehan/Watson/IBM@IBMUS cc SBVR RTF Subject Re: issue 13716 -- SBVR RTF issue Hello Mark, When a semantic community declares which noun concepts are fundamental it is defining the scope of its conceptual model. The fundamental noun concepts are those at the boundary, at the top of the categorization hierarchies. For example, if the body of shared meanings were of EU-Rent..s loyalty club, the ..member.. concept might start from club member or rental customer or driver or person or primate or mammal or animal or living thing or thing. Fundamental noun concepts are those that are not defined in terms of any other noun concepts in the model. They are defined in three ways: 1. As implicitly understood from the terms used for them 2. By adoption from external authorities 3. Informally, within the body of shared meanings. If one BOSM is adopted into another, there may well be scoping issues. Sometimes these require: 1. Redefining some noun concepts that were fundamental in one BOSM in terms of noun concepts defined in the other 2. Introducing a common generalization for noun concepts that were fundamental in both BOSMs Recognizing the fundamental noun concepts in each model is the starting point for integrating the adopted BOSM into the adopting BOSM. Regards John Mark H Linehan wrote: Yes, I think it is a mistake to ask a community to rank its concepts. When that community needs to integrate its concepts with another community, the question of which categorizations are "fundamental" and which are not will get in the way. Better to just admit that there are multiple ways to conceptualize things without declaring that some are fundamental and some not. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com keri keri 03/21/2009 06:08 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: issue 13716 -- SBVR RTF issue On 3/21/09 10:34 AM, "Mark H Linehan" wrote: No, I am not interpreting "fundamental" as "universal". I am saying that a better way to treat "viewpoints" is just to have an alternative categorization. Rather than having a semantic community say "we pick this categorization as 'fundamental' and that other one as a 'viewpoint' " -- instead just have the semantic community define two categorizations. This approach will simplify semantic integration when two semantic communities -- each picking different fundamental conceptualizations -- get together.. Instead of the two communities having to decide which categorization is *really* fundamental, they can just agree on as many categorizations as are needed. Mark, I am still not grasping your point. Let's set "viewpoint" aside for a minute and take things a step at a time . say we want to divide a community's cconcepts into 'fundamental concept' and 'not-fundamental concept'. Is this what you disagreeing with? Keri User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 23 Mar 2009 06:49:57 -1000 Subject: Re: issue 13716 -- SBVR RTF issue From: keri To: Mark H Linehan , SBVR RTF Thread-Topic: issue 13716 -- SBVR RTF issue Thread-Index: Acmr12W9pCMVmhfKEd6cUQARJM+Cgg== Hi, Mark, I thought John and Allan did a great job ... but it appears we are still not connecting. I see in your replies words like "ask a community to rank its concepts" and "organize the categorization hierarchies". This gives the wrong focus to what is happening in this sub-clause. Let's set aside looking at issues of forming some 'hierarchy' and refocus on the idea that, in this sub-clause, we are talking about making a kind of distinction we can make between two categories of concept. In numerous earlier exchanges I have cited the Sowa notions that most closely correspond to this kind of distinction: > ..."the types CAT, DOG, MAMMAL, and ANIMAL are natural types that > relate to the essence of the entities, > > but types like PET, PEDESTRIAN, and SPOUSE are role types that > depend on an accidental relationship to some other entity." In SBVR we happen to have settled on the terminology "fundamental" and "contextualized" for the former and latter notions (respectively) that Sowa talks about above. Closer to home, Terry also makes this kind of distinction, describing it as: > It seems to me that the main need is to distinguish between rigid types > (instances of a rigid type must remain in that type for their lifetime, > e.g. Person) and what I call "role types" (instances may enter or leave > a role type during their lifetime, e.g. Customer). I use "role type" > liberally to embrace not just ontological roles but also phases (e.g. > Child, Adult) etc. From memory, I think SBVR's "situational role" > corresponds at least roughly to what I call a role type. This does not say that the concepts termed "fundamental" are somehow more important to the semantic community, BTW. Perhaps the term "fundamental" is communicating a different sense that what's intended. Keri On 3/23/09 3:26 AM, "Mark H Linehan" wrote: Yes, but its not unusual that there can be multiple ways to organize the categorization hierarchies. The current SBVR scheme implies that some ways to organize the categorization hierarchies are "fundamental" and other ways are just "viewpoints" that define "facets". So it implies that some ways to organize the categorization hierarchies are more significant than others. This is not so bad if confined to a single semantic community. But I think it will generate unnecessary conflict when two semantic communities try to get together if they have chosen different categorization hierarchies. So my question is, rather than have "viewpoints" and "facets" why not simply provide for multiple categorization hierarchies? And then use "concept1 is coextensive with concept2" to say that two concepts from different hierarchies reference the same extensions. Then concept1 and concept2 are functtonally equivalent to two facets, and each categorization hierarchy is equivalent to a viewpoint. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com John Hall Subject Re: issue 13716 -- SBVR RTF issue Hello Mark, When a semantic community declares which noun concepts are fundamental it is defining the scope of its conceptual model. The fundamental noun concepts are those at the boundary, at the top of the categorization hierarchies. For example, if the body of shared meanings were of EU-Rent.s loyalty club, the .member. concept might start from club member or rental customer or driver or person or primate or mammal or animal or living thing or thing. Fundamental noun concepts are those that are not defined in terms of any other noun concepts in the model. They are defined in three ways: 1. As implicitly understood from the terms used for them 2. By adoption from external authorities 3. Informally, within the body of shared meanings. If one BOSM is adopted into another, there may well be scoping issues. Sometimes these require: 1. Redefining some noun concepts that were fundamental in one BOSM in terms of noun concepts defined in the other 2. Introducing a common generalization for noun concepts that were fundamental in both BOSMs Recognizing the fundamental noun concepts in each model is the starting point for integrating the adopted BOSM into the adopting BOSM. Regards John Mark H Linehan wrote: Yes, I think it is a mistake to ask a community to rank its concepts. When that community needs to integrate its concepts with another community, the question of which categorizations are "fundamental" and which are not will get in the way. Better to just admit that there are multiple ways to conceptualize things without declaring that some are fundamental and some not. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com keri keri 03/21/2009 06:08 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: issue 13716 -- SBVR RTF issue On 3/21/09 10:34 AM, "Mark H Linehan" wrote: No, I am not interpreting "fundamental" as "universal". I am saying that a better way to treat "viewpoints" is just to have an alternative categorization. Rather than having a semantic community say "we pick this categorization as 'fundamental' and that other one as a 'viewpoint' " -- instead just have the semantic community define two categorizations. This approach will simplify semantic integration when two semantic communities -- each picking different fundamental conceptualizations -- get together. Instead of the two communities having to decide which categorization is *really* fundamental, they can just agree on as many categorizations as are needed. Mark, I am still not grasping your point. Let's set "viewpoint" aside for a minute and take things a step at a time . say we want to divide a community's concepts into 'fundamental concept' and 'not-fundamental concept'. Is this what you disagreeing with? Keri User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 23 Mar 2009 06:59:55 -1000 Subject: Re: issue 13716 -- SBVR RTF issue From: keri To: Mark H Linehan , SBVR RTF Thread-Topic: issue 13716 -- SBVR RTF issue Thread-Index: Acmr2MosCKb5URfMEd6cUQARJM+Cgg== On 3/22/09 4:02 PM, "Mark H Linehan" wrote: I agree that the proposed definition says that: [a] fact type is [a] concept that is [a thing that] ... specializes the concept 'actuality' The problem with this definition is that it is not true. A fact type does not specialize the concept 'actuality'. And the definition does specify that a 'fact type' is a category of 'concept' (via the leading term in the Definition text), which corresponds to the diagram in 8.1: Let's take an example, the fact type "driver drives car", where 'driver' and 'car' are placeholders for roles of the same names, and 'drives' is the fact symbol. In this case, the fact type itself is the "concept" that is the "thing" referenced in the definition. What that latter phrase of the Definition text refers to is an instance of 'fact type' -- it is that instance of 'fact type' that is the thing that specializes the concept 'actuality'. So in your example it would be (say) Fred driving car9472 (an actuality) that instance is the 'thing' referenced in the definition, not the fact type itself. This thing is NOT a kind of actuality. An instance of the fact type -- where a particular driver and a particular car are specified -- would be an actuality. But the fact type itself is not an actuality. Take a look at the diagram at the start of clause 8.1. "Fact type" is NOT shown as a kind of "actuality" in this diagram. Agreed. What we show diagramatically is just the relationships from the lead terms (the generalization/specialization) -- we have not called on the diagramming conventions to also depict those 'necessary and sufficient characteristics" that distinguish some thing of the defined concept from other things of its more general concept. Keri -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com Subject: Re: issue 13716 -- SBVR RTF issue To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Mon, 23 Mar 2009 13:20:06 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 03/23/2009 13:20:12 Keri, I'm not objecting to the "role" kind of "contextualized concept". I think that's what John Sowa and Terry Halpin describe below, and I'm ok with that. I'm unhappy with the other kind of "contextualized concept", the "facet" kind. And the related idea of "viewpoint". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com keri keri 03/23/2009 12:49 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: issue 13716 -- SBVR RTF issue Hi, Mark, I thought John and Allan did a great job ... but it appears we are still not connecting. I see in your replies words like "ask a community to rank its concepts" and "organize the categorization hierarchies". This gives the wrong focus to what is happening in this sub-clause. Let's set aside looking at issues of forming some 'hierarchy' and refocus on the idea that, in this sub-clause, we are talking about making a kind of distinction we can make between two categories of concept. In numerous earlier exchanges I have cited the Sowa notions that most closely correspond to this kind of distinction: > ..."the types CAT, DOG, MAMMAL, and ANIMAL are natural types that > relate to the essence of the entities, > > but types like PET, PEDESTRIAN, and SPOUSE are role types that > depend on an accidental relationship to some other entity." In SBVR we happen to have settled on the terminology "fundamental" and "contextualized" for the former and latter notions (respectively) that Sowa talks about above. Closer to home, Terry also makes this kind of distinction, describing it as: > It seems to me that the main need is to distinguish between rigid types > (instances of a rigid type must remain in that type for their lifetime, > e.g. Person) and what I call "role types" (instances may enter or leave > a role type during their lifetime, e.g. Customer). I use "role type" > liberally to embrace not just ontological roles but also phases (e.g. > Child, Adult) etc. From memory, I think SBVR's "situational role" > corresponds at least roughly to what I call a role type. This does not say that the concepts termed "fundamental" are somehow more important to the semantic community, BTW. Perhaps the term "fundamental" is communicating a different sense that what's intended. Keri On 3/23/09 3:26 AM, "Mark H Linehan" wrote: Yes, but its not unusual that there can be multiple ways to organize the categorization hierarchies. The current SBVR scheme implies that some ways to organize the categorization hierarchies are "fundamental" and other ways are just "viewpoints" that define "facets". So it implies that some ways to organize the categorization hierarchies are more significant than others. This is not so bad if confined to a single semantic community. But I think it will generate unnecessary conflict when two semantic communities try to get together if they have chosen different categorization hierarchies. So my question is, rather than have "viewpoints" and "facets" why not simply provide for multiple categorization hierarchies? And then use "concept1 is coextensive with concept2" to say that two concepts from different hierarchies reference the same extensions. Then concept1 and concept2 are functtonally equivalent to two facets, and each categorization hierarchy is equivalent to a viewpoint. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com John Hall Subject Re: issue 13716 -- SBVR RTF issue Hello Mark, When a semantic community declares which noun concepts are fundamental it is defining the scope of its conceptual model. The fundamental noun concepts are those at the boundary, at the top of the categorization hierarchies. For example, if the body of shared meanings were of EU-Rent..s loyalty club, the ..member.. concept might start from club member or rental customer or driver or person or primate or mammal or animal or living thing or thing. Fundamental noun concepts are those that are not defined in terms of any other noun concepts in the model. They are defined in three ways: 1. As implicitly understood from the terms used for them 2. By adoption from external authorities 3. Informally, within the body of shared meanings. If one BOSM is adopted into another, there may well be scoping issues. Sometimes these require: 1. Redefining some noun concepts that were fundamental in one BOSM in terms of noun concepts defined in the other 2. Introducing a common generalization for noun concepts that were fundamental in both BOSMs Recognizing the fundamental noun concepts in each model is the starting point for integrating the adopted BOSM into the adopting BOSM. Regards John Mark H Linehan wrote: Yes, I think it is a mistake to ask a community to rank its concepts. When that community needs to integrate its concepts with another community, the question of which categorizations are "fundamental" and which are not will get in the way. Better to just admit that there are multiple ways to conceptualize things without declaring that some are fundamental and some not. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com keri keri 03/21/2009 06:08 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: issue 13716 -- SBVR RTF issue On 3/21/09 10:34 AM, "Mark H Linehan" wrote: No, I am not interpreting "fundamental" as "universal". I am saying that a better way to treat "viewpoints" is just to have an alternative categorization. Rather than having a semantic community say "we pick this categorization as 'fundamental' and that other one as a 'viewpoint' " -- instead just have the semantic community define two categorizations. This approach will simplify semantic integration when two semantic communities -- each picking different fundamental conceptualizations -- get together. Instead of the two communities having to decide which categorization is *really* fundamental, they can just agree on as many categorizations as are needed. Mark, I am still not grasping your point. Let's set "viewpoint" aside for a minute and take things a step at a time . say we want to divide a communitty's concepts into 'fundamental concept' and 'not-fundamental concept'. Is this what you disagreeing with? Keri pic12767.gif Subject: Re: issue 13716 -- SBVR RTF issue To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Mon, 23 Mar 2009 13:40:49 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 03/23/2009 13:40:54 Keri, Clearly we are reading the same words differently. Here is the proposed definition of 'fact type' from the last version of 13716 that you distributed: concept that is the meaning of a verb phrase that involves one or more noun concepts and that specializes the concept ..actuality.. I read this to mean that a fact type both (a) is a concept that is the meaning of a verb phrase (etc); and (b) specializes the concept 'actuality'. For me, the thing "that specializes ..." is the "concept" mentioned at the start of the definition. Somehow, you understand "... and that specializes ..." as referring to the instances of the fact type, rather than referring to the fact type itself (??) A suggestion: how about splitting "and that specializes the concept 'actuality' " into a separate Necessity that can use the original wording. Something like: Definition: concept that is the meaning of a verb phrase that involves one or more noun concepts Necessity: Each instance of each fact type is a state of affairs. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com keri keri 03/23/2009 12:59 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: issue 13716 -- SBVR RTF issue On 3/22/09 4:02 PM, "Mark H Linehan" wrote: I agree that the proposed definition says that: [a] fact type is [a] concept that is [a thing that] ... specializes the concept 'actuality' The problem with this definition is that it is not true. A fact type does not specialize the concept 'actuality'. And the definition does specify that a 'fact type' is a category of 'concept' (via the leading term in the Definition text), which corresponds to the diagram in 8.1: Let's take an example, the fact type "driver drives car", where 'driver' and 'car' are placeholders for roles of the same names, and 'drives' is the fact symbol. In this case, the fact type itself is the "concept" that is the "thing" referenced in the definition. What that latter phrase of the Definition text refers to is an instance of 'fact type' -- it is that instance of 'fact type' that is the thing that specializes the concept 'actuality'. So in your example it would be (say) Fred driving car9472 (an actuality) that instance is the 'thing' referenced in the definition, not the fact type itself. This thing is NOT a kind of actuality. An instance of the fact type -- where a particular driver and a particular car are specified -- would be an actuality. But the fact type itself is not an actuality. Take a look at the diagram at the start of clause 8.1. "Fact type" is NOT shown as a kind of "actuality" in this diagram. Agreed. What we show diagramatically is just the relationships from the lead terms (the generalization/specialization) -- we have not called on the diagramming conventions to also depict those 'necessary and sufficient characteristics" that distinguish some thing of the defined concept from other things of its more general concept. Keri -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com pic16838.gif User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 23 Mar 2009 07:55:23 -1000 Subject: Re: issue 13716 -- SBVR RTF issue From: keri To: Mark H Linehan , SBVR RTF Thread-Topic: issue 13716 -- SBVR RTF issue Thread-Index: Acmr4InRyKg2qBfTEd6cUQARJM+Cgg== On 3/23/09 7:20 AM, "Mark H Linehan" wrote: I'm not objecting to the "role" kind of "contextualized concept". I think that's what John Sowa and Terry Halpin describe below, and I'm ok with that. Ah, that's good to establish. So we're on track up to the point where "contextualized concept" is then further specialized (into 'role' and 'facet'). I'm unhappy with the other kind of "contextualized concept", the "facet" kind. And the related idea of "viewpoint". Yes, I do understand that this notion (facet/aspect) is less well exposed in the U.S. arena. But in Europe it does have some following. I can share my VERY informal, personal way of visualizing these notions: if you imagine a 'table' (column/row stuff) then you can picture 'role' as talking about a row-wise sliver and facet/aspect as talking about a column-wise sliver. (And if that's a less than helpful visual, feel free to ignore what I've written.) But, bottom line, if your practice does not want to consider facet/aspect then you can simply ignore it . stop at 'contextualized concept' (and deal only with 'role'). The main distinction being made in this sub-section is that we have concepts that are 'contextualized' and other that are simply 'fundamental'. That 'contextualized' has flavors (and, possibly, even more that might emerge someday) is a tip of the hat to the communities that need them. Keri User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 23 Mar 2009 08:55:54 -1000 Subject: Re: issue 13716 -- SBVR RTF issue From: keri To: Mark H Linehan , SBVR RTF Thread-Topic: issue 13716 -- SBVR RTF issue Thread-Index: Acmr6P4QPHywLBfcEd6cUQARJM+Cgg== Yes, we appear to be reading this differently. I am breaking the words at the "and" and interpreting the text, as follows, according to what is explained in Annex C: (1) each instance of fact type is an instance of concept . an instance of concept that is the meaning of a verb phrase that involves one or more noun concepts (as distinguished from the other instances of concept that are not that) and (2) each instance of fact type is an instance of concept . an instance of concept that specializes the concept .actuality. (as distinguished from the other instances of concept that do not) As for your "somehow" below . yes, in that any definition of an object type is (ultimately) talking about some 'typical' instance of the defined concept and how that instance can be distinguished from other instances of the defined concept's more general concept, in terms of the "necessary and sufficient characteristics that distinguish a thing of the defined concept from other things of the more general concept." IOW, I am simply allocating the pieces of the Definition text according to the pattern explained in C.3.2.1. (Whether the actual words then make sense is a different matter.) As for whether or not we can split (2) out as a Necessity ... we are told that to do this, it must "follow" from the Definition. So, I don't know. I liked your earlier question that asked whether simply having (1) was enough. It would be easier on the ears/brain. I am suspecting that we can't stop with (1) but I have to leave it to others to explain why not. Keri On 3/23/09 7:40 AM, "Mark H Linehan" wrote: Keri, Clearly we are reading the same words differently. Here is the proposed definition of 'fact type' from the last version of 13716 that you distributed: concept that is the meaning of a verb phrase that involves one or more noun concepts and that specializes the concept .actuality. I read this to mean that a fact type both (a) is a concept that is the meaning of a verb phrase (etc); and (b) specializes the concept 'actuality'. For me, the thing "that specializes ..." is the "concept" mentioned at the start of the definition. Somehow, you understand "... and that specializes ..." as referring to the instances of the fact type, rather than referring to the fact type itself (??) A suggestion: how about splitting "and that specializes the concept 'actuality' " into a separate Necessity that can use the original wording. Something like: Definition: concept that is the meaning of a verb phrase that involves one or more noun concepts Necessity: Each instance of each fact type is a state of affairs. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research Subject: Re: issue 13716 -- SBVR RTF issue To: SBVR RTF X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Mon, 23 Mar 2009 17:16:12 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 03/23/2009 17:16:16 Keri, Reading C.3.2.1, I don't see where you get the idea that the proposed definition has anything to do with "instance". Neither the proposed definition nor C.3.2.1 mention "instance". C.3.2.1 does give the following guideline: A definition of an object type can generally be read as a statement using the following pattern (where ..a. represents either ..a. or ..an.): A is a . So we can read the proposed definition as "A fact type is a concept that is the meaning of a verb phrase that involves one or more noun concepts and that specializes the concept ..actuality..." I think this clearly is applying "concept1 specializes concept2" twice. In one case, it says "concept 'fact type' specializes concept 'concept' " and in the second case it says "concept 'fact type' specializes concept 'actuality' ". The second part is wrong. I found that the Necessity that I propose actually already exists in clause 8.6.2, "Necessities Concerning Extension". It's the 3rd in that list. Except that it claims every instance of a fact type is an "actuality", whereas I would say every instance is a "state of affairs". But, ignoring that issue, the existence of that Necessity supports the idea of just dropping the second part of the definition of "fact type". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com keri keri 03/23/2009 02:55 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: issue 13716 -- SBVR RTF issue Yes, we appear to be reading this differently. I am breaking the words at the "and" and interpreting the text, as follows, according to what is explained in Annex C: (1) each instance of fact type is an instance of concept . an instance of concept that is the meaning of a vverb phrase that involves one or more noun concepts (as distinguished from the other instances of concept that are not that) and (2) each instance of fact type is an instance of concept . an instance of concept that sspecializes the concept ..actuality.. (as distinguished from the other instances of concept that do not) As for your "somehow" below . yes, in that any definiition of an object type is (ultimately) talking about some 'typical' instance of the defined concept and how that instance can be distinguished from other instances of the defined concept's more general concept, in terms of the "necessary and sufficient characteristics that distinguish a thing of the defined concept from other things of the more general concept." IOW, I am simply allocating the pieces of the Definition text according to the pattern explained in C.3.2.1. (Whether the actual words then make sense is a different matter.) As for whether or not we can split (2) out as a Necessity ... we are told that to do this, it must "follow" from the Definition. So, I don't know. I liked your earlier question that asked whether simply having (1) was enough. It would be easier on the ears/brain. I am suspecting that we can't stop with (1) but I have to leave it to others to explain why not. Keri On 3/23/09 7:40 AM, "Mark H Linehan" wrote: Keri, Clearly we are reading the same words differently. Here is the proposed definition of 'fact type' from the last version of 13716 that you distributed: concept that is the meaning of a verb phrase that involves one or more noun concepts and that specializes the concept ..actuality.. I read this to mean that a fact type both (a) is a concept that is the meaning of a verb phrase (etc); and (b) specializes the concept 'actuality'. For me, the thing "that specializes ..." is the "concept" mentioned at the start of the definition. Somehow, you understand "... and that specializes ..." as referring to the instances of the fact type, rather than referring to the fact type itself (??) A suggestion: how about splitting "and that specializes the concept 'actuality' " into a separate Necessity that can use the original wording. Something like: Definition: concept that is the meaning of a verb phrase that involves one or more noun concepts Necessity: Each instance of each fact type is a state of affairs. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research pic057583.gif User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 23 Mar 2009 12:35:00 -1000 Subject: Re: issue 13716 -- SBVR RTF issue From: keri To: Mark H Linehan , SBVR RTF Thread-Topic: issue 13716 -- SBVR RTF issue Thread-Index: AcmsB5mw2CWm0hf6Ed6N3QARJM+Cgg== On 3/23/09 11:16 AM, "Mark H Linehan" wrote: Reading C.3.2.1, I don't see where you get the idea that the proposed definition has anything to do with "instance". Neither the proposed definition nor C.3.2.1 mention "instance". C.3.2.1 does give the following guideline: A definition of an object type can generally be read as a statement using the following pattern (where .a. represents either .a. or .an.): A is a . Ah, but it does talk about 'instance' (albeit indirectly) because I see that it says "a " . so I know that we are talking about "a fact type" (not about "the concept 'fact type'"). Whenever we say "a fact type" we are referring to a generic individual in the population of the concept being defined. If I say "a rental car" I am envisioning some actual rental car, not the concept. When I say "a fact type" I am thinking about some actual fact type, not the concept 'fact type'. The Annex C discussion of keywords says that "a" is for universal quantification or existential quantification, so I personally vocalize "a" as "each" when I'm composing a definition. For some thing to be in the concept's population, I'll be applying the "does this thing have the necessary and sufficient characteristics?" test to each candidate thing, not just to some candidate thing. IAC, when we see "a" in front of a concept term, we understand that it's talking about an instance of that concept. Keri So we can read the proposed definition as "A fact type is a concept that is the meaning of a verb phrase that involves one or more noun concepts and that specializes the concept .actuality.." I think this clearly is applying "concept1 specializes concept2" twice. In one case, it says "concept 'fact type' specializes concept 'concept' " and in the second case it says "concept 'fact type' specializes concept 'actuality' ". The second part is wrong. I found that the Necessity that I propose actually already exists in clause 8.6.2, "Necessities Concerning Extension". It's the 3rd in that list. Except that it claims every instance of a fact type is an "actuality", whereas I would say every instance is a "state of affairs". But, ignoring that issue, the existence of that Necessity supports the idea of just dropping the second part of the definition of "fact type". Subject: Re: issue 13716 -- SBVR RTF issue To: SBVR RTF X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Mon, 23 Mar 2009 22:07:46 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 03/23/2009 22:07:50 Given what Annex C says about the article 'a', isn't it just as reasonable to read "A ..." as "Each keri 03/23/2009 06:35 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: issue 13716 -- SBVR RTF issue On 3/23/09 11:16 AM, "Mark H Linehan" wrote: Reading C.3.2.1, I don't see where you get the idea that the proposed definition has anything to do with "instance". Neither the proposed definition nor C.3.2.1 mention "instance". C.3.2.1 does give the following guideline: A definition of an object type can generally be read as a statement using the following pattern (where ..a. represents either ..a. or ..an.): A is a . Ah, but it does talk about 'instance' (albeit indirectly) because I see that it says "a " . so I know that we are talkingg about "a fact type" (not about "the concept 'fact type'"). Whenever we say "a fact type" we are referring to a generic individual in the population of the concept being defined. If I say "a rental car" I am envisioning some actual rental car, not the concept. When I say "a fact type" I am thinking about some actual fact type, not the concept 'fact type'. The Annex C discussion of keywords says that "a" is for universal quantification or existential quantification, so I personally vocalize "a" as "each" when I'm composing a definition. For some thing to be in the concept's population, I'll be applying the "does this thing have the necessary and sufficient characteristics?" test to each candidate thing, not just to some candidate thing. IAC, when we see "a" in front of a concept term, we understand that it's talking about an instance of that concept. Keri So we can read the proposed definition as "A fact type is a concept that is the meaning of a verb phrase that involves one or more noun concepts and that specializes the concept ..actuality..." I think this clearly is applying "concept1 specializes concept2" twice. In one case, it says "concept 'fact type' specializes concept 'concept' " and in the second case it says "concept 'fact type' specializes concept 'actuality' ". The second part is wrong. I found that the Necessity that I propose actually already exists in clause 8.6.2, "Necessities Concerning Extension". It's the 3rd in that list. Except that it claims every instance of a fact type is an "actuality", whereas I would say every instance is a "state of affairs". But, ignoring that issue, the existence of that Necessity supports the idea of just dropping the second part of the definition of "fact type". pic175154.gif From: Don Baisley To: "sbvr-rtf@omg.org" Date: Mon, 23 Mar 2009 19:18:45 -0700 Subject: RE: issue 13716 -- SBVR RTF issue Thread-Topic: issue 13716 -- SBVR RTF issue Thread-Index: Acmr3xpjWbfpaVJCS52C36gfhq1ynwAQ40YA Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Hi Mark and Keri, You seem to be saying the same thing, but differently. As Mark says: > I read this to mean that a fact type both (a) is a concept that is the meaning of > a verb phrase (etc); and (b) specializes the concept 'actuality'. For me, the thing > "that specializes ..." is the "concept" mentioned at the start of the definition. Mark is correct. Every fact type is a concept that specializes the concept .actuality.. Because every fact type specializes the concept .actuality., we know every instance of every fact type is an actuality. Keri is saying the same thing, but using different words: that instances of the concept .fact type. (each fact type) specializes the concept .actuality.. For any .x. I avoid saying, .an instance of the concept .x.., because it means the same thing as saying .an x.. Mark suggests that the condition of specializing the concept .actuality. can be removed from the definition and put into a Necessity statement. That is true if we can prove from the remaining part of the definition that every fact type specializes the concept .actuality.. I will leave such a proof to others. I.m not so sure. Nondeclarative verb phrases might give us troubles for such a proof. In any case, changing the definition of .fact type. to be in terms of specializing rather than being in terms of the instances of its instances is a good change. Consider a similar case: If we said that a concept was a branch type if all of its instances are EU-Rent branches, then a general concept defined as .positive number less than zero. would be a branch type (all zero of its instances are EU-Rent branches). But that.s nonsense. The definition of a concept .branch type. should include the condition of specializing the concept .EU-Rent branch.. Best regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Monday, March 23, 2009 10:41 AM To: sbvr-rtf@omg.org Subject: Re: issue 13716 -- SBVR RTF issue Keri, Clearly we are reading the same words differently. Here is the proposed definition of 'fact type' from the last version of 13716 that you distributed: concept that is the meaning of a verb phrase that involves one or more noun concepts and that specializes the concept .actuality. I read this to mean that a fact type both (a) is a concept that is the meaning of a verb phrase (etc); and (b) specializes the concept 'actuality'. For me, the thing "that specializes ..." is the "concept" mentioned at the start of the definition. Somehow, you understand "... and that specializes ..." as referring to the instances of the fact type, rather than referring to the fact type itself (??) A suggestion: how about splitting "and that specializes the concept 'actuality' " into a separate Necessity that can use the original wording. Something like: Definition: concept that is the meaning of a verb phrase that involves one or more noun concepts Necessity: Each instance of each fact type is a state of affairs. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com keri keri 03/23/2009 12:59 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: issue 13716 -- SBVR RTF issue On 3/22/09 4:02 PM, "Mark H Linehan" wrote: I agree that the proposed definition says that: [a] fact type is [a] concept that is [a thing that] ... specializes the concept 'actuality' The problem with this definition is that it is not true. A fact type does not specialize the concept 'actuality'. And the definition does specify that a 'fact type' is a category of 'concept' (via the leading term in the Definition text), which corresponds to the diagram in 8.1: Let's take an example, the fact type "driver drives car", where 'driver' and 'car' are placeholders for roles of the same names, and 'drives' is the fact symbol. In this case, the fact type itself is the "concept" that is the "thing" referenced in the definition. What that latter phrase of the Definition text refers to is an instance of 'fact type' -- it is that instance of 'fact type' that is the thing that specializes the concept 'actuality'. So in your example it would be (say) Fred driving car9472 (an actuality) that instance is the 'thing' referenced in the definition, not the fact type itself. This thing is NOT a kind of actuality. An instance of the fact type -- where a particular driver and a particular car are specified -- would be an actuality. But the fact type itself is not an actuality. Take a look at the diagram at the start of clause 8.1. "Fact type" is NOT shown as a kind of "actuality" in this diagram. Agreed. What we show diagramatically is just the relationships from the lead terms (the generalization/specialization) -- we have not called on the diagramming conventions to also depict those 'necessary and sufficient characteristics" that distinguish some thing of the defined concept from other things of its more general concept. Keri -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 24 Mar 2009 06:33:34 -1000 Subject: Re: (offline) RE: issue 13716 -- SBVR RTF issue From: keri To: Mark H Linehan , SBVR RTF Thread-Topic: (offline) RE: issue 13716 -- SBVR RTF issue Thread-Index: AcmsnkY9hJE/zxiREd67vQARJM+Cgg== On 3/24/09 1:58 AM, "Mark H Linehan" wrote: ... Don says "Every fact type is a concept that specializes the concept .actuality.." If this is really true, then we should modify figure 8.1 to show that a fact type is a subtype of an actuality. Don's reply reminded me that this wording is one of the "patterns" of expression that is explained in Annex D. See p. 275 (sub-section D.2.5). In the example shown there (for 'branch type' and 'branch'), this pattern of expression does not mean that the concept 'branch type' is a subtype of 'branch'. But, yes, a branch type (i.e., each of its instances) is. Put the wording for 'fact type' into the pattern and explanation of D.2.5 and it should help you see what is going on. BTW, this pattern of "a xxx is a yyy that specializes the concept 'zzz'." is used over twenty times in the SBVR document. Looking through those might also help. Keri Subject: RE: issue 13716 -- SBVR RTF issue To: SBVR RTF X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Tue, 24 Mar 2009 13:29:23 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 03/24/2009 13:29:27 D.2.5 is about categorization types. It is not relevant to object types, such as "fact type". I quote below the following "Commentary" from D.2.5: Commentary: When you find this pattern -- a ..Definition.. caption that begins, concept that specializes the concept ..other-concept.. and that classifies an other-concept based on... -- it is a compact, textual way to say multiple things, as follows: 1. that the mentioned other-concept has categories for which the other-concept is the more general concept, and 2. that the entry being defined is itself a category of concept, one whose instances are the categories of the mentioned more general concept. Furthermore, the vocabulary entries for the certain category include a ..Concept Type:.. caption that mentions the categorization type. For example, the vocabulary entry for ..city branch.. mentions ..branch type.. as its Concept Type. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com keri keri 03/24/2009 12:33 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: (offline) RE: issue 13716 -- SBVR RTF issue On 3/24/09 1:58 AM, "Mark H Linehan" wrote: ... Don says "Every fact type is a concept that specializes the concept ..actuality..." If this is really true, then we should modify figure 8.1 to show that a fact type is a subtype of an actuality. Don's reply reminded me that this wording is one of the "patterns" of expression that is explained in Annex D. See p. 275 (sub-section D.2.5). In the example shown there (for 'branch type' and 'branch'), this pattern of expression does not mean that the concept 'branch type' is a subtype of 'branch'. But, yes, a branch type (i.e., each of its instances) is. Put the wording for 'fact type' into the pattern and explanation of D.2.5 and it should help you see what is going on. BTW, this pattern of "a xxx is a yyy that specializes the concept 'zzz'." is used over twenty times in the SBVR document. Looking through those might also help. Keri pic310512.gif User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 24 Mar 2009 07:46:49 -1000 Subject: Re: issue 13716 -- SBVR RTF issue From: keri To: Mark H Linehan , SBVR RTF Thread-Topic: issue 13716 -- SBVR RTF issue Thread-Index: AcmsqIHdwIDUVhibEd67vQARJM+Cgg== On 3/24/09 7:29 AM, "Mark H Linehan" wrote: D.2.5 is about categorization types. It is not relevant to object types, such as "fact type". A categorization type is a concept type . and the entry for 'fact type' includes the caption Concept type: concept type so the general understanding does still apply for fact type ... i.e., how to interpret "xxx that specializes the concept 'yyy'" when you come across it. Keri PS . Note that we are currently making changes to some of the wording in D.2 (under Issue 12589 . Ballot 1). I quote below the following "Commentary" from D.2.5: Commentary: When you find this pattern -- a .Definition. caption that begins, concept that specializes the concept .other-concept. and that classifies an other-concept based on... -- it is a compact, textual way to say multiple things, as follows: 1. that the mentioned other-concept has categories for which the other-concept is the more general concept, and 2. that the entry being defined is itself a category of concept, one whose instances are the categories of the mentioned more general concept. Furthermore, the vocabulary entries for the certain category include a .Concept Type:. caption that mentions the categorization type. For example, the vocabulary entry for .city branch. mentions .branch type. as its Concept Type. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 02 Apr 2009 13:02:52 -1000 Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting From: keri To: "Donald R. Chapin" , SBVR RTF Thread-Topic: issue 13716 -- SBVR RTF issue - updated from today's meeting Thread-Index: AcmqcYNwwhwKvBZkEd6JWAARJM+CggDKI0NFAJUF2FAA/j+jmQ== All, It was pointed out to me that I missed a change agreed in the meeting. It calls for one more change to the Definition of 'fact type': to change the end so that it says "roles" rather than "noun concepts". Is that right? (If I hear no objections I will make the fix and re-issue the document ... say, this weekend.) - Keri From: keri [mailto:keri_ah@mac.com] Sent: Wednesday, March 25, 2009 3:36 PM To: Donald R. Chapin; SBVR RTF Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting Attached is the updated Resolution document (along with a view of the resulting 11.1.5 subsection). These reflect the three points we discussed and agreed for this Issue in today's meeting, namely: Adding a summary statement clarifying why this has the nature of a 'fix'. Restoring the "Thing in Context" segmentation (to be addressed in a later issue) Revising the wording of the Definition of 'fact type' In restoring the 'Thing in Context' segmentation I could not find that we ever had a Necessity that specifies what the Figure depicts, so by doing the 'restore' called for in the second bullet we are left with an inconsistency that the 1.0 document currently has between the diagram and the text. If we want to correct this as part of this Resolution, we need to either add a Necessity or remove the Segmentation. Keri Date: Thu, 02 Apr 2009 19:10:58 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: keri CC: SBVR RTF Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n32NB4Gu004703 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1239318668.09845@oA++ZwbMChKsfgr4vQtZ7A X-Spam-Status: No keri wrote: Attached is the updated Resolution document (along with a view of the resulting 11.1.5 subsection). These reflect the three points we discussed and agreed for this Issue in today's meeting, namely: 1. Adding a summary statement clarifying why this has the nature of a 'fix'. 2. Restoring the "Thing in Context" segmentation (to be addressed in a later issue) 3. Revising the wording of the Definition of 'fact type' This is a significant improvement, but I have two remaining complaints: (1) 'fundamental concept' As the original issue points out, some of the definitions were incomprehensible. The definition of 'fundamental concept' still is: Definition: general concept whose real-world individuals are perceived by a given semantic community as being in their essence, apart from any situation in which they are involved or viewpoint from which they are considered I don't know what is meant by "individuals perceived as in their essence" means (I have an image of pigs in a wallow ). And "real world" is not a requirement; unicorns also have an 'essence'. The Dictionary Basis is *much* better: "a property or group of properties of something without which it would not exist or be what it is" I suggest that we replace the Definition of 'fundamental concept' with something more like the NODE definition, e.g.: Definition: general concept that includes only characteristics of a thing without which the thing would not exist or be what it is. It follows from this definition that the properties that characterize a fundamental concept are "intrinsic" in the thing itself. They cannot be assumed, and they cannot be lost or modified without destroying the nature/essence of the thing. The definition John Hall gave is very different: "Fundamental noun concepts are those that are not defined in terms of any other noun concepts in the model." If John's definition is correct, it has to do with how the concept is defined in the vocabulary, not what the nature of the properties is. (John's definition is what a mathematician would call an "undefined term", or a "primitive".) In particular, 'fundamental concept' per the NODE definition would include "woman", defined as "person that is female and is adult", where "person" is a defined concept. But John's definition would not. So you guys need to get your story straight. (I like the NODE definition.) (2) 'facet' The proposed definition reads: Definition: concept that generalizes a concept but incorporates only those characteristics that are relevant to a particular viewpoint I read this to say that a 'is facet of' is a relationship between two concepts, and 'facet' is a role in that relationship. The fact type form might be: 'facet (concept)' is facet of 'base concept'", or equivalently, 'concept1 is facet of concept2', which is a synonymous form for 'concept has facet'. Following this, the example: "rental car has facet 'asset'" makes sense. But if facet were intended to be an object type with that definition, it should mean that the concept 'asset' is derived from 'rental car' by discarding irrelevant concerns. And that is utterly false. When accountants devised the concept 'asset', they probably didn't start with rental cars. An asset is a category of things that are characterized by having negotiable value. It is not derived from any other category. So I suggest first that we make 'facet' Concept type: role. Keep the definition but add two words, so that it reads: general concept that generalizes a given concept but incorporates only those characteristics that are relevant to a particular viewpoint And second, I repeat Mark's observation that you cannot distinguish this characterization from any other categorization. Every more general category discards some characteristics, namely those that are irrelevant to the definition of that category. Further, a "role type" always incorporates at least one "accidental" characteristic -- one that is not intrinsic to the nature of the thing -- namely, the characteristic that relates the thing to the "situation". In that way, "situational role" clearly differs from "fundamental concept". By comparison, an aspect/facet need not include any accidental properties -- it is the nature of some things to exhibit certain facets. An aspect ("facet") is a set of properties assigned to a thing, some of which are intrinsic, or "otherwise extrinsic", and determine its relevance, and some of which are imposed on it by its participation in the class. So, for example, an 'asset' is anything owned by the business that has negotiable (sale/salvage) value. And 'depreciated value' is an accounting property that is imposed on assets. A rental car has a 'depreciated value' because it is considered an 'asset'. As noted, because an aspect/facet can be defined by a set of intrinsic or extrinsic properties, it can't be distinguished from fundamental concepts and situational roles. Its instances could be either, or neither. It just depends on what characteristics are chosen. And it isn't a requirement that an aspect/facet impose additional properties on the things, but it may well be that imposing additional properties is the only reason a business would create a "facet". So I hold with Mark that a facet is just a general concept that a community has slapped a label on. (3) 'contextualization concept'? From the above, it is not clear to me that 'contextualization concept' is anything more than a bag of apples and alleycats. Situation role is an object type; facet is a role in a particular fact type, and the things that play that role are "general concepts". So I don't see how they are part of any templating concept. -Ed "Poor naming leads to obscured concepts, Obscured concepts lead to failure." -- Confucius, c. 500 BC -- 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." User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 02 Apr 2009 15:45:25 -1000 Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting From: keri To: Ed Barkmeyer CC: SBVR RTF Thread-Topic: issue 13716 -- SBVR RTF issue - updated from today's meeting Thread-Index: Acmz/dumGitxRB/xEd6z+gARJM+Cgg== Ed, One way I was taught to understand 'facet' was as akin to a 'view' of (back in the day) an entity (or, if you prefer, entity type). So, for example, if the entity 'car' has a total of 20 characteristics that are of interest to EU-Rent, there might be only 5 of those that are relevant to the viewpoint of accounting -- so they focus on just that aspect/facet of car because their perspective is to view the car in its 'asset-ness'. Some other perspective might have a view of a different sub-set of a car's characteristics -- that would be a different facet of car, from a different viewpoint. Keri On 4/2/09 1:10 PM, "Ed Barkmeyer" wrote: > (2) 'facet' > > The proposed definition reads: > Definition: concept that generalizes a concept but incorporates only > those characteristics that are relevant to a particular viewpoint > > I read this to say that a 'is facet of' is a relationship between two > concepts, and 'facet' is a role in that relationship. The fact type > form might be: 'facet (concept)' is facet of 'base concept'", > or equivalently, 'concept1 is facet of concept2', which is a synonymous > form for 'concept has facet'. > > Following this, the example: "rental car has facet 'asset'" makes sense. > > But if facet were intended to be an object type with that definition, it > should mean that the concept 'asset' is derived from 'rental car' by > discarding irrelevant concerns. And that is utterly false. When > accountants devised the concept 'asset', they probably didn't start with > rental cars. An asset is a category of things that are characterized by > having negotiable value. It is not derived from any other category. > > So I suggest first that we make 'facet' Concept type: role. Keep the > definition but add two words, so that it reads: > general concept that generalizes a given concept but incorporates > only those characteristics that are relevant to a particular viewpoint > > And second, I repeat Mark's observation that you cannot distinguish this > characterization from any other categorization. Every more general > category discards some characteristics, namely those that are irrelevant > to the definition of that category. > > Further, a "role type" always incorporates at least one "accidental" > characteristic -- one that is not intrinsic to the nature of the thing > -- namely, the characteristic that relates the thing to the "situation". > In that way, "situational role" clearly differs from "fundamental > concept". By comparison, an aspect/facet need not include any > accidental properties -- it is the nature of some things to exhibit > certain facets. > > An aspect ("facet") is a set of properties assigned to a thing, some of > which are intrinsic, or "otherwise extrinsic", and determine its > relevance, and some of which are imposed on it by its participation in > the class. So, for example, an 'asset' is anything owned by the > business that has negotiable (sale/salvage) value. And 'depreciated > value' is an accounting property that is imposed on assets. A rental > car has a 'depreciated value' because it is considered an 'asset'. > > As noted, because an aspect/facet can be defined by a set of intrinsic > or extrinsic properties, it can't be distinguished from fundamental > concepts and situational roles. Its instances could be either, or > neither. It just depends on what characteristics are chosen. And it > isn't a requirement that an aspect/facet impose additional properties on > the things, but it may well be that imposing additional properties is > the only reason a business would create a "facet". So I hold with Mark > that a facet is just a general concept that a community has slapped a > label on. Date: Fri, 03 Apr 2009 13:05:12 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: keri CC: SBVR RTF Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n33H5Iiu014796 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1239383120.11436@Fe5fzY11psOhZzmgJSIBLg X-Spam-Status: No keri wrote: One way I was taught to understand 'facet' was as akin to a 'view' of (back in the day) an entity (or, if you prefer, entity type). So, for example, if the entity 'car' has a total of 20 characteristics that are of interest to EU-Rent, there might be only 5 of those that are relevant to the viewpoint of accounting -- so they focus on just that aspect/facet of car because their perspective is to view the car in its 'asset-ness'. Some other perspective might have a view of a different sub-set of a car's characteristics -- that would be a different facet of car, from a different viewpoint. I completely agree. IMO, an "aspect" is a set of characteristics that are significant to a particular viewpoint. (And I won't complain about using "facet" as a synonym for "aspect".) But that is *not* the existing/proposed definition. The proposed definition reads: Definition: concept that generalizes a concept but incorporates only those characteristics that are relevant to a particular viewpoint It is the "generalizes a (given) concept" stuff that seems to make "facet" a role. (I took the "facet" concept to be the characteristics that were given in the definition, not what I thought the term might have meant, or should have meant.) If the intent is what Keri says, I suggest striking "generalizes a concept but". Then the definition would read: a concept defined by a set of characteristics (of things) that are significant to a particular viewpoint. But, as Mark pointed out, _most_ classifiers identify only the characteristics that are important to some viewpoint. The idea that you can talk about the "essence" of something without having a viewpoint is suspect, to say the least. And Allan's point was that mergers often reveal the ingrained preference of organizations to treat different viewpoints as "fundamental". (We used to talk about an organization being run by one of marketing, accounting, or engineering.) The further point I was making was that an aspect/facet tends to include more characteristics than are necessary for identifying the instances. That is, an aspect/facet has essential characteristics that define its intended extension, and structural business rules that specify other required information. In the 'rental car is asset' example, there are business rules: Each asset has a depreciation rule. Each asset has a date of acquisition. From the 'accounting' viewpoint, an 'asset' (a thing that is owned by the business and that has negotiable value) that has no depreciation rule (n-year linear, n-year SYD, n-year DDB, etc.), or no 'date of acquisition' used in that rule, is not being managed as an asset. So the viewpoint treats those as "necessary characteristics that follow from the definition", while no other part of the business would consider those to be necessary characteristics of a 'rental car', although they would have no objection to the definition of 'asset' per se. So, just as a situation role may add 'necessary characteristics' to an object by dint of its playing the role, a facet may add 'necessary characteristics' to an object by dint of its being an "object of interest" to the viewpoint. And that appears to be the point of "contextualization facts". But I hold my contention that: because an aspect/facet can be defined by a set of intrinsic or extrinsic properties, it can't be distinguished from fundamental concepts and situational roles [on that basis]. ... It just depends on what characteristics are chosen. It seems to me that there is an alternative view as well: that a facet is a specialization relationship between concepts that is only visible in a particular viewpoint. So 'Each rental car is an asset' is a necessity for the 'accounting' viewpoint that is not perceived in other business viewpoints that don't use the 'asset' concept. But that also goes back to Mark's observation that any viewpoint can introduce classifiers that have instances that are visible in other business domains of discourse, while the classifier itself (and its concomitant necessities) is not. And one can generalize that notion to say simply that "Each concept has an associated viewpoint". "Each concept has an associated semantic community" seems to be a statement of the same necessity (from a different viewpoint!). OTOH, aspects can be viewed as different from categorizations. The specialization relationship is one-way: the specialized concept is a sufficient condition for the general concept, but we only care about the general concept. The accountants don't care that assets are rental cars and office furniture and signage and so on, unless those categories have different accounting classifications. By comparison we tend to treat the category relationships within a viewpoint as two-way: the general concept "breaks down into" sub-categories. In this view, we introduce the fact type 'concept has facet' (the one-way meta-relationship) to distinguish it from 'concept is category of general concept' (the two-way relationship). 'facet' is just a category of general concept. The business person says "rental cars are assets", i.e., 'each rental car is an asset'. SBVR apparently requires the analyst to determine whether that means: 'rental car is a category of asset' or 'rental car has facet asset'. And that is not so easy, because the facet "asset" itself has accounting categories! An instance of facet (as a category of general concept) can participate in both kinds of specialization relationships. So whichever of these ideas are important, you have to get the definition of 'facet', and the notes and the elaborated example text to match. From the point of view of capturing and using business rules, I only need: 'each rental car is an asset'. The other distinctions are methodological and philosophical noise. -Ed P.S. Clause 11 causes me to wonder whether the BRG is a 'speech community', or even a 'semantic community'. But I apply Brian Meek's razor: "The inability to write cogent definitions is not necessarily a demonstration of confusion; rather, the ability to write cogent definitions must be acknowledged as an unusual skill." -- 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." User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 08 Apr 2009 10:57:07 -1000 Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting From: keri To: "Donald R. Chapin" , SBVR RTF Thread-Topic: issue 13716 -- SBVR RTF issue - updated from today's meeting Thread-Index: AcmqcYNwwhwKvBZkEd6JWAARJM+CggDKI0NFAJUF2FAA/j+jmQEpW1MO Attached is the Resolution document, updated with the one change I mentioned last week. ~ Keri On 4/2/09 1:02 PM, "keri" wrote: All, It was pointed out to me that I missed a change agreed in the meeting. It calls for one more change to the Definition of 'fact type': to change the end so that it says "roles" rather than "noun concepts". Is that right? (If I hear no objections I will make the fix and re-issue the document ... say, this weekend.) - Keri From: keri [mailto:keri_ah@mac.com] Sent: Wednesday, March 25, 2009 3:36 PM To: Donald R. Chapin; SBVR RTF Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting Attached is the updated Resolution document (along with a view of the resulting 11.1.5 subsection). These reflect the three points we discussed and agreed for this Issue in today's meeting, namely: Adding a summary statement clarifying why this has the nature of a 'fix'. Restoring the "Thing in Context" segmentation (to be addressed in a later issue) Revising the wording of the Definition of 'fact type' In restoring the 'Thing in Context' segmentation I could not find that we ever had a Necessity that specifies what the Figure depicts, so by doing the 'restore' called for in the second bullet we are left with an inconsistency that the 1.0 document currently has between the diagram and the text. If we want to correct this as part of this Resolution, we need to either add a Necessity or remove the Segmentation. Keri SBVR Issue 13716 (v4).doc User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 08 Apr 2009 11:53:24 -1000 Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting From: keri To: Ed Barkmeyer , SBVR RTF Thread-Topic: issue 13716 -- SBVR RTF issue - updated from today's meeting Thread-Index: Acm4lHCRrt0XHSSHEd6j/AARJM+Cgg== Ed, All, Here is an updated snippet that attempts to improve the meaning of 'facet' -- the new wording removes the notions of "generalization" from the Definition and replaces the Example of "asset" (which has gotten the understanding and discussion of this notion flying off into outer space, based on what 'asset' conjures up rather than illustrating what a facet is). Apologies to EU-Rent that it does not draw from car rental ... hopefully, John can replace the example with something more appropriate to EU-Rent (and also something that better illustrates the often "parallel life" nature of facets/aspects). And, no, Ed . a facet never adds new characteristics to those incorporated by the base/source concept. The notion really is that the facet/aspect is just a view of (a "sliver of") the related concept. Keri On 4/3/09 7:05 AM, "Ed Barkmeyer" wrote: > keri wrote: > >> One way I was taught to understand 'facet' was as akin to a 'view' of (back >> in the day) an entity (or, if you prefer, entity type). So, for example, if >> the entity 'car' has a total of 20 characteristics that are of interest to >> EU-Rent, there might be only 5 of those that are relevant to the viewpoint >> of accounting -- so they focus on just that aspect/facet of car because >> their perspective is to view the car in its 'asset-ness'. Some other >> perspective might have a view of a different sub-set of a car's >> characteristics -- that would be a different facet of car, from a different >> viewpoint. > > I completely agree. IMO, an "aspect" is a set of characteristics that > are significant to a particular viewpoint. (And I won't complain about > using "facet" as a synonym for "aspect".) But that is *not* the > existing/proposed definition. > > The proposed definition reads: > Definition: concept that generalizes a concept but incorporates only > those characteristics that are relevant to a particular viewpoint > > It is the "generalizes a (given) concept" stuff that seems to make > "facet" a role. (I took the "facet" concept to be the characteristics > that were given in the definition, not what I thought the term might > have meant, or should have meant.) > > If the intent is what Keri says, I suggest striking "generalizes a > concept but". Then the definition would read: > a concept defined by a set of characteristics (of things) that are > significant to a particular viewpoint. > > But, as Mark pointed out, _most_ classifiers identify only the > characteristics that are important to some viewpoint. The idea that you > can talk about the "essence" of something without having a viewpoint is > suspect, to say the least. And Allan's point was that mergers often > reveal the ingrained preference of organizations to treat different > viewpoints as "fundamental". (We used to talk about an organization > being run by one of marketing, accounting, or engineering.) > > The further point I was making was that an aspect/facet tends to include > more characteristics than are necessary for identifying the instances. > That is, an aspect/facet has essential characteristics that define its > intended extension, and structural business rules that specify other > required information. In the 'rental car is asset' example, there are > business rules: > Each asset has a depreciation rule. > Each asset has a date of acquisition. > From the 'accounting' viewpoint, an 'asset' (a thing that is owned by > the business and that has negotiable value) that has no depreciation > rule (n-year linear, n-year SYD, n-year DDB, etc.), or no 'date of > acquisition' used in that rule, is not being managed as an asset. So > the viewpoint treats those as "necessary characteristics that follow > from the definition", while no other part of the business would consider > those to be necessary characteristics of a 'rental car', although they > would have no objection to the definition of 'asset' per se. > > So, just as a situation role may add 'necessary characteristics' to an > object by dint of its playing the role, a facet may add 'necessary > characteristics' to an object by dint of its being an "object of > interest" to the viewpoint. And that appears to be the point of > "contextualization facts". > > But I hold my contention that: >> because an aspect/facet can be defined by a set of intrinsic >> or extrinsic properties, it can't be distinguished from fundamental >> concepts and situational roles [on that basis]. ... >> It just depends on what characteristics are chosen. > > It seems to me that there is an alternative view as well: that a facet > is a specialization relationship between concepts that is only visible > in a particular viewpoint. So 'Each rental car is an asset' is a > necessity for the 'accounting' viewpoint that is not perceived in other > business viewpoints that don't use the 'asset' concept. But that also > goes back to Mark's observation that any viewpoint can introduce > classifiers that have instances that are visible in other business > domains of discourse, while the classifier itself (and its concomitant > necessities) is not. And one can generalize that notion to say simply > that "Each concept has an associated viewpoint". "Each concept has an > associated semantic community" seems to be a statement of the same > necessity (from a different viewpoint!). > > OTOH, aspects can be viewed as different from categorizations. The > specialization relationship is one-way: the specialized concept is a > sufficient condition for the general concept, but we only care about the > general concept. The accountants don't care that assets are rental cars > and office furniture and signage and so on, unless those categories have > different accounting classifications. By comparison we tend to treat > the category relationships within a viewpoint as two-way: the general > concept "breaks down into" sub-categories. > > In this view, we introduce the fact type 'concept has facet' (the > one-way meta-relationship) to distinguish it from 'concept is category > of general concept' (the two-way relationship). 'facet' is just a > category of general concept. The business person says "rental cars are > assets", i.e., 'each rental car is an asset'. SBVR apparently requires > the analyst to determine whether that means: 'rental car is a category > of asset' or 'rental car has facet asset'. And that is not so easy, > because the facet "asset" itself has accounting categories! An instance > of facet (as a category of general concept) can participate in both > kinds of specialization relationships. > > So whichever of these ideas are important, you have to get the > definition of 'facet', and the notes and the elaborated example text to > match. > > From the point of view of capturing and using business rules, I only > need: 'each rental car is an asset'. The other distinctions are > methodological and philosophical noise. > > -Ed > > P.S. Clause 11 causes me to wonder whether the BRG is a 'speech > community', or even a 'semantic community'. But I apply Brian Meek's > razor: > "The inability to write cogent definitions is not necessarily a > demonstration of confusion; rather, the ability to write cogent > definitions must be acknowledged as an unusual skill." Date: Wed, 08 Apr 2009 18:52:51 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: keri CC: SBVR RTF Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n38MquXB017907 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1239835978.84921@Tb3Y6HAyVONV/shHwF5nnw X-Spam-Status: No keri wrote: Here is an updated snippet that attempts to improve the meaning of 'facet' -- the new wording removes the notions of "generalization" from the Definition and replaces the Example of "asset" (which has gotten the understanding and discussion of this notion flying off into outer space, based on what 'asset' conjures up rather than illustrating what a facet is). Apologies to EU-Rent that it does not draw from car rental ... hopefully, John can replace the example with something more appropriate to EU-Rent (and also something that better illustrates the often "parallel life" nature of facets/aspects). The snippet is much better than the text that is currently in the (v4) resolution. And you may want to rework the definition of concept has facet to match. And, no, Ed . a facet never adds new characteristics to those incorporated by the base/source concept. The notion really is that the facet/aspect is just a view of (a "sliver of") the related concept. Now it is my turn to say that that is a database view, based on the erroneous concept that there is a universal 'conceptual schema' from which all 'external views' can be extracted. IMO, the business view is a federation of viewpoints. Actual objects are classified according to viewpoints. The truly fundamental characteristics, whatever they may be, are probably not enough for any of the business viewpoints. The fundamental characteristics of an automobile make it an automobile, full stop. Making it an asset adds essential characteristics, making it a rental car adds essential characteristics, making it a 'car for sale' adds essential characteristics, making it an insured property adds essential characteristics. The additional characteristics are essential to the viewpoint, or to the role, but they are not fundamental. The object itself takes on these characteristics when it assumes the role, or when it is classified as an object of interest to a viewpoint. And it loses those characteristics when it loses the role or the classification. But this is a philosophical objection, not an objection to the text proposed in the snippet. This is why I don't want to get anywhere near the 'methodological stuff' that is being grafted onto SBVR in this section. -Ed P.S. 10 years of messing with distributed manufacturing databases persuaded me that neither the integrated conceptual schema model (from the ANSI 3-schema architecture) nor the federation of viewpoint schemas model works for all business applications. Each has its place. But the advantage of the latter is that it satisfies the Darwinian principle: it is adaptable to change. And many business applications need that. -- 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." X-EDSINT-Source-Ip: 130.175.198.26 Subject: RE: issue 13716 -- SBVR RTF issue - updated from today's meeting Date: Thu, 9 Apr 2009 07:14:26 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 13716 -- SBVR RTF issue - updated from today's meeting Thread-Index: Acm4nVUKsjiL0OztQ7W5DF0bwj9HFQAbh2Eg From: "Cummins, Fred A" To: , "keri" Cc: "SBVR RTF" X-OriginalArrivalTime: 09 Apr 2009 12:14:27.0342 (UTC) FILETIME=[BA5182E0:01C9B90C] X-CFilter-Loop: Reflected X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n39CForu017058 Ed, I think there is value in distinguishing a facet from a role (or whatever terms you want to use). A role is an entity in a context. The role attaches to the principle entity additional characteristics associated with the context. The entity does not have these characteristics before occurring in the context, and these are no longer associated with the entity (except historically) when the entity leaves that context. I would expect a facet could be limited to those characteristics that really are inherent in the principal entity. It could also be limited to what we know about the entity (also related to a context as defining scope of interest), as, for example, the associated elements in a database. Fred -----Original Message----- From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Wednesday, April 08, 2009 6:53 PM To: keri Cc: SBVR RTF Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting keri wrote: > Here is an updated snippet that attempts to improve the meaning of 'facet' > -- the new wording removes the notions of "generalization" from the > Definition and replaces the Example of "asset" (which has gotten the > understanding and discussion of this notion flying off into outer > space, based on what 'asset' conjures up rather than illustrating what a facet is). > Apologies to EU-Rent that it does not draw from car rental ... > hopefully, John can replace the example with something more > appropriate to EU-Rent (and also something that better illustrates the > often "parallel life" nature of facets/aspects). The snippet is much better than the text that is currently in the (v4) resolution. And you may want to rework the definition of concept has facet to match. > And, no, Ed < a facet never adds new characteristics to those > incorporated by the base/source concept. The notion really is that > the facet/aspect is just a view of (a "sliver of") the related concept. Now it is my turn to say that that is a database view, based on the erroneous concept that there is a universal 'conceptual schema' from which all 'external views' can be extracted. IMO, the business view is a federation of viewpoints. Actual objects are classified according to viewpoints. The truly fundamental characteristics, whatever they may be, are probably not enough for any of the business viewpoints. The fundamental characteristics of an automobile make it an automobile, full stop. Making it an asset adds essential characteristics, making it a rental car adds essential characteristics, making it a 'car for sale' adds essential characteristics, making it an insured property adds essential characteristics. The additional characteristics are essential to the viewpoint, or to the role, but they are not fundamental. The object itself takes on these characteristics when it assumes the role, or when it is classified as an object of interest to a viewpoint. And it loses those characteristics when it loses the role or the classification. But this is a philosophical objection, not an objection to the text proposed in the snippet. This is why I don't want to get anywhere near the 'methodological stuff' that is being grafted onto SBVR in this section. -Ed P.S. 10 years of messing with distributed manufacturing databases persuaded me that neither the integrated conceptual schema model (from the ANSI 3-schema architecture) nor the federation of viewpoint schemas model works for all business applications. Each has its place. But the advantage of the latter is that it satisfies the Darwinian principle: it is adaptable to change. And many business applications need that. -- 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." User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 08 Apr 2009 10:57:07 -1000 Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting From: keri To: "Donald R. Chapin" , SBVR RTF Thread-Topic: issue 13716 -- SBVR RTF issue - updated from today's meeting Thread-Index: AcmqcYNwwhwKvBZkEd6JWAARJM+CggDKI0NFAJUF2FAA/j+jmQEpW1MO Attached is the Resolution document, updated with the one change I mentioned last week. ~ Keri On 4/2/09 1:02 PM, "keri" wrote: All, It was pointed out to me that I missed a change agreed in the meeting. It calls for one more change to the Definition of 'fact type': to change the end so that it says "roles" rather than "noun concepts". Is that right? (If I hear no objections I will make the fix and re-issue the document ... say, this weekend.) - Keri From: keri [mailto:keri_ah@mac.com] Sent: Wednesday, March 25, 2009 3:36 PM To: Donald R. Chapin; SBVR RTF Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting Attached is the updated Resolution document (along with a view of the resulting 11.1.5 subsection). These reflect the three points we discussed and agreed for this Issue in today's meeting, namely: Adding a summary statement clarifying why this has the nature of a 'fix'. Restoring the "Thing in Context" segmentation (to be addressed in a later issue) Revising the wording of the Definition of 'fact type' In restoring the 'Thing in Context' segmentation I could not find that we ever had a Necessity that specifies what the Figure depicts, so by doing the 'restore' called for in the second bullet we are left with an inconsistency that the 1.0 document currently has between the diagram and the text. If we want to correct this as part of this Resolution, we need to either add a Necessity or remove the Segmentation. Keri SBVR Issue 13716 (v4).doc Date: Wed, 08 Apr 2009 18:52:51 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: keri CC: SBVR RTF Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n38MquXB017907 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1239835978.84921@Tb3Y6HAyVONV/shHwF5nnw X-Spam-Status: No keri wrote: Here is an updated snippet that attempts to improve the meaning of 'facet' -- the new wording removes the notions of "generalization" from the Definition and replaces the Example of "asset" (which has gotten the understanding and discussion of this notion flying off into outer space, based on what 'asset' conjures up rather than illustrating what a facet is). Apologies to EU-Rent that it does not draw from car rental ... hopefully, John can replace the example with something more appropriate to EU-Rent (and also something that better illustrates the often "parallel life" nature of facets/aspects). The snippet is much better than the text that is currently in the (v4) resolution. And you may want to rework the definition of concept has facet to match. And, no, Ed . a facet never adds new characteristics to those incorporated by the base/source concept. The notion really is that the facet/aspect is just a view of (a "sliver of") the related concept. Now it is my turn to say that that is a database view, based on the erroneous concept that there is a universal 'conceptual schema' from which all 'external views' can be extracted. IMO, the business view is a federation of viewpoints. Actual objects are classified according to viewpoints. The truly fundamental characteristics, whatever they may be, are probably not enough for any of the business viewpoints. The fundamental characteristics of an automobile make it an automobile, full stop. Making it an asset adds essential characteristics, making it a rental car adds essential characteristics, making it a 'car for sale' adds essential characteristics, making it an insured property adds essential characteristics. The additional characteristics are essential to the viewpoint, or to the role, but they are not fundamental. The object itself takes on these characteristics when it assumes the role, or when it is classified as an object of interest to a viewpoint. And it loses those characteristics when it loses the role or the classification. But this is a philosophical objection, not an objection to the text proposed in the snippet. This is why I don't want to get anywhere near the 'methodological stuff' that is being grafted onto SBVR in this section. -Ed P.S. 10 years of messing with distributed manufacturing databases persuaded me that neither the integrated conceptual schema model (from the ANSI 3-schema architecture) nor the federation of viewpoint schemas model works for all business applications. Each has its place. But the advantage of the latter is that it satisfies the Darwinian principle: it is adaptable to change. And many business applications need that. -- 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." X-EDSINT-Source-Ip: 130.175.198.26 Subject: RE: issue 13716 -- SBVR RTF issue - updated from today's meeting Date: Thu, 9 Apr 2009 07:14:26 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 13716 -- SBVR RTF issue - updated from today's meeting Thread-Index: Acm4nVUKsjiL0OztQ7W5DF0bwj9HFQAbh2Eg From: "Cummins, Fred A" To: , "keri" Cc: "SBVR RTF" X-OriginalArrivalTime: 09 Apr 2009 12:14:27.0342 (UTC) FILETIME=[BA5182E0:01C9B90C] X-CFilter-Loop: Reflected X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n39CForu017058 Ed, I think there is value in distinguishing a facet from a role (or whatever terms you want to use). A role is an entity in a context. The role attaches to the principle entity additional characteristics associated with the context. The entity does not have these characteristics before occurring in the context, and these are no longer associated with the entity (except historically) when the entity leaves that context. I would expect a facet could be limited to those characteristics that really are inherent in the principal entity. It could also be limited to what we know about the entity (also related to a context as defining scope of interest), as, for example, the associated elements in a database. Fred -----Original Message----- From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Wednesday, April 08, 2009 6:53 PM To: keri Cc: SBVR RTF Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting keri wrote: > Here is an updated snippet that attempts to improve the meaning of 'facet' > -- the new wording removes the notions of "generalization" from the > Definition and replaces the Example of "asset" (which has gotten the > understanding and discussion of this notion flying off into outer > space, based on what 'asset' conjures up rather than illustrating what a facet is). > Apologies to EU-Rent that it does not draw from car rental ... > hopefully, John can replace the example with something more > appropriate to EU-Rent (and also something that better illustrates the > often "parallel life" nature of facets/aspects). The snippet is much better than the text that is currently in the (v4) resolution. And you may want to rework the definition of concept has facet to match. > And, no, Ed < a facet never adds new characteristics to those > incorporated by the base/source concept. The notion really is that > the facet/aspect is just a view of (a "sliver of") the related concept. Now it is my turn to say that that is a database view, based on the erroneous concept that there is a universal 'conceptual schema' from which all 'external views' can be extracted. IMO, the business view is a federation of viewpoints. Actual objects are classified according to viewpoints. The truly fundamental characteristics, whatever they may be, are probably not enough for any of the business viewpoints. The fundamental characteristics of an automobile make it an automobile, full stop. Making it an asset adds essential characteristics, making it a rental car adds essential characteristics, making it a 'car for sale' adds essential characteristics, making it an insured property adds essential characteristics. The additional characteristics are essential to the viewpoint, or to the role, but they are not fundamental. The object itself takes on these characteristics when it assumes the role, or when it is classified as an object of interest to a viewpoint. And it loses those characteristics when it loses the role or the classification. But this is a philosophical objection, not an objection to the text proposed in the snippet. This is why I don't want to get anywhere near the 'methodological stuff' that is being grafted onto SBVR in this section. -Ed P.S. 10 years of messing with distributed manufacturing databases persuaded me that neither the integrated conceptual schema model (from the ANSI 3-schema architecture) nor the federation of viewpoint schemas model works for all business applications. Each has its place. But the advantage of the latter is that it satisfies the Darwinian principle: it is adaptable to change. And many business applications need that. -- 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." Date: Thu, 09 Apr 2009 11:35:31 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: "Cummins, Fred A" CC: SBVR RTF Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n39FZeCx024318 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1239896143.4294@FjwgTvjTvt70NAMbp7D6yg X-Spam-Status: No Fred Cummins wrote: I think there is value in distinguishing a facet from a role (or whatever terms you want to use). A role is an entity in a context. The role attaches to the principle entity additional characteristics associated with the context. The entity does not have these characteristics before occurring in the context, and these are no longer associated with the entity (except historically) when the entity leaves that context. I would expect a facet could be limited to those characteristics that really are inherent in the principal entity. It could also be limited to what we know about the entity (also related to a context as defining scope of interest), as, for example, the associated elements in a database. A viewpoint is also a context. So the real distinction between a 'role' and a 'facet' is that the properties of a role are transient/"accidental", even though they may persist for a long time, while the properties of a 'facet' are fundamental. Is that what you are saying? I thought that was the fundamental/contextual dichotomy. If that is the definition, then 'facet' is a special case of 'fundamental concept', by definition -- it is a fundamental concept that is only interesting from some viewpoint. But if a 'facet' is just a/the set of the properties of a thing that is interesting in a viewpoint, why restrict it to fundamental properties? Why can't a viewpoint relate to roles as well? In practice, they do. And why do all of the viewpoint properties have to belong to some other conceptualization as well? In practice, some must, others may not. My argument was that I can't fit well-known business concepts and concerns, that are clearly about "aspects" (per NODE), to this model as defined. So I don't see that this model helps business analysts, unless they ignore your definitions (as certain BRG persons obviously do). I don't understand, but I no longer think there is business value in trying to. I won't waste anyone's further time on this. -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." User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 09 Apr 2009 06:38:57 -1000 Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting From: keri To: Ed Barkmeyer , Fred Cummins CC: SBVR RTF Thread-Topic: issue 13716 -- SBVR RTF issue - updated from today's meeting Thread-Index: Acm5Ma1f66co0yUkEd692wARJM+Cgg== Fred, Thanks for jumping in and speaking up on behalf of our friend 'facet'. Ed, A couple of points, below.... On 4/9/09 5:35 AM, "Ed Barkmeyer" wrote: > Fred Cummins wrote: > >> I think there is value in distinguishing a facet from a role (or >> whatever terms you want to use). A role is an entity in a context. The >> role attaches to the principle entity additional characteristics >> associated with the context. The entity does not have these >> characteristics before occurring in the context, and these are no longer >> associated with the entity (except historically) when the entity leaves >> that context. I would expect a facet could be limited to those >> characteristics that really are inherent in the principal entity. It >> could also be limited to what we know about the entity (also related to >> a context as defining scope of interest), as, for example, the >> associated elements in a database. > > A viewpoint is also a context. Yes, a viewpoint is what provides the context for a 'facet'. > So the real distinction between a 'role' and a 'facet' is that the > properties of a role are transient/"accidental", even though they may > persist for a long time, while the properties of a 'facet' are > fundamental. Is that what you are saying? I thought that was the > fundamental/contextual dichotomy. Right. There may be other approaches for allocating characteristics to the various facets of a concept, but the one I am familiar with is from "Entity Life History", as practiced for several decades in the UK and Europe -- primarily, with some pockets here in the U.S. In that practice the facets reflect sets of characteristics (of a base/source concept ("entity")) that change evolve as an interrelated set over time (hence the "life history" perspective). There can be other facets of the base/source concept . other sets of characteristics . that evolve in lives parallel (non-interfering) with the other facets. That is why this perspective on 'facet' never adds characteristics to the base/source concept . the motivation of the analysis doesn't have an objective of whatever you are envisioning going on with "asset" (which, by the way, I removed as Example from the snippet). The motivation is to group/analyze subsets. > ... Why can't a viewpoint relate to > roles as well? It can. The concept (which I have been referring to informally here as the base/source concept) can be fundamental, or not. ... > My argument was that I can't fit well-known business concepts and > concerns, that are clearly about "aspects" (per NODE), to this model as > defined. ... See above. The references that might help could include writings on "Entity Life History" techniques (from the 1980s and 1990s, in particular) and SSADM. So there is well-established practice, which came (BTW) well before the BRG entered the picture. And from dictionaries, here are some definitions that I spotted: One of numerous aspects, as of a subject. [for facet] The particular angle from which something is considered. [for facet] a way in which a thing may be viewed or regarded; interpretation; view: both aspects of a decision.[for aspect] part; feature; phase: That is the aspect of the problem that interests me most. [for aspect] even (as a kind of mental metaphor) the side or surface facing a given direction: the dorsal aspect of a fish; the northern aspect of the house. [for aspect] Keri Date: Thu, 09 Apr 2009 20:10:58 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: keri CC: SBVR RTF Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n3A0B3al022517 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1239927068.4058@IcfNk420yf3UlYFv4vWiCg X-Spam-Status: No keri wrote: So the real distinction between a 'role' and a 'facet' is that the properties of a role are transient/"accidental", even though they may persist for a long time, while the properties of a 'facet' are fundamental. Is that what you are saying? I thought that was the fundamental/contextual dichotomy. Right. There may be other approaches for allocating characteristics to the various facets of a concept, but the one I am familiar with is from "Entity Life History", as practiced for several decades in the UK and Europe -- primarily, with some pockets here in the U.S. In that practice the facets reflect sets of characteristics (of a base/source concept ("entity")) that change evolve as an interrelated set over time (hence the "life history" perspective). So (some of) the properties of a 'facet' are not fundamental -- they change over time. By definition, a fundamental characteristic of a thing is part of its very nature; if it changes you have a different thing. This seems to me to contradict your "Right" above. ... Why can't a viewpoint relate to roles as well? It can. The concept (which I have been referring to informally here as the base/source concept) can be fundamental, or not. Then it is not a requirement that the properties of a facet are fundamental. And what Fred said is simply wrong. The properties in a facet don't necessarily exist until and unless the thing becomes interesting from a given viewpoint. See above. The references that might help could include writings on "Entity Life History" techniques (from the 1980s and 1990s, in particular) and SSADM. So there is well-established practice, which came (BTW) well before the BRG entered the picture. And from dictionaries, here are some definitions that I spotted: * One of numerous aspects, as of a subject. [for facet] * The particular angle from which something is considered. [for facet] * a way in which a thing may be viewed or regarded; interpretation; view: both aspects of a decision.[for aspect] * part; feature; phase: That is the aspect of the problem that interests me most. [for aspect] even (as a kind of mental metaphor) * the side or surface facing a given direction: the dorsal aspect of a fish; the northern aspect of the house. [for aspect] None of these, including the reference, tells me that a viewpoint cannot add additional properties to a thing previously perceived, but not previously perceived as relevant to the viewpoint. As you may recall, that was the only issue I raised. I know what an aspect is. And I can define it. It is the collection of properties of a thing that are relevant to a viewpoint, full stop. It doesn't say that those properties are fundamental or accidental, and it doesn't say whether they are extracted from some other set. In your definitions of 'facet', you and Fred seem to find it necessary to add these additional concerns/constraints. I only asked whether you meant to, and the answer was apparently Yes. The underlying question is whether the dichotomy makes sense: If no fundamental concept is a contextualized concept (dichotomy 1) and every facet is a contextualized concept, then no facet can be fundamental! It follows that every facet must involve at least 1 accidental property. Fred says this is false; therefore the dichotomy is false. And if no role concept is a facet concept (dichotomy 2) then a facet derived from a role must omit at least one property the role requires, or add at least 1 property the role doesn't have. Keri apparently wants to disallow the latter. I don't understand why. That's all I was saying. -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." User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 10 Apr 2009 10:18:47 -1000 Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting From: keri To: Ed Barkmeyer CC: SBVR RTF Thread-Topic: issue 13716 -- SBVR RTF issue - updated from today's meeting Thread-Index: Acm6GY2jzF9SfyYMEd6qIwARJM+Cgg== On 4/9/09 2:10 PM, "Ed Barkmeyer" wrote: ... > So (some of) the properties of a 'facet' are not fundamental -- they > change over time. By definition, a fundamental characteristic of a > thing is part of its very nature; if it changes you have a different > thing. We don't have a notion of 'fundamental characteristic' -- we have 'necessary characteristic' and 'essential characteristic' and 'implied characteristic' but I could not spot where we talk about characteristics being 'fundamental'. A facet is a subset of the characteristics that its base/source concept incorporates -- without regard to the 'kind' of characteristic. So, yes, the subset can include characteristics that can change value over time. > This seems to me to contradict your "Right" above. The 'Right' had to do with how I understood you to contrast 'role' and 'facet'. I had understood the distinction being explained in terms of things being able to step into and out of a role (over time), with the things of a facet being enduring (in the population) but having a subset of characteristics. But perhaps I misread that. (In which case, I could say "Wrong" if that would make you happier. ) ... > Then it is not a requirement that the properties of a facet are > fundamental. And what Fred said is simply wrong. I tried to be careful to speak only to the practice that I know and understand. Fred may have a different practice -- one that is more restrictive in the nature of the kind of characteristics it deals with. However, his more restrictive practice would be accommodated under the broader practice I was describing. I wouldn't know enough to say he is wrong ... simply different. > The properties in a > facet don't necessarily exist until and unless the thing becomes > interesting from a given viewpoint. > >> See above. The references that might help could include writings on >> "Entity Life History" techniques (from the 1980s and 1990s, in particular) >> and SSADM. So there is well-established practice, which came (BTW) well >> before the BRG entered the picture. >> >> And from dictionaries, here are some definitions that I spotted: >> * One of numerous aspects, as of a subject. [for facet] >> * The particular angle from which something is considered. [for facet] >> * a way in which a thing may be viewed or regarded; interpretation; view: >> both aspects of a decision.[for aspect] >> * part; feature; phase: That is the aspect of the problem that interests me >> most. [for aspect] >> even (as a kind of mental metaphor) >> * the side or surface facing a given direction: the dorsal aspect of a fish; >> the northern aspect of the house. [for aspect] > > None of these, including the reference, tells me that a viewpoint cannot > add additional properties to a thing previously perceived, but not > previously perceived as relevant to the viewpoint. > > As you may recall, that was the only issue I raised. And so I proposed a revision to the Definition text to make it clear that, in the sense that is intended for Clause 11, a facet is to be only a subset of characteristics. I'm not relating to your statement that "a viewpoint ... add[ing] additional properties to a thing previously perceived but not previously perceived as relevant to the viewpoint". Try this: Some base concept has a set of characteristics . say, 20 characteristics. And let's say that facet-A views 8 of the 20; facet-B considers 6 of the 20; facet-C deals with 12 of the 20. (Yes, a characteristic may be in more than one facet of the concept . this is not a partitioning.) And let's say that the population of the base concept is 578 individuals at this time. Each facet then has 578 individuals. So I don't grasp what is this 'thing' that was not perceived as relevant to the viewpoint. It is the set of characteristics . a kind of 'mask' on the population . that is considered relevant to the viewpoint, not things perceived individually as relevant, or not. > > I know what an aspect is. And I can define it. It is the collection of > properties of a thing that are relevant to a viewpoint, full stop. OK (but ... see below) ... > It doesn't say that those properties are fundamental or accidental, ...nor did the revised definition... > and > it doesn't say whether they are extracted from some other set. Ah, so here may be our difference. For this notion of 'facet', we are dealing at the level of the concept . set of characteristics. (There are facets even if the population is empty.) So, yes, in the practice I am describing, 'facet' is a concept that selects a set of characteristics from some other specified concept. > In your > definitions of 'facet', you and Fred seem to find it necessary to add > these additional concerns/constraints. I only asked whether you meant > to, and the answer was apparently Yes. For the specified other concept, yes. > > The underlying question is whether the dichotomy makes sense: > If no fundamental concept is a contextualized concept (dichotomy 1) We can give a synonym of "non-contextualized concept" to fundamental concept, if that helps. (That is what we intend by 'fundamental' here.) > and every facet is a contextualized concept, then no facet can be > fundamental! That's right, by definition. (No contextualized concept is a non-contextualized concept.) > It follows that every facet must involve at least 1 > accidental property. Fred says this is false; therefore the dichotomy > is false. We've now put this to rest, yes? > And if no role concept is a facet concept (dichotomy 2) BTW, Ron has logged an issue to remove this constraint. > then a facet > derived from a role must omit at least one property the role requires, > or add at least 1 property the role doesn't have. Keri apparently wants > to disallow the latter. I don't understand why. Because that's the way the practice works. Having the family of facets of a concept represent MORE characteristics than the base concept incorporates would be nonsense. The point is to analyze/specify all the relevant groupings of the characteristics of an entity (concept). So having characteristics in that pool that aren't accounted for in the base concept itself just does not compute. Hope this helps. ~ Keri Date: Fri, 10 Apr 2009 17:49:38 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: keri CC: SBVR RTF Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n3ALnhiT023305 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1240004987.57327@aWc8M2+TatS74ZcVbMyuiQ X-Spam-Status: No Keri, Just forget it. 11.1.5 is of no value to NIST, and I frankly don't care whether it makes any sense. -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." Date: Fri, 10 Apr 2009 17:58:00 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: SBVR RTF Subject: SBVR Issue 13716 -- one minor SE problem X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n3ALw42x023964 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1240005489.10258@DR9IDeGkxF8+CaxP2UqW7Q X-Spam-Status: No In the proposed resolution of Issue 13716, the Definition of contextualization fact is: is-role-of fact or is-facet-of fact The 'or' is stylized as a keyword. But according to Annex C, the keyword 'or' is defined to mean logical disjunction between two propositions. Here it appears between two concepts. According to 8.1, no concept is a proposition. So this usage is apparently incorrect. (I'm not sure whether this usage appears elsewhere.) The obvious fix is: Definition: fact that is an is-role-of fact or is an is-facet-of fact -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." User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 10 Apr 2009 13:54:26 -1000 Subject: Re: SBVR Issue 13716 -- one minor SE problem From: keri To: Ed Barkmeyer , SBVR RTF Thread-Topic: SBVR Issue 13716 -- one minor SE problem Thread-Index: Acm6N63h7KG4NyYqEd68UwARJM+Cgg== Interesting find.... This is intended to be an extensional definition (see Annex C - PDF p. 259: On 4/10/09 11:58 AM, "Ed Barkmeyer" wrote: > In the proposed resolution of Issue 13716, the Definition of > contextualization fact is: is-role-of fact or is-facet-of fact > > The 'or' is stylized as a keyword. But according to Annex C, the > keyword 'or' is defined to mean logical disjunction between two > propositions. Here it appears between two concepts. According to 8.1, > no concept is a proposition. So this usage is apparently incorrect. > > (I'm not sure whether this usage appears elsewhere.) > > The obvious fix is: > Definition: fact that is an is-role-of fact or is an is-facet-of fact > > -Ed User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 10 Apr 2009 13:59:46 -1000 Subject: Re: SBVR Issue 13716 -- one minor SE problem From: keri To: Ed Barkmeyer , SBVR RTF Thread-Topic: SBVR Issue 13716 -- one minor SE problem Thread-Index: Acm6OGyeqyI8diYrEd68UwARJM+Cgg== On 4/10/09 11:58 AM, "Ed Barkmeyer" wrote: > In the proposed resolution of Issue 13716, the Definition of > contextualization fact is: is-role-of fact or is-facet-of fact > > The 'or' is stylized as a keyword. But according to Annex C, the > keyword 'or' is defined to mean logical disjunction between two > propositions. Here it appears between two concepts. According to 8.1, > no concept is a proposition. So this usage is apparently incorrect. > > (I'm not sure whether this usage appears elsewhere.) > > The obvious fix is: > Definition: fact that is an is-role-of fact or is an is-facet-of fact > > -Ed Ed, Interesting find.... This is intended to present an extensional definition -- see Annex C - PDF p. 259, which says: There is another case of this on PDF p. 64 (bindable target): And in EU-Rent (PDF p. 327): Hmmm... Keri Date: Mon, 13 Apr 2009 17:24:35 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: keri CC: SBVR RTF Subject: Re: SBVR Issue 13716 -- one minor SE problem X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n3DLOe2G002473 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1240262683.68501@mxNB73hY2KXEEg4Y3rNZ7w X-Spam-Status: No I wrote: In the proposed resolution of Issue 13716, the Definition of contextualization fact is: is-role-of fact or is-facet-of fact The 'or' is stylized as a keyword. But according to Annex C, the keyword 'or' is defined to mean logical disjunction between two propositions. Here it appears between two concepts. According to 8.1, no concept is a proposition. So this usage is apparently incorrect. (I'm not sure whether this usage appears elsewhere.) Keri wrote: This is intended to present an extensional definition -- see Annex C - PDF p. 259, which says: Another style of formal definition is extensional. It uses disjunction to combine a number of concepts. For example, a contextualized concept is anything that is a role or a facet. contextualized concept Definition: role or facet There is another case of this on PDF p. 64 (bindable target): ... And in EU-Rent (PDF p. 327): ... Yes. We all agree on what it means. It is just that Annex C doesn't say that is what 'or' means. So we should fix one or the others. Since there are other occurrences, this should be a separate Issue. I'll post it. Thanks for finding the other examples. (I couldn't figure out how to do it in the PDF file.) -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." User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 25 Mar 2009 12:35:57 -1000 Subject: Re: issue 13716 -- SBVR RTF issue - updated from today's meeting From: keri To: "Donald R. Chapin" , SBVR RTF Thread-Topic: issue 13716 -- SBVR RTF issue - updated from today's meeting Thread-Index: AcmqcYNwwhwKvBZkEd6JWAARJM+CggDKI0NF Attached is the updated Resolution document (along with a view of the resulting 11.1.5 subsection). These reflect the three points we discussed and agreed for this Issue in today's meeting, namely: Adding a summary statement clarifying why this has the nature of a 'fix'. Restoring the "Thing in Context" segmentation (to be addressed in a later issue) Revising the wording of the Definition of 'fact type' In restoring the 'Thing in Context' segmentation I could not find that we ever had a Necessity that specifies what the Figure depicts, so by doing the 'restore' called for in the second bullet we are left with an inconsistency that the 1.0 document currently has between the diagram and the text. If we want to correct this as part of this Resolution, we need to either add a Necessity or remove the Segmentation. Keri SBVR Issue 13716 (v3).doc User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 16 Jun 2009 06:58:36 -0700 Subject: SBVR Issue 13716 - Question about Kinds of Facts and Fact Types (and ISO) From: keri To: SBVR RTF , "Donald R. Chapin" Thread-Topic: SBVR Issue 13716 - Question about Kinds of Facts and Fact Types (and ISO) Thread-Index: AcmugARrQrYYmxpzEd6h+gARJM+CggCywQwgAAQ2OFIAvgfaYAASRu9SC5DGLiAAXzROTAEwHvuAABHZc+gAfDdacADNMU3r After the March meeting, where the 13716 proposal was discussed, I was updating material that explains these 'template' fact/fact type differences to the 'mere mortal'. I checked the ISO document/diagram to see how ISO makes this kind of distinction in their concepts. Here (below) is the picture -- my annotations to the ISO diagram are in yellow highlighting/blue type. I asked Donald if he could check with the ISO folks to see if their picture has evolved or has more detail than shown in the document -- and whether this has any implications for our 'harmonization' -- and he reports that he now has some information. ~ Keri Date: Tue, 16 Jun 2009 16:04:10 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: keri CC: SBVR RTF Subject: Re: SBVR Issue 13716 - Question about Kinds of Facts and Fact Types (and ISO) X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n5GK4HBZ013486 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-MailScanner-Watermark: 1245787457.5295@W2cFhUXnleb82uhmXd4K1g X-Spam-Status: No keri wrote: After the March meeting, where the 13716 proposal was discussed, I was updating material that explains these 'template' fact/fact type differences to the 'mere mortal'. I checked the ISO document/diagram to see how ISO makes this kind of distinction in their concepts. Here (below) is the picture -- my annotations to the ISO diagram are in yellow highlighting/blue type. I will be interested to see what evolution this diagram may have had. For our purposes (and indeed for most knowledge engineering purposes), there is _exactly one_ 'generic relation' (in the sense of 'fact type'). SBVR calls it 'concept specializes concept', UML calls it 'generalization' and OWL calls it 'subsumption'. As a consequence, one can regard the 'generic relation' as an individual 'fact type', and every individual fact type categorizes facts. Conversely, there are many different associative relations, and two given things may be "associated" in more than one way. There are multiple partitive relations. But 30 years of modeling experience tells me that most people who insist on having this concept disagree on what it means. Characterization of part/whole relationships is the subject of mereology. It is my recollection that there are 3 to 5 "standard mereological axioms" that hold for all "partitive relations", and another dozen that some partitive relations obey in various combinations. An extensive list is to be found at: http://en.wikipedia.org/wiki/Mereology#Axioms_and_primitive_notions In mereology, two importantly different categories of partitive relation are distinguished: 'part' and 'proper part'. 'part' is "reflexive": if P is a 'part' relation, then every thing x is P of itself, i.e. (P x x) holds for all x. 'proper part' is "antireflexive": (PP x x) never holds for any x, no x is PP of itself. 'part' is weakly antisymmetric: (P x y) and (P y x) implies (= x y) [read: if x is P of y and y is P of x, then x is equal to y]. 'proper part' is strongly antisymmetric: (PP x y) implies NOT (PP y x) [read: if x is PP of y then y is not PP of x.] The ISO text, per Keri, is silent on this. So the concept is not well enough defined that we can determine which fact types are in the category. People also have trouble with the transitivity axiom: if x is a part of y, and y is a part of z, then x is a part of z. For many of the relationships business people think of as 'partitive', transitivity is meaningless -- they only have two levels: things and groupings; there is no z for a y grouping to be a part of. But if larger groupings contain smaller groupings, transitivity depends on the containment rules. And we tend to use the same terms to describe different containment concepts at different times. In manufacturing, an automobile or subsystem has a "primary decomposition" and a "complete decomposition". "Complete decomposition" is transitive: every bolt in a subassembly is a part of the car. But "primary decomposition" is not: no bolt is a primary part of the car, although it may be a primary part of the brake assembly. They are both "part/whole relationships", but the ISO definition doesn't tell me whether transitivity is expected to hold or not. What all of this means is that the definition given for 'partitive relation' is subjective. It doesn't state the characteristics that distinguish 'partitive relation' from 'associative relation' in any testable way. Of the five primary mereological axioms for part/whole relationships, I don't know whether ANY of them is intended to hold for all 'partitive relations'. What structural rules distinguish them? I think you probably mean "proper part" and the two axioms that go with it (antireflexive, antisymmetric). But those axioms also hold for many 'associative relations'. Do you also want to assert the transitivity axiom? And if not, do you want to assert some other axiom that makes part/whole special? For example, can the part exist if there is no whole of which it is part? Can the whole exist without some of the parts? Can a part belong to more than one whole? -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." From: Don Baisley To: SBVR RTF Date: Tue, 16 Jun 2009 18:46:54 -0700 Subject: RE: SBVR Issue 13716 - Question about Kinds of Facts and Fact Types (and ISO) Thread-Topic: SBVR Issue 13716 - Question about Kinds of Facts and Fact Types (and ISO) Thread-Index: AcnuvnMptG9kjJyMQuuYZxNg3HzRXwALC7IQ Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n5H1iouA010197 I like Ed's interpretation of ISO's 'generic relation' with respect to SBVR: that SBVR has exactly one of them, which is the one fact type 'concept specializes concept'. This is a cleaner interpretation than having some ISO relations be fact types and others be facts. Regards, Don -----Original Message----- From: Ed Barkmeyer [mailto:edbark@nist.gov] Sent: Tuesday, June 16, 2009 1:04 PM To: keri Cc: SBVR RTF Subject: Re: SBVR Issue 13716 - Question about Kinds of Facts and Fact Types (and ISO) keri wrote: > After the March meeting, where the 13716 proposal was discussed, I was > updating material that explains these 'template' fact/fact type differences > to the 'mere mortal'. I checked the ISO document/diagram to see how ISO > makes this kind of distinction in their concepts. Here (below) is the > picture -- my annotations to the ISO diagram are in yellow highlighting/blue > type. I will be interested to see what evolution this diagram may have had. For our purposes (and indeed for most knowledge engineering purposes), there is _exactly one_ 'generic relation' (in the sense of 'fact type'). SBVR calls it 'concept specializes concept', UML calls it 'generalization' and OWL calls it 'subsumption'. As a consequence, one can regard the 'generic relation' as an individual 'fact type', and every individual fact type categorizes facts. Conversely, there are many different associative relations, and two given things may be "associated" in more than one way. There are multiple partitive relations. But 30 years of modeling experience tells me that most people who insist on having this concept disagree on what it means. Characterization of part/whole relationships is the subject of mereology. It is my recollection that there are 3 to 5 "standard mereological axioms" that hold for all "partitive relations", and another dozen that some partitive relations obey in various combinations. An extensive list is to be found at: http://en.wikipedia.org/wiki/Mereology#Axioms_and_primitive_notions In mereology, two importantly different categories of partitive relation are distinguished: 'part' and 'proper part'. 'part' is "reflexive": if P is a 'part' relation, then every thing x is P of itself, i.e. (P x x) holds for all x. 'proper part' is "antireflexive": (PP x x) never holds for any x, no x is PP of itself. 'part' is weakly antisymmetric: (P x y) and (P y x) implies (= x y) [read: if x is P of y and y is P of x, then x is equal to y]. 'proper part' is strongly antisymmetric: (PP x y) implies NOT (PP y x) [read: if x is PP of y then y is not PP of x.] The ISO text, per Keri, is silent on this. So the concept is not well enough defined that we can determine which fact types are in the category. People also have trouble with the transitivity axiom: if x is a part of y, and y is a part of z, then x is a part of z. For many of the relationships business people think of as 'partitive', transitivity is meaningless -- they only have two levels: things and groupings; there is no z for a y grouping to be a part of. But if larger groupings contain smaller groupings, transitivity depends on the containment rules. And we tend to use the same terms to describe different containment concepts at different times. In manufacturing, an automobile or subsystem has a "primary decomposition" and a "complete decomposition". "Complete decomposition" is transitive: every bolt in a subassembly is a part of the car. But "primary decomposition" is not: no bolt is a primary part of the car, although it may be a primary part of the brake assembly. They are both "part/whole relationships", but the ISO definition doesn't tell me whether transitivity is expected to hold or not. What all of this means is that the definition given for 'partitive relation' is subjective. It doesn't state the characteristics that distinguish 'partitive relation' from 'associative relation' in any testable way. Of the five primary mereological axioms for part/whole relationships, I don't know whether ANY of them is intended to hold for all 'partitive relations'. What structural rules distinguish them? I think you probably mean "proper part" and the two axioms that go with it (antireflexive, antisymmetric). But those axioms also hold for many 'associative relations'. Do you also want to assert the transitivity axiom? And if not, do you want to assert some other axiom that makes part/whole special? For example, can the part exist if there is no whole of which it is part? Can the whole exist without some of the parts? Can a part belong to more than one whole? -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." DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:X-MIMEOLE:In-Reply-To:Thread-Index; b=CtxiaOzADcVRaHbBAY0NymDwPz8zc8FV94rf41NuGd9G+azkpClQY+9kXgsJ5HK5CJiUyW/WoKK1iKe+SP3+G18i2Ko9XxlHDtTyLhgmpJMOyIp7fZdPMmvi8tzMxldK7SZ8SnC3G7JNt5ptAN91fpl4foLeeXox/qBe7BZTzxI= ; X-Yahoo-SMTP: b.l.OgaswBB0CtEn_ZIF.H9k5RdfhYkkxppP9F1YQnPMOFrjDZjKm34- X-YMail-OSG: RA7ZFzoVM1mEgIJ5hfn6EPmqE0hbrsR6db84CABflXKrgs_hFxjX0ttgFaFizXZZPhdNfoJyoaFp15sUutXBJepd7bEPlkTcpMBjzYc65n.oL88ThmxSmOUmfUITodNI8NG1SKGdae97YjqevCQ6XluzP3f_lqxBHEfkks0pHrWMnjQWjSVJdtIrSILyw6VxvNfTPBE99x24.y9kDNAf1PoFfW68mV2gpB2SqjMAdt5GjN_ZQHXdO7Kp8kQgr22mgJ8f4D2ptV8xuhhhhPhCxkwmPYAQ6_DRBSvovr46ZR8j X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: "'keri'" , "'SBVR RTF'" Subject: RE: SBVR Issue 13716 - Question about Kinds of Facts and Fact Types (and ISO) Date: Fri, 19 Jun 2009 16:16:33 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcmugARrQrYYmxpzEd6h+gARJM+CggCywQwgAAQ2OFIAvgfaYAASRu9SC5DGLiAAXzROTAEwHvuAABHZc+gAfDdacADNMU3rAJl3wPA= Keri, The question you posed is very astute and needs to be clearly, and well, answered. I had been pondering the need to answer it since our all day meeting during the March OMG conference. Prof. Gerhard Budin, my counterpart ISO TC 37 to OMG liaison, early in our collaboration in 2006 stressed to me the critical importance of distinguishing between two kinds of .concept relations.: .conceptual relations. and .ontological relations.. .Conceptual relations. are relations directly between the concepts themselves; e.g. the specialization relation, where what is being talked about is one concept being related to another concept as being more narrow or more general, e.g. the concept .points rental. specializes the concept .rental.; the concept .noun concept. specializes the concept .concept.. .Ontological relations. are relations between the actual things (ISO TC 37 objects) that correspond to concepts. While .ontological relations. are documented as relations between the concepts that correspond to the things that are actually related, they are always interpreted as relations between the things themselves; e.g. part whole relations, where what is being talked about is a tire itself in relation to an actual wheel rim on an actual car. .Driver is responsible for rental. designates, based on the given use of the verb concept, the instances (states of affairs) of specific drivers that are responsible for a specific rental contract (in some time frame). .Driver Joe Smith is responsible for rental EU-32764. designates one particular instance (state of affairs) for all time. In ISO 1087-1 only .generic relation. is a .conceptual relation.. All the rest are .ontological relations.. After discussing this with Prof. Budin, I think it would be useful to add those subcategories to the revision of ISO 1087-1 currently under way and on whose revision team I am. As part of considering the answer to your question, I discovered that the currently proposed Issue 13716 Resolution revisions to Clause 11.1.5 would introduce a fairly serious new problem into SBVR by making .fact. part of definitions in Clauses 8, 9, 11 & 12. At present .fact. is not referenced as part of definitions or fact type forms anywhere in Clauses 8, 9, 11 & 12 except: in Clause 8.5, which is there to support the definition of the SBVR XMI, XSD and XML interchange files in Clause 13; in the definition of elementary fact type which, as it stands, really belongs with the Clause 10 concepts; in the definition of .terminological dictionary. which is talking about the documentation of SBVR as is Clause 8.5. Outside of Clause 8.5, there are 22 informal references to .fact(s). in the whole of Clauses 8, 9, 11 & 12, and in the majority of these the signifier .fact. is used to mean .actuality.. SBVR is a metamodel for concept(definition)-centric special purpose business language dictionaries plus guidance specifications in terms those definition-centric dictionaries. SBVR is not a metamodel for fact modeling as practiced in, say, ORM and CogNIAM (ref: ISO Technical Report TR 9007, "The Orange Report"). Fact models of this kind are not represented in the SBVR XMI metamodel file (i.e. are not part of the SBVR metamodel). Their fact populations could not be included in SBVR interchange files (SBVR XSD + SBVR XML) unless local extensions to support them were defined. Fact modeling (so defined) is in SBVR only in Clause 10, specifically and solely to provide a formal interpretation for SBVR. Since the publication of the Orange Report in 1982, the signifier .fact. has been used almost exclusively to refer to .propositions that are taken to be true,. rather than to actualities. Even in 2004, when we separated .actuality. from .proposition taken to be true,. it was too late to reverse 20 years of usage of the signifier .fact.. SBVR includes the verb concept "concept1 specializes concept2", which can be used like any other verb concept, even in SBVR Structured English. You can say "the concept 'points rental' specializes the concept 'rental' ". The style of using the preferred term of the more general concept as the leading word in a definition (e.g. "points rental: rental that ...") is simply one of the fact type forms for .concept1 specializes concept2. that are supported by Structured English syntax. Secondly, this distinction between concept(definition)-centric modeling and fact modeling (so defined) is quite seriously obscured in SBVR because of the conflation of two different concepts in SBVR Clause 8.1: - .proposition. meaning that is true or false (the .semantic content. part in .proposition. + .performative.) - .proposition. + .performative. (where the .performative. part is the .communicative function.) e.g.: o proposition + .deontic. performative = behavioral guidance o proposition + .alethic. performative = definitional rule o proposition + .taken to be true. performative = fact The core meanings are in the propositions which are then made into something else by combination with a particular performative. This is why there is no reason to include the concept .fact. at all in Clauses 8, 9 11 or 12 except to support the formulation of fact statements -- which are really out of scope for a standard for .concept(definition)-centric special purpose business language dictionaries plus guidance specifications in terms those definiton-centric dictionaries.. Examples of general concepts can be provided by using names and fact type forms of individual concepts without needing to turn the individual concepts into facts (by adding the performative .taken to be true.) so that fact statements can be used as examples. Thirdly, Clause 8.1 also defines two concepts (.concept. and .proposition.) as if they were completely separate things when in fact they are at most two perspectives on the same thing: general noun concept = open (existential) proposition individual noun concept = closed (existential) proposition general verb concept = open (relational) proposition individual verb concept = closed (relational) proposition (this is the verb concept that corresponds to a given state of affairs) Probably the best solution here is to add open/closed proposition categories, add existential/relational proposition categories, fix the subcategories of concept to fit the above, and have both .concept. and .proposition. as more general concepts for the subcategories. Fourthly and unfortunately, we did not always follow good term formation practices in SBVR. .Fact type. as a signifier for the concept in Clause 8.1.1 is misleading because: - the definition is about actualities (it would be more accurately named .actuality type. and/or concept relation) - almost every other use of the signifier .fact type. outside of SBVR and in Clause 10 of SBVR mean .type of fact.. I think we can fix the problems with the current Issue 13716 resolution quite simply: - replace .fact type. in the box in the diagram with .ontological relation. (with an appropriate definition) which is in turn a subcategory of the current fact type (actuality type). - replace .fact. in the box in the diagram with .conceptual relation. (with an appropriate definition) which is in turn a subcategory of the current fact type (actuality type). - revise the .fact. wording in the definitions to reference actuality or ontological relation. - revise the terms that contain .fact. to something else: .relation., .verb concept., actuality type, ..) - change the signifier, .fact type. to a signifier that doesn.t communicate the wrong thing to the rest of the world (actuality type, concept relation, ..). We will also need to deal with, in a separate Issue, the conflation of .proposition. with ..performative. + .proposition.., and the separate, unrelated definition of .concept. and its subcategories and .proposition. and its subcategories which need integrating. Donald -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: 16 June 2009 14:59 To: SBVR RTF; Donald R. Chapin Subject: SBVR Issue 13716 - Question about Kinds of Facts and Fact Types (and ISO) After the March meeting, where the 13716 proposal was discussed, I was updating material that explains these 'template' fact/fact type differences to the 'mere mortal'. I checked the ISO document/diagram to see how ISO makes this kind of distinction in their concepts. Here (below) is the picture -- my annotations to the ISO diagram are in yellow highlighting/blue type. I asked Donald if he could check with the ISO folks to see if their picture has evolved or has more detail than shown in the document -- and whether this has any implications for our 'harmonization' -- and he reports that he now has some information. ~ Keri Subject: RE: SBVR Issue 13716 - Question about Kinds of Facts and Fact Types (and ISO) To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Fri, 19 Jun 2009 15:58:57 -0400 X-MIMETrack: Serialize by Router on D01MLC04/01/M/IBM(Release 8.0.1 HF8|December 19, 2008) at 06/19/2009 15:59:03 Could someone send out the current draft of 13716 -- I can't lay my hands on it. Mostly I'm sympathetic to what Donald says, but: If the category "conceptual relationships" only contains the generic/specialization relationship, then why bother with a category? Just identify that relationship in the diagram. Or is there another relationship that we haven't really acknowledged: the part-whole relationship mentioned in the diagram and that Ed wrote so eloquently about. What you call "ontological relations" are generally called "associative relationships". That latter term would be clearer, especially because ontologies definitely provide for the generic/specialization relationship. I'm not sure why you propose "replace ..fact. in the box in the diagram with ..conceptual relation. (with an appropriate definition) which is in turn a subcategory of the current fact type (actuality type)." "Fact" (proposition taken to be true) is not a conceptual relation in the sense of generic/specialization. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Donald Chapin" "Donald Chapin" 06/19/2009 11:16 AM Please respond to To "'keri'" , "'SBVR RTF'" cc Subject RE: SBVR Issue 13716 - Question about Kinds of Facts and Fact Types (and ISO) Keri, The question you posed is very astute and needs to be clearly, and well, answered. I had been pondering the need to answer it since our all day meeting during the March OMG conference. Prof. Gerhard Budin, my counterpart ISO TC 37 to OMG liaison, early in our collaboration in 2006 stressed to me the critical importance of distinguishing between two kinds of ..concept relations..: ..conceptual relations.. and ..ontological relations... ..Conceptual relations.. are relations directly between the concepts themselves; e.g. the specialization relation, where what is being talked about is one concept being related to another concept as being more narrow or more general, e.g. the concept ..points rental.. specializes the concept ..rental..; the concept ..noun concept.. specializes the concept ..concept... ..Ontological relations.. are relations between the actual things (ISO TC 37 objects) that correspond to concepts. While ..ontological relations.. are documented as relations between the concepts that correspond to the things that are actually related, they are always interpreted as relations between the things themselves; e.g. part whole relations, where what is being talked about is a tire itself in relation to an actual wheel rim on an actual car. ..Driver is responsible for rental. designates, based on the given use of the verb concept, the instances (states of affairs) of specific drivers that are responsible for a specific rental contract (in some time frame). ..Driver Joe Smith is responsible for rental EU-32764. designates one particular instance (state of affairs) for all time. In ISO 1087-1 only ..generic relation.. is a ..conceptual relation... All the rest are ..ontological relations... After discussing this with Prof. Budin, I think it would be useful to add those subcategories to the revision of ISO 1087-1 currently under way and on whose revision team I am. As part of considering the answer to your question, I discovered that the currently proposed Issue 13716 Resolution revisions to Clause 11.1.5 would introduce a fairly serious new problem into SBVR by making ..fact.. part of definitions in Clauses 8, 9, 11 & 12. At present ..fact.. is not referenced as part of definitions or fact type forms anywhere in Clauses 8, 9, 11 & 12 except: 1. in Clause 8.5, which is there to support the definition of the SBVR XMI, XSD and XML interchange files in Clause 13; 2. in the definition of elementary fact type which, as it stands, really belongs with the Clause 10 concepts; 3. in the definition of ..terminological dictionary.. which is talking about the documentation of SBVR as is Clause 8.5. Outside of Clause 8.5, there are 22 informal references to ..fact(s).. in the whole of Clauses 8, 9, 11 & 12, and in the majority of these the signifier ..fact. is used to mean ..actuality... SBVR is a metamodel for concept(definition)-centric special purpose business language dictionaries plus guidance specifications in terms those definition-centric dictionaries. SBVR is not a metamodel for fact modeling as practiced in, say, ORM and CogNIAM (ref: ISO Technical Report TR 9007, "The Orange Report"). Fact models of this kind are not represented in the SBVR XMI metamodel file (i.e. are not part of the SBVR metamodel). Their fact populations could not be included in SBVR interchange files (SBVR XSD + SBVR XML) unless local extensions to support them were defined. Fact modeling (so defined) is in SBVR only in Clause 10, specifically and solely to provide a formal interpretation for SBVR. Since the publication of the Orange Report in 1982, the signifier ..fact. has been used almost exclusively to refer to ..propositions that are taken to be true,. rather than to actualities. Even in 2004, when we separated ..actuality.. from ..proposition taken to be true,. it was too late to reverse 20 years of usage of the signifier ..fact.. SBVR includes the verb concept "concept1 specializes concept2", which can be used like any other verb concept, even in SBVR Structured English. You can say "the concept 'points rental' specializes the concept 'rental' ". The style of using the preferred term of the more general concept as the leading word in a definition (e.g. "points rental: rental that ...") is simply one of the fact type forms for ..concept1 specializes concept2. that are supported by Structured English syntax. Secondly, this distinction between concept(definition)-centric modeling and fact modeling (so defined) is quite seriously obscured in SBVR because of the conflation of two different concepts in SBVR Clause 8.1: - ..proposition.. meaning that is true or false (the ..semantic content. part in ..proposition.. + ..performative..) - ..proposition.. + ..performative.. (where the ..performative.. part is the ..communicative function.) e.g.: o proposition + ..deontic. performative = behavioral guidance o proposition + ..alethic. performative = definitional rule o proposition + ..taken to be true. performative = fact The core meanings are in the propositions which are then made into something else by combination with a particular performative. This is why there is no reason to include the concept ..fact.. at all in Clauses 8, 9 11 or 12 except to support the formulation of fact statements -- which are really out of scope for a standard for ..concept(definition)-centric special purpose business language dictionaries plus guidance specifications in terms those definiton-centric dictionaries.. Examples of general concepts can be provided by using names and fact type forms of individual concepts without needing to turn the individual concepts into facts (by adding the performative ..taken to be true.) so that fact statements can be used as examples. Thirdly, Clause 8.1 also defines two concepts (..concept.. and ..proposition..) as if they were completely separate things when in fact they are at most two perspectives on the same thing: general noun concept = open (existential) proposition individual noun concept = closed (existential) proposition general verb concept = open (relational) proposition individual verb concept = closed (relational) proposition (this is the verb concept that corresponds to a given state of affairs) Probably the best solution here is to add open/closed proposition categories, add existential/relational proposition categories, fix the subcategories of concept to fit the above, and have both ..concept.. and ..proposition.. as more general concepts for the subcategories. Fourthly and unfortunately, we did not always follow good term formation practices in SBVR. ..Fact type. as a signifier for the concept in Clause 8.1.1 is misleading because: - the definition is about actualities (it would be more accurately named ..actuality type. and/or concept relation) - almost every other use of the signifier ..fact type. outside of SBVR and in Clause 10 of SBVR mean ..type of fact.. I think we can fix the problems with the current Issue 13716 resolution quite simply: - replace ..fact type. in the box in the diagram with ..ontological relation. (with an appropriate definition) which is in turn a subcategory of the current fact type (actuality type). - replace ..fact. in the box in the diagram with ..conceptual relation. (with an appropriate definition) which is in turn a subcategory of the current fact type (actuality type). - revise the ..fact. wording in the definitions to reference actuality or ontological relation. - revise the terms that contain ..fact. to something else: ..relation., ..verb concept., actuality type, ..) - change the signifier, ..fact type. to a signifier that doesn..t communicate the wrong thing to the rest of the world (actuality type, concept relation, ..). We will also need to deal with, in a separate Issue, the conflation of ..proposition.. with ....performative.. + ..proposition..., and the separate, unrelated definition of ..concept.. and its subcategories and ..proposition.. and its subcategories which need integrating. Donald -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: 16 June 2009 14:59 To: SBVR RTF; Donald R. Chapin Subject: SBVR Issue 13716 - Question about Kinds of Facts and Fact Types (and ISO) After the March meeting, where the 13716 proposal was discussed, I was updating material that explains these 'template' fact/fact type differences to the 'mere mortal'. I checked the ISO document/diagram to see how ISO makes this kind of distinction in their concepts. Here (below) is the picture -- my annotations to the ISO diagram are in yellow highlighting/blue type. I asked Donald if he could check with the ISO folks to see if their picture has evolved or has more detail than shown in the document -- and whether this has any implications for our 'harmonization' -- and he reports that he now has some information. ~ Keri X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004100283 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Sat, 10 Apr 2010 16:29:40 -1000 Subject: SBVR RTF issue 13716 - updated Resolution document From: keri To: SBVR RTF , "Donald R. Chapin" Thread-topic: SBVR RTF issue 13716 - updated Resolution document Thread-index: AcrMKiSpwYQRp3xLSJG36hkPr+f2bwAxJfTKAwwGcK8= All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept .individual concept specializes concept. or any verb concept that specializes it categorization verb concept Definition: the verb concept .general concept specializes concept. or any verb concept that specializes it contextualization verb concept Definition: the verb concept .role ranges over general concept. or the verb concept .concept has facet. or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept .role ranges over general concept. or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept .concept has facet. or any verb concept that specializes it Option: in the definitions above, we can change each case of .verb concept that specializes. to .binary fact type that specializes. if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using .formulated. in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don SBVR Issue 13716 (v6).doc X-Mailer: AtMail PHP 5.61 To: "SBVR RTF" , "keri" Reply-To: john.hall@modelsystems.co.uk X-Origin: 86.2.189.137 X-Atmail-Account: john.hall@modelsystems.co.uk Date: Mon, 19 Apr 2010 13:43:46 +0100 Subject: Re: SBVR RTF issue 13716 - updated Resolution document From: John Hall Hi Keri, I have four specific comments: First, I think this is the only part of the specification where in the diagram we show synonyms as the primary terms (e.g. 'verb concept'), and preferred terms as synonyms (e.g. 'also fact type'), rather than as in the Structured English text. If the primary terms shown in the diagram are better (e.g. the terms make the meanings more intuitively obvious), why aren't they the preferred terms in the text? Second, we acknowledge that verb concepts can be specialized (that's the basis of verb concept templating). So, 'general concept' as a specialization of 'noun concept' ought to be 'general noun concept', to indicate that a general (noun) concept can't be a specialization of a verb concept. . Third, the definition of 'classification verb concept' applies only to noun concepts (an individual concept is a noun concept, so can specialize only a general noun concept). We ought to support classification of verb concepts in an analogous way. Which brings us back to the discussion on needing 'individual verb concept' - a concept, as opposed to 'actuality' and 'state of affairs', which are out in the world. [Note: part of the reason for my tardy reply is that I have been working on my homework from Jacksonville about this topic. It has become quite long and complicated, ranging over 4 issues. I'll simplify it as much as I can, and distribute it in the next day or two]. Fourth, there should also be necessities in 'categorization verb concept' that a general noun concept can specialize only another general noun concept, and that a (general) verb concept can specialize only another (general) verb concept - or perhaps there should be two specializations of 'categorization verb concept', one for noun concepts, the other for verb concepts. More generally, we need to ensure that when we use 'concept' in a definition (not just in the scope of this issue - all through the specification), the meaning applies to verb concepts as well as noun concepts. If it doesn't, we ought to change the definition so that: either, it does apply to both noun and verb concepts or, it is restricted to noun concepts only. Regards, John On Sun 11/04/10 03:29 , "keri" keri_ah@mac.com sent: All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept individual concept specializes concept or any verb concept that specializes it categorization verb concept Definition: the verb concept general concept specializes concept or any verb concept that specializes it contextualization verb concept Definition: the verb concept role ranges over general concept or the verb concept concept has facet or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept role ranges over general concept or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept concept has facet or any verb concept that specializes it Option: in the definitions above, we can change each case of verb concept that specializes to binary fact type that specializes if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using formulated in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=1 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004190123 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 19 Apr 2010 04:51:34 -1000 Subject: Re: SBVR RTF issue 13716 - updated Resolution document From: keri To: "Donald R. Chapin" , John Hall Cc: SBVR RTF Thread-topic: SBVR RTF issue 13716 - updated Resolution document Thread-index: AcrMKiSpwYQRp3xLSJG36hkPr+f2bwAxJfTKAwwGcK8Bp3eMEAAExmIQ Thanks, Donald (& John), for your additional input. Donald, Can you tell me what the milestones are for getting 13716 to agreement in time to make the cut for SBVR 1.1? I'll be offline after May 8 (until late July) so will need to hand off work on 13716 if it is still active during that period. Thanks. Keri On 4/19/10 2:39 AM, "Donald Chapin" wrote: Keri, While I was reviewing all the Issues to put into Ballot 3, I discovered a change in the resolution of Issue 13716 that I had missed before and that increases the ambiguity of the SBVR specification rather than decreases it. It is the change of the signifier of the more general concept of .situational role. from .object type. to .general concept.. I know that the SBVR specification says that .object type. and .general concept. are synonyms. However, this is greatly confusing as .object type. in SBVR means a (general) noun concept that is not a fact type role; while ISO 1087-1 defines general concept as all (noun) concepts that can have more than can correspond to two or more objects (over time). I agree that .general concept. is more business friendly than .object type.. In fact the signifier .object type. does not belong in SBVR at all as .object. is not an SBVR term. That concept needs a term that recognizes that it is a noun concept that is not a fact type role. Until this problem is fixed, changing the signifier of the more general concept of .situational role. to .general concept. opens up the ambiguity that fact type roles can be situational roles which they cannot be. One or more fact type roles can define a situational role, but fact type roles cannot be situational roles because fact type roles can never be .ranged over. by other fact type roles. If you can remove this change, we can add it into the resolution of an Issue that deals with the underlying problem. Sorry I didn.t spot this sooner. Donald -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: 11 April 2010 03:30 To: SBVR RTF; Donald R. Chapin Subject: SBVR RTF issue 13716 - updated Resolution document All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept .individual concept specializes concept. or any verb concept that specializes it categorization verb concept Definition: the verb concept .general concept specializes concept. or any verb concept that specializes it contextualization verb concept Definition: the verb concept .role ranges over general concept. or the verb concept .concept has facet. or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept .role ranges over general concept. or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept .concept has facet. or any verb concept that specializes it Option: in the definitions above, we can change each case of .verb concept that specializes. to .binary fact type that specializes. if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using .formulated. in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don From: Don Baisley To: "Donald.Chapin@btinternet.com" , "'keri'" , "'SBVR RTF'" Subject: RE: SBVR RTF issue 13716 - updated Resolution document Thread-Topic: SBVR RTF issue 13716 - updated Resolution document Thread-Index: AQHK2R89OvbmrrT29kCjxeF8twHXiZIqPc0A///5Z5A= Date: Mon, 19 Apr 2010 19:32:14 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Hi Donald, You talk about an ambiguity with .general concept., but I don.t see it. SBVR has .object type. and .general concept. as synonyms. Within the SBVR community, these two signifiers have the same meaning, which is a meaning given by ISO 1087-1. Are you referring to some non-SBVR meaning of one of these? The reason a fact type role is not a general concept is because it does not satisfy the definition (given by ISO) of general concept. A fact type role is never a noun concept that classifies things on the basis of their common properties. Rather, it characterizes instances based on involvement in a given fact type. I prefer using .general concept. over .object type., as Keri did in her write-up. Best regards, Don From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: Monday, April 19, 2010 5:39 AM To: 'keri'; 'SBVR RTF' Subject: RE: SBVR RTF issue 13716 - updated Resolution document Keri, While I was reviewing all the Issues to put into Ballot 3, I discovered a change in the resolution of Issue 13716 that I had missed before and that increases the ambiguity of the SBVR specification rather than decreases it. It is the change of the signifier of the more general concept of .situational role. from .object type. to .general concept.. I know that the SBVR specification says that .object type. and .general concept. are synonyms. However, this is greatly confusing as .object type. in SBVR means a (general) noun concept that is not a fact type role; while ISO 1087-1 defines general concept as all (noun) concepts that can have more than can correspond to two or more objects (over time). I agree that .general concept. is more business friendly than .object type.. In fact the signifier .object type. does not belong in SBVR at all as .object. is not an SBVR term. That concept needs a term that recognizes that it is a noun concept that is not a fact type role. Until this problem is fixed, changing the signifier of the more general concept of .situational role. to .general concept. opens up the ambiguity that fact type roles can be situational roles which they cannot be. One or more fact type roles can define a situational role, but fact type roles cannot be situational roles because fact type roles can never be .ranged over. by other fact type roles. If you can remove this change, we can add it into the resolution of an Issue that deals with the underlying problem. Sorry I didn.t spot this sooner. Donald -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: 11 April 2010 03:30 To: SBVR RTF; Donald R. Chapin Subject: SBVR RTF issue 13716 - updated Resolution document All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept .individual concept specializes concept. or any verb concept that specializes it categorization verb concept Definition: the verb concept .general concept specializes concept. or any verb concept that specializes it contextualization verb concept Definition: the verb concept .role ranges over general concept. or the verb concept .concept has facet. or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept .role ranges over general concept. or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept .concept has facet. or any verb concept that specializes it Option: in the definitions above, we can change each case of .verb concept that specializes. to .binary fact type that specializes. if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using .formulated. in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: FW5wF7oVM1mZ1B35MGTvArvUY2Htmr8foSO2bSCuoXCZfJLLeZrLQMcr0NwJ372BFUsrYMyLl_xe3TR4Iqe.HqEby6aSew06UfVsjF1ytDhWcK2PoSkt3ACx.zXpb75tN8yVIzljJ2wEykjwpwdFz89xpO5DcgwwlvfwZneOmNxSELSwNfwj9Lqs0Oi.jaWFaMpVDL4ciLC1IELUt.yb8WVvCkVByhiHUgo4GW5hpz2DO.XkEOuBqmroq6FufYOfjTiCipP5.zsvmnf5o7IBjC62uhXfKMo- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Apr 2010 15:40:26 -0500 To: keri , SBVR RTF , "Donald R. Chapin" From: "Ronald G. Ross" Subject: Re: SBVR RTF issue 13716 - updated Resolution document All, This draft resolution arose from discussion at the last SBVR meeting. I believe the idea was to give members time to study the proposed resolution and respond as appropriate. After consideration, I find that the draft resolution does not resolve the issue as posed. It also fails to clarify important terms, especially .categorization. and .classification. (formerly .assortment.). I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution fails to support these goals in important ways. What would a business person mean if they used the words .categorization. and .classification.? What example(s) would they give if you asked for some? I.m quite confident they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb concept 'general concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb concept 'individual concept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines .categorization verb concept. and .classification verb concept., not simply .categorization. and .classification., respectively. What are these former concepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: .A number of the definitions in subsection 11.1.5 are incomprehensible ... Unfortunately, these replacements are not terribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. Even the original issue 13716 write-up said as much: . . these concepts are defined as kinds of .fact types., but should actually be defined as kinds of *facts*.. The draft resolution does not fix that core problem; it just makes things even more complicated (no mean feat). With respect to the concepts .categorization. and .classification., I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use .categorization. and .classification. as standard SBVR terms so when people say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say .That represents or creates a categorization (or a classification).. 3. To be able to ask business people for real-life examples from their business . and have definitions to fall back on if they give something inappropriate. The parts of the draft resolution that address .true. verb concepts (fact types) are acceptable, even notable improvements. Below is what I propose as a resolution to Issue 13716. The definitions I propose are these (sorry, I don.t do SBVR-SE): * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find .is-role-of fact [type]. and .is-facet-of fact [type]. in the above scheme because there are no natural business terms (in English at least) for those concepts. (.Rollification. and .facetification. have been facetiously proposed, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., .categorization. and .classification.). The term .element of structure. is used prominently in my book, Business Rule Concepts 3rd ed. Surely, no one can doubt that: * The three categories above are key meanings in *structuring* a business concept system. * A concept system indeed has structure that needs to be designed (or adopted) by the business to operate. Here is a proposed definition for .element of structure. (again, sorry for the lack of SBVR-SE): the categorization scheme of the concept .meaning. that classifies a meaning based on its part in organizing a community.s concept system Finally, I recommend that the strange concepts .categorization verb concept. and .classification verb concept. be eliminated from the proposed resolution and from SBVR completely. Again, simpler is better. Ron At 09:29 PM 4/10/2010, keri wrote: All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept .individual concept specializes concept. or any verb concept that specializes it categorization verb concept Definition: the verb concept .general concept specializes concept. or any verb concept that specializes it contextualization verb concept Definition: the verb concept .role ranges over general concept. or the verb concept .concept has facet. or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept .role ranges over general concept. or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept .concept has facet. or any verb concept that specializes it Option: in the definitions above, we can change each case of .verb concept that specializes. to .binary fact type that specializes. if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using .formulated. in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: ZDuHwqsVM1mGRukbZsOpklxo0L3d52TR8ZxcWwNUw09h.bQMN5SZIusABhEXi1gFwYeO891jb_jC._eqDsYF72yL7s1c_OUNTU2JtgESPT9XDH0K37MSPt.pXTIYfOZD__lGXLy5Di8Nl.sm9OXLtZ51TfzhfHeCsRmd5h61dyOeRk2mARCTDuV7ZHZ1T_BXE0HBhFuRL0Akm0oCPQNEfQbDy.gGiKd7uW6ScVqD..zDmnVmnx8AQn6d7py_CI5vyl0- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Apr 2010 16:10:48 -0500 To: john.hall@modelsystems.co.uk, "SBVR RTF" , "keri" From: "Ronald G. Ross" Subject: Re: SBVR RTF issue 13716 - updated Resolution document At 07:43 AM 4/19/2010, John Hall wrote: Hi Keri, I have four specific comments: . Third, the definition of 'classification verb concept' applies only to noun concepts (an individual concept is a noun concept, so can specialize only a general noun concept). We ought to support classification of verb concepts in an analogous way. Which brings us back to the discussion on needing 'individual verb concept' - a concept, as opposed to 'actuality' and 'state of affairs', which are out in the world. [Note: part of the reason for my tardy reply is that I have been working on my homework from Jacksonville about this topic. It has become quite long and complicated, ranging over 4 issues. I'll simplify it as much as I can, and distribute it in the next day or two]. John, While I was preparing my response to the draft 13716 resolution that I sent just now, I ran across this very problem. I tried to reason it out for myself, but quickly ran to the limit of my knowledge. Here was my train of thought: * I had to think back whether "verb concept" is ever used where every role is an individual concept. Why would I need "Eiffel Tower is located in Paris" if I can simply say "The Eiffel Tower is located in Paris."?? * I looked at the SBVR definitions of "fact type" and "role". I find nothing that could prevent all the fact type roles of a fact type from being/representing/ranging-over individual concepts. * So I ask myself why? My answer: Let say for the scope of my vocabulary I am only interested in whether the Eiffel Tower is or isn't in Paris. Otherwise, I don't care where it is. Let's say I don't know where it is, but I want to be prepared for when I find out. So I specify the fact type form "Eiffel Tower is located in Paris". Then when I find out where it is, I can now confidently say either "The Eiffel Tower is located in Paris." or "The Eiffel Tower is not located in Paris." O.K. fine, I get that (if I'm right). * So now a new question: Why isn't the fact type expressed as "Eiffel Tower is located in Paris" an *individual* concept? Why can't the distinction between general and individual concepts also to made for fact types? This sample fact type could only possibly lead to one fact (correspond to one actuality), right? Ron P.S. The reason this question came up is because I think all elements of structure (so my e-mail response to the draft resolution) should involve at least one general (noun) concept ... so you actually can build on them ... but it appears that SBVR does not give me a term to use that restricts verb concepts that way. If it did, we might use it to restrict the definition for "element of structure" (structural member). More generally, we need to ensure that when we use 'concept' in a definition (not just in the scope of this issue - all through the specification), the meaning applies to verb concepts as well as noun concepts. If it doesn't, we ought to change the definition so that: either, it does apply to both noun and verb concepts or, it is restricted to noun concepts only. Regards, John On Sun 11/04/10 03:29 , "keri" keri_ah@mac.com sent: All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept individual concept specializes concept or any verb concept that specializes it categorization verb concept Definition: the verb concept general concept specializes concept or any verb concept that specializes it contextualization verb concept Definition: the verb concept role ranges over general concept or the verb concept concept has facet or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept role ranges over general concept or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept concept has facet or any verb concept that specializes it Option: in the definitions above, we can change each case of verb concept that specializes to binary fact type that specializes if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using formulated in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don From: Don Baisley To: SBVR RTF Subject: RE: SBVR RTF issue 13716 - updated Resolution document Thread-Topic: SBVR RTF issue 13716 - updated Resolution document Thread-Index: AQHK2R89OvbmrrT29kCjxeF8twHXiZIqxC8A//+celA= Date: Mon, 19 Apr 2010 21:47:03 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: I agree with Ron that .categorization. and .classification. are more useful concepts than what had been proposed. I see no need to keep the weird stuff: .categorization verb concept., etc. Regards, Don From: Ronald G. Ross [mailto:rross@BRSolutions.com] Sent: Monday, April 19, 2010 1:40 PM To: keri; SBVR RTF; Donald R. Chapin Subject: Re: SBVR RTF issue 13716 - updated Resolution document All, This draft resolution arose from discussion at the last SBVR meeting. I believe the idea was to give members time to study the proposed resolution and respond as appropriate. After consideration, I find that the draft resolution does not resolve the issue as posed. It also fails to clarify important terms, especially .categorization. and .classification. (formerly .assortment.). I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution fails to support these goals in important ways. What would a business person mean if they used the words .categorization. and .classification.? What example(s) would they give if you asked for some? I.m quite confident they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb concept 'general concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb concept 'individual concept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines .categorization verb concept. and .classification verb concept., not simply .categorization. and .classification., respectively. What are these former concepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: .A number of the definitions in subsection 11.1.5 are incomprehensible ... Unfortunately, these replacements are not terribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. Even the original issue 13716 write-up said as much: . . these concepts are defined as kinds of .fact types., but should actually be defined as kinds of *facts*.. The draft resolution does not fix that core problem; it just makes things even more complicated (no mean feat). With respect to the concepts .categorization. and .classification., I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use .categorization. and .classification. as standard SBVR terms so when people say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say .That represents or creates a categorization (or a classification).. 3. To be able to ask business people for real-life examples from their business . and have definitions to fall back on if they give something inappropriate. The parts of the draft resolution that address .true. verb concepts (fact types) are acceptable, even notable improvements. Below is what I propose as a resolution to Issue 13716. The definitions I propose are these (sorry, I don.t do SBVR-SE): * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find .is-role-of fact [type]. and .is-facet-of fact [type]. in the above scheme because there are no natural business terms (in English at least) for those concepts. (.Rollification. and .facetification. have been facetiously proposed, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., .categorization. and .classification.). The term .element of structure. is used prominently in my book, Business Rule Concepts 3rd ed. Surely, no one can doubt that: * The three categories above are key meanings in *structuring* a business concept system. * A concept system indeed has structure that needs to be designed (or adopted) by the business to operate. Here is a proposed definition for .element of structure. (again, sorry for the lack of SBVR-SE): the categorization scheme of the concept .meaning. that classifies a meaning based on its part in organizing a community.s concept system Finally, I recommend that the strange concepts .categorization verb concept. and .classification verb concept. be eliminated from the proposed resolution and from SBVR completely. Again, simpler is better. Ron At 09:29 PM 4/10/2010, keri wrote: All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept .individual concept specializes concept. or any verb concept that specializes it categorization verb concept Definition: the verb concept .general concept specializes concept. or any verb concept that specializes it contextualization verb concept Definition: the verb concept .role ranges over general concept. or the verb concept .concept has facet. or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept .role ranges over general concept. or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept .concept has facet. or any verb concept that specializes it Option: in the definitions above, we can change each case of .verb concept that specializes. to .binary fact type that specializes. if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using .formulated. in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004190230 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 19 Apr 2010 12:10:54 -1000 Subject: Re: SBVR RTF issue 13716 - updated Resolution document From: keri To: SBVR RTF Thread-topic: SBVR RTF issue 13716 - updated Resolution document Thread-index: AQHK2R89OvbmrrT29kCjxeF8twHXiZIqxC8A//+celCAAAdzYA== I find Ron's newly-proposed items useful, and I also favor retaining the ones we have worked up thus far. They are not in conflict with Ron's new items . they serve different purposes/audiences. Keri On 4/19/10 11:47 AM, "Don Baisley" wrote: I agree with Ron that .categorization. and .classification. are more useful concepts than what had been proposed. I see no need to keep the weird stuff: .categorization verb concept., etc. Regards, Don From: Ronald G. Ross [mailto:rross@BRSolutions.com] Sent: Monday, April 19, 2010 1:40 PM To: keri; SBVR RTF; Donald R. Chapin Subject: Re: SBVR RTF issue 13716 - updated Resolution document All, This draft resolution arose from discussion at the last SBVR meeting. I believe the idea was to give members time to study the proposed resolution and respond as appropriate. After consideration, I find that the draft resolution does not resolve the issue as posed. It also fails to clarify important terms, especially .categorization. and .classification. (formerly .assortment.). I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution fails to support these goals in important ways. What would a business person mean if they used the words .categorization. and .classification.? What example(s) would they give if you asked for some? I.m quite confident they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb concept 'general concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb concept 'individual concept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines .categorization verb concept. and .classification verb concept., not simply .categorization. and .classification., respectively. What are these former concepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: .A number of the definitions in subsection 11.1.5 are incomprehensible ... Unfortunately, these replacements are not terribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. Even the original issue 13716 write-up said as much: . . these concepts are defined as kinds of .fact types., but should actually be defined as kinds of *facts*.. The draft resolution does not fix that core problem; it just makes things even more complicated (no mean feat). With respect to the concepts .categorization. and .classification., I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use .categorization. and .classification. as standard SBVR terms so when people say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say .That represents or creates a categorization (or a classification).. 3. To be able to ask business people for real-life examples from their business . and have definitions to fall back on if they give something inappropriate. The parts of the draft resolution that address .true. verb concepts (fact types) are acceptable, even notable improvements. Below is what I propose as a resolution to Issue 13716. The definitions I propose are these (sorry, I don.t do SBVR-SE): * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find .is-role-of fact [type]. and .is-facet-of fact [type]. in the above scheme because there are no natural business terms (in English at least) for those concepts. (.Rollification. and .facetification. have been facetiously proposed, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., .categorization. and .classification.). The term .element of structure. is used prominently in my book, Business Rule Concepts 3rd ed. Surely, no one can doubt that: * The three categories above are key meanings in *structuring* a business concept system. * A concept system indeed has structure that needs to be designed (or adopted) by the business to operate. Here is a proposed definition for .element of structure. (again, sorry for the lack of SBVR-SE): the categorization scheme of the concept .meaning. that classifies a meaning based on its part in organizing a community.s concept system Finally, I recommend that the strange concepts .categorization verb concept. and .classification verb concept. be eliminated from the proposed resolution and from SBVR completely. Again, simpler is better. Ron At 09:29 PM 4/10/2010, keri wrote: All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept .individual concept specializes concept. or any verb concept that specializes it categorization verb concept Definition: the verb concept .general concept specializes concept. or any verb concept that specializes it contextualization verb concept Definition: the verb concept .role ranges over general concept. or the verb concept .concept has facet. or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept .role ranges over general concept. or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept .concept has facet. or any verb concept that specializes it Option: in the definitions above, we can change each case of .verb concept that specializes. to .binary fact type that specializes. if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using .formulated. in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004190231 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 19 Apr 2010 12:17:52 -1000 Subject: Re: SBVR RTF issue 13716 - updated Resolution document From: keri To: "Donald R. Chapin" , SBVR RTF Thread-topic: SBVR RTF issue 13716 - updated Resolution document Thread-index: AQHK2R89OvbmrrT29kCjxeF8twHXiZIqPc0A///5Z5CAADLbgg== Donald, I'm confused by your request. Issue 13716 is written from the perspective of SBVR 1.0 which has these two terms as synonyms. It appears that making the change you suggest, in anticipation of an issue not yet logged, would introduce an unnecessary dependency between 13716 and the issue yet-to-come. Would it not be better to deal with any needed changes to 11.1.5 as part of your new issue, as a part of its resolution of your object type/general concept question? Keri On 4/19/10 9:32 AM, "Don Baisley" wrote: Hi Donald, You talk about an ambiguity with .general concept., but I don.t see it. SBVR has .object type. and .general concept. as synonyms. Within the SBVR community, these two signifiers have the same meaning, which is a meaning given by ISO 1087-1. Are you referring to some non-SBVR meaning of one of these? The reason a fact type role is not a general concept is because it does not satisfy the definition (given by ISO) of general concept. A fact type role is never a noun concept that classifies things on the basis of their common properties. Rather, it characterizes instances based on involvement in a given fact type. I prefer using .general concept. over .object type., as Keri did in her write-up. Best regards, Don From: Donald Chapin [mailto:Donald.Chapin@btinternet.com] Sent: Monday, April 19, 2010 5:39 AM To: 'keri'; 'SBVR RTF' Subject: RE: SBVR RTF issue 13716 - updated Resolution document Keri, While I was reviewing all the Issues to put into Ballot 3, I discovered a change in the resolution of Issue 13716 that I had missed before and that increases the ambiguity of the SBVR specification rather than decreases it. It is the change of the signifier of the more general concept of .situational role. from .object type. to .general concept.. I know that the SBVR specification says that .object type. and .general concept. are synonyms. However, this is greatly confusing as .object type. in SBVR means a (general) noun concept that is not a fact type role; while ISO 1087-1 defines general concept as all (noun) concepts that can have more than can correspond to two or more objects (over time). I agree that .general concept. is more business friendly than .object type.. In fact the signifier .object type. does not belong in SBVR at all as .object. is not an SBVR term. That concept needs a term that recognizes that it is a noun concept that is not a fact type role. Until this problem is fixed, changing the signifier of the more general concept of .situational role. to .general concept. opens up the ambiguity that fact type roles can be situational roles which they cannot be. One or more fact type roles can define a situational role, but fact type roles cannot be situational roles because fact type roles can never be .ranged over. by other fact type roles. If you can remove this change, we can add it into the resolution of an Issue that deals with the underlying problem. Sorry I didn.t spot this sooner. Donald -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: 11 April 2010 03:30 To: SBVR RTF; Donald R. Chapin Subject: SBVR RTF issue 13716 - updated Resolution document All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept .individual concept specializes concept. or any verb concept that specializes it categorization verb concept Definition: the verb concept .general concept specializes concept. or any verb concept that specializes it contextualization verb concept Definition: the verb concept .role ranges over general concept. or the verb concept .concept has facet. or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept .role ranges over general concept. or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept .concept has facet. or any verb concept that specializes it Option: in the definitions above, we can change each case of .verb concept that specializes. to .binary fact type that specializes. if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using .formulated. in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004190236 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 19 Apr 2010 12:33:18 -1000 Subject: Re: SBVR RTF issue 13716 - updated Resolution document From: keri To: John Hall , SBVR RTF Thread-topic: SBVR RTF issue 13716 - updated Resolution document Thread-index: AcrgEE7SjX3RDkwDEd+wswARJM+Cgg== John, Some words, below.... On 4/19/10 2:43 AM, "John Hall" wrote: Hi Keri, I have four specific comments: First, I think this is the only part of the specification where in the diagram we show synonyms as the primary terms (e.g. 'verb concept'), and preferred terms as synonyms (e.g. 'also fact type'), rather than as in the Structured English text. If the primary terms shown in the diagram are better (e.g. the terms make the meanings more intuitively obvious), why aren't they the preferred terms in the text? Is this an issue with this issue, or a general question? For the latter, I can offer my opinion that I thought the point of having synonyms was to let an audience use the term that best suited it. If there is some unwritten rule about primary terms needing to be used in other vocabularies then perhaps that rule needs to be written down. If it was up to me, certainly, I would like to see different primary terms in the place where they are originally introduced. But the primary terms, as I recall, were decided by the preference of the vocabulary/audience where first defined. Does that audience now prefer, for example, to have 'verb concept' be primary, rather than 'fact type'? I don't know. I could be an interesting (other) issue. Second, we acknowledge that verb concepts can be specialized (that's the basis of verb concept templating). So, 'general concept' as a specialization of 'noun concept' ought to be 'general noun concept', to indicate that a general (noun) concept can't be a specialization of a verb concept. I was simply attempting to apply the existing term for the concept already reflected in 11.1.5. Are you asking for the current synonym term 'general concept' to be re-termed as 'general noun concept'? ... as part of this Issue? Third, the definition of 'classification verb concept' applies only to noun concepts (an individual concept is a noun concept, so can specialize only a general noun concept). We ought to support classification of verb concepts in an analogous way. Which brings us back to the discussion on needing 'individual verb concept' - a concept, as opposed to 'actuality' and 'state of affairs', which are out in the world. [Note: part of the reason for my tardy reply is that I have been working on my homework from Jacksonville about this topic. It has become quite long and complicated, ranging over 4 issues. I'll simplify it as much as I can, and distribute it in the next day or two]. Can you make these as suggestions under the banner of the Issue that you are compiling? I'm concerned that making these part of 13716 introduces an interdependency between these two Issues. Fourth, there should also be necessities in 'categorization verb concept' that a general noun concept can specialize only another general noun concept, and that a (general) verb concept can specialize only another (general) verb concept - or perhaps there should be two specializations of 'categorization verb concept', one for noun concepts, the other for verb concepts. And, again, perhaps part of your Issue's resolution? ~ Keri More generally, we need to ensure that when we use 'concept' in a definition (not just in the scope of this issue - all through the specification), the meaning applies to verb concepts as well as noun concepts. If it doesn't, we ought to change the definition so that: either, it does apply to both noun and verb concepts or, it is restricted to noun concepts only. Regards, John On Sun 11/04/10 03:29 , "keri" keri_ah@mac.com sent: All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept .individual concept specializes concept. or any verb concept that specializes it categorization verb concept Definition: the verb concept .general concept specializes concept. or any verb concept that specializes it contextualization verb concept Definition: the verb concept .role ranges over general concept. or the verb concept .concept has facet. or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept .role ranges over general concept. or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept .concept has facet. or any verb concept that specializes it Option: in the definitions above, we can change each case of .verb concept that specializes. to .binary fact type that specializes. if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using .formulated. in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don Subject: RE: SBVR RTF issue 13716 - updated Resolution document Date: Tue, 20 Apr 2010 07:17:36 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: SBVR RTF issue 13716 - updated Resolution document thread-index: AcrgAK1NS8jQBqWiSxu22hb73gyA0AAQdvtw From: "Markus Schacher" To: "Ronald G. Ross" , "keri" , "SBVR RTF" , "Donald R. Chapin" X-OriginalArrivalTime: 20 Apr 2010 05:21:20.0790 (UTC) FILETIME=[4FB3D360:01CAE049] Ron, I understand that you want to turn the verb concepts "general concept GC specializes concept C" and "individual concept IC specializes concept C" from fact types into facts. I think this is correct as they represent the following propositions assumed to be true (a kind of facts): * categorization: "for each individual concept IC specializes C is true that IC specializes GC" * classification: "for each individual concept IC specializes C is true that IC is a member of C" The second expression could even be replaced by "it is true that IC is a member of C" which makes it obvious that this is a fact. In contrast to those facts, verb concepts such as "buyer B buys good G" are not facts by themselves but just types of a set of potential facts that may or may not be true. There is no quantification such as "for each..." involved that would turn this phrase into a ground phrase. To sum-up: I believe that categorization and classification are facts whereas verb concepts are fact types (a different kind of animal) and that you, Ron, are correct. Best regards, Markus -------------------------------------------------------------------------------- From: Ronald G. Ross [mailto:rross@BRSolutions.com] Sent: Montag, 19. April 2010 22:40 To: keri; SBVR RTF; Donald R. Chapin Subject: Re: SBVR RTF issue 13716 - updated Resolution document All, This draft resolution arose from discussion at the last SBVR meeting. I believe the idea was to give members time to study the proposed resolution and respond as appropriate. After consideration, I find that the draft resolution does not resolve the issue as posed. It also fails to clarify important terms, especially .categorization. and .classification. (formerly .assortment.). I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution fails to support these goals in important ways. What would a business person mean if they used the words .categorization. and .classification.? What example(s) would they give if you asked for some? I.m quite confident they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb concept 'general concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb concept 'individual concept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines .categorization verb concept. and .classification verb concept., not simply .categorization. and .classification., respectively. What are these former concepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: .A number of the definitions in subsection 11.1.5 are incomprehensible ... Unfortunately, these replacements are not terribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. Even the original issue 13716 write-up said as much: . . these concepts are defined as kinds of .fact types., but should actually be defined as kinds of *facts*.. The draft resolution does not fix that core problem; it just makes things even more complicated (no mean feat). With respect to the concepts .categorization. and .classification., I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use .categorization. and .classification. as standard SBVR terms so when people say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say .That represents or creates a categorization (or a classification).. 3. To be able to ask business people for real-life examples from their business . and have definitions to fall back on if they give something inappropriate. The parts of the draft resolution that address .true. verb concepts (fact types) are acceptable, even notable improvements. Below is what I propose as a resolution to Issue 13716. The definitions I propose are these (sorry, I don.t do SBVR-SE): * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find .is-role-of fact [type]. and .is-facet-of fact [type]. in the above scheme because there are no natural business terms (in English at least) for those concepts. (.Rollification. and .facetification. have been facetiously proposed, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., .categorization. and .classification.). The term .element of structure. is used prominently in my book, Business Rule Concepts 3rd ed. Surely, no one can doubt that: * The three categories above are key meanings in *structuring* a business concept system. * A concept system indeed has structure that needs to be designed (or adopted) by the business to operate. Here is a proposed definition for .element of structure. (again, sorry for the lack of SBVR-SE): the categorization scheme of the concept .meaning. that classifies a meaning based on its part in organizing a community.s concept system Finally, I recommend that the strange concepts .categorization verb concept. and .classification verb concept. be eliminated from the proposed resolution and from SBVR completely. Again, simpler is better. Ron At 09:29 PM 4/10/2010, keri wrote: All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept .individual concept specializes concept. or any verb concept that specializes it categorization verb concept Definition: the verb concept .general concept specializes concept. or any verb concept that specializes it contextualization verb concept Definition: the verb concept .role ranges over general concept. or the verb concept .concept has facet. or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept .role ranges over general concept. or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept .concept has facet. or any verb concept that specializes it Option: in the definitions above, we can change each case of .verb concept that specializes. to .binary fact type that specializes. if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using .formulated. in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003260086 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 26 Mar 2010 04:15:07 -1000 Subject: [OFFLINE] SBVR RTF issue 13716 - for your eyes From: keri To: SBVR RTF , "Donald R. Chapin" , Don Baisley Thread-topic: [OFFLINE] SBVR RTF issue 13716 - for your eyes Thread-index: AcrMKiSpwYQRp3xLSJG36hkPr+f2bwAxJfTK All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept .individual concept specializes concept. or any verb concept that specializes it categorization verb concept Definition: the verb concept .general concept specializes concept. or any verb concept that specializes it contextualization verb concept Definition: the verb concept .role ranges over general concept. or the verb concept .concept has facet. or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept .role ranges over general concept. or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept .concept has facet. or any verb concept that specializes it Option: in the definitions above, we can change each case of .verb concept that specializes. to .binary fact type that specializes. if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using .formulated. in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 17 Mar 2010 13:06:20 -1000 Subject: SBVR RTF issue 13716 - for discussion at next week's meeting From: keri To: "Donald R. Chapin" , SBVR RTF Thread-Topic: SBVR RTF issue 13716 - for discussion at next week's meeting Thread-Index: AcmqcYNwwhwKvBZkEd6JWAARJM+CggDKI0NFAJUF2FAA/j+jmQEpW1MODlPYQ2A1Ep/zOA== All, Attached is the latest work on Issue 13716, updated from our previous discussions on this Issue. The attached documents are (1) a view of 11.1.5, as it would appear and (2) the change-tracked view of the same. Note that there are also a few supporting changes in other sub-clauses, but the thrust of this Issue is to "refactor" (correct & improve) sub-clause 11.1.5. Donald, please place this on next week's agenda for discussion and (hopefully) agreement. If agreed, I will then put the changes into the appropriate "Resolution Edit Instruction" format. Regards, Keri Issue 13716-SBVR 1.0 ch11.1.5 - UPDATED (rev4).doc Issue 13716-SBVR 1.0 ch11.1.5 - UPDATED (rev4-CT).doc Subject: Re: SBVR RTF issue 13716 - for discussion at next week's meeting X-KeepSent: 72F692E2:6963BD15-852576EA:00416753; type=4; name=$KeepSent To: SBVR RTF X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Thu, 18 Mar 2010 08:31:27 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 03/18/2010 08:32:18 Keri, I read through the change-tracked version and have these comments: 1. I don't understand how 'Verb Concept Templating' is a proper segmentation given that 'is property-of verb concept' is a kind of 'associative verb concept' and both are included in the segmentation. The same point arises with respect to 'conceptualization verb concept', 'is-role-of verb concept' and 'is-facet-of verb concept'. 2. Why eliminate the "Dictionary Basis" entries from 'property-of verb concept'? 3. The (new) definition for 'classification verb concept' seems to be an example, not a definition of a category. And we are missing a definition? Ditto for 'categorization verb concept'. (Or should these be, for example "the verb concept 'general concept specializes concept' or a specialization of the verb concept 'general concept specializes concept' ".) Similar points apply to 'is-role-of verb concept' and 'is-facet-of verb concept'. 4. The general concept of both 'is-role-of verb concept' and 'is-facet-of verb concept' is given as 'contextualization verb concept' but the latter is defined as 'is-role-of verb concept or is-facet-of verb concept'. This creates an inheritance 'loop'. That is one, can't tell determine whether a verb concept is an 'is-role-of verb concept' or an 'is-facet-of verb concept' without knowing whether it is a 'contextualization verb concept'. But in order to know whether a verb concept is a 'contextualization concept' you have to identify the verb concept as either an 'is-role-of verb concept' or an 'is-facet-of verb concept'. 5. Why are we deleting the first two Necessities of 'is-role-of verb concept' and 'is-facet-of verb concept'? 6. Could we make the definition of 'facet' a little clearer by adding 'given' so that it reads ' concept that generalizes a given concept but incorporates only those characteristics that are relevant to a particular viewpoint'. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com keri ---03/17/2010 07:10:54 PM---All, keri 03/17/2010 07:06 PM To "Donald R. Chapin" , SBVR RTF cc Subject SBVR RTF issue 13716 - for discussion at next week's meeting All, Attached is the latest work on Issue 13716, updated from our previous discussions on this Issue. The attached documents are (1) a view of 11.1.5, as it would appear and (2) the change-tracked view of the same. Note that there are also a few supporting changes in other sub-clauses, but the thrust of this Issue is to "refactor" (correct & improve) sub-clause 11.1.5. Donald, please place this on next week's agenda for discussion and (hopefully) agreement. If agreed, I will then put the changes into the appropriate "Resolution Edit Instruction" format. Regards, Keri[attachment "Issue 13716-SBVR 1.0 ch11.1.5 - UPDATED (rev4).doc" deleted by Mark H Linehan/Watson/IBM] [attachment "Issue 13716-SBVR 1.0 ch11.1.5 - UPDATED (rev4-CT).doc" deleted by Mark H Linehan/Watson/IBM] pic04419.gif User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 18 Mar 2010 08:22:59 -1000 Subject: Re: SBVR RTF issue 13716 - for discussion at next week's meeting From: keri To: Mark H Linehan , SBVR RTF Thread-Topic: SBVR RTF issue 13716 - for discussion at next week's meeting Thread-Index: AcrGyAmVSBCLcDK7Ed+oOQARJM+Cgg== From: Mark H Linehan User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 18 Mar 2010 10:06:20 -1000 Subject: Re: SBVR RTF issue 13716 - for discussion at next week's meeting From: keri To: Mark H Linehan , SBVR RTF Thread-Topic: SBVR RTF issue 13716 - for discussion at next week's meeting Thread-Index: AcrG1nmqt/JGADLJEd+oOQARJM+Cgg== From: Mark H Linehan Date: March 18, 2010 9:00:26 AM GMT-10:00 To: keri Subject: Re: SBVR RTF issue 13716 - for discussion at next week's meeting Further comments like this. -------------------------------- 1. I don't understand how 'Verb Concept Templating' is a proper segmentation given that 'is property-of verb concept' is a kind of 'associative verb concept' and both are included in the segmentation. The same point arises with respect to 'conceptualization verb concept', 'is-role-of verb concept' and 'is-facet-of verb concept'. Are you saying that your view of 'segmentation' would not allow for categories of categories? I don't believe that this a restriction that the SBVR notion has. Input anyone??? The definition of 'segmentation' says that it's categories must be '... complete (total) and disjoint with respect to the general concept that has the categorization scheme '. In the proposed resolution, 'is-property-of verb concept' is not disjoint with respect to 'associative verb concept' because an instance of the first is also an instance of the latter. 'Disjoint' means that every instance classifies into a maximum of one category, and 'complete' means that every instance classifies into at least one category. You can certainly define a concept structure with categories of categories, but a segmentation scheme can't contain both a more general category and a specialization of that category. A scheme can certainly contain a structuring of categories as a taxonomy/hierarchy. The important point about a 'segmentation' is that the instances allocated into the scheme are all accounted for, and each only once . i.e., every instance allocated to one and only one [lowest] category. If there are seven instances and one of the instances is an is-property-of verb concept, that is still only one instance of the seven. It is not two instances because it is simultaneously an associative verb concept (its more general concept), plus however many other 'boxes' are above it in the hierarchy. However, if it's felt that there is some flaw in the definition of 'segmentation' that doesn't get this intent exactly as it should be, that would be a separate issue. ... 3. The (new) definition for 'classification verb concept' seems to be an example, not a definition of a category. And we are missing a definition? Ditto for 'categorization verb concept'. (Or should these be, for example "the verb concept 'general concept specializes concept' or a specialization of the verb concept 'general concept specializes concept' ".) Similar points apply to 'is-role-of verb concept' and 'is-facet-of verb concept'. My bad. These four notions are now individual concepts. I reflected that in the style used for the Definition but neglected to capitalize the names . e.g., Classification verb concept, Categorization verb concept, Is-role-of verb concept, Is-facet-of verb concept. I will make those changes. Hmm, the examples of several of these show multiple instances. So how can these verb concepts be individual concepts? No, the examples show multiple uses. Note the wording of the examples . each illustrates a fact that is forumlated using the single verb concept. Also, I might specialize any of these 4 verb concepts. The specializations themselves may fall into the categorizations given. I suppose so. Then you'd be specializing the fact type, the way we did in the 11.1.2 additions, and giving it a name. But that's beyond the scope of this issue. 4. The general concept of both 'is-role-of verb concept' and 'is-facet-of verb concept' is given as 'contextualization verb concept' but the latter is defined as 'is-role-of verb concept or is-facet-of verb concept'. This creates an inheritance 'loop'. That is one, can't tell determine whether a verb concept is an 'is-role-of verb concept' or an 'is-facet-of verb concept' without knowing whether it is a 'contextualization verb concept'. But in order to know whether a verb concept is a 'contextualization concept' you have to identify the verb concept as either an 'is-role-of verb concept' or an 'is-facet-of verb concept'. Actually, these two entries are written specifically to avoid the appearance of such a 'loop. The Definition text for Is-role-of verb concept and Is-facet-of verb concept does NOT refer to the more general concept as part of the Definition text; each definition stands on its own. For example, something can be referred to as "Is-role-of verb concept" when it is the verb concept 'role ranges over general concept'. The General Concept caption has been used in those two entries to show that these two notions have been generalized as the more general concept. And the more general concept simply uses the extensional form of definition (which is not that uncommon when categorization structures are constructed . nodes are often brought together as a 'super node' in the hierarchy just because ... think 'tax code'!) I have no problem with extensional definitions. I think the "General Concept" caption should be omitted from these two entries to avoid this confusion. I prefer to leave it. For completeness, don't we have to declare the more general concept, somewhere, as part of the entry? Hmmm... I suppose it could be argued that it's taken care of by the more general concept entry, but somehow it seems incomplete to leave it out. However, if the group wants to remove it (and it's legit. to do so) then okay. 5. Why are we deleting the first two Necessities of 'is-role-of verb concept' and 'is-facet-of verb concept'? Because they are no longer correct. I think this depends upon whether we end up agreeing (or not) that "is-role-of verb concept" and "is-face-of verb concept" are individual concepts. Of course. And since this is a proposal that this is the case (i.e., to use individual concepts) then the Necessities are gone as part of the overall change. (The "individual concept" approach came up at a previous meeting ... Ed's suggestion, I believe. That was better received by the group than the earlier stab which had tried to mix fact types and [metamodel] facts in one 'picture' ....) 6. Could we make the definition of 'facet' a little clearer by adding 'given' so that it reads ' concept that generalizes a given concept but incorporates only those characteristics that are relevant to a particular viewpoint'. Sounds like an improvement? Any objections??? Thanks! Keri A 6th point -- shouldn't "classification verb concept" and "categorization verb concept" have "General Concept: binary verb concept"? I think we are relying on Clause 8 to take care of all of that kind of detail . i.e., where the base "concept specializes concept" is first specified. - K -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com To: sbvr-rtf@omg.org Subject: Re: SBVR RTF issue 13716 - for discussion at next week's meeting X-KeepSent: 308EAEF1:649E3BD5-852576EB:000B8B2E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Thu, 18 Mar 2010 22:16:25 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 03/18/2010 22:16:26, Serialize complete at 03/18/2010 22:16:26 Further comments like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com keri 03/18/2010 04:06 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: SBVR RTF issue 13716 - for discussion at next week's meeting From: Mark H Linehan Date: March 18, 2010 9:00:26 AM GMT-10:00 To: keri Subject: Re: SBVR RTF issue 13716 - for discussion at next week's meeting Further comments like this. -------------------------------- 1. I don't understand how 'Verb Concept Templating' is a proper segmentation given that 'is property-of verb concept' is a kind of 'associative verb concept' and both are included in the segmentation. The same point arises with respect to 'conceptualization verb concept', 'is-role-of verb concept' and 'is-facet-of verb concept'. Are you saying that your view of 'segmentation' would not allow for categories of categories? I don't believe that this a restriction that the SBVR notion has. Input anyone??? The definition of 'segmentation' says that it's categories must be '... complete (total) and disjoint with respect to the general concept that has the categorization scheme '. In the proposed resolution, 'is-property-of verb concept' is not disjoint with respect to 'associative verb concept' because an instance of the first is also an instance of the latter. 'Disjoint' means that every instance classifies into a maximum of one category, and 'complete' means that every instance classifies into at least one category. You can certainly define a concept structure with categories of categories, but a segmentation scheme can't contain both a more general category and a specialization of that category. A scheme can certainly contain a structuring of categories as a taxonomy/hierarchy. The important point about a 'segmentation' is that the instances allocated into the scheme are all accounted for, and each only once . i.e., everry instance allocated to one and only one [lowest] category. If there are seven instances and one of the instances is an is-property-of verb concept, that is still only one instance of the seven. It is not two instances because it is simultaneously an associative verb concept (its more general concept), plus however many other 'boxes' are above it in the hierarchy. However, if it's felt that there is some flaw in the definition of 'segmentation' that doesn't get this intent exactly as it should be, that would be a separate issue. I don't think that plain reading of the existing definition of 'segmentation' supports the idea that the "disjoint" categories can be subcategories of one another. An easy fix would be to drop the subcategories out of the list of Necessities. ... 3. The (new) definition for 'classification verb concept' seems to be an example, not a definition of a category. And we are missing a definition? Ditto for 'categorization verb concept'. (Or should these be, for example "the verb concept 'general concept specializes concept' or a specialization of the verb concept 'general concept specializes concept' ".) Similar points apply to 'is-role-of verb concept' and 'is-facet-of verb concept'. My bad. These four notions are now individual concepts. I reflected that in the style used for the Definition but neglected to capitalize the names . e.g., Classification verb cooncept, Categorization verb concept, Is-role-of verb concept, Is-facet-of verb concept. I will make those changes. Hmm, the examples of several of these show multiple instances. So how can these verb concepts be individual concepts? No, the examples show multiple uses. Note the wording of the examples . each illustrates a fact that is forumlated usinng the single verb concept. How is a "use" of a verb concept different from an instance of the verb concept? We have " 'replacement car' ranges over 'rental car' " and " 'pickup branch' ranges over 'branch' ". Wouldn't each of these verb concepts be categorized as 'is-role-of verb concepts"? Also, I might specialize any of these 4 verb concepts. The specializations themselves may fall into the categorizations given. I suppose so. Then you'd be specializing the fact type, the way we did in the 11.1.2 additions, and giving it a name. But that's beyond the scope of this issue. It addresses the question of whether 'is-role-of verb concept' is really an individual concept. 4. The general concept of both 'is-role-of verb concept' and 'is-facet-of verb concept' is given as 'contextualization verb concept' but the latter is defined as 'is-role-of verb concept or is-facet-of verb concept'. This creates an inheritance 'loop'. That is one, can't tell determine whether a verb concept is an 'is-role-of verb concept' or an 'is-facet-of verb concept' without knowing whether it is a 'contextualization verb concept'. But in order to know whether a verb concept is a 'contextualization concept' you have to identify the verb concept as either an 'is-role-of verb concept' or an 'is-facet-of verb concept'. Actually, these two entries are written specifically to avoid the appearance of such a 'loop. The Definition text for Is-role-of verb concept and Is-facet-of verb concept does NOT refer to the more general concept as part of the Definition text; each definition stands on its own. For example, something can be referred to as "Is-role-of verb concept" when it is the verb concept 'role ranges over general concept'. The General Concept caption has been used in those two entries to show that these two notions have been generalized as the more general concept. And the more general concept simply uses the extensional form of definition (which is not that uncommon when categorization structures are constructed . nodes are often brought ttogether as a 'super node' in the hierarchy just because ... think 'tax code'!) I have no problem with extensional definitions. I think the "General Concept" caption should be omitted from these two entries to avoid this confusion. I prefer to leave it. For completeness, don't we have to declare the more general concept, somewhere, as part of the entry? Hmmm... I suppose it could be argued that it's taken care of by the more general concept entry, but somehow it seems incomplete to leave it out.Yes, I think it is taken care of in the extensional definition. However, if the group wants to remove it (and it's legit. to do so) then okay. 5. Why are we deleting the first two Necessities of 'is-role-of verb concept' and 'is-facet-of verb concept'? Because they are no longer correct. I think this depends upon whether we end up agreeing (or not) that "is-role-of verb concept" and "is-face-of verb concept" are individual concepts. Of course. And since this is a proposal that this is the case (i.e., to use individual concepts) then the Necessities are gone as part of the overall change. (The "individual concept" approach came up at a previous meeting ... Ed's suggestion, I believe. That was better received by the group than the earlier stab which had tried to mix fact types and [metamodel] facts in one 'picture' ....) 6. Could we make the definition of 'facet' a little clearer by adding 'given' so that it reads ' concept that generalizes a given concept but incorporates only those characteristics that are relevant to a particular viewpoint'. Sounds like an improvement? Any objections??? Thanks! Keri A 6th point -- shouldn't "classification verb concept" and "categorization verb concept" have "General Concept: binary verb concept"? I think we are relying on Clause 8 to take care of all of that kind of detail . i.e., where the base "concept speecializes concept" is first specified. - K -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 19 Mar 2010 12:41:26 -1000 Subject: Re: SBVR RTF issue 13716 - for discussion at next week's meeting From: keri To: SBVR RTF , Mark H Linehan Thread-Topic: SBVR RTF issue 13716 - for discussion at next week's meeting Thread-Index: AcrHtU7jjaj6YzOoEd+sdQARJM+Cgg== A big thanks to Mark for the careful read and probing questions. An updated set of documents is attached. Mark, I have made some comments to your comments, below. Keri From: Mark H Linehan Date: March 18, 2010 4:16:25 PM GMT-10:00 To: sbvr-rtf@omg.org Subject: Re: SBVR RTF issue 13716 - for discussion at next week's meeting Further comments like this. -------------------------------- ... However, if it's felt that there is some flaw in the definition of 'segmentation' that doesn't get this intent exactly as it should be, that would be a separate issue. I don't think that plain reading of the existing definition of 'segmentation' supports the idea that the "disjoint" categories can be subcategories of one another. An easy fix would be to drop the subcategories out of the list of Necessities. I have changed 'segmentation' to 'categorization scheme'. (If needed, the clarification of 'segmentation' can be raised as its own issue.) ... No, the examples show multiple uses. Note the wording of the examples . each illustrates a fact that is forumlated using the single verb concept. How is a "use" of a verb concept different from an instance of the verb concept? We have " 'replacement car' ranges over 'rental car' " and " 'pickup branch' ranges over 'branch' ". Wouldn't each of these verb concepts be categorized as 'is-role-of verb concepts"? Hmmm... when you say "each of these verb concepts" are you referring to the Examples? The Example does not say that 'replacement car ranges over rental car' is a verb concept/fact type (form). What the examples intend to show are some statements of facts that use this particular verb concept to make a fact statement. Each fact statement is a complete sentence; each ends with a period. The full statement of the facts you refer to is: The role .replacement car. ranges over the general concept .rental car.. The role .pick-up branch. ranges over the general concept .branch.. These fact statements MENTION some concepts and USE this particular verb concept from SBVR. However, if you think it would be helpful to illustrate a case of 'instance' then this could be added as an Example so that the two could be seen side-by-side: The actuality that the role .replacement car. ranges over the general concept .rental car. is an instance of the Is-role-of Verb Concept. The fact that the role .replacement car. ranges over the general concept .rental car. is formulated using the Is-role-of Verb Concept. (BTW, "situational" has been added before "role" in the Examples.) ... I think the "General Concept" caption should be omitted from these two entries to avoid this confusion. I prefer to leave it. For completeness, don't we have to declare the more general concept, somewhere, as part of the entry? Hmmm... I suppose it could be argued that it's taken care of by the more general concept entry, but somehow it seems incomplete to leave it out. Yes, I think it is taken care of in the extensional definition. However, if the group wants to remove it (and it's legit. to do so) then okay. For discussion/decision by the group . keep or toss? ~ Keri Issue 13716-SBVR 1.0 ch11.1.5 - UPDATED (rev5).doc Issue 13716-SBVR 1.0 ch11.1.5 - UPDATED (rev5-CT).doc X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1003220254 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 22 Mar 2010 10:56:57 -1000 Subject: Re: SBVR RTF issue 13716 - for discussion at next week's meeting From: keri To: SBVR RTF Thread-topic: SBVR RTF issue 13716 - for discussion at next week's meeting Thread-index: AcrHtU7jjaj6YzOoEd+sdQARJM+CggCTOaeg All, There's a question about why 'characteristic' (unary fact type) is not in the taxonomy of 11.1.5. I don't think that omission was intended. If there are no objections I propose it be added, like this (highlighted yellow). Comments? ~ Keri On 3/19/10 12:41 PM, "keri" wrote: A big thanks to Mark for the careful read and probing questions. An updated set of documents is attached. Mark, I have made some comments to your comments, below. Keri From: Mark H Linehan Date: March 18, 2010 4:16:25 PM GMT-10:00 To: sbvr-rtf@omg.org Subject: Re: SBVR RTF issue 13716 - for discussion at next week's meeting Further comments like this. -------------------------------- ... However, if it's felt that there is some flaw in the definition of 'segmentation' that doesn't get this intent exactly as it should be, that would be a separate issue. I don't think that plain reading of the existing definition of 'segmentation' supports the idea that the "disjoint" categories can be subcategories of one another. An easy fix would be to drop the subcategories out of the list of Necessities. I have changed 'segmentation' to 'categorization scheme'. (If needed, the clarification of 'segmentation' can be raised as its own issue.) ... No, the examples show multiple uses. Note the wording of the examples . each illustrates a fact that is forumlated using the single verb concept. How is a "use" of a verb concept different from an instance of the verb concept? We have " 'replacement car' ranges over 'rental car' " and " 'pickup branch' ranges over 'branch' ". Wouldn't each of these verb concepts be categorized as 'is-role-of verb concepts"? Hmmm... when you say "each of these verb concepts" are you referring to the Examples? The Example does not say that 'replacement car ranges over rental car' is a verb concept/fact type (form). What the examples intend to show are some statements of facts that use this particular verb concept to make a fact statement. Each fact statement is a complete sentence; each ends with a period. The full statement of the facts you refer to is: The role .replacement car. ranges over the general concept .rental car.. The role .pick-up branch. ranges over the general concept .branch.. These fact statements MENTION some concepts and USE this particular verb concept from SBVR. However, if you think it would be helpful to illustrate a case of 'instance' then this could be added as an Example so that the two could be seen side-by-side: The actuality that the role .replacement car. ranges over the general concept .rental car. is an instance of the Is-role-of Verb Concept. The fact that the role .replacement car. ranges over the general concept .rental car. is formulated using the Is-role-of Verb Concept. (BTW, "situational" has been added before "role" in the Examples.) ... I think the "General Concept" caption should be omitted from these two entries to avoid this confusion. I prefer to leave it. For completeness, don't we have to declare the more general concept, somewhere, as part of the entry? Hmmm... I suppose it could be argued that it's taken care of by the more general concept entry, but somehow it seems incomplete to leave it out. Yes, I think it is taken care of in the extensional definition. However, if the group wants to remove it (and it's legit. to do so) then okay. For discussion/decision by the group . keep or toss? ~ Keri X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: yDKG4xkVM1m4t268WGPc0srVVqlIj3R_THVVQAHELQwci5umCaKTXJTcODYesqfmAq_Fyc4kqbBljxXjinh0lndQYxM89fjBfwCM_jAemQ7sDzsjRjmEnxdHhL7QUzyZp3qcFEJkAztgLrNTgVwm1CiucqZWfy9CqiRANttlSa98vOnWUt35aBuAXIoDisMQyub.N3lY6fL3u6d1iZVI9snZgiaK1keqrRi0rtBJeEpsLMVd2FWhiU0Y5nMk3wW.YyfJX26vLP6Kj2xOMScD9F.fEjdW4rc- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 22 Mar 2010 16:05:23 -0500 To: keri , SBVR RTF From: "Ronald G. Ross" Subject: Re: SBVR RTF issue 13716 - for discussion at next week's meeting At 03:56 PM 3/22/2010, keri wrote: All, There's a question about why 'characteristic' (unary fact type) is not in the taxonomy of 11.1.5. I don't think that omission was intended. If there are no objections I propose it be added, like this (highlighted yellow). Comments? I'm pretty sure the original intention was to be complete, so I think it was probably an oversight. In any event, I definitely think it should be included ... its absence is conspicuous. Ron ~ Keri On 3/19/10 12:41 PM, "keri" wrote: A big thanks to Mark for the careful read and probing questions. An updated set of documents is attached. Mark, I have made some comments to your comments, below. Keri From: Mark H Linehan Date: March 18, 2010 4:16:25 PM GMT-10:00 To: sbvr-rtf@omg.org Subject: Re: SBVR RTF issue 13716 - for discussion at next week's meeting Further comments like this. -------------------------------- ... However, if it's felt that there is some flaw in the definition of 'segmentation' that doesn't get this intent exactly as it should be, that would be a separate issue. I don't think that plain reading of the existing definition of 'segmentation' supports the idea that the "disjoint" categories can be subcategories of one another. An easy fix would be to drop the subcategories out of the list of Necessities. I have changed 'segmentation' to 'categorization scheme'. (If needed, the clarification of 'segmentation' can be raised as its own issue.) ... No, the examples show multiple uses. Note the wording of the examples each illustrates a fact that is forumlated using the single verb concept. How is a "use" of a verb concept different from an instance of the verb concept? We have " 'replacement car' ranges over 'rental car' " and " 'pickup branch' ranges over 'branch' ". Wouldn't each of these verb concepts be categorized as 'is-role-of verb concepts"? Hmmm... when you say "each of these verb concepts" are you referring to the Examples? The Example does not say that 'replacement car ranges over rental car' is a verb concept/fact type (form). What the examples intend to show are some statements of facts that use this particular verb concept to make a fact statement. Each fact statement is a complete sentence; each ends with a period. The full statement of the facts you refer to is: The role .replacement car. ranges over the general concept .rental car.. The role .pick-up branch. ranges over the general concept .branch.. These fact statements MENTION some concepts and USE this particular verb concept from SBVR. However, if you think it would be helpful to illustrate a case of 'instance' then this could be added as an Example so that the two could be seen side-by-side: The actuality that the role .replacement car. ranges over the general concept .rental car. is an instance of the Is-role-of Verb Concept. The fact that the role .replacement car. ranges over the general concept .rental car. is formulated using the Is-role-of Verb Concept. (BTW, "situational" has been added before "role" in the Examples.) ... I think the "General Concept" caption should be omitted from these two entries to avoid this confusion. I prefer to leave it. For completeness, don't we have to declare the more general concept, somewhere, as part of the entry? Hmmm... I suppose it could be argued that it's taken care of by the more general concept entry, but somehow it seems incomplete to leave it out. Yes, I think it is taken care of in the extensional definition. However, if the group wants to remove it (and it's legit. to do so) then okay. For discussion/decision by the group keep or toss? ~ Keri DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:In-Reply-To:X-MimeOLE; b=vkdtwoy8Y3+VONu4WNIjnkJKsnJQq8wIBTlDFNuxK2CPMg+KuT0h4PvlYY8xL9/tUXnX5w+KMNFSaCwDqPowtrbbYB5fVIT+kU4AA3IXRpMe02NvG+5IbPX62fvTdrHsyjvkFhXFywIBUBFRpDIpa9MdPvXaTAOHkyjhqc7fUbU= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=s1024; t=1269338938; bh=7fkSR18p3s1hZbskYMmjcAOBWhGtLOh33vPpBJLWSvo=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:In-Reply-To:X-MimeOLE; b=HFYbD5OUW7hMpkzS/+fe+p3/0zZ/XEmukUD7fg4fiJgXTAjVxBpPur0zEcxvSRg3B7MQS+fVkUeEWPgKlS8DvcM3JMwRa5qIfAZDJMw595kZ9Z0M9+YfSnZ6OXNPYAamW2yXn4bJQsqj6Cw7GaQpnMfoTG22asExYXNZ4pIVDR4= X-Yahoo-SMTP: ipAFRh2swBALpDiVMXIwBxwhmA51J31AV6tKcA.nNICCSy6cH9UoQMM- X-YMail-OSG: 1ctCC40VM1kSq3dq7NlDCCHWxsgiGramrmmTBK7mxD486ddUhNzVgUaS3HymL_L3DgW_zWAzS6EY0tLGphojZ77gohILLoAwpJGXUgzud05yN5iEwbXdcs6eAQpz3OgRot6Ynfw9fYMeLz.ck_.0DdGhLmHIkwMI9JLLBhg6P6nQ4XieIsM9cSbyMnch0H9tuAjEVD8y8X.cnF5fJYZiJVxJ4mXAt18pBgF5r.g3juS92q8_TAHhlIoOKTNq1Him0PnLXUTjGAY- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: "'SBVR RTF'" Subject: RE: SBVR RTF issue 13716 - for discussion at next week's meeting Date: Tue, 23 Mar 2010 06:08:52 -0400 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcrHtU7jjaj6YzOoEd+sdQARJM+CggCTOaegABsZa5A= On 22 March 2010 16:57 Keri wrote: All, There's a question about why 'characteristic' (unary fact type) is not in the taxonomy of 11.1.5. I don't think that omission was intended. If there are no objections I propose it be added, like this (highlighted yellow). Comments? The current entry in Clause 8 for .characteristic. conflates two different concepts: - the ISO 1087 .characteristic. concept, which is a qualifier (the meaning of an adjective or an adjectival phrase) and, in formal logic terms, the logical predicate without the argument (placeholder / noun concept playing a role). - a verb concept (Clause 8 fact type), which has the logical predicate plus one, but only one, argument (placeholder / noun concept playing the role) The .unary verb concept. (unary Clause 8 fact type) concept belongs in a taxonomy of verb concepts (Clause 8 fact types), but the ISO .characteristic. concept does not. Donald ~ Keri On 3/19/10 12:41 PM, "keri" wrote: A big thanks to Mark for the careful read and probing questions. An updated set of documents is attached. Mark, I have made some comments to your comments, below. Keri From: Mark H Linehan Date: March 18, 2010 4:16:25 PM GMT-10:00 To: sbvr-rtf@omg.org Subject: Re: SBVR RTF issue 13716 - for discussion at next week's meeting Further comments like this. -------------------------------- ... However, if it's felt that there is some flaw in the definition of 'segmentation' that doesn't get this intent exactly as it should be, that would be a separate issue. I don't think that plain reading of the existing definition of 'segmentation' supports the idea that the "disjoint" categories can be subcategories of one another. An easy fix would be to drop the subcategories out of the list of Necessities. I have changed 'segmentation' to 'categorization scheme'. (If needed, the clarification of 'segmentation' can be raised as its own issue.) ... No, the examples show multiple uses. Note the wording of the examples . each illustrates a fact that is forumlated using the single verb concept. How is a "use" of a verb concept different from an instance of the verb concept? We have " 'replacement car' ranges over 'rental car' " and " 'pickup branch' ranges over 'branch' ". Wouldn't each of these verb concepts be categorized as 'is-role-of verb concepts"? Hmmm... when you say "each of these verb concepts" are you referring to the Examples? The Example does not say that 'replacement car ranges over rental car' is a verb concept/fact type (form). What the examples intend to show are some statements of facts that use this particular verb concept to make a fact statement. Each fact statement is a complete sentence; each ends with a period. The full statement of the facts you refer to is: The role .replacement car. ranges over the general concept .rental car.. The role .pick-up branch. ranges over the general concept .branch.. These fact statements MENTION some concepts and USE this particular verb concept from SBVR. However, if you think it would be helpful to illustrate a case of 'instance' then this could be added as an Example so that the two could be seen side-by-side: The actuality that the role .replacement car. ranges over the general concept .rental car. is an instance of the Is-role-of Verb Concept. The fact that the role .replacement car. ranges over the general concept .rental car. is formulated using the Is-role-of Verb Concept. (BTW, "situational" has been added before "role" in the Examples.) ... I think the "General Concept" caption should be omitted from these two entries to avoid this confusion. I prefer to leave it. For completeness, don't we have to declare the more general concept, somewhere, as part of the entry? Hmmm... I suppose it could be argued that it's taken care of by the more general concept entry, but somehow it seems incomplete to leave it out. Yes, I think it is taken care of in the extensional definition. However, if the group wants to remove it (and it's legit. to do so) then okay. For discussion/decision by the group . keep or toss? ~ Keri From: "Barkmeyer, Edward J." To: "Donald.Chapin@btinternet.com" , "'SBVR RTF'" Date: Tue, 23 Mar 2010 15:55:11 -0400 Subject: RE: SBVR RTF issue 13716 - for discussion at next week's meeting Thread-Topic: SBVR RTF issue 13716 - for discussion at next week's meeting Thread-Index: AcrHtU7jjaj6YzOoEd+sdQARJM+CggCTOaegABsZa5AAFQj95g== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edward.barkmeyer@nist.gov X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o2NJp9Fv028478 Donald wrote: There's a question about why 'characteristic' (unary fact type) is not in the taxonomy of 11.1.5. I don't think that omission was intended. If there are no objections I propose it be added, like this (highlighted yellow). Comments? The current entry in Clause 8 for .characteristic. conflates two different concepts: - the ISO 1087 .characteristic. concept, which is a qualifier (the meaning of an adjective or an adjectival phrase) and, in formal logic terms, the logical predicate without the argument (placeholder / noun concept playing a role). - a verb concept (Clause 8 fact type), which has the logical predicate plus one, but only one, argument (placeholder / noun concept playing the role) The .unary verb concept. (unary Clause 8 fact type) concept belongs in a taxonomy of verb concepts (Clause 8 fact types), but the ISO .characteristic. concept does not. With all due respect, I think this is a syntactic distinction, not a conceptual one. The two fact type forms, with and without the (implicit) subject placeholder, are just that -- different fact type forms for fact types that are 'characteristics'. In SBVR, and in formal logic, the linguistic 'adjectival phrase' concept is always captured as a unary fact type. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Office: +1 301-975-3528 Gaithersburg, MD 20899-8263 Mobile: +1 240-672-5800 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004240128 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Sat, 24 Apr 2010 08:13:49 -1000 Subject: Re: SBVR RTF issue 13716 - updated Resolution document From: keri To: "Donald R. Chapin" , SBVR RTF Thread-topic: SBVR RTF issue 13716 - updated Resolution document Thread-index: AcrMKiSpwYQRp3xLSJG36hkPr+f2bwAxJfTKAwwGcK8Bp3eMEAAExmIQAJtJIcAAZzwlaQ== Donald, All, Attached is an updated Resolution document, reflecting Ron's additional items, plus reverting to use the primary terms. Donald, I am available for a telcon either Thurs. Apr. 29 or Fri. Apr. 30. The week after that is full of appointments, and Ron also isn't available that first week of May. And, to clarify: while I am physically in touch until May 8, after tomorrow I will have limited internet access (phone for sending/receiving email, but no file sends). Hopefully, any further changes to the Resolution document will only involve deletions (or small changes to text), which someone else can readily pick up. Regards, Keri On 4/22/10 7:14 AM, "Donald Chapin" wrote: Keri, nald, Can you tell me what the milestones are for getting 13716 to agreement in time to make the cut for SBVR 1.1? I'll be offline after May 8 (until late July) so will need to hand off work on 13716 if it is still active during that period. The milestones for completing the SBVR RTF report for the June OMG meeting as discussed in the March 25th SBVR RTF meeting are (working backwards): - SBVR RTF Report due on Monday, 24th May (the OMG 4-week deadline) - One week for Ron & Terry to incorporate revisions to Annex E into their respective Annexes (start 17th May latest) - Two weeks for John to bring Annex E up to date (start 3rd May latest) - One week for a final ballot (start 26th April latest) With regard to specific milestones for getting the Issue 13716 to agreement, as discussion is ongoing and several new points have been raised recently by several people, I don.t really know what the milestones are except to track the open questions and try to bring closure on them as quickly as possible. It may be necessary to schedule a telecon. I will do everything I am able to do to try to bring closure before you go on May 8th. Donald Thanks. Keri On 4/19/10 2:39 AM, "Donald Chapin" wrote: Keri, While I was reviewing all the Issues to put into Ballot 3, I discovered a change in the resolution of Issue 13716 that I had missed before and that increases the ambiguity of the SBVR specification rather than decreases it. It is the change of the signifier of the more general concept of .situational role. from .object type. to .general concept.. I know that the SBVR specification says that .object type. and .general concept. are synonyms. However, this is greatly confusing as .object type. in SBVR means a (general) noun concept that is not a fact type role; while ISO 1087-1 defines general concept as all (noun) concepts that can have more than can correspond to two or more objects (over time). I agree that .general concept. is more business friendly than .object type.. In fact the signifier .object type. does not belong in SBVR at all as .object. is not an SBVR term. That concept needs a term that recognizes that it is a noun concept that is not a fact type role. Until this problem is fixed, changing the signifier of the more general concept of .situational role. to .general concept. opens up the ambiguity that fact type roles can be situational roles which they cannot be. One or more fact type roles can define a situational role, but fact type roles cannot be situational roles because fact type roles can never be .ranged over. by other fact type roles. If you can remove this change, we can add it into the resolution of an Issue that deals with the underlying problem. Sorry I didn.t spot this sooner. Donald -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: 11 April 2010 03:30 To: SBVR RTF; Donald R. Chapin Subject: SBVR RTF issue 13716 - updated Resolution document All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept .individual concept specializes concept. or any verb concept that specializes it categorization verb concept Definition: the verb concept .general concept specializes concept. or any verb concept that specializes it contextualization verb concept Definition: the verb concept .role ranges over general concept. or the verb concept .concept has facet. or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept .role ranges over general concept. or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept .concept has facet. or any verb concept that specializes it Option: in the definitions above, we can change each case of .verb concept that specializes. to .binary fact type that specializes. if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using .formulated. in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don SBVR Issue 13716 (v7B).doc X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004240128 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Sat, 24 Apr 2010 08:14:18 -1000 Subject: Re: SBVR RTF issue 13716 - updated Resolution document From: keri To: "Donald R. Chapin" , SBVR RTF Thread-topic: SBVR RTF issue 13716 - updated Resolution document Thread-index: AcrMKiSpwYQRp3xLSJG36hkPr+f2bwAxJfTKAwwGcK8Bp3eMEAAExmIQAJtJIcAAZ0B3Zg== Donald, All, Attached is an updated Resolution document, reflecting Ron's additional items, plus reverting to use the primary terms. Donald, I am available for a telcon either Thurs. Apr. 29 or Fri. Apr. 30. The week after that is full of appointments, and Ron also isn't available that first week of May. And, to clarify: while I am physically in touch until May 8, after tomorrow I will have limited internet access (phone for sending/receiving email, but no file sends). Hopefully, any further changes to the Resolution document will only involve deletions (or small changes to text), which someone else can readily pick up. Regards, Keri On 4/22/10 7:14 AM, "Donald Chapin" wrote: Keri, On 19 April 2010 15:52 Keri wrote: . Donald, Can you tell me what the milestones are for getting 13716 to agreement in time to make the cut for SBVR 1.1? I'll be offline after May 8 (until late July) so will need to hand off work on 13716 if it is still active during that period. The milestones for completing the SBVR RTF report for the June OMG meeting as discussed in the March 25th SBVR RTF meeting are (working backwards): - SBVR RTF Report due on Monday, 24th May (the OMG 4-week deadline) - One week for Ron & Terry to incorporate revisions to Annex E into their respective Annexes (start 17th May latest) - Two weeks for John to bring Annex E up to date (start 3rd May latest) - One week for a final ballot (start 26th April latest) With regard to specific milestones for getting the Issue 13716 to agreement, as discussion is ongoing and several new points have been raised recently by several people, I don.t really know what the milestones are except to track the open questions and try to bring closure on them as quickly as possible. It may be necessary to schedule a telecon. I will do everything I am able to do to try to bring closure before you go on May 8th. Donald Thanks. Keri On 4/19/10 2:39 AM, "Donald Chapin" wrote: Keri, While I was reviewing all the Issues to put into Ballot 3, I discovered a change in the resolution of Issue 13716 that I had missed before and that increases the ambiguity of the SBVR specification rather than decreases it. It is the change of the signifier of the more general concept of .situational role. from .object type. to .general concept.. I know that the SBVR specification says that .object type. and .general concept. are synonyms. However, this is greatly confusing as .object type. in SBVR means a (general) noun concept that is not a fact type role; while ISO 1087-1 defines general concept as all (noun) concepts that can have more than can correspond to two or more objects (over time). I agree that .general concept. is more business friendly than .object type.. In fact the signifier .object type. does not belong in SBVR at all as .object. is not an SBVR term. That concept needs a term that recognizes that it is a noun concept that is not a fact type role. Until this problem is fixed, changing the signifier of the more general concept of .situational role. to .general concept. opens up the ambiguity that fact type roles can be situational roles which they cannot be. One or more fact type roles can define a situational role, but fact type roles cannot be situational roles because fact type roles can never be .ranged over. by other fact type roles. If you can remove this change, we can add it into the resolution of an Issue that deals with the underlying problem. Sorry I didn.t spot this sooner. Donald -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: 11 April 2010 03:30 To: SBVR RTF; Donald R. Chapin Subject: SBVR RTF issue 13716 - updated Resolution document All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept .individual concept specializes concept. or any verb concept that specializes it categorization verb concept Definition: the verb concept .general concept specializes concept. or any verb concept that specializes it contextualization verb concept Definition: the verb concept .role ranges over general concept. or the verb concept .concept has facet. or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept .role ranges over general concept. or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept .concept has facet. or any verb concept that specializes it Option: in the definitions above, we can change each case of .verb concept that specializes. to .binary fact type that specializes. if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using .formulated. in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don SBVR Issue 13716 (v7B)1.doc To: sbvr-rtf@omg.org Subject: Re: SBVR RTF issue 13716 - updated Resolution document X-KeepSent: E504C9B3:16049F2B-85257710:0046BAEF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Mon, 26 Apr 2010 08:46:30 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 04/26/2010 08:46:40, Serialize complete at 04/26/2010 08:46:40 The proposed new definition of "fact type" makes no sense to me: "concept that specializes the concept actuality and that is the meaning of a verb phrase that involves one or more roles ". I do not believe that every fact type is also an actuality. 'man jumps over moon' may be a fact type but clearly is not an actuality. I don't understand the "Elements of Structure" categorization scheme: * Why do we include "classification" and "categorization" facts in this scheme, but not (for example) facts about partitive or associative or contextualization verb concepts? Why call out a separate categorization scheme for "classification" and "categorization" versus the "Verb Concept Templating" scheme? (The answer to this question should be included in the text.) * Why are we defining facts about "classification verb concept" and "categorization verb concept" and categorizing the facts? As far as I can remember, there are no other cases in SBVR where we follow this pattern -- where we define concepts as kinds of facts. * Why do we include "fact type" in "Elements of Structure"? My opinion: it does not belong in "Elements of Structure" since it is not the same concept type as "categorization" and "classification". ("fact type" is a concept, whereas "classification" and "categorization" are facts. So how can they all participate in the same categorization scheme?) * Do we need the separate glossary entries for "classification fact" and "categorization fact", given that these are just synonyms for the entries that are immediately above each of them? Our usual practices is to create "see" entries only when the primary term is at some other location in the document. Regarding the new figure 11.5: * Is the generalization line from "verb concept" to "meaning" correct? "Verb concept" is already a kind of "concept" which is a kind of "meaning". Also, "verb concept" is not mutually exclusive with "concept". * Should "concept" share a generalization line with "classification" and "categorization"? "Concept" is certainly not mutually exclusive with those two. I think the definition of "contextualization verb concept" should be given extensionally, as it is today. I think an extensional definition makes the relationship among this, "is-role-of verb concept" and "is-facet-of verb concept" clearer. The first letter of the example for "is-property-of verb concept" should be capitalized. It looks like we're not changing the definition of "partitive fact type" at all. At least, I can't spot the change. Did you meant to start the definition with "binary verb concept ..."? I don't see any change to the General Concept for "situational role". I see that you are consistently replacing Examples with Notes, but they sure look like Examples to me. Why do you want to mark them as Notes? -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004260090 Subject: Re: SBVR RTF issue 13716 - updated Resolution document From: keri Date: Mon, 26 Apr 2010 04:09:55 -1000 Cc: sbvr-rtf@omg.org To: Mark H Linehan X-Mailer: Apple Mail (2.1078) Mark, You're right about the error in the diagram. My bad. Here is a corrected view. Keri On Apr 26, 2010, at 2:46 AM, Mark H Linehan wrote: The proposed new definition of "fact type" makes no sense to me: "concept that specializes the concept .actuality. and that is the meaning of a verb phrase that involves one or more roles ". I do not believe that every fact type is also an actuality. 'man jumps over moon' may be a fact type but clearly is not an actuality. I don't understand the "Elements of Structure" categorization scheme: * Why do we include "classification" and "categorization" facts in this scheme, but not (for example) facts about partitive or associative or contextualization verb concepts? Why call out a separate categorization scheme for "classification" and "categorization" versus the "Verb Concept Templating" scheme? (The answer to this question should be included in the text.) * Why are we defining facts about "classification verb concept" and "categorization verb concept" and categorizing the facts? As far as I can remember, there are no other cases in SBVR where we follow this pattern -- where we define concepts as kinds of facts. * Why do we include "fact type" in "Elements of Structure"? My opinion: it does not belong in "Elements of Structure" since it is not the same concept type as "categorization" and "classification". ("fact type" is a concept, whereas "classification" and "categorization" are facts. So how can they all participate in the same categorization scheme?) * Do we need the separate glossary entries for "classification fact" and "categorization fact", given that these are just synonyms for the entries that are immediately above each of them? Our usual practices is to create "see" entries only when the primary term is at some other location in the document. Regarding the new figure 11.5: * Is the generalization line from "verb concept" to "meaning" correct? "Verb concept" is already a kind of "concept" which is a kind of "meaning". Also, "verb concept" is not mutually exclusive with "concept". * Should "concept" share a generalization line with "classification" and "categorization"? "Concept" is certainly not mutually exclusive with those two. I think the definition of "contextualization verb concept" should be given extensionally, as it is today. I think an extensional definition makes the relationship among this, "is-role-of verb concept" and "is-facet-of verb concept" clearer. The first letter of the example for "is-property-of verb concept" should be capitalized. It looks like we're not changing the definition of "partitive fact type" at all. At least, I can't spot the change. Did you meant to start the definition with "binary verb concept ..."? I don't see any change to the General Concept for "situational role". I see that you are consistently replacing Examples with Notes, but they sure look like Examples to me. Why do you want to mark them as Notes? -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com PastedGraphic-1.tiff X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004260112 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 26 Apr 2010 05:42:14 -1000 Subject: Re: SBVR RTF issue 13716 - updated Resolution document From: keri To: Mark H Linehan , SBVR RTF Thread-topic: SBVR RTF issue 13716 - updated Resolution document Thread-index: AcrlVwrTSTWr9FFKEd+XyQARJM+Cgg== Mark, I'll answer where I can. Ron may want to expand on the "Elements of Structure" bits. Keri On 4/26/10 2:46 AM, "Mark H Linehan" wrote: The proposed new definition of "fact type" makes no sense to me: "concept that specializes the concept .actuality. and that is the meaning of a verb phrase that involves one or more roles ". I do not believe that every fact type is also an actuality. 'man jumps over moon' may be a fact type but clearly is not an actuality. This is actually only changing the final term from "noun concepts" to "roles" -- In the notes that were circulated many moons back, there was an annotation that "this wording change was agreed in meeting discussion notes." If you have an issue with fact type and actuality that is not part of this issue. I don't understand the "Elements of Structure" categorization scheme: * Why do we include "classification" and "categorization" facts in this scheme, but not (for example) facts about partitive or associative or contextualization verb concepts? Why call out a separate categorization scheme for "classification" and "categorization" versus the "Verb Concept Templating" scheme? (The answer to this question should be included in the text.) These two are for the constructs (in a user's model) that apply/use the given SBVR fact types: customer is a category of person; Switzerland assorts to country . these are what a user would be specifying in their model, so that's what's relevant to be able to talk about with them. The others (partitive, associative, et al) - those are what they are in the user's model: person rents car; insurance is included in rental contract. So there we talk to the user about their model's partitive verb concepts, their associative verb concepts, etc. * Why are we defining facts about "classification verb concept" and "categorization verb concept" and categorizing the facts? As far as I can remember, there are no other cases in SBVR where we follow this pattern -- where we define concepts as kinds of facts. Ron explained this when he submitted his proposal to add these. * Why do we include "fact type" in "Elements of Structure"? My opinion: it does not belong in "Elements of Structure" since it is not the same concept type as "categorization" and "classification". ("fact type" is a concept, whereas "classification" and "categorization" are facts. So how can they all participate in the same categorization scheme?) Ron explained this when he submitted his proposal to add these. * Do we need the separate glossary entries for "classification fact" and "categorization fact", given that these are just synonyms for the entries that are immediately above each of them? Our usual practices is to create "see" entries only when the primary term is at some other location in the document. It was my convention in preparing Clauses 11 and 12 to include entries for synonyms . I believe I did that consistently. But if there is some other convention to omit them, per your suggestion of a guideline, that's fine too. And the other cases should be removed as well. (Probably needs a covering Issue for the work.) The group needs to decide this. Regarding the new figure 11.5: * Is the generalization line from "verb concept" to "meaning" correct? "Verb concept" is already a kind of "concept" which is a kind of "meaning". Also, "verb concept" is not mutually exclusive with "concept". * Should "concept" share a generalization line with "classification" and "categorization"? "Concept" is certainly not mutually exclusive with those two. Corrected graphic sent earlier. I think the definition of "contextualization verb concept" should be given extensionally, as it is today. I think an extensional definition makes the relationship among this, "is-role-of verb concept" and "is-facet-of verb concept" clearer. This was discussed in the meeting and the group preferred it this new way. It can be whichever way the group prefers. The first letter of the example for "is-property-of verb concept" should be capitalized. It is a phrase, not a complete sentence. It looks like we're not changing the definition of "partitive fact type" at all. At least, I can't spot the change. Did you meant to start the definition with "binary verb concept ..."? You're probably correct here. That change instruction can be deleted. (It reverted back to use 'fact type' as part of Donald's edict on synonym usage, thereby making it "no change.") I don't see any change to the General Concept for "situational role". Ditto. I see that you are consistently replacing Examples with Notes, but they sure look like Examples to me. Why do you want to mark them as Notes? I am not "consistently replacing" things . these were cases where the one SBVR verb concept (or a specialization of it) would be giving an example of itself. Since these are examples of the USAGE of these entries it was stated that these were more appropriately labeled as notes about it. E.g., we wouldn't give an example of "Switzerland" but might want to make a note about it. For the record, nothing in this Issue is put forth as "my" personal idea or position . I am the scribe, capturing what the group is saying/agreeing on this Issue. I don't need to 'endorse' something to record it. - Keri To: sbvr-rtf@omg.org Subject: Re: SBVR RTF issue 13716 - updated Resolution document X-KeepSent: EDCC5A19:BA07A51E-85257712:00475391; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Tue, 27 Apr 2010 09:12:07 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 04/27/2010 09:12:18, Serialize complete at 04/27/2010 09:12:18 My own responses inserted like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com keri 04/26/2010 11:42 AM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: SBVR RTF issue 13716 - updated Resolution document Mark, I'll answer where I can. Ron may want to expand on the "Elements of Structure" bits. Keri On 4/26/10 2:46 AM, "Mark H Linehan" wrote: The proposed new definition of "fact type" makes no sense to me: "concept that specializes the concept actuality and that is the meaning of a verb phrase that involves one or more roles ". I do not believe that every fact type is also an actuality. 'man jumps over moon' may be a fact type but clearly is not an actuality. This is actually only changing the final term from "noun concepts" to "roles" -- In the notes that were circulated many moons back, there was an annotation that "this wording change was agreed in meeting discussion notes." If you have an issue with fact type and actuality that is not part of this issue. The proposed resolution changes the text to what I quote above. I disagree with it because I don't believe the concept 'fact type' incorporates each characteristic of the concept 'actuality'. I remember we had a previous email discussion about this and there is a rationalization, but that rationalization does not appear in the proposed resolution. I don't understand the "Elements of Structure" categorization scheme: * Why do we include "classification" and "categorization" facts in this scheme, but not (for example) facts about partitive or associative or contextualization verb concepts? Why call out a separate categorization scheme for "classification" and "categorization" versus the "Verb Concept Templating" scheme? (The answer to this question should be included in the text.) These two are for the constructs (in a user's model) that apply/use the given SBVR fact types: customer is a category of person; Switzerland assorts to country . these are what a user would be specifying in their model, so that's what's relevant to be able to talk about with them. The others (partitive, associative, et al) - those are what they are in the user's model: person rents car; insurance is included in rental contract. So there we talk to the user about their model's partitive verb concepts, their associative verb concepts, etc. Yes, I understand that the "Elements of Structure" categorization scheme is about the structure of the noun concepts of the user domain model, and the "Verb Concept Templating" scheme is about the verb concepts. But why make this separation? * Why are we defining facts about "classification verb concept" and "categorization verb concept" and categorizing the facts? As far as I can remember, there are no other cases in SBVR where we follow this pattern -- where we define concepts as kinds of facts. Ron explained this when he submitted his proposal to add these. Could we add a note that gives this explanation? * Why do we include "fact type" in "Elements of Structure"? My opinion: it does not belong in "Elements of Structure" since it is not the same concept type as "categorization" and "classification". ("fact type" is a concept, whereas "classification" and "categorization" are facts. So how can they all participate in the same categorization scheme?) Ron explained this when he submitted his proposal to add these. I think it is logically wrong. * Do we need the separate glossary entries for "classification fact" and "categorization fact", given that these are just synonyms for the entries that are immediately above each of them? Our usual practices is to create "see" entries only when the primary term is at some other location in the document. It was my convention in preparing Clauses 11 and 12 to include entries for synonyms . I beliieve I did that consistently. But if there is some other convention to omit them, per your suggestion of a guideline, that's fine too. And the other cases should be removed as well. (Probably needs a covering Issue for the work.) The group needs to decide this. Regarding the new figure 11.5: * Is the generalization line from "verb concept" to "meaning" correct? "Verb concept" is already a kind of "concept" which is a kind of "meaning". Also, "verb concept" is not mutually exclusive with "concept". * Should "concept" share a generalization line with "classification" and "categorization"? "Concept" is certainly not mutually exclusive with those two. Corrected graphic sent earlier. I think the definition of "contextualization verb concept" should be given extensionally, as it is today. I think an extensional definition makes the relationship among this, "is-role-of verb concept" and "is-facet-of verb concept" clearer. This was discussed in the meeting and the group preferred it this new way. It can be whichever way the group prefers. The first letter of the example for "is-property-of verb concept" should be capitalized. It is a phrase, not a complete sentence. It looks like we're not changing the definition of "partitive fact type" at all. At least, I can't spot the change. Did you meant to start the definition with "binary verb concept ..."? You're probably correct here. That change instruction can be deleted. (It reverted back to use 'fact type' as part of Donald's edict on synonym usage, thereby making it "no change.") I don't see any change to the General Concept for "situational role". Ditto. I see that you are consistently replacing Examples with Notes, but they sure look like Examples to me. Why do you want to mark them as Notes? I am not "consistently replacing" things . these were ccases where the one SBVR verb concept (or a specialization of it) would be giving an example of itself. Since these are examples of the USAGE of these entries it was stated that these were more appropriately labeled as notes about it. E.g., we wouldn't give an example of "Switzerland" but might want to make a note about it. I think these are Examples. For the record, nothing in this Issue is put forth as "my" personal idea or position . I am the scribe, captturing what the group is saying/agreeing on this Issue. I don't need to 'endorse' something to record it. - Keri Subject: Re: SBVR RTF issue 13716 - updated Resolution document X-KeepSent: 31569D84:B18412EF-85257718:0044A9CB; type=4; name=$KeepSent To: SBVR RTF X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Mon, 3 May 2010 09:42:55 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 05/03/2010 09:45:05 >>I inserted comments like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com keri ---05/01/2010 06:11:15 PM---Mark, Let me jump in on some of your points, while Ron is composing his response. keri 05/01/2010 06:09 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: SBVR RTF issue 13716 - updated Resolution document Mark, Let me jump in on some of your points, while Ron is composing his response. ------------------------------ On the change to the definition of 'fact type'. Let's remove this from this Issue's write-up -- I will send in a separate Issue to the Definition of 'fact type' as captured from the meeting notes. >>I would be ok with including a change in this Issue if it is limited to changing "noun concept" to "role". I think that changing "fact type" to be "... specialize the concept 'actuality' " should be handled separately. ------------------------------ On Elements of Structure vis--vis Verb Concept Templating. The difference for these two schemes is not one of nominalization. The new concepts Ron has proposed are categories of 'fact' and they use nouns, as for any term. This may be more clear if you look at the synonyms, which present the longer (full) term: "classification fact" and "categorization fact". These are not nominalizations any more than "fact" is a nominalization. >> (1) I think these definitions are using "fact of " as a round-about way of meaning "nominalization" because we are missing the "nominalization" concept in clauses 8 and 11. "Categorization" is defined in Merriam-Webster online as "to put into a category", which uses an infinitive. Infinitives are noun phrases, i.e. nominalizations. (2) Why not be consistent and do the same for "Verb Concept Templating"? For example, "association: fact that a fact type has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations" ------------------------------ On either/or choice: These schemes are not an either/or choice -- they accomplish different objectives ... different uses, different audiences. Verb Concept Templating inventories the various kinds (categories) of verb concepts. The Elements of Structure scheme presents the kinds of things that a business person uses in his fact model. I don't see how "they accomplish different objectives ... different uses, different audiences". What are these different objectives, uses, audiences? The only difference I can see is that the Elements of Structure categorize ways of classifying nouns, while the Verb Concept Templating categorizes verb concepts. To me, associations and partitions are just as much a part of structuring a vocabulary as classifications and categorizations. ------------------------------ On making the schemes more distinct (less confusing). I appreciate that the single 11.1.5 diagram may have grown too large for easy digestion. We might want to consider having several, smaller diagrams, much as Clause 8 presents several diagrams within a sub-clause. For example, we could show the following for the new scheme, to make its constituent parts more obvious (below), and then one or two other diagrams for the rest of 11.1.5. ------------------------------ On including 'noun concept' in Elements of Structure. Ron intends for "Elements of Structure" to mean only the verbish elements (think: the lines on a graphical model). The noun concepts (the 'boxes') are what are being 'structured' via the connecting lines. So then, "Elements of Structure" should categorize the verbs, not meaning in general. ------------------------------ On what Elements of Structure categorizes. You say that this should not go up as high as 'meaning' (you wrote: "Elements of Structure" should categorize "concept", not "meaning". "Elements of Structure" does not categorize other kinds of "meaning", such as "questions" and "propositions".). But 'fact' is a kind of proposition so, yes, this scheme does need to reflect that these elements are categories of 'meaning'. Hmm, I think the definitions of "classification" and "categorization" may be wrong. They use the form "fact of " but I think they should be "instance of ". In which case they would be "actualities" rather than "propositions". ------------------------------ On "based on". This verb was used because that is the terminology SBVR defines for relating 'proposition' and 'fact type' in this manner. The notes given for categorization verb concept and classification verb concept (and for is-role-of verb concept and is-facet-of verb concept) talk (informally) about things being formulated using -- this is that same sense, only it's using the defined SBVR terminology to show the specific correspondence between the related kinds of 'facts' and 'fact types'. However, if making these connections explicit adds confusion then these fact types can be omitted. In any case, the explanation is given in the Notes clauses. ~ Keri On 4/30/10 6:54 AM, "Mark H Linehan" wrote: Ron, Regarding the change of the definition of "fact type" -- we definitely are suffering from the lack of a convenience document. I have no objection to changing "noun concepts" to "roles". My concern is about changing from "concept that is the meaning of a verb phrase that... " (as in the adopted spec) to "concept that specializes the concept 'actuality' ..." I looked through all three RTF ballots that we have voted on so far, and cannot find one that changes the definition of "fact type" like this. Maybe I missed it, but I suspect an error in compiling the change. ------------------------------- Regarding "Elements of Structure" -- in English, we often nominalize verbs. For example, "murder" is the noun concept corresponding to the verb concept "person1 murders person2". As another example, "legalization" is the noun concept corresponding to "law legalizes state of affairs". In the same way, "categorization" is a nominalization of "concept1 specializes concept2". I think the only difference between the "Elements of Structure" categorization scheme and the "Verb Concept Templating" categorization scheme is that one is about nominalizations of verbs, while the other is about the verbs themselves. I think it is confusing to have two categorization schemes that attempt to categorize essentially the same concepts. We should pick one or the other. To put it another way, why should categorization and classification be in a separate categorization scheme from is-property-of and siblings? Categorization, association, and partition are all ways to structure concepts. Why should some of these be in one categorization scheme and some in another? The only difference that I can see is that we provide a "built in" SBVR verb concept for "categorization" whereas association, partition, etc., require their own domain vocabulary concepts. [ I think that this is a deficit in SBVR: why don't we provide "property-of" and "association" verb concepts as part of SBVR itself? (We do use "has" and "includes" in lots of examples in EU-Rent but neither are defined generally.) ] I suggest the noun concepts "classification" and "categorization" be added to clause 11.1.2 right after "concept1 has more general concept2" to emphasize how they relate to that verb concept. And I think "... is based on ..." is the wrong way to describe the relationship of "categorization" to the "specializes" verb concept. What we really need is a way to describe the nominalization relationship between a noun concept and a verb concept. We have nominalization as a kind of formulation in clause 9, but no equivalent concept in clause 8 or 11. If we did have the "nominalization" concept, it would be another entry in "Elements of Structure". ------------------------------ Regarding "categorization verb concept" and "classification verb concept" -- I believe the only reason we need these is for parallel construction of the "Verb Concept Templating" categorization scheme. These two verb concepts would go away if we switch to a categorization scheme based on nominalizations. On the other hand, we will need to keep them if we retain a categorization scheme of verb concepts. ------------------------------ Regarding including "verb concept" as one category of "Elements of Structure" -- why not also include "noun concept" as another category of "Elements of Structure"? Going further, I think "Elements of Structure" should categorize "concept", not "meaning". "Elements of Structure" does not categorize other kinds of "meaning", such as "questions" and "propositions". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" ---04/29/2010 09:16:21 PM---Mark, Some responses like this. "Ronald G. Ross" 04/29/2010 09:16 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: SBVR RTF issue 13716 - updated Resolution document Mark, Some responses like this. Ron At 08:12 AM 4/27/2010, Mark H Linehan wrote: My own responses inserted like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com keri 04/26/2010 11:42 AM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: SBVR RTF issue 13716 - updated Resolution document Mark, I'll answer where I can. Ron may want to expand on the "Elements of Structure" bits. Keri On 4/26/10 2:46 AM, "Mark H Linehan" wrote: The proposed new definition of "fact type" makes no sense to me: "concept that specializes the concept .. actuality.. and that is the meaning of a verb phrase that involves one or more roles ". I do not believe that every fact type is also an actuality. 'man jumps over moon' may be a fact type but clearly is not an actuality. This is actually only changing the final term from "noun concepts" to "roles" -- In the notes that were circulated many moons back, there was an annotation that "this wording change was agreed in meeting discussion notes." If you have an issue with fact type and actuality that is not part of this issue. The proposed resolution changes the text to what I quote above. I disagree with it because I don't believe the concept 'fact type' incorporates each characteristic of the concept 'actuality'. I remember we had a previous email discussion about this and there is a rationalization, but that rationalization does not appear in the proposed resolution. These concerns are not part of the issue 13716 discussion. (I think the difficulty is that we've had no convenience document for a good while, so it's becoming very difficult to keep up with changes(??). Anyway, I don't know why there would be a problem with changing "noun concept" to "role" ... but as Keri says, that's just not part of this issue.) I don't understand the "Elements of Structure" categorization scheme: * Why do we include "classification" and "categorization" facts in this scheme, You probably understand this (I can't tell from the above), but let's be clear what's being proposed for inclusion: *Not* classification and categorization facts per se, just the terms "classification" and "categorization" (and their definitions). In some SBVR user's vocabulary, the actual facts would already be "there" (in some form). These two new entries just allow the users to specifically call those facts "classifications" and "categorizations". Why is that useful? Here is what I wrote in my original message: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose." "With respect to the concepts categorization and classification, I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use categorization and classification as standard SBVR terms so when people say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say That represents or creates a categorization (or a classification). 3. To be able to ask business people for real-life examples from their business . and have definitiions to fall back on if they give something inappropriate." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Do you think that some note(s) ought to be included to explain the above? (I think all of Clause 11 should be annotated, so I certainly agree. IMHO, it's naive to think that terms and definitions 'sell' or even explain themselves on their own.) but not (for example) facts about partitive or associative or contextualization verb concepts? For verb concepts, both the fact types and the individual facts come from the SBVR user's domain. Why would we call those out special?? The point is that for verb concepts, we have the terms needed for people to talk about entries in their vocabulary. For example, they can say (pointing to something): * That's an associative fact type. * That's a fact formed based on an associative fact type. (I might not be saying that quite right.) There are no additional terms (words) they would use (unless I am missing something). It's just about the words people need to use to build concept systems. Why call out a separate categorization scheme for "classification" and "categorization" versus the "Verb Concept Templating" scheme? I'm not sure what you are saying. The Verb Concept 'Templating' Scheme refers only to fact types (verb concepts). But there is additional vocabulary ("classification" and "categorization") people use when they structure their concept systems. We just need those two terms, that's all. (Read on.) (The answer to this question should be included in the text.) As above. These two are for the constructs (in a user's model) that apply/use the given SBVR fact types: customer is a category of person; Switzerland assorts to country . these are what a uuser would be specifying in their model, so that's what's relevant to be able to talk about with them. The others (partitive, associative, et al) - those are what they are in the user's model: person rents car; insurance is included in rental contract. So there we talk to the user about their model's partitive verb concepts, their associative verb concepts, etc. Yes, I understand that the "Elements of Structure" categorization scheme is about the structure of the noun concepts of the user domain model, and the "Verb Concept Templating" scheme is about the verb concepts. But why make this separation? I don't follow why you say one is about noun concepts and one is about verb concepts. From the user's perspective (i.e., building of SBVR concept systems), all of the following are ultimately about asserting something about noun concepts: * fact types (verb concepts) * classifications * categorizations These are 'structural members' core to the user's concept system. * Why are we defining facts about "classification verb concept" and "categorization verb concept" I have no use whatsoever for "classification verb concept" and "categorization verb concept". I think those concepts are strange (wonky) and unneeded. That was one major reason I disagree with the current resolution drafted by Keri. I also have no use whatsoever for "contextualization verb concept". That's a term no builder of a concept system would ever use. Let's get rid of that! I wrote: "You do not find is-role-of fact [type] and is-facet-of fact [type] in [my proposed] scheme because there are no natural business terms (in English at least) for those concepts. (Rollification and facetification have been facetiously proposed, which illustrates my point very effectively.)". and categorizing the facts? As far as I can remember, there are no other cases in SBVR where we follow this pattern -- where we define concepts as kinds of facts. Ron explained this when he submitted his proposal to add these. Could we add a note that gives this explanation? At this point, I'm not sure what (which) needs explaining, so help me out ... (?). * Why do we include "fact type" in "Elements of Structure"? My opinion: it does not belong in "Elements of Structure" since it is not the same concept type as "categorization" and "classification". ("fact type" is a concept, whereas "classification" and "categorization" are facts. So how can they all participate in the same categorization scheme?) Ron explained this when he submitted his proposal to add these. I think it is logically wrong. Here's what I wrote: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ " ... the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., categorization and classification). The term element of structure is used prominently in my book, Business Rule Concepts 3rd ed. Surely, no one can doubt that: * The three categories above are key meanings in *structuring* a business concept system. * A concept system indeed has structure that needs to be designed (or adopted) by the business to operate. Here is a proposed definition for element of structure (again, sorry for the lack of SBVR-SE): the categorization scheme of the concept meaning that classifies a meaning based on its part in organizing a communitys concept system ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ According to the proposed definition, the categorization scheme is not *logically* wrong ... they are indeed all meanings. You might argue that it is simply not needed ... But in the Clause 11 context, I think it's quite useful. * Do we need the separate glossary entries for "classification fact" and "categorization fact", given that these are just synonyms for the entries that are immediately above each of them? Our usual practices is to create "see" entries only when the primary term is at some other location in the document. It was my convention in preparing Clauses 11 and 12 to include entries for synonyms . I beliieve I did that consistenttly. But if there is some other convention to omit them, per your suggestion of a guideline, that's fine too. And the other cases should be removed as well. (Probably needs a covering Issue for the work.) The group needs to decide this. Regarding the new figure 11.5: * Is the generalization line from "verb concept" to "meaning" correct? According to the proposed definition of "element of structure", yes. It has to go that high to avoid the differentiation of facts and fact types. "Verb concept" is already a kind of "concept" which is a kind of "meaning". Also, "verb concept" is not mutually exclusive with "concept". * Should "concept" share a generalization line with "classification" and "categorization"? "Concept" is certainly not mutually exclusive with those two. Corrected graphic sent earlier. I think the definition of "contextualization verb concept" should be given extensionally, as it is today. I think an extensional definition makes the relationship among this, "is-role-of verb concept" and "is-facet-of verb concept" clearer. I think we should do away with these wonky concepts/terms. What does it add? Who would use it? This was discussed in the meeting and the group preferred it this new way. It can be whichever way the group prefers. The first letter of the example for "is-property-of verb concept" should be capitalized. It is a phrase, not a complete sentence. It looks like we're not changing the definition of "partitive fact type" at all. At least, I can't spot the change. Did you meant to start the definition with "binary verb concept ..."? You're probably correct here. That change instruction can be deleted. (It reverted back to use 'fact type' as part of Donald's edict on synonym usage, thereby making it "no change.") I don't see any change to the General Concept for "situational role". Ditto. I see that you are consistently replacing Examples with Notes, but they sure look like Examples to me. Why do you want to mark them as Notes? That's where "classification verb concept" and "categorization verb concept" get so wonky. If you ignore the "or any verb concept that specializes it", the definition IS the (only) example. All you can do is give notes about how it would be used ... which are *not* really examples. It all gets impossible. I am pleading for simplification. Let's get rid of this junk. I am not "consistently replacing" things . these were ccases where the one SBVR verb concept (or a specialization of it) would be giving an example of itself. Since these are examples of the USAGE of these entries it was stated that these were more appropriately labeled as notes about it. E.g., we wouldn't give an example of "Switzerland" but might want to make a note about it. I think these are Examples. If it's that confusing, it couldn't be very good. For the record, nothing in this Issue is put forth as "my" personal idea or position . I am the scribee, captturing what the group is saying/agreeing on this Issue. I don't need to 'endorse' something to record it. - Keri (See attached file: ISSUE 13716 V7.2C1.png) ISSUE 13716 V71.2C1.png pic17225.gif X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1005030100 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 03 May 2010 12:14:11 -0700 Subject: Re: SBVR RTF issue 13716 - updated Resolution document From: keri To: Mark H Linehan , SBVR RTF Thread-topic: SBVR RTF issue 13716 - updated Resolution document Thread-index: Acrq9M+jDk4YGFboEd+XqgARJM+Cgg== Mark, I'm stumped on where to go with this. The new items in the scheme Ron has proposed are indeed categories of 'fact': categorization fact classification fact The existing scheme (Verb Concept Templating) has categories of 'fact type' (verb concept) - e.g., categorization fact type (categorization verb concept) and classification fact type (classification verb concept). The Definitions are all written in the typical manner ... with the term for the more general concept beginning the definition text (i.e., 'fact that' and 'fact type that', respectively). Until we are on the same page about what Ron is proposing we will be talking past each other by dipping into details. I am not seeing what you are seeing in your proposal that these are nominalizations. Keri On 5/3/10 6:42 AM, "Mark H Linehan" wrote: >>I inserted comments like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com keri ---05/01/2010 06:11:15 PM---Mark, Let me jump in on some of your points, while Ron is composing his response. keri 05/01/2010 06:09 PM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: SBVR RTF issue 13716 - updated Resolution document Mark, Let me jump in on some of your points, while Ron is composing his response. ------------------------------ On the change to the definition of 'fact type'. Let's remove this from this Issue's write-up -- I will send in a separate Issue to the Definition of 'fact type' as captured from the meeting notes. >>I would be ok with including a change in this Issue if it is limited to changing "noun concept" to "role". I think that changing "fact type" to be "... specialize the concept 'actuality' " should be handled separately. ------------------------------ On Elements of Structure vis-is Verb Concept Templating. The difference for these two schemes is not one of nominalization. The new concepts Ron has proposed are categories of 'fact' and they use nouns, as for any term. This may be more clear if you look at the synonyms, which present the longer (full) term: "classification fact" and "categorization fact". These are not nominalizations any more than "fact" is a nominalization. >> (1) I think these definitions are using "fact of " as a round-about way of meaning "nominalization" because we are missing the "nominalization" concept in clauses 8 and 11. "Categorization" is defined in Merriam-Webster online as "to put into a category", which uses an infinitive. Infinitives are noun phrases, i.e. nominalizations. (2) Why not be consistent and do the same for "Verb Concept Templating"? For example, "association: fact that a fact type has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations" ------------------------------ On either/or choice: These schemes are not an either/or choice -- they accomplish different objectives ... different uses, different audiences. Verb Concept Templating inventories the various kinds (categories) of verb concepts. The Elements of Structure scheme presents the kinds of things that a business person uses in his fact model. I don't see how "they accomplish different objectives ... different uses, different audiences". What are these different objectives, uses, audiences? The only difference I can see is that the Elements of Structure categorize ways of classifying nouns, while the Verb Concept Templating categorizes verb concepts. To me, associations and partitions are just as much a part of structuring a vocabulary as classifications and categorizations. ------------------------------ On making the schemes more distinct (less confusing). I appreciate that the single 11.1.5 diagram may have grown too large for easy digestion. We might want to consider having several, smaller diagrams, much as Clause 8 presents several diagrams within a sub-clause. For example, we could show the following for the new scheme, to make its constituent parts more obvious (below), and then one or two other diagrams for the rest of 11.1.5. ------------------------------ On including 'noun concept' in Elements of Structure. Ron intends for "Elements of Structure" to mean only the verbish elements (think: the lines on a graphical model). The noun concepts (the 'boxes') are what are being 'structured' via the connecting lines. So then, "Elements of Structure" should categorize the verbs, not meaning in general. ------------------------------ On what Elements of Structure categorizes. You say that this should not go up as high as 'meaning' (you wrote: "Elements of Structure" should categorize "concept", not "meaning". "Elements of Structure" does not categorize other kinds of "meaning", such as "questions" and "propositions".). But 'fact' is a kind of proposition so, yes, this scheme does need to reflect that these elements are categories of 'meaning'. Hmm, I think the definitions of "classification" and "categorization" may be wrong. They use the form "fact of " but I think they should be "instance of ". In which case they would be "actualities" rather than "propositions". ------------------------------ On "based on". This verb was used because that is the terminology SBVR defines for relating 'proposition' and 'fact type' in this manner. The notes given for categorization verb concept and classification verb concept (and for is-role-of verb concept and is-facet-of verb concept) talk (informally) about things being formulated using -- this is that same sense, only it's using the defined SBVR terminology to show the specific correspondence between the related kinds of 'facts' and 'fact types'. However, if making these connections explicit adds confusion then these fact types can be omitted. In any case, the explanation is given in the Notes clauses. ~ Keri On 4/30/10 6:54 AM, "Mark H Linehan" wrote: Ron, Regarding the change of the definition of "fact type" -- we definitely are suffering from the lack of a convenience document. I have no objection to changing "noun concepts" to "roles". My concern is about changing from "concept that is the meaning of a verb phrase that... " (as in the adopted spec) to "concept that specializes the concept 'actuality' ..." I looked through all three RTF ballots that we have voted on so far, and cannot find one that changes the definition of "fact type" like this. Maybe I missed it, but I suspect an error in compiling the change. ------------------------------- Regarding "Elements of Structure" -- in English, we often nominalize verbs. For example, "murder" is the noun concept corresponding to the verb concept "person1 murders person2". As another example, "legalization" is the noun concept corresponding to "law legalizes state of affairs". In the same way, "categorization" is a nominalization of "concept1 specializes concept2". I think the only difference between the "Elements of Structure" categorization scheme and the "Verb Concept Templating" categorization scheme is that one is about nominalizations of verbs, while the other is about the verbs themselves. I think it is confusing to have two categorization schemes that attempt to categorize essentially the same concepts. We should pick one or the other. To put it another way, why should categorization and classification be in a separate categorization scheme from is-property-of and siblings? Categorization, association, and partition are all ways to structure concepts. Why should some of these be in one categorization scheme and some in another? The only difference that I can see is that we provide a "built in" SBVR verb concept for "categorization" whereas association, partition, etc., require their own domain vocabulary concepts. [ I think that this is a deficit in SBVR: why don't we provide "property-of" and "association" verb concepts as part of SBVR itself? (We do use "has" and "includes" in lots of examples in EU-Rent but neither are defined generally.) ] I suggest the noun concepts "classification" and "categorization" be added to clause 11.1.2 right after "concept1 has more general concept2" to emphasize how they relate to that verb concept. And I think "... is based on ..." is the wrong way to describe the relationship of "categorization" to the "specializes" verb concept. What we really need is a way to describe the nominalization relationship between a noun concept and a verb concept. We have nominalization as a kind of formulation in clause 9, but no equivalent concept in clause 8 or 11. If we did have the "nominalization" concept, it would be another entry in "Elements of Structure". ------------------------------ Regarding "categorization verb concept" and "classification verb concept" -- I believe the only reason we need these is for parallel construction of the "Verb Concept Templating" categorization scheme. These two verb concepts would go away if we switch to a categorization scheme based on nominalizations. On the other hand, we will need to keep them if we retain a categorization scheme of verb concepts. ------------------------------ Regarding including "verb concept" as one category of "Elements of Structure" -- why not also include "noun concept" as another category of "Elements of Structure"? Going further, I think "Elements of Structure" should categorize "concept", not "meaning". "Elements of Structure" does not categorize other kinds of "meaning", such as "questions" and "propositions". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" ---04/29/2010 09:16:21 PM---Mark, Some responses like this. "Ronald G. Ross" 04/29/2010 09:16 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: SBVR RTF issue 13716 - updated Resolution document Mark, Some responses like this. Ron At 08:12 AM 4/27/2010, Mark H Linehan wrote: My own responses inserted like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com keri 04/26/2010 11:42 AM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: SBVR RTF issue 13716 - updated Resolution document Mark, I'll answer where I can. Ron may want to expand on the "Elements of Structure" bits. Keri On 4/26/10 2:46 AM, "Mark H Linehan" wrote: The proposed new definition of "fact type" makes no sense to me: "concept that specializes the concept actuality and that is the meaning of a verb phrase that involves one or more roles ". I do not believe that every fact type is also an actuality. 'man jumps over moon' may be a fact type but clearly is not an actuality. This is actually only changing the final term from "noun concepts" to "roles" -- In the notes that were circulated many moons back, there was an annotation that "this wording change was agreed in meeting discussion notes." If you have an issue with fact type and actuality that is not part of this issue. The proposed resolution changes the text to what I quote above. I disagree with it because I don't believe the concept 'fact type' incorporates each characteristic of the concept 'actuality'. I remember we had a previous email discussion about this and there is a rationalization, but that rationalization does not appear in the proposed resolution. These concerns are not part of the issue 13716 discussion. (I think the difficulty is that we've had no convenience document for a good while, so it's becoming very difficult to keep up with changes(??). Anyway, I don't know why there would be a problem with changing "noun concept" to "role" ... but as Keri says, that's just not part of this issue.) I don't understand the "Elements of Structure" categorization scheme: * Why do we include "classification" and "categorization" facts in this scheme, You probably understand this (I can't tell from the above), but let's be clear what's being proposed for inclusion: *Not* classification and categorization facts per se, just the terms "classification" and "categorization" (and their definitions). In some SBVR user's vocabulary, the actual facts would already be "there" (in some form). These two new entries just allow the users to specifically call those facts "classifications" and "categorizations". Why is that useful? Here is what I wrote in my original message: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose." "With respect to the concepts .categorization. and .classification., I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use .categorization. and .classification. as standard SBVR terms so when people say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say .That represents or creates a categorization (or a classification).. 3. To be able to ask business people for real-life examples from their business . and have definitions to fall back on if they give something inappropriate." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Do you think that some note(s) ought to be included to explain the above? (I think all of Clause 11 should be annotated, so I certainly agree. IMHO, it's naive to think that terms and definitions 'sell' or even explain themselves on their own.) but not (for example) facts about partitive or associative or contextualization verb concepts? For verb concepts, both the fact types and the individual facts come from the SBVR user's domain. Why would we call those out special?? The point is that for verb concepts, we have the terms needed for people to talk about entries in their vocabulary. For example, they can say (pointing to something): * That's an associative fact type. * That's a fact formed based on an associative fact type. (I might not be saying that quite right.) There are no additional terms (words) they would use (unless I am missing something). It's just about the words people need to use to build concept systems. Why call out a separate categorization scheme for "classification" and "categorization" versus the "Verb Concept Templating" scheme? I'm not sure what you are saying. The Verb Concept 'Templating' Scheme refers only to fact types (verb concepts). But there is additional vocabulary ("classification" and "categorization") people use when they structure their concept systems. We just need those two terms, that's all. (Read on.) (The answer to this question should be included in the text.) As above. These two are for the constructs (in a user's model) that apply/use the given SBVR fact types: customer is a category of person; Switzerland assorts to country . these are what a user would be specifying in their model, so that's what's relevant to be able to talk about with them. The others (partitive, associative, et al) - those are what they are in the user's model: person rents car; insurance is included in rental contract. So there we talk to the user about their model's partitive verb concepts, their associative verb concepts, etc. Yes, I understand that the "Elements of Structure" categorization scheme is about the structure of the noun concepts of the user domain model, and the "Verb Concept Templating" scheme is about the verb concepts. But why make this separation? I don't follow why you say one is about noun concepts and one is about verb concepts. From the user's perspective (i.e., building of SBVR concept systems), all of the following are ultimately about asserting something about noun concepts: * fact types (verb concepts) * classifications * categorizations These are 'structural members' core to the user's concept system. * Why are we defining facts about "classification verb concept" and "categorization verb concept" I have no use whatsoever for "classification verb concept" and "categorization verb concept". I think those concepts are strange (wonky) and unneeded. That was one major reason I disagree with the current resolution drafted by Keri. I also have no use whatsoever for "contextualization verb concept". That's a term no builder of a concept system would ever use. Let's get rid of that! I wrote: "You do not find .is-role-of fact [type]. and .is-facet-of fact [type]. in [my proposed] scheme because there are no natural business terms (in English at least) for those concepts. (.Rollification. and .facetification. have been facetiously proposed, which illustrates my point very effectively.)". and categorizing the facts? As far as I can remember, there are no other cases in SBVR where we follow this pattern -- where we define concepts as kinds of facts. Ron explained this when he submitted his proposal to add these. Could we add a note that gives this explanation? At this point, I'm not sure what (which) needs explaining, so help me out ... (?). * Why do we include "fact type" in "Elements of Structure"? My opinion: it does not belong in "Elements of Structure" since it is not the same concept type as "categorization" and "classification". ("fact type" is a concept, whereas "classification" and "categorization" are facts. So how can they all participate in the same categorization scheme?) Ron explained this when he submitted his proposal to add these. I think it is logically wrong. Here's what I wrote: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ " ... the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., .categorization. and .classification.). The term .element of structure. is used prominently in my book, Business Rule Concepts 3rd ed. Surely, no one can doubt that: * The three categories above are key meanings in *structuring* a business concept system. * A concept system indeed has structure that needs to be designed (or adopted) by the business to operate. Here is a proposed definition for .element of structure. (again, sorry for the lack of SBVR-SE): the categorization scheme of the concept .meaning. that classifies a meaning based on its part in organizing a community.s concept system ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ According to the proposed definition, the categorization scheme is not *logically* wrong ... they are indeed all meanings. You might argue that it is simply not needed ... But in the Clause 11 context, I think it's quite useful. * Do we need the separate glossary entries for "classification fact" and "categorization fact", given that these are just synonyms for the entries that are immediately above each of them? Our usual practices is to create "see" entries only when the primary term is at some other location in the document. It was my convention in preparing Clauses 11 and 12 to include entries for synonyms . I beliieve I did that consistently. But if there is some other convention to omit them, per your suggestion of a guideline, that's fine too. And the other cases should be removed as well. (Probably needs a covering Issue for the work.) The group needs to decide this. Regarding the new figure 11.5: * Is the generalization line from "verb concept" to "meaning" correct? According to the proposed definition of "element of structure", yes. It has to go that high to avoid the differentiation of facts and fact types. "Verb concept" is already a kind of "concept" which is a kind of "meaning". Also, "verb concept" is not mutually exclusive with "concept". * Should "concept" share a generalization line with "classification" and "categorization"? "Concept" is certainly not mutually exclusive with those two. Corrected graphic sent earlier. I think the definition of "contextualization verb concept" should be given extensionally, as it is today. I think an extensional definition makes the relationship among this, "is-role-of verb concept" and "is-facet-of verb concept" clearer. I think we should do away with these wonky concepts/terms. What does it add? Who would use it? This was discussed in the meeting and the group preferred it this new way. It can be whichever way the group prefers. The first letter of the example for "is-property-of verb concept" should be capitalized. It is a phrase, not a complete sentence. It looks like we're not changing the definition of "partitive fact type" at all. At least, I can't spot the change. Did you meant to start the definition with "binary verb concept ..."? You're probably correct here. That change instruction can be deleted. (It reverted back to use 'fact type' as part of Donald's edict on synonym usage, thereby making it "no change.") I don't see any change to the General Concept for "situational role". Ditto. I see that you are consistently replacing Examples with Notes, but they sure look like Examples to me. Why do you want to mark them as Notes? That's where "classification verb concept" and "categorization verb concept" get so wonky. If you ignore the "or any verb concept that specializes it", the definition IS the (only) example. All you can do is give notes about how it would be used ... which are *not* really examples. It all gets impossible. I am pleading for simplification. Let's get rid of this junk. I am not "consistently replacing" things . these were ccases where the one SBVR verb concept (or a specialization of it) would be giving an example of itself. Since these are examples of the USAGE of these entries it was stated that these were more appropriately labeled as notes about it. E.g., we wouldn't give an example of "Switzerland" but might want to make a note about it. I think these are Examples. If it's that confusing, it couldn't be very good. For the record, nothing in this Issue is put forth as "my" personal idea or position . I am the scribe, captturing what the group is saying/agreeing on this Issue. I don't need to 'endorse' something to record it. - Keri (See attached file: ISSUE 13716 V7.2C1.png) Date: Mon, 03 May 2010 19:41:26 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: keri CC: SBVR RTF Subject: Re: SBVR RTF issue 13716 - updated Resolution document X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: o43NfVDd015292 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1273534892.88373@nddMQXsSHluHnKsQefNtSA X-Spam-Status: No A brief comment, of no particular value: Keri wrote: On Elements of Structure vis--vis Verb Concept Templating. The difference for these two schemes is not one of nominalization. The new concepts Ron has proposed are categories of 'fact' and they use nouns, as for any term. This may be more clear if you look at the synonyms, which present the longer (full) term: "classification fact" and "categorization fact". These are not nominalizations any more than "fact" is a nominalization. Mark wrote: >> (1) I think these definitions are using "fact of " as a round-about way of meaning "nominalization" because we are missing the "nominalization" concept in clauses 8 and 11. Keri is correct. The categorization facts are not "nominalizations" per se. Nominalization occurs when the verb acts on the proposition itself, e.g.," Keri thinks that categorization facts are facts". "That categorization facts are facts" is a nominalization. The fact type here is 'person thinks proposition'. "the fact of a bishop managing a diocese" and "the fact that a bishop manages a diocese" are just English language isms. "Each bishop manages a diocese" is the representation of the fact you mean. Now that fact is a proposition and it may become nominalized if you use it verbatim in a sentence that speaks of it as a proposition. On the other hand, the proposition can be "objectified" -- that is, used to refer to the corresponding actuality. The distinction between nominalization and objectification is exactly the same as that between designation and denotation. A factual statement "designates" a fact, and "denotes" the corresponding actuality. So if you are talking about the fact, it is a nominalization, and if you are talking about the actuality, it is an objectification. In English, we often say "the fact that X" for the latter case. What characterizes a bishop is actual management of a diocese -- the instance of the fact type -- not the proposition. I think Mark's point, however, is well-taken. A fact of itself is a true proposition, full stop. But every use of the expression of a fact in some fact type role will necessarily either nominalize it (refer to the proposition) or objectify it (refer to the actuality). And it is easy to determine which, because the fact type role is typed either 'actuality' (state of affairs) or 'proposition' (meaning). We introduce 'nonminalization' and 'objectification' in Clause 9, in order to assign a variable to the corresponding proposition or actuality when the logical formulation of the fact itself has free variables in it, that is, variables that are bound/quantified outside the nominalization or objectification. Example: Each person who has a vision impediment must have the fact that he requires corrective lenses indicated on his driver's license. "the fact that he requires corrective lenses" is a nominalization -- the fact is what must be indicated on the driver's license, not the actuality. But the "he" refers to the variable that ranges over "person who has a vision impediment" in the overall rule. For each person, the fact that that person requires corrective lenses is a different fact from the fact that any other person requires them. So we need to introduce a variable whose value is the appropriate fact in each case. This stuff is really confusing, but it is something that only SBVR can do. "Categorization" is defined in Merriam-Webster online as "to put into a category", which uses an infinitive. Infinitives are noun phrases, i.e. nominalizations. Again, infinitives and gerunds are usually objectifications -- they refer to the actualities. Categorization is a noun phrase that refers to a collection of actualities of persons putting specific things in categories. (2) Why not be consistent and do the same for "Verb Concept Templating"? For example, "association: fact that a fact type has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations" Ah, well. Much of clause 11 mystifies me as well. -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." To: sbvr-rtf@omg.org Subject: Re: SBVR RTF issue 13716 - updated Resolution document X-KeepSent: 6DB52B78:859D3572-85257719:00441AAC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Tue, 4 May 2010 10:06:56 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 05/04/2010 10:06:57, Serialize complete at 05/04/2010 10:06:57 I accept Ed's argument that "classification" and "categorization" are objectifications rather than nominalizations. In clause 9.2.7, in the entry for 'objectification', there is an example of defining a term as an objectification: late return defined as actuality that a given rental is returned late. I think the definitions of "classification" and "categorization" would be clearer if they followed this pattern, rather than "fact that ...." And they would not introduce the connotation of "proposition taken as true". So we would have: categorization: actuality that a given general concept specializes a given general concept classification: actuality that a given individual concept specializes a given general concept For consistency, we should drop "categorization fact" and "classification fact". I still believe we should combine "Elements of Structure" and "Verb Concept Templating" by defining similar objectifications for the concepts currently proposed for "Verb Concept Templating": association: actuality that a given verb concept has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations property: actuality that a given association defines that each instance of a given concept has a particular quality or trait partition: actuality that a given binary verb concept defines that each instance of a given part is in the composition of a given whole contextualization: situation or view situation: actuality that a given verb concept defines [?situational?] roles that are understood or assessed with respect to a set of circumstances view: actuality that a given verb concept defines a mode or manner of of looking at or regarding a given concept (from Merriam-Webster Collegiate, 'view', 2a) Notes: * I put a couple of possible variations in "[? ... ?]" above * I propose "association" instead of "associative verb concept", "partition" instead of "partitive verb concept", "property" instead of "is-property-of verb concept", "situation" instead of "is-role-of verb concept", and "view" instead of "is-facet-of verb concept" The main advantage of this approach is that it considerably simplifies clause 11.1.5 by combining the two proposed categorization schemes. Another advantage is that it uses real English terms such as "association" instead of made up terms such as "associative verb concept". A third advantage is that these definition are easier to understand (at least to me), because they all use active rather than passive voice. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Ed Barkmeyer 05/03/2010 07:41 PM Please respond to edbark@nist.gov To keri cc SBVR RTF Subject Re: SBVR RTF issue 13716 - updated Resolution document A brief comment, of no particular value: Keri wrote: > On Elements of Structure vis--vis Verb Concept Templating. > The difference for these two schemes is not one of nominalization. The new concepts Ron has proposed are categories of 'fact' and they use nouns, as for any term. This may be more clear if you look at the synonyms, which present the longer (full) term: "classification fact" and "categorization fact". These are not nominalizations any more than "fact" is a nominalization. > Mark wrote: > >> (1) I think these definitions are using "fact of " as a round-about way of meaning "nominalization" because we are missing the "nominalization" concept in clauses 8 and 11. Keri is correct. The categorization facts are not "nominalizations" per se. Nominalization occurs when the verb acts on the proposition itself, e.g.," Keri thinks that categorization facts are facts". "That categorization facts are facts" is a nominalization. The fact type here is 'person thinks proposition'. "the fact of a bishop managing a diocese" and "the fact that a bishop manages a diocese" are just English language isms. "Each bishop manages a diocese" is the representation of the fact you mean. Now that fact is a proposition and it may become nominalized if you use it verbatim in a sentence that speaks of it as a proposition. On the other hand, the proposition can be "objectified" -- that is, used to refer to the corresponding actuality. The distinction between nominalization and objectification is exactly the same as that between designation and denotation. A factual statement "designates" a fact, and "denotes" the corresponding actuality. So if you are talking about the fact, it is a nominalization, and if you are talking about the actuality, it is an objectification. In English, we often say "the fact that X" for the latter case. What characterizes a bishop is actual management of a diocese -- the instance of the fact type -- not the proposition. I think Mark's point, however, is well-taken. A fact of itself is a true proposition, full stop. But every use of the expression of a fact in some fact type role will necessarily either nominalize it (refer to the proposition) or objectify it (refer to the actuality). And it is easy to determine which, because the fact type role is typed either 'actuality' (state of affairs) or 'proposition' (meaning). We introduce 'nonminalization' and 'objectification' in Clause 9, in order to assign a variable to the corresponding proposition or actuality when the logical formulation of the fact itself has free variables in it, that is, variables that are bound/quantified outside the nominalization or objectification. Example: Each person who has a vision impediment must have the fact that he requires corrective lenses indicated on his driver's license. "the fact that he requires corrective lenses" is a nominalization -- the fact is what must be indicated on the driver's license, not the actuality. But the "he" refers to the variable that ranges over "person who has a vision impediment" in the overall rule. For each person, the fact that that person requires corrective lenses is a different fact from the fact that any other person requires them. So we need to introduce a variable whose value is the appropriate fact in each case. This stuff is really confusing, but it is something that only SBVR can do. > "Categorization" is defined in Merriam-Webster online as "to put into a category", which uses an infinitive. Infinitives are noun phrases, i.e. nominalizations. Again, infinitives and gerunds are usually objectifications -- they refer to the actualities. Categorization is a noun phrase that refers to a collection of actualities of persons putting specific things in categories. > (2) Why not be consistent and do the same for "Verb Concept Templating"? For example, "association: fact that a fact type has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations" > Ah, well. Much of clause 11 mystifies me as well. -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." From: Don Baisley To: "sbvr-rtf@omg.org" Subject: RE: SBVR RTF issue 13716 - updated Resolution document Thread-Topic: SBVR RTF issue 13716 - updated Resolution document Thread-Index: AQHK6xolOvbmrrT29kCjxeF8twHXiZJBxUAAgAA5GOA= Date: Wed, 5 May 2010 00:48:14 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Are categorizations and classifications actualities, or are they propositions? I tend to think of them as I think of generalizations, which can be true or false. It seems that categorizations and classifications can be correct or incorrect, that is, true or false. A categorization is not a matter of something actually being in a certain category. I tend to think of a categorization as a proposition, based on judgment, that something is in a certain category. So I would side with Ron and Keri.s definition. > situation: actuality that a given verb concept defines [?situational?] roles that > are understood or assessed with respect to a set of circumstances I don.t understand Mark.s proposed objectifying definitions. I cannot imaging defining .situation. as he has it. Regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Tuesday, May 04, 2010 7:07 AM To: sbvr-rtf@omg.org Subject: Re: SBVR RTF issue 13716 - updated Resolution document I accept Ed's argument that "classification" and "categorization" are objectifications rather than nominalizations. In clause 9.2.7, in the entry for 'objectification', there is an example of defining a term as an objectification: .late return. defined as .actuality that a given rental is returned late.. I think the definitions of "classification" and "categorization" would be clearer if they followed this pattern, rather than "fact that ...." And they would not introduce the connotation of "proposition taken as true". So we would have: categorization: actuality that a given general concept specializes a given general concept classification: actuality that a given individual concept specializes a given general concept For consistency, we should drop "categorization fact" and "classification fact". I still believe we should combine "Elements of Structure" and "Verb Concept Templating" by defining similar objectifications for the concepts currently proposed for "Verb Concept Templating": association: actuality that a given verb concept has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations property: actuality that a given association defines that each instance of a given concept has a particular quality or trait partition: actuality that a given binary verb concept defines that each instance of a given part is in the composition of a given whole contextualization: situation or view situation: actuality that a given verb concept defines [?situational?] roles that are understood or assessed with respect to a set of circumstances view: actuality that a given verb concept defines a mode or manner of of looking at or regarding a given concept (from Merriam-Webster Collegiate, 'view', 2a) Notes: * I put a couple of possible variations in "[? ... ?]" above * I propose "association" instead of "associative verb concept", "partition" instead of "partitive verb concept", "property" instead of "is-property-of verb concept", "situation" instead of "is-role-of verb concept", and "view" instead of "is-facet-of verb concept" The main advantage of this approach is that it considerably simplifies clause 11.1.5 by combining the two proposed categorization schemes. Another advantage is that it uses real English terms such as "association" instead of made up terms such as "associative verb concept". A third advantage is that these definition are easier to understand (at least to me), because they all use active rather than passive voice. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Ed Barkmeyer 05/03/2010 07:41 PM Please respond to edbark@nist.gov To keri cc SBVR RTF Subject Re: SBVR RTF issue 13716 - updated Resolution document A brief comment, of no particular value: Keri wrote: > On Elements of Structure vis-is Verb Concept Templating. > The difference for these two schemes is not one of nominalization. The new concepts Ron has proposed are categories of 'fact' and they use nouns, as for any term. This may be more clear if you look at the synonyms, which present the longer (full) term: "classification fact" and "categorization fact". These are not nominalizations any more than "fact" is a nominalization. > Mark wrote: > >> (1) I think these definitions are using "fact of " as a round-about way of meaning "nominalization" because we are missing the "nominalization" concept in clauses 8 and 11. Keri is correct. The categorization facts are not "nominalizations" per se. Nominalization occurs when the verb acts on the proposition itself, e.g.," Keri thinks that categorization facts are facts". "That categorization facts are facts" is a nominalization. The fact type here is 'person thinks proposition'. "the fact of a bishop managing a diocese" and "the fact that a bishop manages a diocese" are just English language isms. "Each bishop manages a diocese" is the representation of the fact you mean. Now that fact is a proposition and it may become nominalized if you use it verbatim in a sentence that speaks of it as a proposition. On the other hand, the proposition can be "objectified" -- that is, used to refer to the corresponding actuality. The distinction between nominalization and objectification is exactly the same as that between designation and denotation. A factual statement "designates" a fact, and "denotes" the corresponding actuality. So if you are talking about the fact, it is a nominalization, and if you are talking about the actuality, it is an objectification. In English, we often say "the fact that X" for the latter case. What characterizes a bishop is actual management of a diocese -- the instance of the fact type -- not the proposition. I think Mark's point, however, is well-taken. A fact of itself is a true proposition, full stop. But every use of the expression of a fact in some fact type role will necessarily either nominalize it (refer to the proposition) or objectify it (refer to the actuality). And it is easy to determine which, because the fact type role is typed either 'actuality' (state of affairs) or 'proposition' (meaning). We introduce 'nonminalization' and 'objectification' in Clause 9, in order to assign a variable to the corresponding proposition or actuality when the logical formulation of the fact itself has free variables in it, that is, variables that are bound/quantified outside the nominalization or objectification. Example: Each person who has a vision impediment must have the fact that he requires corrective lenses indicated on his driver's license. "the fact that he requires corrective lenses" is a nominalization -- the fact is what must be indicated on the driver's license, not the actuality. But the "he" refers to the variable that ranges over "person who has a vision impediment" in the overall rule. For each person, the fact that that person requires corrective lenses is a different fact from the fact that any other person requires them. So we need to introduce a variable whose value is the appropriate fact in each case. This stuff is really confusing, but it is something that only SBVR can do. > "Categorization" is defined in Merriam-Webster online as "to put into a category", which uses an infinitive. Infinitives are noun phrases, i.e. nominalizations. Again, infinitives and gerunds are usually objectifications -- they refer to the actualities. Categorization is a noun phrase that refers to a collection of actualities of persons putting specific things in categories. > (2) Why not be consistent and do the same for "Verb Concept Templating"? For example, "association: fact that a fact type has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations" > Ah, well. Much of clause 11 mystifies me as well. -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." DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=btinternet.com; h=DKIM-Signature:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Cc:References:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:X-MimeOLE:In-Reply-To; b=entmQErW1bFNhOlfCHKF+X0WZXN9LKNyPjlz5jCyI1YJXeykJ+gk3Rj80lTMXLrGP4JAVB/z9fe7w+UhlBFEKfCgx/l5dFYUMQJrZRDz5BB++tXm9EKVcApbmPXIp2ii0bQ1yb/L78hYZZh1tvKppsUtrrk2h8E6vPlrH0nKgns= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btinternet.com; s=s1024; t=1271956469; bh=j6Bnwkob3Emr896nGzsN0BC5ILk7gqnyJI9FPDbakcg=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Cc:References:Subject:Date:Organization:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:X-MimeOLE:In-Reply-To; b=D/uVjzr7KL6jidFJjHkKfZT7pdJCPTt4x3pvD5mO0gPx5F3Oe4765TZoye9a0/eE92aS5yybsaolf+KflGE+V+NCKnWeKJG9P3tMjT4p/OCfFFG7eiMMPj2V0wAls6TjjOyIdtzyhaVMaI543hMZ3UK3VSoy8EGQkp5clh1ShnM= X-Yahoo-SMTP: ipAFRh2swBALpDiVMXIwBxwhmA51J31AV6tKcA.nNICCSy6cH9UoQMM- X-YMail-OSG: IsMGCa4VM1mQGOi8xG1muRZsFussYvSXTcQy2Ltz_rZw8q0z_ElDr5LdWWOyQ9nKQlmb0zmcuB_edS4GD7yjnVWgGMYerCq4hJBtTlz5WWUop795.XM_88EBmF5vWFtObMIZ._0g2HLFl0ITf5W965ANAFOIG5tXgh_KrQxzyuKzLDfQOYnb9SGetiKT9FlkD5k88B1NwT14syfY6I1F.4adqNLRCDqxL8WVV9zIv95O3KaFJ7VF9Bkomoj9WHLltT6bjJcyf00- X-Yahoo-Newman-Property: ymail-3 Reply-To: From: "Donald Chapin" To: "'keri'" , "'John Hall'" Cc: "'SBVR RTF'" Subject: RE: SBVR RTF issue 13716 - updated Resolution document Date: Thu, 22 Apr 2010 18:14:23 +0100 Organization: Business Semantics Ltd X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcrMKiSpwYQRp3xLSJG36hkPr+f2bwAxJfTKAwwGcK8Bp3eMEAAExmIQAJtJIcA= Keri, On 19 April 2010 15:52 Keri wrote: nald, Can you tell me what the milestones are for getting 13716 to agreement in time to make the cut for SBVR 1.1? I'll be offline after May 8 (until late July) so will need to hand off work on 13716 if it is still active during that period. The milestones for completing the SBVR RTF report for the June OMG meeting as discussed in the March 25th SBVR RTF meeting are (working backwards): - SBVR RTF Report due on Monday, 24th May (the OMG 4-week deadline) - One week for Ron & Terry to incorporate revisions to Annex E into their respective Annexes (start 17th May latest) - Two weeks for John to bring Annex E up to date (start 3rd May latest) - One week for a final ballot (start 26th April latest) With regard to specific milestones for getting the Issue 13716 to agreement, as discussion is ongoing and several new points have been raised recently by several people, I don.t really know what the milestones are except to track the open questions and try to bring closure on them as quickly as possible. It may be necessary to schedule a telecon. I will do everything I am able to do to try to bring closure before you go on May 8th. Donald Thanks. Keri On 4/19/10 2:39 AM, "Donald Chapin" wrote: Keri, While I was reviewing all the Issues to put into Ballot 3, I discovered a change in the resolution of Issue 13716 that I had missed before and that increases the ambiguity of the SBVR specification rather than decreases it. It is the change of the signifier of the more general concept of .situational role. from .object type. to .general concept.. I know that the SBVR specification says that .object type. and .general concept. are synonyms. However, this is greatly confusing as .object type. in SBVR means a (general) noun concept that is not a fact type role; while ISO 1087-1 defines general concept as all (noun) concepts that can have more than can correspond to two or more objects (over time). I agree that .general concept. is more business friendly than .object type.. In fact the signifier .object type. does not belong in SBVR at all as .object. is not an SBVR term. That concept needs a term that recognizes that it is a noun concept that is not a fact type role. Until this problem is fixed, changing the signifier of the more general concept of .situational role. to .general concept. opens up the ambiguity that fact type roles can be situational roles which they cannot be. One or more fact type roles can define a situational role, but fact type roles cannot be situational roles because fact type roles can never be .ranged over. by other fact type roles. If you can remove this change, we can add it into the resolution of an Issue that deals with the underlying problem. Sorry I didn.t spot this sooner. Donald -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: 11 April 2010 03:30 To: SBVR RTF; Donald R. Chapin Subject: SBVR RTF issue 13716 - updated Resolution document All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept .individual concept specializes concept. or any verb concept that specializes it categorization verb concept Definition: the verb concept .general concept specializes concept. or any verb concept that specializes it contextualization verb concept Definition: the verb concept .role ranges over general concept. or the verb concept .concept has facet. or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept .role ranges over general concept. or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept .concept has facet. or any verb concept that specializes it Option: in the definitions above, we can change each case of .verb concept that specializes. to .binary fact type that specializes. if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using .formulated. in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1004260112 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 26 Apr 2010 05:42:14 -1000 Subject: Re: SBVR RTF issue 13716 - updated Resolution document From: keri To: Mark H Linehan , SBVR RTF Thread-topic: SBVR RTF issue 13716 - updated Resolution document Thread-index: AcrlVwrTSTWr9FFKEd+XyQARJM+Cgg== Mark, I'll answer where I can. Ron may want to expand on the "Elements of Structure" bits. Keri On 4/26/10 2:46 AM, "Mark H Linehan" wrote: The proposed new definition of "fact type" makes no sense to me: "concept that specializes the concept .actuality. and that is the meaning of a verb phrase that involves one or more roles ". I do not believe that every fact type is also an actuality. 'man jumps over moon' may be a fact type but clearly is not an actuality. This is actually only changing the final term from "noun concepts" to "roles" -- In the notes that were circulated many moons back, there was an annotation that "this wording change was agreed in meeting discussion notes." If you have an issue with fact type and actuality that is not part of this issue. I don't understand the "Elements of Structure" categorization scheme: * Why do we include "classification" and "categorization" facts in this scheme, but not (for example) facts about partitive or associative or contextualization verb concepts? Why call out a separate categorization scheme for "classification" and "categorization" versus the "Verb Concept Templating" scheme? (The answer to this question should be included in the text.) These two are for the constructs (in a user's model) that apply/use the given SBVR fact types: customer is a category of person; Switzerland assorts to country . these are what a user would be specifying in their model, so that's what's relevant to be able to talk about with them. The others (partitive, associative, et al) - those are what they are in the user's model: person rents car; insurance is included in rental contract. So there we talk to the user about their model's partitive verb concepts, their associative verb concepts, etc. * Why are we defining facts about "classification verb concept" and "categorization verb concept" and categorizing the facts? As far as I can remember, there are no other cases in SBVR where we follow this pattern -- where we define concepts as kinds of facts. Ron explained this when he submitted his proposal to add these. * Why do we include "fact type" in "Elements of Structure"? My opinion: it does not belong in "Elements of Structure" since it is not the same concept type as "categorization" and "classification". ("fact type" is a concept, whereas "classification" and "categorization" are facts. So how can they all participate in the same categorization scheme?) Ron explained this when he submitted his proposal to add these. * Do we need the separate glossary entries for "classification fact" and "categorization fact", given that these are just synonyms for the entries that are immediately above each of them? Our usual practices is to create "see" entries only when the primary term is at some other location in the document. It was my convention in preparing Clauses 11 and 12 to include entries for synonyms . I believe I did that consistently. But if there is some other convention to omit them, per your suggestion of a guideline, that's fine too. And the other cases should be removed as well. (Probably needs a covering Issue for the work.) The group needs to decide this. Regarding the new figure 11.5: * Is the generalization line from "verb concept" to "meaning" correct? "Verb concept" is already a kind of "concept" which is a kind of "meaning". Also, "verb concept" is not mutually exclusive with "concept". * Should "concept" share a generalization line with "classification" and "categorization"? "Concept" is certainly not mutually exclusive with those two. Corrected graphic sent earlier. I think the definition of "contextualization verb concept" should be given extensionally, as it is today. I think an extensional definition makes the relationship among this, "is-role-of verb concept" and "is-facet-of verb concept" clearer. This was discussed in the meeting and the group preferred it this new way. It can be whichever way the group prefers. The first letter of the example for "is-property-of verb concept" should be capitalized. It is a phrase, not a complete sentence. It looks like we're not changing the definition of "partitive fact type" at all. At least, I can't spot the change. Did you meant to start the definition with "binary verb concept ..."? You're probably correct here. That change instruction can be deleted. (It reverted back to use 'fact type' as part of Donald's edict on synonym usage, thereby making it "no change.") I don't see any change to the General Concept for "situational role". Ditto. I see that you are consistently replacing Examples with Notes, but they sure look like Examples to me. Why do you want to mark them as Notes? I am not "consistently replacing" things . these were cases where the one SBVR verb concept (or a specialization of it) would be giving an example of itself. Since these are examples of the USAGE of these entries it was stated that these were more appropriately labeled as notes about it. E.g., we wouldn't give an example of "Switzerland" but might want to make a note about it. For the record, nothing in this Issue is put forth as "my" personal idea or position . I am the scribe, capturing what the group is saying/agreeing on this Issue. I don't need to 'endorse' something to record it. - Keri X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: 5net4FcVM1mUI9LN5ZFPhTlSEVTXGFTwx3KxRbstJZmz4EQ3m1FfaCc0EDwxOHZCWlSZ1CsXPu2fEWO56D7fF6wroU_Hr4m0whrTHM0oscca28.DeVKl7uzRaCh6aUx0aspfUZFeWJCmaoE6asjR8UKmCi6Ch7uvfOzBnfRlRVkem8My0.HuflIzEAzO3dkKJH3b021Nic8ZXNgSK4hNot05btSG1OlY.cDD1RtliRc2vDsxM6D.R3Yk8tJGy5yoV_0T51DBrtmlwEKETeqa2MVo5fZgebg- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 29 Apr 2010 20:16:00 -0500 To: Mark H Linehan , sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: Re: SBVR RTF issue 13716 - updated Resolution document Mark, Some responses like this. Ron At 08:12 AM 4/27/2010, Mark H Linehan wrote: My own responses inserted like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com keri 04/26/2010 11:42 AM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: SBVR RTF issue 13716 - updated Resolution document Mark, I'll answer where I can. Ron may want to expand on the "Elements of Structure" bits. Keri On 4/26/10 2:46 AM, "Mark H Linehan" wrote: The proposed new definition of "fact type" makes no sense to me: "concept that specializes the concept actuality and that is the meaning of a verb phrase that involves one or more roles ". I do not believe that every fact type is also an actuality. 'man jumps over moon' may be a fact type but clearly is not an actuality. This is actually only changing the final term from "noun concepts" to "roles" -- In the notes that were circulated many moons back, there was an annotation that "this wording change was agreed in meeting discussion notes." If you have an issue with fact type and actuality that is not part of this issue. The proposed resolution changes the text to what I quote above. I disagree with it because I don't believe the concept 'fact type' incorporates each characteristic of the concept 'actuality'. I remember we had a previous email discussion about this and there is a rationalization, but that rationalization does not appear in the proposed resolution. These concerns are not part of the issue 13716 discussion. (I think the difficulty is that we've had no convenience document for a good while, so it's becoming very difficult to keep up with changes(??). Anyway, I don't know why there would be a problem with changing "noun concept" to "role" ... but as Keri says, that's just not part of this issue.) I don't understand the "Elements of Structure" categorization scheme: * Why do we include "classification" and "categorization" facts in this scheme, You probably understand this (I can't tell from the above), but let's be clear what's being proposed for inclusion: *Not* classification and categorization facts per se, just the terms "classification" and "categorization" (and their definitions). In some SBVR user's vocabulary, the actual facts would already be "there" (in some form). These two new entries just allow the users to specifically call those facts "classifications" and "categorizations". Why is that useful? Here is what I wrote in my original message: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose." "With respect to the concepts .categorization. and .classification., I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use .categorization. and .classification. as standard SBVR terms so when people say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say .That represents or creates a categorization (or a classification).. 3. To be able to ask business people for real-life examples from their business . and have definitions to fall back on if they give something inappropriate." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Do you think that some note(s) ought to be included to explain the above? (I think all of Clause 11 should be annotated, so I certainly agree. IMHO, it's naive to think that terms and definitions 'sell' or even explain themselves on their own.) but not (for example) facts about partitive or associative or contextualization verb concepts? For verb concepts, both the fact types and the individual facts come from the SBVR user's domain. Why would we call those out special?? The point is that for verb concepts, we have the terms needed for people to talk about entries in their vocabulary. For example, they can say (pointing to something): * That's an associative fact type. * That's a fact formed based on an associative fact type. (I might not be saying that quite right.) There are no additional terms (words) they would use (unless I am missing something). It's just about the words people need to use to build concept systems. Why call out a separate categorization scheme for "classification" and "categorization" versus the "Verb Concept Templating" scheme? I'm not sure what you are saying. The Verb Concept 'Templating' Scheme refers only to fact types (verb concepts). But there is additional vocabulary ("classification" and "categorization") people use when they structure their concept systems. We just need those two terms, that's all. (Read on.) (The answer to this question should be included in the text.) As above. These two are for the constructs (in a user's model) that apply/use the given SBVR fact types: customer is a category of person; Switzerland assorts to country . these are what a user would be specifying in their model, so that's what's relevant to be able to talk about with them. The others (partitive, associative, et al) - those are what they are in the user's model: person rents car; insurance is included in rental contract. So there we talk to the user about their model's partitive verb concepts, their associative verb concepts, etc. Yes, I understand that the "Elements of Structure" categorization scheme is about the structure of the noun concepts of the user domain model, and the "Verb Concept Templating" scheme is about the verb concepts. But why make this separation? I don't follow why you say one is about noun concepts and one is about verb concepts. From the user's perspective (i.e., building of SBVR concept systems), all of the following are ultimately about asserting something about noun concepts: * fact types (verb concepts) * classifications * categorizations These are 'structural members' core to the user's concept system. * Why are we defining facts about "classification verb concept" and "categorization verb concept" I have no use whatsoever for "classification verb concept" and "categorization verb concept". I think those concepts are strange (wonky) and unneeded. That was one major reason I disagree with the current resolution drafted by Keri. I also have no use whatsoever for "contextualization verb concept". That's a term no builder of a concept system would ever use. Let's get rid of that! I wrote: "You do not find .is-role-of fact [type]. and .is-facet-of fact [type]. in [my proposed] scheme because there are no natural business terms (in English at least) for those concepts. (.Rollification. and .facetification. have been facetiously proposed, which illustrates my point very effectively.)". and categorizing the facts? As far as I can remember, there are no other cases in SBVR where we follow this pattern -- where we define concepts as kinds of facts. Ron explained this when he submitted his proposal to add these. Could we add a note that gives this explanation? At this point, I'm not sure what (which) needs explaining, so help me out ... (?). * Why do we include "fact type" in "Elements of Structure"? My opinion: it does not belong in "Elements of Structure" since it is not the same concept type as "categorization" and "classification". ("fact type" is a concept, whereas "classification" and "categorization" are facts. So how can they all participate in the same categorization scheme?) Ron explained this when he submitted his proposal to add these. I think it is logically wrong. Here's what I wrote: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ " ... the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., .categorization. and .classification.). The term .element of structure. is used prominently in my book, Business Rule Concepts 3rd ed. Surely, no one can doubt that: * The three categories above are key meanings in *structuring* a business concept system. * A concept system indeed has structure that needs to be designed (or adopted) by the business to operate. Here is a proposed definition for .element of structure. (again, sorry for the lack of SBVR-SE): the categorization scheme of the concept .meaning. that classifies a meaning based on its part in organizing a community.s concept system ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ According to the proposed definition, the categorization scheme is not *logically* wrong ... they are indeed all meanings. You might argue that it is simply not needed ... But in the Clause 11 context, I think it's quite useful. * Do we need the separate glossary entries for "classification fact" and "categorization fact", given that these are just synonyms for the entries that are immediately above each of them? Our usual practices is to create "see" entries only when the primary term is at some other location in the document. It was my convention in preparing Clauses 11 and 12 to include entries for synonyms . I beliieve I did that consistently. But if there is some other convention to omit them, per your suggestion of a guideline, that's fine too. And the other cases should be removed as well. (Probably needs a covering Issue for the work.) The group needs to decide this. Regarding the new figure 11.5: * Is the generalization line from "verb concept" to "meaning" correct? According to the proposed definition of "element of structure", yes. It has to go that high to avoid the differentiation of facts and fact types. "Verb concept" is already a kind of "concept" which is a kind of "meaning". Also, "verb concept" is not mutually exclusive with "concept". * Should "concept" share a generalization line with "classification" and "categorization"? "Concept" is certainly not mutually exclusive with those two. Corrected graphic sent earlier. I think the definition of "contextualization verb concept" should be given extensionally, as it is today. I think an extensional definition makes the relationship among this, "is-role-of verb concept" and "is-facet-of verb concept" clearer. I think we should do away with these wonky concepts/terms. What does it add? Who would use it? This was discussed in the meeting and the group preferred it this new way. It can be whichever way the group prefers. The first letter of the example for "is-property-of verb concept" should be capitalized. It is a phrase, not a complete sentence. It looks like we're not changing the definition of "partitive fact type" at all. At least, I can't spot the change. Did you meant to start the definition with "binary verb concept ..."? You're probably correct here. That change instruction can be deleted. (It reverted back to use 'fact type' as part of Donald's edict on synonym usage, thereby making it "no change.") I don't see any change to the General Concept for "situational role". Ditto. I see that you are consistently replacing Examples with Notes, but they sure look like Examples to me. Why do you want to mark them as Notes? That's where "classification verb concept" and "categorization verb concept" get so wonky. If you ignore the "or any verb concept that specializes it", the definition IS the (only) example. All you can do is give notes about how it would be used ... which are *not* really examples. It all gets impossible. I am pleading for simplification. Let's get rid of this junk. I am not "consistently replacing" things . these were ccases where the one SBVR verb concept (or a specialization of it) would be giving an example of itself. Since these are examples of the USAGE of these entries it was stated that these were more appropriately labeled as notes about it. E.g., we wouldn't give an example of "Switzerland" but might want to make a note about it. I think these are Examples. If it's that confusing, it couldn't be very good. For the record, nothing in this Issue is put forth as "my" personal idea or position . I am the scribe, captturing what the group is saying/agreeing on this Issue. I don't need to 'endorse' something to record it. - Keri Subject: Re: SBVR RTF issue 13716 - updated Resolution document X-KeepSent: 180C0C4F:BED5A426-85257715:00411AA3; 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: Fri, 30 Apr 2010 09:54:02 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 04/30/2010 09:54:03 Ron, Regarding the change of the definition of "fact type" -- we definitely are suffering from the lack of a convenience document. I have no objection to changing "noun concepts" to "roles". My concern is about changing from "concept that is the meaning of a verb phrase that... " (as in the adopted spec) to "concept that specializes the concept 'actuality' ..." I looked through all three RTF ballots that we have voted on so far, and cannot find one that changes the definition of "fact type" like this. Maybe I missed it, but I suspect an error in compiling the change. ------------------------------- Regarding "Elements of Structure" -- in English, we often nominalize verbs. For example, "murder" is the noun concept corresponding to the verb concept "person1 murders person2". As another example, "legalization" is the noun concept corresponding to "law legalizes state of affairs". In the same way, "categorization" is a nominalization of "concept1 specializes concept2". I think the only difference between the "Elements of Structure" categorization scheme and the "Verb Concept Templating" categorization scheme is that one is about nominalizations of verbs, while the other is about the verbs themselves. I think it is confusing to have two categorization schemes that attempt to categorize essentially the same concepts. We should pick one or the other. To put it another way, why should categorization and classification be in a separate categorization scheme from is-property-of and siblings? Categorization, association, and partition are all ways to structure concepts. Why should some of these be in one categorization scheme and some in another? The only difference that I can see is that we provide a "built in" SBVR verb concept for "categorization" whereas association, partition, etc., require their own domain vocabulary concepts. [ I think that this is a deficit in SBVR: why don't we provide "property-of" and "association" verb concepts as part of SBVR itself? (We do use "has" and "includes" in lots of examples in EU-Rent but neither are defined generally.) ] I suggest the noun concepts "classification" and "categorization" be added to clause 11.1.2 right after "concept1 has more general concept2" to emphasize how they relate to that verb concept. And I think "... is based on ..." is the wrong way to describe the relationship of "categorization" to the "specializes" verb concept. What we really need is a way to describe the nominalization relationship between a noun concept and a verb concept. We have nominalization as a kind of formulation in clause 9, but no equivalent concept in clause 8 or 11. If we did have the "nominalization" concept, it would be another entry in "Elements of Structure". ------------------------------ Regarding "categorization verb concept" and "classification verb concept" -- I believe the only reason we need these is for parallel construction of the "Verb Concept Templating" categorization scheme. These two verb concepts would go away if we switch to a categorization scheme based on nominalizations. On the other hand, we will need to keep them if we retain a categorization scheme of verb concepts. ------------------------------ Regarding including "verb concept" as one category of "Elements of Structure" -- why not also include "noun concept" as another category of "Elements of Structure"? Going further, I think "Elements of Structure" should categorize "concept", not "meaning". "Elements of Structure" does not categorize other kinds of "meaning", such as "questions" and "propositions". -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" ---04/29/2010 09:16:21 PM---Mark, Some responses like this. "Ronald G. Ross" 04/29/2010 09:16 PM To Mark H Linehan/Watson/IBM@IBMUS, sbvr-rtf@omg.org cc Subject Re: SBVR RTF issue 13716 - updated Resolution document Mark, Some responses like this. Ron At 08:12 AM 4/27/2010, Mark H Linehan wrote: My own responses inserted like this. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com keri 04/26/2010 11:42 AM To Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF cc Subject Re: SBVR RTF issue 13716 - updated Resolution document Mark, I'll answer where I can. Ron may want to expand on the "Elements of Structure" bits. Keri On 4/26/10 2:46 AM, "Mark H Linehan" wrote: The proposed new definition of "fact type" makes no sense to me: "concept that specializes the concept .. actuality.. and that is the meaning of a verb phrase that involves one or more roles ". I do not believe that every fact type is also an actuality. 'man jumps over moon' may be a fact type but clearly is not an actuality. This is actually only changing the final term from "noun concepts" to "roles" -- In the notes that were circulated many moons back, there was an annotation that "this wording change was agreed in meeting discussion notes." If you have an issue with fact type and actuality that is not part of this issue. The proposed resolution changes the text to what I quote above. I disagree with it because I don't believe the concept 'fact type' incorporates each characteristic of the concept 'actuality'. I remember we had a previous email discussion about this and there is a rationalization, but that rationalization does not appear in the proposed resolution. These concerns are not part of the issue 13716 discussion. (I think the difficulty is that we've had no convenience document for a good while, so it's becoming very difficult to keep up with changes(??). Anyway, I don't know why there would be a problem with changing "noun concept" to "role" ... but as Keri says, that's just not part of this issue.) I don't understand the "Elements of Structure" categorization scheme: * Why do we include "classification" and "categorization" facts in this scheme, You probably understand this (I can't tell from the above), but let's be clear what's being proposed for inclusion: *Not* classification and categorization facts per se, just the terms "classification" and "categorization" (and their definitions). In some SBVR user's vocabulary, the actual facts would already be "there" (in some form). These two new entries just allow the users to specifically call those facts "classifications" and "categorizations". Why is that useful? Here is what I wrote in my original message: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ "I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose." "With respect to the concepts categorization and classification, I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use categorization and classification as standard SBVR terms so when people say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say That represents or creates a categorization (or a classification). 3. To be able to ask business people for real-life examples from their business . and have definitionss to fall back on if they give something inappropriate." ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Do you think that some note(s) ought to be included to explain the above? (I think all of Clause 11 should be annotated, so I certainly agree. IMHO, it's naive to think that terms and definitions 'sell' or even explain themselves on their own.) but not (for example) facts about partitive or associative or contextualization verb concepts? For verb concepts, both the fact types and the individual facts come from the SBVR user's domain. Why would we call those out special?? The point is that for verb concepts, we have the terms needed for people to talk about entries in their vocabulary. For example, they can say (pointing to something): * That's an associative fact type. * That's a fact formed based on an associative fact type. (I might not be saying that quite right.) There are no additional terms (words) they would use (unless I am missing something). It's just about the words people need to use to build concept systems. Why call out a separate categorization scheme for "classification" and "categorization" versus the "Verb Concept Templating" scheme? I'm not sure what you are saying. The Verb Concept 'Templating' Scheme refers only to fact types (verb concepts). But there is additional vocabulary ("classification" and "categorization") people use when they structure their concept systems. We just need those two terms, that's all. (Read on.) (The answer to this question should be included in the text.) As above. These two are for the constructs (in a user's model) that apply/use the given SBVR fact types: customer is a category of person; Switzerland assorts to country . these are what aa user would be specifying in their model, so that's what's relevant to be able to talk about with them. The others (partitive, associative, et al) - those are what they are in the user's model: person rents car; insurance is included in rental contract. So there we talk to the user about their model's partitive verb concepts, their associative verb concepts, etc. Yes, I understand that the "Elements of Structure" categorization scheme is about the structure of the noun concepts of the user domain model, and the "Verb Concept Templating" scheme is about the verb concepts. But why make this separation? I don't follow why you say one is about noun concepts and one is about verb concepts. From the user's perspective (i.e., building of SBVR concept systems), all of the following are ultimately about asserting something about noun concepts: * fact types (verb concepts) * classifications * categorizations These are 'structural members' core to the user's concept system. * Why are we defining facts about "classification verb concept" and "categorization verb concept" I have no use whatsoever for "classification verb concept" and "categorization verb concept". I think those concepts are strange (wonky) and unneeded. That was one major reason I disagree with the current resolution drafted by Keri. I also have no use whatsoever for "contextualization verb concept". That's a term no builder of a concept system would ever use. Let's get rid of that! I wrote: "You do not find is-role-of fact [type] and is-facet-of fact [type] in [my proposed] scheme because there are no natural business terms (in English at least) for those concepts. (Rollification and facetification have been facetiously proposed, which illustrates my point very effectively.)". and categorizing the facts? As far as I can remember, there are no other cases in SBVR where we follow this pattern -- where we define concepts as kinds of facts. Ron explained this when he submitted his proposal to add these. Could we add a note that gives this explanation? At this point, I'm not sure what (which) needs explaining, so help me out ... (?). * Why do we include "fact type" in "Elements of Structure"? My opinion: it does not belong in "Elements of Structure" since it is not the same concept type as "categorization" and "classification". ("fact type" is a concept, whereas "classification" and "categorization" are facts. So how can they all participate in the same categorization scheme?) Ron explained this when he submitted his proposal to add these. I think it is logically wrong. Here's what I wrote: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ " ... the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., categorization and classification). The term element of structure is used prominently in my book, Business Rule Concepts 3rd ed. Surely, no one can doubt that: * The three categories above are key meanings in *structuring* a business concept system. * A concept system indeed has structure that needs to be designed (or adopted) by the business to operate. Here is a proposed definition for element of structure (again, sorry for the lack of SBVR-SE): the categorization scheme of the concept meaning that classifies a meaning based on its part in organizing a communitys concept system ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ According to the proposed definition, the categorization scheme is not *logically* wrong ... they are indeed all meanings. You might argue that it is simply not needed ... But in the Clause 11 context, I think it's quite useful. * Do we need the separate glossary entries for "classification fact" and "categorization fact", given that these are just synonyms for the entries that are immediately above each of them? Our usual practices is to create "see" entries only when the primary term is at some other location in the document. It was my convention in preparing Clauses 11 and 12 to include entries for synonyms . I beliieve I did that consistently. But if there is some other convention to omit them, per your suggestion of a guideline, that's fine too. And the other cases should be removed as well. (Probably needs a covering Issue for the work.) The group needs to decide this. Regarding the new figure 11.5: * Is the generalization line from "verb concept" to "meaning" correct? According to the proposed definition of "element of structure", yes. It has to go that high to avoid the differentiation of facts and fact types. "Verb concept" is already a kind of "concept" which is a kind of "meaning". Also, "verb concept" is not mutually exclusive with "concept". * Should "concept" share a generalization line with "classification" and "categorization"? "Concept" is certainly not mutually exclusive with those two. Corrected graphic sent earlier. I think the definition of "contextualization verb concept" should be given extensionally, as it is today. I think an extensional definition makes the relationship among this, "is-role-of verb concept" and "is-facet-of verb concept" clearer. I think we should do away with these wonky concepts/terms. What does it add? Who would use it? This was discussed in the meeting and the group preferred it this new way. It can be whichever way the group prefers. The first letter of the example for "is-property-of verb concept" should be capitalized. It is a phrase, not a complete sentence. It looks like we're not changing the definition of "partitive fact type" at all. At least, I can't spot the change. Did you meant to start the definition with "binary verb concept ..."? You're probably correct here. That change instruction can be deleted. (It reverted back to use 'fact type' as part of Donald's edict on synonym usage, thereby making it "no change.") I don't see any change to the General Concept for "situational role". Ditto. I see that you are consistently replacing Examples with Notes, but they sure look like Examples to me. Why do you want to mark them as Notes? That's where "classification verb concept" and "categorization verb concept" get so wonky. If you ignore the "or any verb concept that specializes it", the definition IS the (only) example. All you can do is give notes about how it would be used ... which are *not* really examples. It all gets impossible. I am pleading for simplification. Let's get rid of this junk. I am not "consistently replacing" things . these were ccases where tthe one SBVR verb concept (or a specialization of it) would be giving an example of itself. Since these are examples of the USAGE of these entries it was stated that these were more appropriately labeled as notes about it. E.g., we wouldn't give an example of "Switzerland" but might want to make a note about it. I think these are Examples. If it's that confusing, it couldn't be very good. For the record, nothing in this Issue is put forth as "my" personal idea or position . I am the scribe, captturing what the group is saying//agreeing on this Issue. I don't need to 'endorse' something to record it. - Keri Subject: Re: SBVR RTF issue 13716 - updated Resolution document X-KeepSent: 2FCB7094:F07A8E86-8525771B:0040B9F3; 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, 6 May 2010 10:33:53 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 05/06/2010 10:33:57 Keri, I think this is a great example, and I like the way you annotated it with the circled letters. I think we should add it to clause 11 as explanatory material because I agree with the basic idea of "Verb Concept Templating". However, I disagree with some of the details: In SBVR, all relationship instances are instances (actualities) of verb concepts. For example, "the concept 'operating country' specializes the concept 'country' " is an instance of the verb concept "concept1 specializes concept2". Just like "agent Joe operates agency 1" would be an instance of "agent operates agency". ("agent Joe" and "agency 1" should be double-underlined as instances, but my mail client doesn't do double-underlining.) SBVR does not distinguish "noun structuring" from other verb concepts. Of course there is a difference: the specializes relationship is defined by the SBVR metamodel and its roles are filled by domain vocabulary (model) concepts, while the operates relationship is defined in a domain vocabulary (model) and its roles are filled by instances. But SBVR doesn't formally make a distinction between metamodeling levels because business users don't make that distinction. Contrast this with UML, which formalizes metamodeling levels: M0 (instance), M1 (model), M2 (UML metamodel), M3 (MOF metametamodel). In UML, the inheritance or specializes relationship is formally a different kind of thing than an association relationship. If SBVR distinguished formally between noun structuring and verb concepts, then I would agree that "Elements of Structure" should be separate from "Verb Concept Templating". But SBVR does not make that distinction anywhere else, so why should we introduce it in clause 11? If we want to add it to SBVR, then we should start by making this distinction in clause 8. I think it is strange that the spec has lots of examples of instances of property-of (has) and partitive (includes) verb concepts but the verb concepts themselves are missing from clause 8. I believe they are fundamental to structuring a vocabulary and should be provided by SBVR in order to standardize how domain vocabularies model these concepts. I inserted additional comments below, like this. ------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com keri ---05/05/2010 05:05:17 PM---Mark, keri 05/05/2010 05:03 PM To Mark H Linehan/Watson/IBM@IBMUS, "Ronald G. Ross" , SBVR RTF cc Subject Re: SBVR RTF issue 13716 - updated Resolution document Mark, Your new concepts do not match what Ron is asking for to meet his needs. (Ron, Please jump in if I misrepresent your notions.) Let me illustrate, using this annotated fact model diagram from EU-Rent, as representative of what a business user might draw to represent one of his fact models: We could begin by explaining to the user that this diagram represents his vocabulary's nouns (noun concepts) using boxes, with the term inside. Then, the model diagram is "structured" by connecting the boxes with lines, for the verbish elements. These lines are of different kinds, as reflected by various graphical conventions. For example, the lines marked A, B, and C are all for fact types (verb concepts) that are in the user's vocabulary. Other lines (e.g, D, E, and F) represent facts (meta model facts). (a) The term "meta model" is not defined in SBVR so we should not use it in any explanation. (b) Lines D, E, and F are instances (actualities) of the specializes or corresponds to verb concepts. They are not "facts" in the sense of "propositions taken to be true". (c) If we had defined "concept1 has concept2" (is-property-of) and "concept1includes concept2" (partitive) verb concepts in clause 8, then B and C would be instances of those verb concepts and it would be easy to agree that B and C fit in "Elements of Structure". (d) The only difference between "Elements of Structure" and "Verb Concept Templating" is whether they are defined at the meta-model level with roles filled by model concepts, or they are defined at the model level, and their roles are filled by instances. Since SBVR avoids the idea of "modeling level" elsewhere, it would be inconsistent to introduce modeling levels as the key distinction between these two categorization schemes. We could get even more specific and distinguish the first three as different kinds (categories) of fact type (verb concept): A = associative fact type (associative verb concept) B = is-property-of fact type (is-property-of verb concept) C = partitive fact type (partitive verb concept) We can also distinguish the second three as different kinds . the lines annotated D, E, and F can be distinguisshed as three different kinds (categories) of fact: D = categorization fact (or, as Ron prefers for use with business users, categorization) E = classification fact (or, as Ron prefers for use with business users, classification) F = is-role-of fact I believe these are instances (actualities) of specialization, corresponds to, and ranges over -- not facts. Below is the Elements of Structure scheme, annotated for cross-reference to the model diagram. This Scheme provides the terminology that is needed to have this kind of conversation with the business user. My objection is to splitting these into two separate categorization schemes. I do not have a problem with the individual categories A through F. (But there should be a G for is-facet-of.) Keri On 5/4/10 7:06 AM, "Mark H Linehan" wrote: I accept Ed's argument that "classification" and "categorization" are objectifications rather than nominalizations. In clause 9.2.7, in the entry for 'objectification', there is an example of defining a term as an objectification: late return defined as actuality that a given rental is returned late. I think the definitions of "classification" and "categorization" would be clearer if they followed this pattern, rather than "fact that ...." And they would not introduce the connotation of "proposition taken as true". So we would have: categorization: actuality that a given general concept specializes a given general concept classification: actuality that a given individual concept specializes a given general concept For consistency, we should drop "categorization fact" and "classification fact". I still believe we should combine "Elements of Structure" and "Verb Concept Templating" by defining similar objectifications for the concepts currently proposed for "Verb Concept Templating": association: actuality that a given verb concept has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations property: actuality that a given association defines that each instance of a given concept has a particular quality or trait partition: actuality that a given binary verb concept defines that each instance of a given part is in the composition of a given whole contextualization: situation or view situation: actuality that a given verb concept defines [?situational?] roles that are understood or assessed with respect to a set of circumstances view: actuality that a given verb concept defines a mode or manner of of looking at or regarding a given concept (from Merriam-Webster Collegiate, 'view', 2a) Notes: * I put a couple of possible variations in "[? ... ?]" above * I propose "association" instead of "associative verb concept", "partition" instead of "partitive verb concept", "property" instead of "is-property-of verb concept", "situation" instead of "is-role-of verb concept", and "view" instead of "is-facet-of verb concept" The main advantage of this approach is that it considerably simplifies clause 11.1.5 by combining the two proposed categorization schemes. Another advantage is that it uses real English terms such as "association" instead of made up terms such as "associative verb concept". A third advantage is that these definition are easier to understand (at least to me), because they all use active rather than passive voice. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Ed Barkmeyer 05/03/2010 07:41 PM Please respond to edbark@nist.gov To keri cc SBVR RTF Subject Re: SBVR RTF issue 13716 - updated Resolution document A brief comment, of no particular value: Keri wrote: > On Elements of Structure vis--vis Verb Concept Templating. > The difference for these two schemes is not one of nominalization. The new concepts Ron has proposed are categories of 'fact' and they use nouns, as for any term. This may be more clear if you look at the synonyms, which present the longer (full) term: "classification fact" and "categorization fact". These are not nominalizations any more than "fact" is a nominalization. > Mark wrote: > >> (1) I think these definitions are using "fact of " as a round-about way of meaning "nominalization" because we are missing the "nominalization" concept in clauses 8 and 11. Keri is correct. The categorization facts are not "nominalizations" per se. Nominalization occurs when the verb acts on the proposition itself, e.g.," Keri thinks that categorization facts are facts". "That categorization facts are facts" is a nominalization. The fact type here is 'person thinks proposition'. "the fact of a bishop managing a diocese" and "the fact that a bishop manages a diocese" are just English language isms. "Each bishop manages a diocese" is the representation of the fact you mean. Now that fact is a proposition and it may become nominalized if you use it verbatim in a sentence that speaks of it as a proposition. On the other hand, the proposition can be "objectified" -- that is, used to refer to the corresponding actuality. The distinction between nominalization and objectification is exactly the same as that between designation and denotation. A factual statement "designates" a fact, and "denotes" the corresponding actuality. So if you are talking about the fact, it is a nominalization, and if you are talking about the actuality, it is an objectification. In English, we often say "the fact that X" for the latter case. What characterizes a bishop is actual management of a diocese -- the instance of the fact type -- not the proposition. I think Mark's point, however, is well-taken. A fact of itself is a true proposition, full stop. But every use of the expression of a fact in some fact type role will necessarily either nominalize it (refer to the proposition) or objectify it (refer to the actuality). And it is easy to determine which, because the fact type role is typed either 'actuality' (state of affairs) or 'proposition' (meaning). We introduce 'nonminalization' and 'objectification' in Clause 9, in order to assign a variable to the corresponding proposition or actuality when the logical formulation of the fact itself has free variables in it, that is, variables that are bound/quantified outside the nominalization or objectification. Example: Each person who has a vision impediment must have the fact that he requires corrective lenses indicated on his driver's license. "the fact that he requires corrective lenses" is a nominalization -- the fact is what must be indicated on the driver's license, not the actuality. But the "he" refers to the variable that ranges over "person who has a vision impediment" in the overall rule. For each person, the fact that that person requires corrective lenses is a different fact from the fact that any other person requires them. So we need to introduce a variable whose value is the appropriate fact in each case. This stuff is really confusing, but it is something that only SBVR can do. > "Categorization" is defined in Merriam-Webster online as "to put into a category", which uses an infinitive. Infinitives are noun phrases, i.e. nominalizations. Again, infinitives and gerunds are usually objectifications -- they refer to the actualities. Categorization is a noun phrase that refers to a collection of actualities of persons putting specific things in categories. > (2) Why not be consistent and do the same for "Verb Concept Templating"? For example, "association: fact that a fact type has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations" > Ah, well. Much of clause 11 mystifies me as well. -Ed pic59606.gif Subject: RE: SBVR RTF issue 13716 - updated Resolution document X-KeepSent: 0937B34E:7FE810BF-8525771B:0051A1A8; 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, 6 May 2010 11:00:44 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 05/06/2010 11:00:47 When you specify "concept1 specializes concept2" in an SBVR vocabulary (or do the equivalent with the General Concept label or using a Definition that starts with 'concept2 that ....') you are stating something about the structure of the vocabulary. The specialization exists in all possible worlds, like a Necessity rule. So a specialization among two concepts is not true or false, it just is. This is why I claim that specialization and classification are not propositions -- because they are not true or false but instead are part of the vocabulary structure. Whether a categorization is "correct or incorrect" is a matter of modeling choice or how close the vocabulary fits with reality as we perceive it. But within any particular vocabulary, a categorization cannot be "correct or incorrect". It just plain exists. Regarding "situation" -- I'm not sure this is the best label for this concept. I am searching for another one. -------------------------------- 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 ---05/04/2010 08:53:27 PM---Are categorizations and classifications actualities, or are they propositions? Don Baisley 05/04/2010 08:48 PM To "sbvr-rtf@omg.org" cc Subject RE: SBVR RTF issue 13716 - updated Resolution document Are categorizations and classifications actualities, or are they propositions? I tend to think of them as I think of generalizations, which can be true or false. It seems that categorizations and classifications can be correct or incorrect, that is, true or false. A categorization is not a matter of something actually being in a certain category. I tend to think of a categorization as a proposition, based on judgment, that something is in a certain category. So I would side with Ron and Keris definition. > situation: actuality that a given verb concept defines [?situational?] roles that > are understood or assessed with respect to a set of circumstances I dont understand Marks proposed objectifying definitions. I cannot imaging defining situation as he has it. Regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Tuesday, May 04, 2010 7:07 AM To: sbvr-rtf@omg.org Subject: Re: SBVR RTF issue 13716 - updated Resolution document I accept Ed's argument that "classification" and "categorization" are objectifications rather than nominalizations. In clause 9.2.7, in the entry for 'objectification', there is an example of defining a term as an objectification: late return defined as actuality that a given rental is returned late. I think the definitions of "classification" and "categorization" would be clearer if they followed this pattern, rather than "fact that ...." And they would not introduce the connotation of "proposition taken as true". So we would have: categorization: actuality that a given general concept specializes a given general concept classification: actuality that a given individual concept specializes a given general concept For consistency, we should drop "categorization fact" and "classification fact". I still believe we should combine "Elements of Structure" and "Verb Concept Templating" by defining similar objectifications for the concepts currently proposed for "Verb Concept Templating": association: actuality that a given verb concept has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations property: actuality that a given association defines that each instance of a given concept has a particular quality or trait partition: actuality that a given binary verb concept defines that each instance of a given part is in the composition of a given whole contextualization: situation or view situation: actuality that a given verb concept defines [?situational?] roles that are understood or assessed with respect to a set of circumstances view: actuality that a given verb concept defines a mode or manner of of looking at or regarding a given concept (from Merriam-Webster Collegiate, 'view', 2a) Notes: * I put a couple of possible variations in "[? ... ?]" above * I propose "association" instead of "associative verb concept", "partition" instead of "partitive verb concept", "property" instead of "is-property-of verb concept", "situation" instead of "is-role-of verb concept", and "view" instead of "is-facet-of verb concept" The main advantage of this approach is that it considerably simplifies clause 11.1.5 by combining the two proposed categorization schemes. Another advantage is that it uses real English terms such as "association" instead of made up terms such as "associative verb concept". A third advantage is that these definition are easier to understand (at least to me), because they all use active rather than passive voice. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Ed Barkmeyer 05/03/2010 07:41 PM Please respond to edbark@nist.gov To keri cc SBVR RTF Subject Re: SBVR RTF issue 13716 - updated Resolution document A brief comment, of no particular value: Keri wrote: > On Elements of Structure vis--vis Verb Concept Templating. > The difference for these two schemes is not one of nominalization. The new concepts Ron has proposed are categories of 'fact' and they use nouns, as for any term. This may be more clear if you look at the synonyms, which present the longer (full) term: "classification fact" and "categorization fact". These are not nominalizations any more than "fact" is a nominalization. > Mark wrote: > >> (1) I think these definitions are using "fact of " as a round-about way of meaning "nominalization" because we are missing the "nominalization" concept in clauses 8 and 11. Keri is correct. The categorization facts are not "nominalizations" per se. Nominalization occurs when the verb acts on the proposition itself, e.g.," Keri thinks that categorization facts are facts". "That categorization facts are facts" is a nominalization. The fact type here is 'person thinks proposition'. "the fact of a bishop managing a diocese" and "the fact that a bishop manages a diocese" are just English language isms. "Each bishop manages a diocese" is the representation of the fact you mean. Now that fact is a proposition and it may become nominalized if you use it verbatim in a sentence that speaks of it as a proposition. On the other hand, the proposition can be "objectified" -- that is, used to refer to the corresponding actuality. The distinction between nominalization and objectification is exactly the same as that between designation and denotation. A factual statement "designates" a fact, and "denotes" the corresponding actuality. So if you are talking about the fact, it is a nominalization, and if you are talking about the actuality, it is an objectification. In English, we often say "the fact that X" for the latter case. What characterizes a bishop is actual management of a diocese -- the instance of the fact type -- not the proposition. I think Mark's point, however, is well-taken. A fact of itself is a true proposition, full stop. But every use of the expression of a fact in some fact type role will necessarily either nominalize it (refer to the proposition) or objectify it (refer to the actuality). And it is easy to determine which, because the fact type role is typed either 'actuality' (state of affairs) or 'proposition' (meaning). We introduce 'nonminalization' and 'objectification' in Clause 9, in order to assign a variable to the corresponding proposition or actuality when the logical formulation of the fact itself has free variables in it, that is, variables that are bound/quantified outside the nominalization or objectification. Example: Each person who has a vision impediment must have the fact that he requires corrective lenses indicated on his driver's license. "the fact that he requires corrective lenses" is a nominalization -- the fact is what must be indicated on the driver's license, not the actuality. But the "he" refers to the variable that ranges over "person who has a vision impediment" in the overall rule. For each person, the fact that that person requires corrective lenses is a different fact from the fact that any other person requires them. So we need to introduce a variable whose value is the appropriate fact in each case. This stuff is really confusing, but it is something that only SBVR can do. > "Categorization" is defined in Merriam-Webster online as "to put into a category", which uses an infinitive. Infinitives are noun phrases, i.e. nominalizations. Again, infinitives and gerunds are usually objectifications -- they refer to the actualities. Categorization is a noun phrase that refers to a collection of actualities of persons putting specific things in categories. > (2) Why not be consistent and do the same for "Verb Concept Templating"? For example, "association: fact that a fact type has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations" > Ah, well. Much of clause 11 mystifies me as well. -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." pic12185.gif X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: 2GyRHz8VM1mzLZmAB6TBLkm9_BYDB8ZHJA3TBMxf8lBPfYim_aWS9ge5iAiXhLXJGSYAJEQ3ZzBLD_1RoeuBFh6uLogP4TRa1evRe1zWYKdHh8FYeQt8DzGkvHF6oH.J37LdwE.UBD9hwXj7ESktmxpWtBZcxBNT0sDGn79trdHTsydrdOWejvkAdWTO0Rruq8F0CK2CBTEmYYH1brDrzTHEX0zBxL9uCIeXCPDmR9p9gsGsQyxuPbL5O0RX5NTHFbQ- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 06 May 2010 13:50:45 -0500 To: Mark H Linehan , "sbvr-rtf@omg.org" From: "Ronald G. Ross" Subject: RE: SBVR RTF issue 13716 - updated Resolution document At 10:00 AM 5/6/2010, Mark H Linehan wrote: When you specify "concept1 specializes concept2" in an SBVR vocabulary (or do the equivalent with the General Concept label or using a Definition that starts with 'concept2 that ....') you are stating something about the structure of the vocabulary. The specialization exists in all possible worlds, like a Necessity rule. So a specialization among two concepts is not true or false, it just is. This is why I claim that specialization and classification are not propositions -- because they are not true or false but instead are part of the vocabulary structure. Whether a categorization is "correct or incorrect" is a matter of modeling choice or how close the vocabulary fits with reality as we perceive it. But within any particular vocabulary, a categorization cannot be "correct or incorrect". It just plain exists. In fact model terms, aren't *facts* what we 'say' "just plain exist"? What other way is there? True propositions - facts. I agree that categorizations and classifications are part of vocabulary structure -- indeed, "elements of structure". But *what* specifically?? They have to be *something*. What else could they be except facts? Ron Regarding "situation" -- I'm not sure this is the best label for this concept. I am searching for another one. -------------------------------- 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 ---05/04/2010 08:53:27 PM---Are categorizations and classifications actualities, or are they propositions? Don Baisley 05/04/2010 08:48 PM To "sbvr-rtf@omg.org" cc Subject RE: SBVR RTF issue 13716 - updated Resolution document Are categorizations and classifications actualities, or are they propositions? I tend to think of them as I think of generalizations, which can be true or false. It seems that categorizations and classifications can be correct or incorrect, that is, true or false. A categorization is not a matter of something actually being in a certain category. I tend to think of a categorization as a proposition, based on judgment, that something is in a certain category. So I would side with Ron and Keris definition. > situation: actuality that a given verb concept defines [?situational?] roles that > are understood or assessed with respect to a set of circumstances I dont understand Marks proposed objectifying definitions. I cannot imaging defining situation as he has it. Regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Tuesday, May 04, 2010 7:07 AM To: sbvr-rtf@omg.org Subject: Re: SBVR RTF issue 13716 - updated Resolution document I accept Ed's argument that "classification" and "categorization" are objectifications rather than nominalizations. In clause 9.2.7, in the entry for 'objectification', there is an example of defining a term as an objectification: late return defined as actuality that a given rental is returned late. I think the definitions of "classification" and "categorization" would be clearer if they followed this pattern, rather than "fact that ...." And they would not introduce the connotation of "proposition taken as true". So we would have: categorization: actuality that a given general concept specializes a given general concept classification: actuality that a given individual concept specializes a given general concept For consistency, we should drop "categorization fact" and "classification fact". I still believe we should combine "Elements of Structure" and "Verb Concept Templating" by defining similar objectifications for the concepts currently proposed for "Verb Concept Templating": association: actuality that a given verb concept has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations property: actuality that a given association defines that each instance of a given concept has a particular quality or trait partition: actuality that a given binary verb concept defines that each instance of a given part is in the composition of a given whole contextualization: situation or view situation: actuality that a given verb concept defines [?situational?] roles that are understood or assessed with respect to a set of circumstances view: actuality that a given verb concept defines a mode or manner of of looking at or regarding a given concept (from Merriam-Webster Collegiate, 'view', 2a) Notes: * I put a couple of possible variations in "[? ... ?]" above * I propose "association" instead of "associative verb concept", "partition" instead of "partitive verb concept", "property" instead of "is-property-of verb concept", "situation" instead of "is-role-of verb concept", and "view" instead of "is-facet-of verb concept" The main advantage of this approach is that it considerably simplifies clause 11.1.5 by combining the two proposed categorization schemes. Another advantage is that it uses real English terms such as "association" instead of made up terms such as "associative verb concept". A third advantage is that these definition are easier to understand (at least to me), because they all use active rather than passive voice. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Ed Barkmeyer 05/03/2010 07:41 PM Please respond to edbark@nist.gov To keri cc SBVR RTF Subject Re: SBVR RTF issue 13716 - updated Resolution document A brief comment, of no particular value: Keri wrote: > On Elements of Structure vis--vis Verb Concept Templating. > The difference for these two schemes is not one of nominalization. The new concepts Ron has proposed are categories of 'fact' and they use nouns, as for any term. This may be more clear if you look at the synonyms, which present the longer (full) term: "classification fact" and "categorization fact". These are not nominalizations any more than "fact" is a nominalization. > Mark wrote: > >> (1) I think these definitions are using "fact of " as a round-about way of meaning "nominalization" because we are missing the "nominalization" concept in clauses 8 and 11. Keri is correct. The categorization facts are not "nominalizations" per se. Nominalization occurs when the verb acts on the proposition itself, e.g.," Keri thinks that categorization facts are facts". "That categorization facts are facts" is a nominalization. The fact type here is 'person thinks proposition'. "the fact of a bishop managing a diocese" and "the fact that a bishop manages a diocese" are just English language isms. "Each bishop manages a diocese" is the representation of the fact you mean. Now that fact is a proposition and it may become nominalized if you use it verbatim in a sentence that speaks of it as a proposition. On the other hand, the proposition can be "objectified" -- that is, used to refer to the corresponding actuality. The distinction between nominalization and objectification is exactly the same as that between designation and denotation. A factual statement "designates" a fact, and "denotes" the corresponding actuality. So if you are talking about the fact, it is a nominalization, and if you are talking about the actuality, it is an objectification. In English, we often say "the fact that X" for the latter case. What characterizes a bishop is actual management of a diocese -- the instance of the fact type -- not the proposition. I think Mark's point, however, is well-taken. A fact of itself is a true proposition, full stop. But every use of the expression of a fact in some fact type role will necessarily either nominalize it (refer to the proposition) or objectify it (refer to the actuality). And it is easy to determine which, because the fact type role is typed either 'actuality' (state of affairs) or 'proposition' (meaning). We introduce 'nonminalization' and 'objectification' in Clause 9, in order to assign a variable to the corresponding proposition or actuality when the logical formulation of the fact itself has free variables in it, that is, variables that are bound/quantified outside the nominalization or objectification. Example: Each person who has a vision impediment must have the fact that he requires corrective lenses indicated on his driver's license. "the fact that he requires corrective lenses" is a nominalization -- the fact is what must be indicated on the driver's license, not the actuality. But the "he" refers to the variable that ranges over "person who has a vision impediment" in the overall rule. For each person, the fact that that person requires corrective lenses is a different fact from the fact that any other person requires them. So we need to introduce a variable whose value is the appropriate fact in each case. This stuff is really confusing, but it is something that only SBVR can do. > "Categorization" is defined in Merriam-Webster online as "to put into a category", which uses an infinitive. Infinitives are noun phrases, i.e. nominalizations. Again, infinitives and gerunds are usually objectifications -- they refer to the actualities. Categorization is a noun phrase that refers to a collection of actualities of persons putting specific things in categories. > (2) Why not be consistent and do the same for "Verb Concept Templating"? For example, "association: fact that a fact type has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations" > Ah, well. Much of clause 11 mystifies me as well. -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." X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=5.0.0-0908210000 definitions=main-1005070097 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 07 May 2010 09:48:24 -0700 Subject: Re: SBVR RTF issue 13716 - updated Resolution document From: keri To: Mark H Linehan , "Donald R. Chapin" , SBVR RTF Thread-topic: SBVR RTF issue 13716 - updated Resolution document Thread-index: AcruBRusWiAYsln4Ed+J9QARJM+Cgg== Mark, I'm fine with adding my annotated example (though I believe it should appear in one of the Annex sections, since it is not normative). When I group decides I will make any additions requested. We (of the business-facing perspective) have been told that this interpretation (of fact types and facts) is the proper SBVR interpretation. If that is not the case, it needs to be agreed by the team. I am not the one to field your questions so I defer to others on the team who can make this call. A couple of other points to your points. When I used "meta model" it was said parenthetically . i.e., informally. In both of the examples there is a 4th element that was not reflected in the annotations (characteristic for the verb concepts; is-facet-of for the facts). I was only showing representative examples, from the EU-Rent model diagram that had the widest range of constructs. Donald, Please hand this Issue to another 'minder' since I'm going offline starting tomorrow. I'll catch what I can when I can grab a signal, but I won't be able to guide this Issue with consistent, timely attention. (Fingers crossed for NO ASH from the pesky volcano!!) Thanks. Keri On 5/6/10 7:33 AM, "Mark H Linehan" wrote: Keri, I think this is a great example, and I like the way you annotated it with the circled letters. I think we should add it to clause 11 as explanatory material because I agree with the basic idea of "Verb Concept Templating". However, I disagree with some of the details: In SBVR, all relationship instances are instances (actualities) of verb concepts. For example, "the concept 'operating country' specializes the concept 'country' " is an instance of the verb concept "concept1 specializes concept2". Just like "agent Joe operates agency 1" would be an instance of "agent operates agency". ("agent Joe" and "agency 1" should be double-underlined as instances, but my mail client doesn't do double-underlining.) SBVR does not distinguish "noun structuring" from other verb concepts. Of course there is a difference: the specializes relationship is defined by the SBVR metamodel and its roles are filled by domain vocabulary (model) concepts, while the operates relationship is defined in a domain vocabulary (model) and its roles are filled by instances. But SBVR doesn't formally make a distinction between metamodeling levels because business users don't make that distinction. Contrast this with UML, which formalizes metamodeling levels: M0 (instance), M1 (model), M2 (UML metamodel), M3 (MOF metametamodel). In UML, the inheritance or specializes relationship is formally a different kind of thing than an association relationship. If SBVR distinguished formally between noun structuring and verb concepts, then I would agree that "Elements of Structure" should be separate from "Verb Concept Templating". But SBVR does not make that distinction anywhere else, so why should we introduce it in clause 11? If we want to add it to SBVR, then we should start by making this distinction in clause 8. I think it is strange that the spec has lots of examples of instances of property-of (has) and partitive (includes) verb concepts but the verb concepts themselves are missing from clause 8. I believe they are fundamental to structuring a vocabulary and should be provided by SBVR in order to standardize how domain vocabularies model these concepts. I inserted additional comments below, like this. ------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com keri ---05/05/2010 05:05:17 PM---Mark, keri 05/05/2010 05:03 PM To Mark H Linehan/Watson/IBM@IBMUS, "Ronald G. Ross" , SBVR RTF cc Subject Re: SBVR RTF issue 13716 - updated Resolution document Mark, Your new concepts do not match what Ron is asking for to meet his needs. (Ron, Please jump in if I misrepresent your notions.) Let me illustrate, using this annotated fact model diagram from EU-Rent, as representative of what a business user might draw to represent one of his fact models: We could begin by explaining to the user that this diagram represents his vocabulary's nouns (noun concepts) using boxes, with the term inside. Then, the model diagram is "structured" by connecting the boxes with lines, for the verbish elements. These lines are of different kinds, as reflected by various graphical conventions. For example, the lines marked A, B, and C are all for fact types (verb concepts) that are in the user's vocabulary. Other lines (e.g, D, E, and F) represent facts (meta model facts). (a) The term "meta model" is not defined in SBVR so we should not use it in any explanation. (b) Lines D, E, and F are instances (actualities) of the specializes or corresponds to verb concepts. They are not "facts" in the sense of "propositions taken to be true". (c) If we had defined "concept1 has concept2" (is-property-of) and "concept1includes concept2" (partitive) verb concepts in clause 8, then B and C would be instances of those verb concepts and it would be easy to agree that B and C fit in "Elements of Structure". (d) The only difference between "Elements of Structure" and "Verb Concept Templating" is whether they are defined at the meta-model level with roles filled by model concepts, or they are defined at the model level, and their roles are filled by instances. Since SBVR avoids the idea of "modeling level" elsewhere, it would be inconsistent to introduce modeling levels as the key distinction between these two categorization schemes. We could get even more specific and distinguish the first three as different kinds (categories) of fact type (verb concept): A = associative fact type (associative verb concept) B = is-property-of fact type (is-property-of verb concept) C = partitive fact type (partitive verb concept) We can also distinguish the second three as different kinds . the lines annotated D, E, and F can be distinguished as three different kinds (categories) of fact: D = categorization fact (or, as Ron prefers for use with business users, categorization) E = classification fact (or, as Ron prefers for use with business users, classification) F = is-role-of fact I believe these are instances (actualities) of specialization, corresponds to, and ranges over -- not facts. Below is the Elements of Structure scheme, annotated for cross-reference to the model diagram. This Scheme provides the terminology that is needed to have this kind of conversation with the business user. My objection is to splitting these into two separate categorization schemes. I do not have a problem with the individual categories A through F. (But there should be a G for is-facet-of.) Keri On 5/4/10 7:06 AM, "Mark H Linehan" wrote: I accept Ed's argument that "classification" and "categorization" are objectifications rather than nominalizations. In clause 9.2.7, in the entry for 'objectification', there is an example of defining a term as an objectification: .late return. defined as .actuality that a given rental is returned late.. I think the definitions of "classification" and "categorization" would be clearer if they followed this pattern, rather than "fact that ...." And they would not introduce the connotation of "proposition taken as true". So we would have: categorization: actuality that a given general concept specializes a given general concept classification: actuality that a given individual concept specializes a given general concept For consistency, we should drop "categorization fact" and "classification fact". I still believe we should combine "Elements of Structure" and "Verb Concept Templating" by defining similar objectifications for the concepts currently proposed for "Verb Concept Templating": association: actuality that a given verb concept has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations property: actuality that a given association defines that each instance of a given concept has a particular quality or trait partition: actuality that a given binary verb concept defines that each instance of a given part is in the composition of a given whole contextualization: situation or view situation: actuality that a given verb concept defines [?situational?] roles that are understood or assessed with respect to a set of circumstances view: actuality that a given verb concept defines a mode or manner of of looking at or regarding a given concept (from Merriam-Webster Collegiate, 'view', 2a) Notes: * I put a couple of possible variations in "[? ... ?]" above * I propose "association" instead of "associative verb concept", "partition" instead of "partitive verb concept", "property" instead of "is-property-of verb concept", "situation" instead of "is-role-of verb concept", and "view" instead of "is-facet-of verb concept" The main advantage of this approach is that it considerably simplifies clause 11.1.5 by combining the two proposed categorization schemes. Another advantage is that it uses real English terms such as "association" instead of made up terms such as "associative verb concept". A third advantage is that these definition are easier to understand (at least to me), because they all use active rather than passive voice. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Ed Barkmeyer 05/03/2010 07:41 PM Please respond to edbark@nist.gov To keri cc SBVR RTF Subject Re: SBVR RTF issue 13716 - updated Resolution document A brief comment, of no particular value: Keri wrote: > On Elements of Structure vis-is Verb Concept Templating. > The difference for these two schemes is not one of nominalization. The new concepts Ron has proposed are categories of 'fact' and they use nouns, as for any term. This may be more clear if you look at the synonyms, which present the longer (full) term: "classification fact" and "categorization fact". These are not nominalizations any more than "fact" is a nominalization. > Mark wrote: > >> (1) I think these definitions are using "fact of " as a round-about way of meaning "nominalization" because we are missing the "nominalization" concept in clauses 8 and 11. Keri is correct. The categorization facts are not "nominalizations" per se. Nominalization occurs when the verb acts on the proposition itself, e.g.," Keri thinks that categorization facts are facts". "That categorization facts are facts" is a nominalization. The fact type here is 'person thinks proposition'. "the fact of a bishop managing a diocese" and "the fact that a bishop manages a diocese" are just English language isms. "Each bishop manages a diocese" is the representation of the fact you mean. Now that fact is a proposition and it may become nominalized if you use it verbatim in a sentence that speaks of it as a proposition. On the other hand, the proposition can be "objectified" -- that is, used to refer to the corresponding actuality. The distinction between nominalization and objectification is exactly the same as that between designation and denotation. A factual statement "designates" a fact, and "denotes" the corresponding actuality. So if you are talking about the fact, it is a nominalization, and if you are talking about the actuality, it is an objectification. In English, we often say "the fact that X" for the latter case. What characterizes a bishop is actual management of a diocese -- the instance of the fact type -- not the proposition. I think Mark's point, however, is well-taken. A fact of itself is a true proposition, full stop. But every use of the expression of a fact in some fact type role will necessarily either nominalize it (refer to the proposition) or objectify it (refer to the actuality). And it is easy to determine which, because the fact type role is typed either 'actuality' (state of affairs) or 'proposition' (meaning). We introduce 'nonminalization' and 'objectification' in Clause 9, in order to assign a variable to the corresponding proposition or actuality when the logical formulation of the fact itself has free variables in it, that is, variables that are bound/quantified outside the nominalization or objectification. Example: Each person who has a vision impediment must have the fact that he requires corrective lenses indicated on his driver's license. "the fact that he requires corrective lenses" is a nominalization -- the fact is what must be indicated on the driver's license, not the actuality. But the "he" refers to the variable that ranges over "person who has a vision impediment" in the overall rule. For each person, the fact that that person requires corrective lenses is a different fact from the fact that any other person requires them. So we need to introduce a variable whose value is the appropriate fact in each case. This stuff is really confusing, but it is something that only SBVR can do. > "Categorization" is defined in Merriam-Webster online as "to put into a category", which uses an infinitive. Infinitives are noun phrases, i.e. nominalizations. Again, infinitives and gerunds are usually objectifications -- they refer to the actualities. Categorization is a noun phrase that refers to a collection of actualities of persons putting specific things in categories. > (2) Why not be consistent and do the same for "Verb Concept Templating"? For example, "association: fact that a fact type has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations" > Ah, well. Much of clause 11 mystifies me as well. -Ed X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: Xuyf2AQVM1nNmqLAzYRJGXMAIhXTRVykwUSOboe7muBzGd4f.roAT629B7JUbSf7KYG1lLukXjtOFKgTTSttdi8hGJLnxDLALOC05KLdjRpe0TuIqAHl7pOf1yHl.lUgSWye.EH1mnxrDnXzT5jv8QPRgHySOTCQ0v7DSZ5KYT55lGGubCxpgcDwLFTgLpYV_QbJRtZAvJxNyIzkYoJBv0ETqFlkocaBb5dkN7Ij6KumQlwTSW85YlfBcpfvUQncgLpyfjwM0RNJ1E0FZMZfirGaH5TiwCqisiFb.sQcG.rzNAlGK2S27cUOe.C941iGMsPDYF8XKeLaSTdW6yrqRPzhKqBN9Nl2G1PzWr8MdlDo7j.TARbfZ6hWL6ONwySuPByPR.2Lz7L6H8qUky9vBi4- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 07 May 2010 12:14:23 -0500 To: Mark H Linehan , "sbvr-rtf@omg.org" From: "Ronald G. Ross" Subject: RE: SBVR RTF issue 13716 - updated Resolution document All, I am resending this reply because Mark seems not to have received it. Mark, Please confirm you get this. (Thanks.) Ron At 10:00 AM 5/6/2010, Mark H Linehan wrote: When you specify "concept1 specializes concept2" in an SBVR vocabulary (or do the equivalent with the General Concept label or using a Definition that starts with 'concept2 that ....') you are stating something about the structure of the vocabulary. The specialization exists in all possible worlds, like a Necessity rule. So a specialization among two concepts is not true or false, it just is. This is why I claim that specialization and classification are not propositions -- because they are not true or false but instead are part of the vocabulary structure. Whether a categorization is "correct or incorrect" is a matter of modeling choice or how close the vocabulary fits with reality as we perceive it. But within any particular vocabulary, a categorization cannot be "correct or incorrect". It just plain exists. In fact model terms, aren't *facts* what we 'say' "just plain exist"? What other way is there? True propositions - facts. I agree that categorizations and classifications are part of vocabulary structure -- indeed, "elements of structure". But *what* specifically?? They have to be *something*. What else could they be except facts? Ron Regarding "situation" -- I'm not sure this is the best label for this concept. I am searching for another one. -------------------------------- 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 ---05/04/2010 08:53:27 PM---Are categorizations and classifications actualities, or are they propositions? Don Baisley 05/04/2010 08:48 PM To "sbvr-rtf@omg.org" cc Subject RE: SBVR RTF issue 13716 - updated Resolution document Are categorizations and classifications actualities, or are they propositions? I tend to think of them as I think of generalizations, which can be true or false. It seems that categorizations and classifications can be correct or incorrect, that is, true or false. A categorization is not a matter of something actually being in a certain category. I tend to think of a categorization as a proposition, based on judgment, that something is in a certain category. So I would side with Ron and Keris definition. > situation: actuality that a given verb concept defines [?situational?] roles that > are understood or assessed with respect to a set of circumstances I dont understand Marks proposed objectifying definitions. I cannot imaging defining situation as he has it. Regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Tuesday, May 04, 2010 7:07 AM To: sbvr-rtf@omg.org Subject: Re: SBVR RTF issue 13716 - updated Resolution document I accept Ed's argument that "classification" and "categorization" are objectifications rather than nominalizations. In clause 9.2.7, in the entry for 'objectification', there is an example of defining a term as an objectification: late return defined as actuality that a given rental is returned late. I think the definitions of "classification" and "categorization" would be clearer if they followed this pattern, rather than "fact that ...." And they would not introduce the connotation of "proposition taken as true". So we would have: categorization: actuality that a given general concept specializes a given general concept classification: actuality that a given individual concept specializes a given general concept For consistency, we should drop "categorization fact" and "classification fact". I still believe we should combine "Elements of Structure" and "Verb Concept Templating" by defining similar objectifications for the concepts currently proposed for "Verb Concept Templating": association: actuality that a given verb concept has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations property: actuality that a given association defines that each instance of a given concept has a particular quality or trait partition: actuality that a given binary verb concept defines that each instance of a given part is in the composition of a given whole contextualization: situation or view situation: actuality that a given verb concept defines [?situational?] roles that are understood or assessed with respect to a set of circumstances view: actuality that a given verb concept defines a mode or manner of of looking at or regarding a given concept (from Merriam-Webster Collegiate, 'view', 2a) Notes: * I put a couple of possible variations in "[? ... ?]" above * I propose "association" instead of "associative verb concept", "partition" instead of "partitive verb concept", "property" instead of "is-property-of verb concept", "situation" instead of "is-role-of verb concept", and "view" instead of "is-facet-of verb concept" The main advantage of this approach is that it considerably simplifies clause 11.1.5 by combining the two proposed categorization schemes. Another advantage is that it uses real English terms such as "association" instead of made up terms such as "associative verb concept". A third advantage is that these definition are easier to understand (at least to me), because they all use active rather than passive voice. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Ed Barkmeyer 05/03/2010 07:41 PM Please respond to edbark@nist.gov To keri cc SBVR RTF Subject Re: SBVR RTF issue 13716 - updated Resolution document A brief comment, of no particular value: Keri wrote: > On Elements of Structure vis--vis Verb Concept Templating. > The difference for these two schemes is not one of nominalization. The new concepts Ron has proposed are categories of 'fact' and they use nouns, as for any term. This may be more clear if you look at the synonyms, which present the longer (full) term: "classification fact" and "categorization fact". These are not nominalizations any more than "fact" is a nominalization. > Mark wrote: > >> (1) I think these definitions are using "fact of " as a round-about way of meaning "nominalization" because we are missing the "nominalization" concept in clauses 8 and 11. Keri is correct. The categorization facts are not "nominalizations" per se. Nominalization occurs when the verb acts on the proposition itself, e.g.," Keri thinks that categorization facts are facts". "That categorization facts are facts" is a nominalization. The fact type here is 'person thinks proposition'. "the fact of a bishop managing a diocese" and "the fact that a bishop manages a diocese" are just English language isms. "Each bishop manages a diocese" is the representation of the fact you mean. Now that fact is a proposition and it may become nominalized if you use it verbatim in a sentence that speaks of it as a proposition. On the other hand, the proposition can be "objectified" -- that is, used to refer to the corresponding actuality. The distinction between nominalization and objectification is exactly the same as that between designation and denotation. A factual statement "designates" a fact, and "denotes" the corresponding actuality. So if you are talking about the fact, it is a nominalization, and if you are talking about the actuality, it is an objectification. In English, we often say "the fact that X" for the latter case. What characterizes a bishop is actual management of a diocese -- the instance of the fact type -- not the proposition. I think Mark's point, however, is well-taken. A fact of itself is a true proposition, full stop. But every use of the expression of a fact in some fact type role will necessarily either nominalize it (refer to the proposition) or objectify it (refer to the actuality). And it is easy to determine which, because the fact type role is typed either 'actuality' (state of affairs) or 'proposition' (meaning). We introduce 'nonminalization' and 'objectification' in Clause 9, in order to assign a variable to the corresponding proposition or actuality when the logical formulation of the fact itself has free variables in it, that is, variables that are bound/quantified outside the nominalization or objectification. Example: Each person who has a vision impediment must have the fact that he requires corrective lenses indicated on his driver's license. "the fact that he requires corrective lenses" is a nominalization -- the fact is what must be indicated on the driver's license, not the actuality. But the "he" refers to the variable that ranges over "person who has a vision impediment" in the overall rule. For each person, the fact that that person requires corrective lenses is a different fact from the fact that any other person requires them. So we need to introduce a variable whose value is the appropriate fact in each case. This stuff is really confusing, but it is something that only SBVR can do. > "Categorization" is defined in Merriam-Webster online as "to put into a category", which uses an infinitive. Infinitives are noun phrases, i.e. nominalizations. Again, infinitives and gerunds are usually objectifications -- they refer to the actualities. Categorization is a noun phrase that refers to a collection of actualities of persons putting specific things in categories. > (2) Why not be consistent and do the same for "Verb Concept Templating"? For example, "association: fact that a fact type has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations" > Ah, well. Much of clause 11 mystifies me as well. -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." From: Don Baisley To: "sbvr-rtf@omg.org" Subject: RE: SBVR RTF issue 13716 - updated Resolution document Thread-Topic: SBVR RTF issue 13716 - updated Resolution document Thread-Index: AQHK6xolOvbmrrT29kCjxeF8twHXiZJBxUAAgAA5GOCAAvqaAIABm+Wg Date: Fri, 7 May 2010 23:06:27 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Mark wrote: > When you specify "concept1 specializes concept2" in an SBVR vocabulary > (or do the equivalent with the General Concept label or using a Definition > that starts with 'concept2 that ....') you are stating something about the > structure of the vocabulary. The meaning of what is being stated is a fact . a proposition taken as true about concepts representted in a vocabulary. E.g., the fact that the concept .checking account. specializes the concept .account.. That fact would be part of a fact model about those concepts. That fact would be part of the body of shared meanings of the community that owns the vocabulary. The fact corresponds to an actuality, but the actuality is not what is in the body of shared meanings. That fact is the meaning of a statement the community asserts about its concepts. That fact, not the actuality, is what.s in the body of shared meanings. That.s why Ron and Keri are talking about facts, not actualities, when referring to categorizations and classifications. There is a saying, .All generalizations are false, even this one.. Ron and Keri very reasonably use the terms .categorization. and .classification., like people often use the term .generalization., to refer to the meanings of certain kinds of statements. These meanings are important parts of a community.s body of shared meanings. SBVR is about meanings. In this case, the meanings are facts the community asserts about its concepts. Best regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Thursday, May 06, 2010 8:01 AM To: sbvr-rtf@omg.org Subject: RE: SBVR RTF issue 13716 - updated Resolution document When you specify "concept1 specializes concept2" in an SBVR vocabulary (or do the equivalent with the General Concept label or using a Definition that starts with 'concept2 that ....') you are stating something about the structure of the vocabulary. The specialization exists in all possible worlds, like a Necessity rule. So a specialization among two concepts is not true or false, it just is. This is why I claim that specialization and classification are not propositions -- because they are not true or false but instead are part of the vocabulary structure. Whether a categorization is "correct or incorrect" is a matter of modeling choice or how close the vocabulary fits with reality as we perceive it. But within any particular vocabulary, a categorization cannot be "correct or incorrect". It just plain exists. Regarding "situation" -- I'm not sure this is the best label for this concept. I am searching for another one. -------------------------------- 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 ---05/04/2010 08:53:27 PM---Are categorizations and classifications actualities, or are they propositions? Don Baisley 05/04/2010 08:48 PM To "sbvr-rtf@omg.org" cc Subject RE: SBVR RTF issue 13716 - updated Resolution document Are categorizations and classifications actualities, or are they propositions? I tend to think of them as I think of generalizations, which can be true or false. It seems that categorizations and classifications can be correct or incorrect, that is, true or false. A categorization is not a matter of something actually being in a certain category. I tend to think of a categorization as a proposition, based on judgment, that something is in a certain category. So I would side with Ron and Keri.s definition. > situation: actuality that a given verb concept defines [?situational?] roles that > are understood or assessed with respect to a set of circumstances I don.t understand Mark.s proposed objectifying definitions. I cannot imaging defining .situation. as he has it. Regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Tuesday, May 04, 2010 7:07 AM To: sbvr-rtf@omg.org Subject: Re: SBVR RTF issue 13716 - updated Resolution document I accept Ed's argument that "classification" and "categorization" are objectifications rather than nominalizations. In clause 9.2.7, in the entry for 'objectification', there is an example of defining a term as an objectification: .late return. defined as .actuality that a given rental is returned late.. I think the definitions of "classification" and "categorization" would be clearer if they followed this pattern, rather than "fact that ...." And they would not introduce the connotation of "proposition taken as true". So we would have: categorization: actuality that a given general concept specializes a given general concept classification: actuality that a given individual concept specializes a given general concept For consistency, we should drop "categorization fact" and "classification fact". I still believe we should combine "Elements of Structure" and "Verb Concept Templating" by defining similar objectifications for the concepts currently proposed for "Verb Concept Templating": association: actuality that a given verb concept has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations property: actuality that a given association defines that each instance of a given concept has a particular quality or trait partition: actuality that a given binary verb concept defines that each instance of a given part is in the composition of a given whole contextualization: situation or view situation: actuality that a given verb concept defines [?situational?] roles that are understood or assessed with respect to a set of circumstances view: actuality that a given verb concept defines a mode or manner of of looking at or regarding a given concept (from Merriam-Webster Collegiate, 'view', 2a) Notes: * I put a couple of possible variations in "[? ... ?]" above * I propose "association" instead of "associative verb concept", "partition" instead of "partitive verb concept", "property" instead of "is-property-of verb concept", "situation" instead of "is-role-of verb concept", and "view" instead of "is-facet-of verb concept" The main advantage of this approach is that it considerably simplifies clause 11.1.5 by combining the two proposed categorization schemes. Another advantage is that it uses real English terms such as "association" instead of made up terms such as "associative verb concept". A third advantage is that these definition are easier to understand (at least to me), because they all use active rather than passive voice. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Ed Barkmeyer 05/03/2010 07:41 PM Please respond to edbark@nist.gov To keri cc SBVR RTF Subject Re: SBVR RTF issue 13716 - updated Resolution document A brief comment, of no particular value: Keri wrote: > On Elements of Structure vis-is Verb Concept Templating. > The difference for these two schemes is not one of nominalization. The new concepts Ron has proposed are categories of 'fact' and they use nouns, as for any term. This may be more clear if you look at the synonyms, which present the longer (full) term: "classification fact" and "categorization fact". These are not nominalizations any more than "fact" is a nominalization. > Mark wrote: > >> (1) I think these definitions are using "fact of " as a round-about way of meaning "nominalization" because we are missing the "nominalization" concept in clauses 8 and 11. Keri is correct. The categorization facts are not "nominalizations" per se. Nominalization occurs when the verb acts on the proposition itself, e.g.," Keri thinks that categorization facts are facts". "That categorization facts are facts" is a nominalization. The fact type here is 'person thinks proposition'. "the fact of a bishop managing a diocese" and "the fact that a bishop manages a diocese" are just English language isms. "Each bishop manages a diocese" is the representation of the fact you mean. Now that fact is a proposition and it may become nominalized if you use it verbatim in a sentence that speaks of it as a proposition. On the other hand, the proposition can be "objectified" -- that is, used to refer to the corresponding actuality. The distinction between nominalization and objectification is exactly the same as that between designation and denotation. A factual statement "designates" a fact, and "denotes" the corresponding actuality. So if you are talking about the fact, it is a nominalization, and if you are talking about the actuality, it is an objectification. In English, we often say "the fact that X" for the latter case. What characterizes a bishop is actual management of a diocese -- the instance of the fact type -- not the proposition. I think Mark's point, however, is well-taken. A fact of itself is a true proposition, full stop. But every use of the expression of a fact in some fact type role will necessarily either nominalize it (refer to the proposition) or objectify it (refer to the actuality). And it is easy to determine which, because the fact type role is typed either 'actuality' (state of affairs) or 'proposition' (meaning). We introduce 'nonminalization' and 'objectification' in Clause 9, in order to assign a variable to the corresponding proposition or actuality when the logical formulation of the fact itself has free variables in it, that is, variables that are bound/quantified outside the nominalization or objectification. Example: Each person who has a vision impediment must have the fact that he requires corrective lenses indicated on his driver's license. "the fact that he requires corrective lenses" is a nominalization -- the fact is what must be indicated on the driver's license, not the actuality. But the "he" refers to the variable that ranges over "person who has a vision impediment" in the overall rule. For each person, the fact that that person requires corrective lenses is a different fact from the fact that any other person requires them. So we need to introduce a variable whose value is the appropriate fact in each case. This stuff is really confusing, but it is something that only SBVR can do. > "Categorization" is defined in Merriam-Webster online as "to put into a category", which uses an infinitive. Infinitives are noun phrases, i.e. nominalizations. Again, infinitives and gerunds are usually objectifications -- they refer to the actualities. Categorization is a noun phrase that refers to a collection of actualities of persons putting specific things in categories. > (2) Why not be consistent and do the same for "Verb Concept Templating"? For example, "association: fact that a fact type has more than one role and has a nonhierarchical subject-oriented connection drawn from experience, based on practical rather than theoretical considerations" > Ah, well. Much of clause 11 mystifies me as well. -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." X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: dNjCu.cVM1nYUNUa1lWiBObuL.vlZSEmVIpW00U.LTqHHVhILVa7yzTGqPm5j34OvhgArds7G.G_vLNwsGPfxENoLuNj6U0rMC4z5aaMpJuCf8mlEpo3dlxyWR268otPEdlHxL97xTdZJyMb77OF1c7fY320Pm5USE3P3cC1HSNcCzEjQvE1PtB8fvz4F__ZbVSR.UKDuREag_bZWmdu91jwJcysXcuGqXs_aujnO4Pg3TP74bnn48eFd9mkxuqjXazfZnUH7Ogf6xvwiaQ7w.WO93Jb.3yg X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 25 Jun 2010 23:55:09 -0500 To: SBVR RTF From: "Ronald G. Ross" Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 All, At Thursday's face-to-face meeting in Minneapolis, I believe the consensus of the group was that we need to take a step back from the resolution produced from the last meeting (see critique below, in original e-mail), and re-gear for this issue. I came away with the following points of understanding/instructions/guidelines, as I believe Donald recorded in the meeting notes. Feedback welcome. 1. We should avoid the term "fact" in definitions for entries in this section (e.g., for categorization, classification, etc.). Instead, the word "connection" should be used. The point as I understood it is not necessarily that usage of "fact" is wrong, but rather that it conflates meta-levels, and could easily be misunderstood in the fact modeling community (e.g., ORM) in the context of Clause 11. If correct, in my mind this device simply displaces the problem, does not solve it (because "connection" still must be grounded in SBVR). However, I am willing to see what develops on that score. "Connection" is not a bad signifier if it can be properly grounded. 2. It would be useful to include "characterization" among the entries. 3. It is desirable to have both SBVR and natural-language dictionary definitions for each entry. 4. Exposition of the rational for changes in the existing document is necessary for justification purposes. Specifically, what's broken/wrong in the existing specification must be identified. See attached. 5. Each entry should be nominalized (e.g., "association" instead of "associative fact type"). If it can't be nominalized using a term *business people* might naturally use, there is no justification for including the entry in Clause 11. In addition, I believe Mark wanted to see all the entries as categorizing 'meaning'. I have attached a new sketch for a resolution as well as draft SBVR entries, with comments. (As always, sorry about the lack of SBVR-SE.) Generally, I believe this direction represents good progress ... and possibly a huge simplification of the whole subsection. Ron At 03:40 PM 4/19/2010, Ronald G. Ross wrote: All, This draft resolution arose from discussion at the last SBVR meeting. I believe the idea was to give members time to study the proposed resolution and respond as appropriate. After consideration, I find that the draft resolution does not resolve the issue as posed. It also fails to clarify important terms, especially .categorization. and .classification. (formerly .assortment.). I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution fails to support these goals in important ways. What would a business person mean if they used the words .categorization. and .classification.? What example(s) would they give if you asked for some? I.m quite confident they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb concept 'general concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb concept 'individual concept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines .categorization verb concept. and .classification verb concept., not simply .categorization. and .classification., respectively. What are these former concepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: .A number of the definitions in subsection 11.1.5 are incomprehensible ... Unfortunately, these replacements are not terribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. Even the original issue 13716 write-up said as much: . . these concepts are defined as kinds of .fact types., but should actually be defined as kinds of *facts*.. The draft resolution does not fix that core problem; it just makes things even more complicated (no mean feat). With respect to the concepts .categorization. and .classification., I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use .categorization. and .classification. as standard SBVR terms so when people say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say .That represents or creates a categorization (or a classification).. 3. To be able to ask business people for real-life examples from their business . and have definitions to fall back on if they give something inappropriate. The parts of the draft resolution that address .true. verb concepts (fact types) are acceptable, even notable improvements. Below is what I propose as a resolution to Issue 13716. The definitions I propose are these (sorry, I don.t do SBVR-SE): * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find .is-role-of fact [type]. and .is-facet-of fact [type]. in the above scheme because there are no natural business terms (in English at least) for those concepts. (.Rollification. and .facetification. have been facetiously proposed, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., .categorization. and .classification.). The term .element of structure. is used prominently in my book, Business Rule Concepts 3rd ed. Surely, no one can doubt that: * The three categories above are key meanings in *structuring* a business concept system. * A concept system indeed has structure that needs to be designed (or adopted) by the business to operate. Here is a proposed definition for .element of structure. (again, sorry for the lack of SBVR-SE): the categorization scheme of the concept .meaning. that classifies a meaning based on its part in organizing a community.s concept system Finally, I recommend that the strange concepts .categorization verb concept. and .classification verb concept. be eliminated from the proposed resolution and from SBVR completely. Again, simpler is better. Ron At 09:29 PM 4/10/2010, keri wrote: All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept .individual concept specializes concept. or any verb concept that specializes it categorization verb concept Definition: the verb concept .general concept specializes concept. or any verb concept that specializes it contextualization verb concept Definition: the verb concept .role ranges over general concept. or the verb concept .concept has facet. or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept .role ranges over general concept. or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept .concept has facet. or any verb concept that specializes it Option: in the definitions above, we can change each case of .verb concept that specializes. to .binary fact type that specializes. if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using .formulated. in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don 08-01-02 - problem exposition for issue 13716.pdf Issue 13716-SBVR 1.0 ch11.1.5 - version 7.doc Issue 13716 - diagram sketch for version 7.zip X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: 4oyM7R0VM1m2cBAFo1iRsp8rX2vP4godXbfGH857d7ZZY6udlXcLvTstbeRfVgYA791TaLIMovGlVqHmTzaLGX.v769alrzF5jzxoKL4E_TJWEzsFfc2K2VgAQmoQ8kuMXWb7mC988B37qVBIw4bSOwEZdkWaSrz0lC3FTRfdB4c_GRQDaL1ZXbi9anxmzHWjaZ5PI6Y2j_FUoUvORpnRdsdcXn38qpZeLTt9iWF2mRC4tmeA0Ilkp4WKYca9l7bb0a4 X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 26 Jun 2010 13:36:16 -0500 To: SBVR RTF From: "Ronald G. Ross" Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 All, Off-line, I have already had 2 bits of feedback about my message yesterday. Allow me to clarify. * Re: Point 5. Since "categorization", "classification" and "characterization" are nouns, the point applies only to those 'concept connections' that are left, which are all fact types, not facts. As I understand it, SBVR uses "nominalized" only for fact types. * Categorization", "classification" and "characterization" as *business people* would use the terms are facts, not fact types. That was a major problem with the draft resolution coming out of the previous meeting. Below is what I had written (4/19/2010) about that crucial point. I strongly suggest that to discuss this point further, we take *examples* and work them through. The working draft I sent yesterday does include examples ... we can use those or others. Ron [4/19/2010]: I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution [coming out of the previous meeting] fails to support these goals in important ways. What would a business person mean if they used the words .categorization. and .classification.? What example(s) would they give if you asked for some? I.m quite confident they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb concept 'general concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb concept 'individual concept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines .categorization verb concept. and .classification verb concept., not simply .categorization. and .classification., respectively. What are these former concepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: .A number of the definitions in subsection 11.1.5 are incomprehensible ... Unfortunately, these replacements are not terribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. ... the original issue 13716 write-up said as much: . . these concepts are defined as kinds of .fact types., but should actually be defined as kinds of *facts*.. The draft resolution does not fix that core problem; it just makes things even more complicated (no mean feat). With respect to the concepts .categorization. and .classification., I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use .categorization. and .classification. as standard SBVR terms so when people say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say .That represents or creates a categorization (or a classification).. 3. To be able to ask business people for real-life examples from their business . and have definitions to fall back on if they give something inappropriate. ... The definitions I propose are these (sorry, I don.t do SBVR-SE): * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find .is-role-of fact [type]. and .is-facet-of fact [type]. in the above scheme because there are no natural business terms (in English at least) for those concepts. (.Rollification. and .facetification. have been facetiously proposed, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., .categorization. and .classification.). At 11:55 PM 6/25/2010, Ronald G. Ross wrote: All, At Thursday's face-to-face meeting in Minneapolis, I believe the consensus of the group was that we need to take a step back from the resolution produced from the last meeting (see critique below, in original e-mail), and re-gear for this issue. I came away with the following points of understanding/instructions/guidelines, as I believe Donald recorded in the meeting notes. Feedback welcome. 1. We should avoid the term "fact" in definitions for entries in this section (e.g., for categorization, classification, etc.). Instead, the word "connection" should be used. The point as I understood it is not necessarily that usage of "fact" is wrong, but rather that it conflates meta-levels, and could easily be misunderstood in the fact modeling community (e.g., ORM) in the context of Clause 11. If correct, in my mind this device simply displaces the problem, does not solve it (because "connection" still must be grounded in SBVR). However, I am willing to see what develops on that score. "Connection" is not a bad signifier if it can be properly grounded. 2. It would be useful to include "characterization" among the entries. 3. It is desirable to have both SBVR and natural-language dictionary definitions for each entry. 4. Exposition of the rational for changes in the existing document is necessary for justification purposes. Specifically, what's broken/wrong in the existing specification must be identified. See attached. 5. Each entry should be nominalized (e.g., "association" instead of "associative fact type"). If it can't be nominalized using a term *business people* might naturally use, there is no justification for including the entry in Clause 11. In addition, I believe Mark wanted to see all the entries as categorizing 'meaning'. I have attached a new sketch for a resolution as well as draft SBVR entries, with comments. (As always, sorry about the lack of SBVR-SE.) Generally, I believe this direction represents good progress ... and possibly a huge simplification of the whole subsection. Ron At 03:40 PM 4/19/2010, Ronald G. Ross wrote: All, This draft resolution arose from discussion at the last SBVR meeting. I believe the idea was to give members time to study the proposed resolution and respond as appropriate. After consideration, I find that the draft resolution does not resolve the issue as posed. It also fails to clarify important terms, especially .categorization. and .classification. (formerly .assortment.). I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution fails to support these goals in important ways. What would a business person mean if they used the words .categorization. and .classification.? What example(s) would they give if you asked for some? I.m quite confident they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb concept 'general concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb concept 'individual concept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines .categorization verb concept. and .classification verb concept., not simply .categorization. and .classification., respectively. What are these former concepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: .A number of the definitions in subsection 11.1.5 are incomprehensible ... Unfortunately, these replacements are not terribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. Even the original issue 13716 write-up said as much: . . these concepts are defined as kinds of .fact types., but should actually be defined as kinds of *facts*.. The draft resolution does not fix that core problem; it just makes things even more complicated (no mean feat). With respect to the concepts .categorization. and .classification., I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use .categorization. and .classification. as standard SBVR terms so when people say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say .That represents or creates a categorization (or a classification).. 3. To be able to ask business people for real-life examples from their business . and have definitions to fall back on if they give something inappropriate. The parts of the draft resolution that address .true. verb concepts (fact types) are acceptable, even notable improvements. Below is what I propose as a resolution to Issue 13716. The definitions I propose are these (sorry, I don.t do SBVR-SE): * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find .is-role-of fact [type]. and .is-facet-of fact [type]. in the above scheme because there are no natural business terms (in English at least) for those concepts. (.Rollification. and .facetification. have been facetiously proposed, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., .categorization. and .classification.). The term .element of structure. is used prominently in my book, Business Rule Concepts 3rd ed. Surely, no one can doubt that: * The three categories above are key meanings in *structuring* a business concept system. * A concept system indeed has structure that needs to be designed (or adopted) by the business to operate. Here is a proposed definition for .element of structure. (again, sorry for the lack of SBVR-SE): the categorization scheme of the concept .meaning. that classifies a meaning based on its part in organizing a community.s concept system Finally, I recommend that the strange concepts .categorization verb concept. and .classification verb concept. be eliminated from the proposed resolution and from SBVR completely. Again, simpler is better. Ron At 09:29 PM 4/10/2010, keri wrote: All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept .individual concept specializes concept. or any verb concept that specializes it categorization verb concept Definition: the verb concept .general concept specializes concept. or any verb concept that specializes it contextualization verb concept Definition: the verb concept .role ranges over general concept. or the verb concept .concept has facet. or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept .role ranges over general concept. or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept .concept has facet. or any verb concept that specializes it Option: in the definitions above, we can change each case of .verb concept that specializes. to .binary fact type that specializes. if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using .formulated. in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don To: sbvr-rtf@omg.org Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 X-KeepSent: 819AAD97:9B8308A1-85257750:004C8DEB; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Mark H Linehan Date: Mon, 28 Jun 2010 10:27:13 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 06/28/2010 10:27:19, Serialize complete at 06/28/2010 10:27:19 Ron, Overall, I like your approach. I think that "concept connection" is unnecessary and adds complexity. I think it would be just as meaningful to define "categorization " as "fact that a given general concept specializes a given general concept" instead of "concept connection that a given general concept specializes a given general concept". If we use "fact", then we appeal to business persons' intuitive understanding of "fact" as well as the formal meaning in SBVR ("proposition taken as true"). If we use "concept connection", then both business people and SBVR specialists just have to go look at the definition of this unfamiliar term. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/26/2010 02:36 PM To SBVR RTF cc Subject Re: issue 13716 - Refactoring of Clause 11.1.5 All, Off-line, I have already had 2 bits of feedback about my message yesterday. Allow me to clarify. * Re: Point 5. Since "categorization", "classification" and "characterization" are nouns, the point applies only to those 'concept connections' that are left, which are all fact types, not facts. As I understand it, SBVR uses "nominalized" only for fact types. * Categorization", "classification" and "characterization" as *business people* would use the terms are facts, not fact types. That was a major problem with the draft resolution coming out of the previous meeting. Below is what I had written (4/19/2010) about that crucial point. I strongly suggest that to discuss this point further, we take *examples* and work them through. The working draft I sent yesterday does include examples ... we can use those or others. Ron [4/19/2010]: I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution [coming out of the previous meeting] fails to support these goals in important ways. What would a business person mean if they used the words categorization and classification? What example(s) would they give if you asked for some? Im quite confident they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb concept 'general concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb conceept 'individual concept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines categorization verb concept and classification verb concept, not simply categorization and classification, respectively. What are these former concepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: A number of the definitions in subsection 11.1.5 are incomprehensible .. Unfortunately, these replacements are not teerribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. ... the original issue 13716 write-up said as much: . these concepts are defined as kinds of facct types, but should actually be defined as kinds of *facts*. The draft resolution does not fix that core problem; it just makes things even more complicated (no mean feat). With respect to the concepts categorization and classification, I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use categorization and classification as standard SBVR terms so when people say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say That represents or creates a categorization (or a classification). 3. To be able to ask business people for real-life examples from their business . and have definitions to fall back on if theey give something inappropriate. ... The definitions I propose are these (sorry, I dont do SBVR-SE): * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find is-role-of fact [type] and is-facet-of fact [type] in the above scheme because there are no natural business terms (in English at least) for those concepts. (Rollification and facetification have been facetiously proposed, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., categorization and classification). At 11:55 PM 6/25/2010, Ronald G. Ross wrote: All, At Thursday's face-to-face meeting in Minneapolis, I believe the consensus of the group was that we need to take a step back from the resolution produced from the last meeting (see critique below, in original e-mail), and re-gear for this issue. I came away with the following points of understanding/instructions/guidelines, as I believe Donald recorded in the meeting notes. Feedback welcome. 1. We should avoid the term "fact" in definitions for entries in this section (e.g., for categorization, classification, etc.). Instead, the word "connection" should be used. The point as I understood it is not necessarily that usage of "fact" is wrong, but rather that it conflates meta-levels, and could easily be misunderstood in the fact modeling community (e.g., ORM) in the context of Clause 11. If correct, in my mind this device simply displaces the problem, does not solve it (because "connection" still must be grounded in SBVR). However, I am willing to see what develops on that score. "Connection" is not a bad signifier if it can be properly grounded. 2. It would be useful to include "characterization" among the entries. 3. It is desirable to have both SBVR and natural-language dictionary definitions for each entry. 4. Exposition of the rational for changes in the existing document is necessary for justification purposes. Specifically, what's broken/wrong in the existing specification must be identified. See attached. 5. Each entry should be nominalized (e.g., "association" instead of "associative fact type"). If it can't be nominalized using a term *business people* might naturally use, there is no justification for including the entry in Clause 11. In addition, I believe Mark wanted to see all the entries as categorizing 'meaning'. I have attached a new sketch for a resolution as well as draft SBVR entries, with comments. (As always, sorry about the lack of SBVR-SE.) Generally, I believe this direction represents good progress ... and possibly a huge simplification of the whole subsection. Ron At 03:40 PM 4/19/2010, Ronald G. Ross wrote: All, This draft resolution arose from discussion at the last SBVR meeting. I believe the idea was to give members time to study the proposed resolution and respond as appropriate. After consideration, I find that the draft resolution does not resolve the issue as posed. It also fails to clarify important terms, especially categorization and classification (formerly assortment). I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution fails to support these goals in important ways. What would a business person mean if they used the words categorization and classification? What example(s) would they give if you asked for some? Im quite confident they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb conncept 'general concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb concept 'individual cconcept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines categorization verb concept and classification verb concept, not simply categorization and classification, respectively. What are these former concepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: A number of the definitions in subsection 11.1.5 are incomprehensible .. Unffortunately, these replacements are not terribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. Even the original issue 13716 write-up said as much: . thesse concepts are defined as kinds of fact types, but should actually be defined as kinds of *facts*. The draft resolution does not fix that core problem; it just makes things even more complicated (no mean feat). With respect to the concepts categorization and classification, I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use categorization and classification as standard SBVR terms so when people say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say That represents or creates a categorization (or a classification). 3. To be able to ask business people for real-life examples from their business . aand have definitions to fall back on if they give something inappropriate. The parts of the draft resolution that address true verb concepts (fact types) are acceptable, even notable improvements. Below is what I propose as a resolution to Issue 13716. The definitions I propose are these (sorry, I dont do SBVR-SE): * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find is-role-of fact [type] and is-facet-of fact [type] in the above scheme because there are no natural business terms (in English at least) for those concepts. (Rollification and facetification have been facetiously proposed, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., categorization and classification). The term element of structure is used prominently in my book, Business Rule Concepts 3rd ed. Surely, no one can doubt that: * The three categories above are key meanings in *structuring* a business concept system. * A concept system indeed has structure that needs to be designed (or adopted) by the business to operate. Here is a proposed definition for element of structure (again, sorry for the lack of SBVR-SE): the categorization scheme of the concept meaning that classifies a meaning based on its part in organizing a communitys concept system Finally, I recommend that the strange concepts categorization verb concept and classification verb concept be eliminated from the proposed resolution and from SBVR completely. Again, simpler is better. Ron At 09:29 PM 4/10/2010, keri wrote: All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept individual concept specializes concept or any verb concept that specializes it categorization verb concept Definition: the verb concept general concept specializes concept or any verb concept that specializes it contextualization verb concept Definition: the verb concept role ranges over general concept or the verb concept concept has facet or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept role ranges over general concept or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept concept has facet or any verb concept that specializes it Option: in the definitions above, we can change each case of verb concept that specializes to binary fact type that specializes if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using formulated in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: sJ1oZ04VM1mlrfUa7KrfrTLa6PnoBJXKVx56kNOURG8hiGY zkU7XuzMmcKjt928yr.Tu9I3zdvjQsIbkv.xZNvCrvIsFHMCHhjER3BCXogz cVi4ELgPCeXdRkFq6Pfip2D5zC2Wmh5JNL63scFan2ibKND6fBL02YUIhd9E SmNd4_VEMKiG5qUrxAKmylSXwAIXOJUpWbGcRjYV622UQ2eN3vNn8SIZ_dBB jS1CsbiKZdY_sso0heR2dfRJDUu08karYOegjCccEK88QJ_T_3NH0p88XpxN I2pnThpgHOmE- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 20 Aug 2010 11:17:37 -0500 To: Mark H Linehan , sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 All, I would like to pick this discussion back up. In response to Mark's comments below, a revised resolution is attached. There are two fundamental principles on which this resolution is based. 1. Classifications, categorizations and characterizations are facts. (So there is no value add in the concept "concept connection".) 2. The (only) utility of Clause 11.1.5 lies with providing standardization for terms (signifiers) business people and business analysts might actually use in developing vocabulary, not in creating new names (signifiers) for (sometimes obscure) concepts. If we can all agree these principles, and the resulting simple resolution, then we might finally put this issue to rest. Ron P.S. This e-mail contains much of the most recent discussion below. At 06:13 PM 6/28/2010, Ronald G. Ross wrote: At 09:27 AM 6/28/2010, Mark H Linehan wrote: Ron, Overall, I like your approach. I think that "concept connection" is unnecessary and adds complexity. I agree. I included it simply because it was requested during the meeting. I think it would be just as meaningful to define "categorization " as "fact that a given general concept specializes a given general concept" instead of "concept connection that a given general concept specializes a given general concept". If we use "fact", then we appeal to business persons' intuitive understanding of "fact" as well as the formal meaning in SBVR ("proposition taken as true"). If we use "concept connection", then both business people and SBVR specialists just have to go look at the definition of this unfamiliar term. Again, I agree. Perhaps once everyone has a chance to think through all the discussion below (we weren't really prepared meeting-time, including myself), they'll see how simple and useful this all (finally) becomes. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/26/2010 02:36 PM To SBVR RTF cc Subject Re: issue 13716 - Refactoring of Clause 11.1.5 All, Off-line, I have already had 2 bits of feedback about my message yesterday. Allow me to clarify. * Re: Point 5. Since "categorization", "classification" and "characterization" are nouns, the point applies only to those 'concept connections' that are left, which are all fact types, not facts. As I understand it, SBVR uses "nominalized" only for fact types. * Categorization", "classification" and "characterization" as *business people* would use the terms are facts, not fact types. That was a major problem with the draft resolution coming out of the previous meeting. Below is what I had written (4/19/2010) about that crucial point. I strongly suggest that to discuss this point further, we take *examples* and work them through. The working draft I sent yesterday does include examples ... we can use those or others. Ron [4/19/2010]: I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution [coming out of the previous meeting] fails to support these goals in important ways. What would a business person mean if they used the words categorization and classification? What example(s) would they give if you asked for some? Im quite confident they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb concept 'general concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb conceept 'individual concept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines categorization verb concept and classification verb concept, not simply categorization and classification, respectively. What are these former concepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: A number of the definitions in subsection 11.1.5 are incomprehensible .. Unfortunately, these replacements are not teerribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. ... the original issue 13716 write-up said as much: . these concepts are defined as kinds of facct types, but should actually be defined as kinds of *facts*. The draft resolution does not fix that core problem; it just makes things even more complicated (no mean feat). With respect to the concepts categorization and classification, I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use categorization and classification as standard SBVR terms so when people say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say That represents or creates a categorization (or a classification). 3. To be able to ask business people for real-life examples from their business . and have definitions to fall back on if theey give something inappropriate. ... The definitions I propose are these (sorry, I dont do SBVR-SE): * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find is-role-of fact [type] and is-facet-of fact [type] in the above scheme because there are no natural business terms (in English at least) for those concepts. (Rollification and facetification have been facetiously proposed, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., categorization and classification). At 11:55 PM 6/25/2010, Ronald G. Ross wrote: All, At Thursday's face-to-face meeting in Minneapolis, I believe the consensus of the group was that we need to take a step back from the resolution produced from the last meeting (see critique below, in original e-mail), and re-gear for this issue. I came away with the following points of understanding/instructions/guidelines, as I believe Donald recorded in the meeting notes. Feedback welcome. 1. We should avoid the term "fact" in definitions for entries in this section (e.g., for categorization, classification, etc.). Instead, the word "connection" should be used. The point as I understood it is not necessarily that usage of "fact" is wrong, but rather that it conflates meta-levels, and could easily be misunderstood in the fact modeling community (e.g., ORM) in the context of Clause 11. If correct, in my mind this device simply displaces the problem, does not solve it (because "connection" still must be grounded in SBVR). However, I am willing to see what develops on that score. "Connection" is not a bad signifier if it can be properly grounded. 2. It would be useful to include "characterization" among the entries. 3. It is desirable to have both SBVR and natural-language dictionary definitions for each entry. 4. Exposition of the rational for changes in the existing document is necessary for justification purposes. Specifically, what's broken/wrong in the existing specification must be identified. See attached. 5. Each entry should be nominalized (e.g., "association" instead of "associative fact type"). If it can't be nominalized using a term *business people* might naturally use, there is no justification for including the entry in Clause 11. In addition, I believe Mark wanted to see all the entries as categorizing 'meaning'. I have attached a new sketch for a resolution as well as draft SBVR entries, with comments. (As always, sorry about the lack of SBVR-SE.) Generally, I believe this direction represents good progress ... and possibly a huge simplification of the whole subsection. Ron At 03:40 PM 4/19/2010, Ronald G. Ross wrote: All, This draft resolution arose from discussion at the last SBVR meeting. I believe the idea was to give members time to study the proposed resolution and respond as appropriate. After consideration, I find that the draft resolution does not resolve the issue as posed. It also fails to clarify important terms, especially categorization and classification (formerly assortment). I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution fails to support these goals in important ways. What would a business person mean if they used the words categorization and classification? What example(s) would they give if you asked for some? Im quite confident they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb conncept 'general concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb concept 'individual cconcept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines categorization verb concept and classification verb concept, not simply categorization and classification, respectively. What are these former concepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: A number of the definitions in subsection 11.1.5 are incomprehensible .. Unffortunately, these replacements are not terribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. Even the original issue 13716 write-up said as much: . thesse concepts are defined as kinds of fact types, but should actually be defined as kinds of *facts*. The draft resolution does not fix that core problem; it just makes things even more complicated (no mean feat). With respect to the concepts categorization and classification, I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use categorization and classification as standard SBVR terms so when people say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say That represents or creates a categorization (or a classification). 3. To be able to ask business people for real-life examples from their business . aand have definitions to fall back on if they give something inappropriate. The parts of the draft resolution that address true verb concepts (fact types) are acceptable, even notable improvements. Below is what I propose as a resolution to Issue 13716. The definitions I propose are these (sorry, I dont do SBVR-SE): * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find is-role-of fact [type] and is-facet-of fact [type] in the above scheme because there are no natural business terms (in English at least) for those concepts. (Rollification and facetification have been facetiously proposed, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., categorization and classification). The term element of structure is used prominently in my book, Business Rule Concepts 3rd ed. Surely, no one can doubt that: * The three categories above are key meanings in *structuring* a business concept system. * A concept system indeed has structure that needs to be designed (or adopted) by the business to operate. Here is a proposed definition for element of structure (again, sorry for the lack of SBVR-SE): the categorization scheme of the concept meaning that classifies a meaning based on its part in organizing a communitys concept system Finally, I recommend that the strange concepts categorization verb concept and classification verb concept be eliminated from the proposed resolution and from SBVR completely. Again, simpler is better. Ron At 09:29 PM 4/10/2010, keri wrote: All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept individual concept specializes concept or any verb concept that specializes it categorization verb concept Definition: the verb concept general concept specializes concept or any verb concept that specializes it contextualization verb concept Definition: the verb concept role ranges over general concept or the verb concept concept has facet or any verb concept that specializes either of them is-role-of verb concept Definition: the verb concept role ranges over general concept or any verb concept that specializes it is-facet-of verb concept Definition: the verb concept concept has facet or any verb concept that specializes it Option: in the definitions above, we can change each case of verb concept that specializes to binary fact type that specializes if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using formulated in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don Issue 13716 - diagram sketch for version 8.zip Issue 13716-SBVR 1.0 ch11.1.5 - version 8.doc 08-01-02 - problem exposition for issue 13716 v2.pdf From: Don Baisley To: "sbvr-rtf@omg.org" Subject: RE: issue 13716 - Refactoring of Clause 11.1.5 Thread-Topic: issue 13716 - Refactoring of Clause 11.1.5 Thread-Index: AQHLFs5Ol31mJSjtR06AP0qYg4bR7JLq20QRgAAbDLA= Date: Fri, 20 Aug 2010 18:32:40 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.74] Ron is correct that there is no need for anything called .concept connection.. Focusing on useful words is a good approach. I see some problems with the terms in the Word document Ron sent out. 1. The use of the signifier .property. for the concept defined in the document troubles me. Note that SBVR adopts ISO.s definition of .characteristic. which uses the word .property. in its more widely-used sense: .abstraction of a property of an object [thing] or of a set of objects.. Also, the .Dictionary Basis. given in the document matches the ISO usage, not the defined concept. The defined concept seems more aligned with the programming / data modeling notion. 2. The signifiers .inclusion. and .composition. don.t seem to me to be words that people use to refer to verb concepts of any sort. The definition in the document is unlike anything I find in dictionaries. 3. a .classification. seems to me to most typically involve a thing and a class or type, not an individual concept and a more general concept. In other words, a .classification. is typically an objectification of .instance of., not an objectification of .specializes.. It.s about the correspondence relation. Which of these facts are classifications?: 1. Ron is a person. 2. Ron is an instance of the general concept .person.. 3. The individual concept .Ron. specializes the general concept .person.. Definitely 2, and 1 because it really says the same thing (its logical formulation is an instantiation formulation). But 3? Best regards, Don From: Ronald G. Ross [mailto:rross@BRSolutions.com] Sent: Friday, August 20, 2010 9:18 AM To: Mark H Linehan; sbvr-rtf@omg.org Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 All, I would like to pick this discussion back up. In response to Mark's comments below, a revised resolution is attached. There are two fundamental principles on which this resolution is based. 1. Classifications, categorizations and characterizations are facts. (So there is no value add in the concept "concept connection".) 2. The (only) utility of Clause 11.1.5 lies with providing standardization for terms (signifiers) business people and business analysts might actually use in developing vocabulary, not in creating new names (signifiers) for (sometimes obscure) concepts. If we can all agree these principles, and the resulting simple resolution, then we might finally put this issue to rest. Ron P.S. This e-mail contains much of the most recent discussion below. At 06:13 PM 6/28/2010, Ronald G. Ross wrote: At 09:27 AM 6/28/2010, Mark H Linehan wrote: Ron, Overall, I like your approach. I think that "concept connection" is unnecessary and adds complexity. I agree. I included it simply because it was requested during the meeting. I think it would be just as meaningful to define "categorization " as "fact that a given general concept specializes a given general concept" instead of "concept connection that a given general concept specializes a given general concept". If we use "fact", then we appeal to business persons' intuitive understanding of "fact" as well as the formal meaning in SBVR ("proposition taken as true"). If we use "concept connection", then both business people and SBVR specialists just have to go look at the definition of this unfamiliar term. Again, I agree. Perhaps once everyone has a chance to think through all the discussion below (we weren't really prepared meeting-time, including myself), they'll see how simple and useful this all (finally) becomes. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/26/2010 02:36 PM To SBVR RTF cc Subject Re: issue 13716 - Refactoring of Clause 11.1.5 All, Off-line, I have already had 2 bits of feedback about my message yesterday. Allow me to clarify. * Re: Point 5. Since "categorization", "classification" and "characterization" are nouns, the point applies only to those 'concept connections' that are left, which are all fact types, not facts. As I understand it, SBVR uses "nominalized" only for fact types. * Categorization", "classification" and "characterization" as *business people* would use the terms are facts, not fact types. That was a major problem with the draft resolution coming out of the previous meeting. Below is what I had written (4/19/2010) about that crucial point. I strongly suggest that to discuss this point further, we take *examples* and work them through. The working draft I sent yesterday does include examples ... we can use those or others. Ron [4/19/2010]: I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution [coming out of the previous meeting] fails to support these goals in important ways. What would a business person mean if they used the words categorizization and classification? What exa? What example(s) would they give if you asked for some? Im..m quite confident they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb cooncept 'general concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb conceept 'individual concept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines categorization verb concept157; and classification verb concept, not sot simply categorization and classifclassification, respectively. What are these former cconcepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: A number of the definitions in sububsection 11.1.5 are incomprehensible .. Unforfortunately, these replacements are not teerribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. ... the original issue 13716 write-up said as much: . thesehese concepts are defined as kinds of facct types.., but should actually be defined as kinds of *facts**. The draft resolution does not fix that core problem; it just makes things even more complicated (no mean feat). With respect to the concepts categorization and classificationion, I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use categorization and classi..classification as standard SBVR terms so when people sa say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say That represents or creates a categorization (or a classification). 3. To be able to ask businesss people for real-life examples from their business . aand have definitions to fall back on if theey give something inappropriate. ... The definitions I propose are these (sorry, I dont do SBVR-SE): br> * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find isis-role-of fact [type] and is-facet-of faf fact [type] in the above scheme because there arre no natural business terms (in English at least) for those concepts. (Rollification and facetification have been facetiously proposed,, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., catategorization and classification). ..). At 11:55 PM 6/25/2010, Ronald G. Ross wrote: All, At Thursday's face-to-face meeting in Minneapolis, I believe the consensus of the group was that we need to take a step back from the resolution produced from the last meeting (see critique below, in original e-mail), and re-gear for this issue. I came away with the following points of understanding/instructions/guidelines, as I believe Donald recorded in the meeting notes. Feedback welcome. 1. We should avoid the term "fact" in definitions for entries in this section (e.g., for categorization, classification, etc.). Instead, the word "connection" should be used. The point as I understood it is not necessarily that usage of "fact" is wrong, but rather that it conflates meta-levels, and could easily be misunderstood in the fact modeling community (e.g., ORM) in the context of Clause 11. If correct, in my mind this device simply displaces the problem, does not solve it (because "connection" still must be grounded in SBVR). However, I am willing to see what develops on that score. "Connection" is not a bad signifier if it can be properly grounded. 2. It would be useful to include "characterization" among the entries. 3. It is desirable to have both SBVR and natural-language dictionary definitions for each entry. 4. Exposition of the rational for changes in the existing document is necessary for justification purposes. Specifically, what's broken/wrong in the existing specification must be identified. See attached. 5. Each entry should be nominalized (e.g., "association" instead of "associative fact type"). If it can't be nominalized using a term *business people* might naturally use, there is no justification for including the entry in Clause 11. In addition, I believe Mark wanted to see all the entries as categorizing 'meaning'. I have attached a new sketch for a resolution as well as draft SBVR entries, with comments. (As always, sorry about the lack of SBVR-SE.) Generally, I believe this direction represents good progress ... and possibly a huge simplification of the whole subsection. Ron At 03:40 PM 4/19/2010, Ronald G. Ross wrote: All, This draft resolution arose from discussion at the last SBVR meeting. I believe the idea was to give members time to study the proposed resolution and respond as appropriate. After consideration, I find that the draft resolution does not resolve the issue as posed. It also fails to clarify important terms, especially categorization.. and classification (formerly rly assortment). I believe a principal purpurpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution fails to support these goals in important ways. What would a business person mean if they used the words categorization.. and classification? What example(s) wole(s) would they give if you asked for some? Im quite conconfident they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb connceept 'general concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb concept 'individual cconncept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines categorization verb concept an; and classification verb concept, not simpsimply categorization and classificassification, respectively. What are these former conccepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: A number of the definitions in subsecection 11.1.5 are incomprehensible .. Unfforturtunately, these replacements are not terribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. Even the original issue 13716 write-up said as much: . thesse sse concepts are defined as kinds of fact types.., but should actually be defined as kinds of *facts*. The draft resolution does not fix that core prroblem; it just makes things even more complicated (no mean feat). With respect to the concepts .categorization and classificationon, I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use categorization and classifi.classification as standard SBVR terms so when people say ay them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say That > represents or creates a categorization (or a classification). 3. To be able to ask business people for real-life examples from their business . aannd have definitions to fall back on if they give something inappropriate. The parts of the draft resolution that address true verb concepts (fact (fact types) are acceptable, even notable improvements. Below is what I propose as a resolution to Issue 13716. The definitions I propose are these (sorry, I dont do SBVR-SE): > * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find .is-role-of fact [type] and is-facet-ocet-of fact [type] in the above scheme because therre are no natural business terms (in English at least) for those concepts. (Rollification and facetification have been facetiously propoposed, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., .categorization and classificationon). The term element of structure. is used prominently in my book, Business Rule Concepts 3rd ed. Surely, no one can doubt that: * The three categories above are key meanings in *structuring* a business concept system. * A concept system indeed has structure that needs to be designed (or adopted) by the business to operate. Here is a proposed definition for element of structure. (again, sorry for the lack of SBVR-SE): the categorization scheme of the concept meaning that. that classifies a meaning based on its part in organizing a communitys concept system Finally, I re recommend that the strange concepts categorization v verb concept and classification verb con concept be eliminated from the proposed resolutioon and from SBVR completely. Again, simpler is better. Ron At 09:29 PM 4/10/2010, keri wrote: All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept individual concncept specializes concept or any verb concept that at specializes it categorization verb concept Definition: the verb concept general c concept specializes concept or any verb concept th that specializes it contextualization verb concept Definition: the verb concept rolole ranges over general concept or the verb cb concept concept has facet or any verb conce concept that specializes either of them is-role-of verb concept Definition: the verb concept role ranges over general concept or any veany verb concept that specializes it is-facet-of verb concept Definition: the verb concept concept has facet or any verb concept that spt specializes it Option: in the definitions above, we can change each case of verb concept that spspecializes to binary fact type that specializes. if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using .formulated in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: iHkBO6MVM1lU46IX8ELiq67tQhIzWq0BC6H85W2lc_eOyZe vSmcUzHT_rBczMqNTk3LLfc9Z6opePK8kmdf.7BjX80Gc3mW73iP_M7Wst7s 5TNl9Nrn.UfJG5QMjuc5okukTs3BDjmOJIXZytAys3mckL9sYZbigUm4RMv1 0wqUFVJoAMIaqA4hzMLCdp35oEMAmYz2LuSJ6qrOwYAtlVmXNep4GTX9CZvt Fhm3rye1hUBc1ph3bix.DsEgG.dLfIAbvu2tmgEb3YQQ- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 20 Aug 2010 15:54:30 -0500 To: Don Baisley , "sbvr-rtf@omg.org" From: "Ronald G. Ross" Subject: RE: issue 13716 - Refactoring of Clause 11.1.5 At 01:32 PM 8/20/2010, Don Baisley wrote: Ron is correct that there is no need for anything called concept connection. Focusing on useful words is a good approach. Thanks, Don. Specific replies below. I see some problems with the terms in the Word document Ron sent out. 1. The use of the signifier property for the concept defined in the document troubles me. Note that SBVR adopts ISOs definition of characteristic which uses the word property in its more widely-used sense: abstraction of a property of an object [thing] or of a set of objects. Also, the Dictionary Basis given in the document matches the ISO usage, not the defined concept. The defined concept seems more aligned with the programming / data modeling notion. Doesn't trouble me. But in the interest of seeking solutions, I see three other possibilities. 1. Drop the concept from SBVR. I am against doing that. This is a useful concept in the real world. 2. Keep the existing signifier "is-property-of". Not elegant, but I could live with it. 3. Call it "attribution". We could base it on the following MWUD definitions: * [attribution] 4: the fact of being an attribute : the logical relation of an attribute to its subject * [attribute] 2: an object closely associated with and thought of as belonging to a specific person, thing, or office 2. The signifiers inclusion and composition dont seem to me to be words that people use to refer to verb concepts of any sort. The definition in the document is unlike anything I find in dictionaries. I checked. I agree with you on "inclusion". As for "composition", how about the following definition from MWUD? (Note: "arrangement" is probably wrong, but "combination" seems O.K.). [composition] 2a : the particular arrangement or combination of parts of a unit or whole Since this concept is adopted from ISO, I think we should keep it. I could live with the existing signifiers: "part-whole verb concept" and "partitive verb concept". Not elegant, but oh well. 3. a classification seems to me to most typically involve a thing and a class or type, not an individual concept and a more general concept. In other words, a classification is typically an objectification of instance of, not an objectification of specializes. Its about the correspondence relation. Which of these facts are classifications?: 1. Ron is a person. 2. Ron is an instance of the general concept person. 3. The individual concept Ron specializes the general concept person. Definitely 2, and 1 because it really says the same thing (its logical formulation is an instantiation formulation). But 3? I'll leave this to the logics-trained people on the team. I will simply say I'm not sure how you can prove to me that when I classify something, that something is not just in my head(?). Of course, I *am* Ron. And it *is* my head. Anyway, please propose alternate definition. Ron Best regards, Don From: Ronald G. Ross [ mailto:rross@BRSolutions.com] Sent: Friday, August 20, 2010 9:18 AM To: Mark H Linehan; sbvr-rtf@omg.org Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 All, I would like to pick this discussion back up. In response to Mark's comments below, a revised resolution is attached. There are two fundamental principles on which this resolution is based. 1. Classifications, categorizations and characterizations are facts. (So there is no value add in the concept "concept connection".) 2. The (only) utility of Clause 11.1.5 lies with providing standardization for terms (signifiers) business people and business analysts might actually use in developing vocabulary, not in creating new names (signifiers) for (sometimes obscure) concepts. If we can all agree these principles, and the resulting simple resolution, then we might finally put this issue to rest. Ron P.S. This e-mail contains much of the most recent discussion below. At 06:13 PM 6/28/2010, Ronald G. Ross wrote: At 09:27 AM 6/28/2010, Mark H Linehan wrote: Ron, Overall, I like your approach. I think that "concept connection" is unnecessary and adds complexity. I agree. I included it simply because it was requested during the meeting. I think it would be just as meaningful to define "categorization " as "fact that a given general concept specializes a given general concept" instead of "concept connection that a given general concept specializes a given general concept". If we use "fact", then we appeal to business persons' intuitive understanding of "fact" as well as the formal meaning in SBVR ("proposition taken as true"). If we use "concept connection", then both business people and SBVR specialists just have to go look at the definition of this unfamiliar term. Again, I agree. Perhaps once everyone has a chance to think through all the discussion below (we weren't really prepared meeting-time, including myself), they'll see how simple and useful this all (finally) becomes. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/26/2010 02:36 PM To SBVR RTF cc Subject Re: issue 13716 - Refactoring of Clause 11.1.5 All, Off-line, I have already had 2 bits of feedback about my message yesterday. Allow me to clarify. * Re: Point 5. Since "categorization", "classification" and "characterization" are nouns, the point applies only to those 'concept connections' that are left, which are all fact types, not facts. As I understand it, SBVR uses "nominalized" only for fact types. * Categorization", "classification" and "characterization" as *business people* would use the terms are facts, not fact types. That was a major problem with the draft resolution coming out of the previous meeting. Below is what I had written (4/19/2010) about that crucial point. I strongly suggest that to discuss this point further, we take *examples* and work them through. The working draft I sent yesterday does include examples ... we can use those or others. Ron [4/19/2010]: I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution [coming out of the previous meeting] fails to support these goals in important ways. What would a business person mean if they used the words ..categorizization.. and ..classification..? What exa? What example(s) would they give if you asked for some? I..m.m quite confident they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb cooncept 'general concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb conceept 'individual concept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines ..categorization verb concept.157; and ..classification verb concept., not sot simply ..categorization. and ..classifclassification., respectively. What are these former cconcepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: ..A number of the definitions in sububsection 11.1.5 are incomprehensible ... Unforfortunately, these replacements are not teerribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. ... the original issue 13716 write-up said as much: .. . thesehese concepts are defined as kinds of ..facct types.., but should actually be defined as kinds of *facts**.. The draft resolution does not fix that core problem; it just makes things even more complicated (no mean feat). With respect to the concepts .categorization.. and ..classification.n, I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use ..categorization.. and ..classiclassification.. as standard SBVR terms so when people sa say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say ..That represents or creates a categorization (or a classification).. 3. To be able to ask businesss people for real-life examples from their business . aand have definitions to fall back on if theey give something inappropriate. ... The definitions I propose are these (sorry, I don..t do SBVR-SE): br> * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find ..isis-role-of fact [type]. and ..is-facet-of faf fact [type]. in the above scheme because there arre no natural business terms (in English at least) for those concepts. (..Rollification. and ..facetification. have been facetiously proposed,, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., ..catategorization.. and ..classification..). ). At 11:55 PM 6/25/2010, Ronald G. Ross wrote: All, At Thursday's face-to-face meeting in Minneapolis, I believe the consensus of the group was that we need to take a step back from the resolution produced from the last meeting (see critique below, in original e-mail), and re-gear for this issue. I came away with the following points of understanding/instructions/guidelines, as I believe Donald recorded in the meeting notes. Feedback welcome. 1. We should avoid the term "fact" in definitions for entries in this section (e.g., for categorization, classification, etc.). Instead, the word "connection" should be used. The point as I understood it is not necessarily that usage of "fact" is wrong, but rather that it conflates meta-levels, and could easily be misunderstood in the fact modeling community (e.g., ORM) in the context of Clause 11. If correct, in my mind this device simply displaces the problem, does not solve it (because "connection" still must be grounded in SBVR). However, I am willing to see what develops on that score. "Connection" is not a bad signifier if it can be properly grounded. 2. It would be useful to include "characterization" among the entries. 3. It is desirable to have both SBVR and natural-language dictionary definitions for each entry. 4. Exposition of the rational for changes in the existing document is necessary for justification purposes. Specifically, what's broken/wrong in the existing specification must be identified. See attached. 5. Each entry should be nominalized (e.g., "association" instead of "associative fact type"). If it can't be nominalized using a term *business people* might naturally use, there is no justification for including the entry in Clause 11. In addition, I believe Mark wanted to see all the entries as categorizing 'meaning'. I have attached a new sketch for a resolution as well as draft SBVR entries, with comments. (As always, sorry about the lack of SBVR-SE.) Generally, I believe this direction represents good progress ... and possibly a huge simplification of the whole subsection. Ron At 03:40 PM 4/19/2010, Ronald G. Ross wrote: All, This draft resolution arose from discussion at the last SBVR meeting. I believe the idea was to give members time to study the proposed resolution and respond as appropriate. After consideration, I find that the draft resolution does not resolve the issue as posed. It also fails to clarify important terms, especially ..categorization.. and ..classification.. (formerly ..rly assortment..). I believe a principal purpurpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution fails to support these goals in important ways. What would a business person mean if they used the words ..categorization.. and ..classification..? What example(s) wole(s) would they give if you asked for some? I..m quite conconfident they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb connceept 'general concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb concept 'individual cconncept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines ..categorization verb concept. an; and ..classification verb concept., not simpsimply ..categorization. and ..classificassification., respectively. What are these former conccepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: ..A number of the definitions in subsecection 11.1.5 are incomprehensible ... Unfforturtunately, these replacements are not terribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. Even the original issue 13716 write-up said as much: .. . thesse sse concepts are defined as kinds of ..fact types., but should actually be defined as kinds of *facts*.. The draft resolution does not fix that core prroblem; it just makes things even more complicated (no mean feat). With respect to the concepts ..categorization.. and ..classification..on, I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use ..categorization.. and ..classifi.classification.. as standard SBVR terms so when people say ay them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say ..That > represents or creates a categorization (or a classification).. 3. To be able to ask business people for real-life examples from their business . aannd have definitions to fall back on if they give something inappropriate. The parts of the draft resolution that address ..true.. verb concepts (fact (fact types) are acceptable, even notable improvements. Below is what I propose as a resolution to Issue 13716. The definitions I propose are these (sorry, I don..t do SBVR-SE): > * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find ..is-role-of fact [type]. and ..is-facet-ocet-of fact [type]. in the above scheme because therre are no natural business terms (in English at least) for those concepts. (..Rollification. and .facetification. have been facetiously propoposed, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., ..categorization.. and ..classification..on). The term ..element of structure. is used prominently in my book, Business Rule Concepts 3rd ed. Surely, no one can doubt that: * The three categories above are key meanings in *structuring* a business concept system. * A concept system indeed has structure that needs to be designed (or adopted) by the business to operate. Here is a proposed definition for ..element of structure. (again, sorry for the lack of SBVR-SE): the categorization scheme of the concept ..meaning.. that that classifies a meaning based on its part in organizing a community..s concept system Finally, I re recommend that the strange concepts ..categorization v verb concept. and ..classification verb con concept. be eliminated from the proposed resolutioon and from SBVR completely. Again, simpler is better. Ron At 09:29 PM 4/10/2010, keri wrote: All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" < Don.Baisley@microsoft.com> wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept ..individual concncept specializes concept.. or any verb concept that at specializes it categorization verb concept Definition: the verb concept ..general c concept specializes concept.. or any verb concept th that specializes it contextualization verb concept Definition: the verb concept ..rolole ranges over general concept.. or the verb cb concept ..concept has facet.. or any verb conce concept that specializes either of them is-role-of verb concept Definition: the verb concept ..role ranges over general concept.. or any veany verb concept that specializes it is-facet-of verb concept Definition: the verb concept .concept has facet.. or any verb concept that spt specializes it Option: in the definitions above, we can change each case of ..verb concept that spspecializes. to ..binary fact type that specializes. if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using ..formulated. in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don From: Don Baisley To: "Ronald G. Ross" , "sbvr-rtf@omg.org" Subject: RE: issue 13716 - Refactoring of Clause 11.1.5 Thread-Topic: issue 13716 - Refactoring of Clause 11.1.5 Thread-Index: AQHLFs5Ol31mJSjtR06AP0qYg4bR7JLq20QRgAAbDLCAADAy8oAEds6Q Date: Mon, 23 Aug 2010 17:27:12 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] Ron, You asked for an alternative definition for .classification.. How about this? Definition: fact that a given thing is an instance of a given general concept Your example can be more direct. That is, remove this: Example: The individual concept .Switzerland. specializes the general concept .country.. and replace it with this: Example: Switzerland is a country. Or, if you prefer the wordier form, you can use this: Example: Switzerland is an instance of the general concept .country.. I like the shorter example, which is formulated logically using an instantiation formulation. I think the shorter version is what business people would use. It more directly captures what a business person would want to say. Best regards, Don From: Ronald G. Ross [mailto:rross@BRSolutions.com] Sent: Friday, August 20, 2010 1:55 PM To: Don Baisley; sbvr-rtf@omg.org Subject: RE: issue 13716 - Refactoring of Clause 11.1.5 At 01:32 PM 8/20/2010, Don Baisley wrote: Ron is correct that there is no need for anything called concept t connection. Focusing on useful words is aa good approach. Thanks, Don. Specific replies below. I see some problems with the terms in the Word document Ron sent out. 1. The use of the signifier property. for the concept defined in the document troubles me. Note that SBVR adopts ISOs definition on of characteristic which uses the word property in its more widely-used sense: .e: abstraction of a property of an object [thing] oror of a set of objects. Also, the D..Dictionary Basis given in the document matches the ISO usage, not the defined concept. The defined concept seems more aligned with the programming / data modeling notion. Doesn't trouble me. But in the interest of seeking solutions, I see three other possibilities. 1. Drop the concept from SBVR. I am against doing that. This is a useful concept in the real world. 2. Keep the existing signifier "is-property-of". Not elegant, but I could live with it. 3. Call it "attribution". We could base it on the following MWUD definitions: * [attribution] 4: the fact of being an attribute : the logical relation of an attribute to its subject * [attribute] 2: an object closely associated with and thought of as belonging to a specific person, thing, or office 2. The signifiers ininclusion and composition 157; dont seem to me to be words that people use to re refer to verb concepts of any sort. The definition in the document is unlike anything I find in dictionaries. I checked. I agree with you on "inclusion". As for "composition", how about the following definition from MWUD? (Note: "arrangement" is probably wrong, but "combination" seems O.K.). [composition] 2a : the particular arrangement or combination of parts of a unit or whole Since this concept is adopted from ISO, I think we should keep it. I could live with the existing signifiers: "part-whole verb concept" and "partitive verb concept". Not elegant, but oh well. 3. a classification se; seems to me to most typically involve a thing and a class or type, not an individual concept and a more general concept. In other words, a classification#.. is typically an objectification of instance o of, not an objectification of specialiializes. Its about the correspondence rela relation. Which of these facts are classifications?: 1. Ron is a person. 2. Ron is an instance of the general concept peperson. 3. The individual conceptept Ron specializes the general concept t person. Definitely 2, and 1 be1 because it really says the same thing (its logical formulation is an instantiation formulation). But 3? I'll leave this to the logics-trained people on the team. I will simply say I'm not sure how you can prove to me that when I classify something, that something is not just in my head(?). Of course, I *am* Ron. And it *is* my head. Anyway, please propose alternate definition. Ron Best regards, Don From: Ronald G. Ross [ mailto:rross@BRSolutions.com] Sent: Friday, August 20, 2010 9:18 AM To: Mark H Linehan; sbvr-rtf@omg.org Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 All, I would like to pick this discussion back up. In response to Mark's comments below, a revised resolution is attached. There are two fundamental principles on which this resolution is based. 1. Classifications, categorizations and characterizations are facts. (So there is no value add in the concept "concept connection".) 2. The (only) utility of Clause 11.1.5 lies with providing standardization for terms (signifiers) business people and business analysts might actually use in developing vocabulary, not in creating new names (signifiers) for (sometimes obscure) concepts. If we can all agree these principles, and the resulting simple resolution, then we might finally put this issue to rest. Ron P.S. This e-mail contains much of the most recent discussion below. At 06:13 PM 6/28/2010, Ronald G. Ross wrote: At 09:27 AM 6/28/2010, Mark H Linehan wrote: Ron, Overall, I like your approach. I think that "concept connection" is unnecessary and adds complexity. I agree. I included it simply because it was requested during the meeting. I think it would be just as meaningful to define "categorization " as "fact that a given general concept specializes a given general concept" instead of "concept connection that a given general concept specializes a given general concept". If we use "fact", then we appeal to business persons' intuitive understanding of "fact" as well as the formal meaning in SBVR ("proposition taken as true"). If we use "concept connection", then both business people and SBVR specialists just have to go look at the definition of this unfamiliar term. Again, I agree. Perhaps once everyone has a chance to think through all the discussion below (we weren't really prepared meeting-time, including myself), they'll see how simple and useful this all (finally) becomes. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/26/2010 02:36 PM To SBVR RTF cc Subject Re: issue 13716 - Refactoring of Clause 11.1.5 All, Off-line, I have already had 2 bits of feedback about my message yesterday. Allow me to clarify. * Re: Point 5. Since "categorization", "classification" and "characterization" are nouns, the point applies only to those 'concept connections' that are left, which are all fact types, not facts. As I understand it, SBVR uses "nominalized" only for fact types. * Categorization", "classification" and "characterization" as *business people* would use the terms are facts, not fact types. That was a major problem with the draft resolution coming out of the previous meeting. Below is what I had written (4/19/2010) about that crucial point. I strongly suggest that to discuss this point further, we take *examples* and work them through. The working draft I sent yesterday does include examples ... we can use those or others. Ron [4/19/2010]: I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution [coming out of the previous meeting] fails to support these goals in important ways. What would a business person mean if they used the words ..categorizizationâ.. and ..classification..? What exa? What exa? What example(s) would they give if you asked for some? I..m.m quite confident they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb cooncept 'general concept specializes conccept' or any verb concept that specializes it * classification verb concept . the verb connceept 'individual concept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines ..categorization vererb concept.157; and ..classification ven verb concept., not sot simply ..categorigorization. and ..classifclassificationn., respectively. What are these former cconceptss? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: ..A number of the definitions in sububsecection 11.1.5 are incomprehensible ... Unforforfortunately, these replacements are not teerribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. ... the original issue 13716 write-up said as much: .. . t.. thesehese concepts are defined as kinds of ..facct t types.., but should actually be defineefined as kinds of *facts**.. The draft resolutionn does not fix that core problem; it just makes things even more complicated (no mean feat). With respect to the concepts .categorization.... and ..classification.n, I believe the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use ..categorization.. and ..c...classiclassification.. as standard SBVR termterms so when people sa say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say ..That represents or creates a categorizatation (or a classification).. 3. To be able to ask businesss people for real-life examples from their business . aand have definitions to fall back on if theey give something inappropriate. ... The definitions I propose are these (sorry, I don...t do SBVR-SE): br> * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find ..isis-role-of fact [type]e]. and ..is-facet-of faf fact [type]]. in the above scheme because there arre no natuural business terms (in English at least) for those concepts. (..Rollification. and ....facetification. have been faceacetiously proposed,, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., ..catategorization.. and ..cl..classification..). ). At 11:55 PM 6/25/2010, Ronald G. Ross wrote: All, At Thursday's face-to-face meeting in Minneapolis, I believe the consensus of the group was that we need to take a step back from the resolution produced from the last meeting (see critique below, in original e-mail), and re-gear for this issue. I came away with the following points of understanding/instructions/guidelines, as I believe Donald recorded in the meeting notes. Feedback welcome. 1. We should avoid the term "fact" in definitions for entries in this section (e.g., for categorization, classification, etc.). Instead, the word "connection" should be used. The point as I understood it is not necessarily that usage of "fact" is wrong, but rather that it conflates meta-levels, and could easily be misunderstood in the fact modeling community (e.g., ORM) in the context of Clause 11. If correct, in my mind this device simply displaces the problem, does not solve it (because "connection" still must be grounded in SBVR). However, I am willing to see what develops on that score. "Connection" is not a bad signifier if it can be properly grounded. 2. It would be useful to include "characterization" among the entries. 3. It is desirable to have both SBVR and natural-language dictionary definitions for each entry. 4. Exposition of the rational for changes in the existing document is necessary for justification purposes. Specifically, what's broken/wrong in the existing specification must be identified. See attached. 5. Each entry should be nominalized (e.g., "association" instead of "associative fact type"). If it can't be nominalized using a term *business people* might naturally use, there is no justification for including the entry in Clause 11. In addition, I believe Mark wanted to see all the entries as categorizing 'meaning'. I have attached a new sketch for a resolution as well as draft SBVR entries, with comments. (As always, sorry about the lack of SBVR-SE.) Generally, I believe this direction represents good progress ... and possibly a huge simplification of the whole subsection. Ron At 03:40 PM 4/19/2010, Ronald G. Ross wrote: All, This draft resolution arose from discussion at the last SBVR meeting. I believe the idea was to give members time to study the proposed resolution and respond as appropriate. After consideration, I find that the draft resolution does not resolve the issue as posed. It also fails to clarify important terms, especially ..categorization.... and ..classification.. (formerly ....rly assortment..). I b> I believe a principal purpurpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution fails to support these goals in important ways. What would a business person mean if they used the words ..categorization.. and ..cl..classification..? What example(s) wole(s) would thethey give if you asked for some? I..m quite conconfinfident they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb connceeppt 'general concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb concept 'individual cconnncept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines ..categorization verb concept.#157; an; and ..classification verb concept., not simpsimply ..categorization. a7; and ..classificassification., respectivctively. What are these former conccepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: ..A n number of the definitions in subsecection 11.1.5 are incomprehensible ... Unfforturtunately, these re replacements are not terribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. Even the original issue 13716 write-up said as much: .. . thesse sse concepts ats are defined as kinds of ..fact types., but should actually be defined as kinds of **facts*.. The draft resolution does not fix thhat core prroblem; it just makes things even more complicated (no mean feat). With respect to the concepts ..categorization.. and ..c...classification..on, I believe thieve the following fundamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use ..categorization.. and ..classifi.classi.classification.. as standard SBVR terms so when people le say ay them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say ..i>That > represents or creates a categorization (or a classification).. 3. To be able to ask business people for real-life examples from their business . aannd have definitions to fall back on if thhey give something inappropriate. The parts of the draft resolution that address ..true.... verb concepts (fact (fact types) are acceptable, even notable improvements. Below is what I propose as a resolution to Issue 13716. The definitions I propose are these (sorry, I don..t do SBVR-SE): > * Categorization:on: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find ..is-role-of fact [ [type]. and ..is-facet-ocet-of fact [ty [type]. in the above scheme because therre are nno natural business terms (in English at least) for those concepts. (..Rollification. and .facetification. have been fac facetiously propoposed, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., ..categorization.. and . ..classification..on). < The term ..element of structure. is used prominently in my book, Business Rule Concepts 3rd ed. Surely, no one can doubt that: * The three categories above are key meanings in *structuring* a business concept system. * A concept system indeed has structure that needs to be designed (or adopted) by the business to operate. Here is a proposed definition for ..element of structureâ. (again, sorry for the lack of SBVR-SE): the categorrization scheme of the concept ..meaning.. ... that that classifies a meaning based on its part in organizing a community..s concept system > Finally, I re recommend that the strange concepts ...categorization v verb concept. and ....classification verb con concept. be eliminatted from the proposed resolutioon and from SBVR completely. Again, simpler is better. Ron At 09:29 PM 4/10/2010, keri wrote: All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" < Don.Baisley@microsoft.com> wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept ..individual concncept spececializes concept.. or any verb concept that at spespecializes it categorization verb concept Definition: the verb concept ..general c concept specializes concept.. ... or any verb concept th that specializes it contextualization verb concept Definition: the verb concept ..rolole ranges s over general concept.. or the verb cb concencept ..concept has facet.. or any verb conce conce concept that specializes either of them is-role-of verb concept Definition: the verb concept ..role ranges over generaral concept.. or any veany verb concept that speciacializes it is-facet-of verb concept Definition: the verb concept .concept has facet.. or any verb concept thept that spt specializes it Option: in the definitions above, we can change each case of ..verb concept that spspecializes. to ....binary fact type that specializes. if we want to narrow the definitions in that way. Be sure to fix the examples. I recommend not using ..formulated. in in these business-facing examples. Examples should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don To: sbvr-rtf@omg.org Subject: RE: issue 13716 - Refactoring of Clause 11.1.5 X-KeepSent: BD8E73DD:C5DDB53B-85257789:0048C035; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Mark H Linehan Date: Tue, 24 Aug 2010 09:36:26 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 08/24/2010 09:36:26, Serialize complete at 08/24/2010 09:36:26 Regarding "classification" -- with the definition proposed by Don, what's the difference between "categorization" and "classification"? I think the real problem is that the term "classification" is wrong. One idea -- how about "instantiation"? I don't think "assortment" is a true synonym of either "classification" or "instantiation". I think of "assortment" as in this example: "the gift basket contains an assortment of cheeses". From Merriam-Webster Online, I get that an assortment is "2: a collection of assorted things or persons ", where "assorted" means "2: consisting of various kinds ". I do think it makes sense to have "assortment" as a concept in this section with a definition such as "fact that a given verb concept means various kinds of some concept are collected within another concept". I think "attribution" is good. I like "composition". I suggest that the definitions for "association" and the other verb-concept-based entries follow the pattern of "fact that ..." just like "categorization" (etc.) For example, "assocation" would be better-defined as "fact that a given verb concept has more than one role ...". Similarly, "composition" could be defined as "fact that a given verb concept means a given part is in the composition of a given whole". To me, the use of "fact that ...." is much clearer than embedding "actuality" somewhere within the definition. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com From: Don Baisley To: "Ronald G. Ross" , "sbvr-rtf@omg.org" Date: 08/23/2010 01:29 PM Subject: RE: issue 13716 - Refactoring of Clause 11.1.5 -------------------------------------------------------------------------------- Ron, You asked for an alternative definition for classification. How about this? Definition: fact that a given thing is an instance of a given general concept Your example can be more direct. That is, remove this: Example: The individual concept Switzerland specializes the general concept country. and replace it with this: Example: Switzerland is a country. Or, if you prefer the wordier form, you can use this: Example: Switzerland is an instance of the general concept country. I like the shorter example, which is formulated logically using an instantiation formulation. I think the shorter version is what business people would use. It more directly captures what a business person would want to say. Best regards, Don From: Ronald G. Ross [mailto:rross@BRSolutions.com] Sent: Friday, August 20, 2010 1:55 PM To: Don Baisley; sbvr-rtf@omg.org Subject: RE: issue 13716 - Refactoring of Clause 11.1.5 At 01:32 PM 8/20/2010, Don Baisley wrote: Ron is correct that there is no need for anything called ..concept connection. Focusing on usefuseful words is a good approach. Thanks, Don. Specific replies below. I see some problems with the terms in the Word document Ron sent out. 1. The use of the signifier ..propererty for the concept defined in the document troublees me. Note that SBVR adopts ISO..s definitionion of ..characteristic which uses the word .property in its more widely-used sense: ..abstraction of a property of an object [thing] or of a set of objects. Also, the ..Dictionary Bay Basis given in the document matches the ISO usage, nnot the defined concept. The defined concept seems more aligned with the programming / data modeling notion. Doesn't trouble me. But in the interest of seeking solutions, I see three other possibilities. 1. Drop the concept from SBVR. I am against doing that. This is a useful concept in the real world. 2. Keep the existing signifier "is-property-of". Not elegant, but I could live with it. 3. Call it "attribution". We could base it on the following MWUD definitions: * [attribution] 4: the fact of being an attribute : the logical relation of an attribute to its subject * [attribute] 2: an object closely associated with and thought of as belonging to a specific person, thing, or office 2. The signifiers ..inclusion. and composition don..t seem to me tto me to be words that people use to refer to verb concepts of any sort. The definition in the document is unlike anything I find in dictionaries. I checked. I agree with you on "inclusion". As for "composition", how about the following definition from MWUD? (Note: "arrangement" is probably wrong, but "combination" seems O.K.). [composition] 2a : the particular arrangement or combination of parts of a unit or whole Since this concept is adopted from ISO, I think we should keep it. I could live with the existing signifiers: "part-whole verb concept" and "partitive verb concept". Not elegant, but oh well. 3. a ..classification seems to me to most typicalically involve a thing and a class or type, not an individual concept and a more general concept. In other words, a ..classification is typically an objectjectification of ..instance of, not an objectificafication of ..specializes. It..s about the out the correspondence relation. Which of these facts are classifications?: 1. Ron is a person. 2. Ron is an instance of the general concept ..person... 3. The indhe individual concept ..Ron.. specializes the generageneral concept ..person... Definitely itely 2, and 1 because it really says the same thing (its logical formulation is an instantiation formulation). But 3? I'll leave this to the logics-trained people on the team. I will simply say I'm not sure how you can prove to me that when I classify something, that something is not just in my head(?). Of course, I *am* Ron. And it *is* my head. Anyway, please propose alternate definition. Ron Best regards, Don From: Ronald G. Ross [ mailto:rross@BRSolutions.com] Sent: Friday, August 20, 2010 9:18 AM To: Mark H Linehan; sbvr-rtf@omg.org Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 All, I would like to pick this discussion back up. In response to Mark's comments below, a revised resolution is attached. There are two fundamental principles on which this resolution is based. 1. Classifications, categorizations and characterizations are facts. (So there is no value add in the concept "concept connection".) 2. The (only) utility of Clause 11.1.5 lies with providing standardization for terms (signifiers) business people and business analysts might actually use in developing vocabulary, not in creating new names (signifiers) for (sometimes obscure) concepts. If we can all agree these principles, and the resulting simple resolution, then we might finally put this issue to rest. Ron P.S. This e-mail contains much of the most recent discussion below. At 06:13 PM 6/28/2010, Ronald G. Ross wrote: At 09:27 AM 6/28/2010, Mark H Linehan wrote: Ron, Overall, I like your approach. I think that "concept connection" is unnecessary and adds complexity. I agree. I included it simply because it was requested during the meeting. I think it would be just as meaningful to define "categorization " as "fact that a given general concept specializes a given general concept" instead of "concept connection that a given general concept specializes a given general concept". If we use "fact", then we appeal to business persons' intuitive understanding of "fact" as well as the formal meaning in SBVR ("proposition taken as true"). If we use "concept connection", then both business people and SBVR specialists just have to go look at the definition of this unfamiliar term. Again, I agree. Perhaps once everyone has a chance to think through all the discussion below (we weren't really prepared meeting-time, including myself), they'll see how simple and useful this all (finally) becomes. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" 06/26/2010 02:36 PM To SBVR RTF cc Subject Re: issue 13716 - Refactoring of Clause 11.1.5 All, Off-line, I have already had 2 bits of feedback about my message yesterday. Allow me to clarify. * Re: Point 5. Since "categorization", "classification" and "characterization" are nouns, the point applies only to those 'concept connections' that are left, which are all fact types, not facts. As I understand it, SBVR uses "nominalized" only for fact types. * Categorization", "classification" and "characterization" as *business people* would use the terms are facts, not fact types. That was a major problem with the draft resolution coming out of the previous meeting. Below is what I had written (4/19/2010) about that crucial point. I strongly suggest that to discuss this point further, we take *examples* and work them through. The working draft I sent yesterday does include examples ... we can use those or others. Ron [4/19/2010]: I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution [coming out of the previous meeting] fails to support these goals in important ways. What would a business person mean if they used the words â..categorizizationâ.. . and â..classificationâ..? What exa? What exhat example(s) would they give if you asked for some? Iâ..m.m quite confident they would not mean th the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb cooncept 'general concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb conceeptt 'individual concept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines â..categorization verb conceptâ157; and â..classification verb conceptâ, not sot simply â..categorizationâ and and â..classifclassificationâ, respectively. Wha What are these former cconcepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: â..A number o of the definitions in sububsection 11.1.5 are incomprehensible .â. Unforfortunately, these replacements s are not teerribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. ... the original issue 13716 write-up said as much: â.. . thesehese concepts are definefined as kinds of â..facct typesâ..., bu, but should actually be defined as kinds of *facts**.â The draft resolution does not fix that core problem; it just makes things even more complicated (no mean feat). With respect to the concepts â..categorizationâ.. and â..classificationâ.ionâ.., I believe the following fundandamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use â..categorizatioionâ.. and â..classi.classificationââ. as standard SBVR terms so when people sa say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say â..That represesents or creates a categorization (or a classification).â 3. To be able to ask businesss people ffor real-life examples from their business . aand have definitions to fall back on if theey give something inappropriate. ... The definitions I propose are these (sorry, I donâ..t do SBVR-SE): br&br> * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find â.isis-role-of fact [type]â and â..is-face-facet-of faf fact [type]â in the above scheme becausee there arre no natural business terms (in English at least) for those concepts. (â..Rollificationâ and â..â.facetificationâ have have been facetiously proposed,, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., â..catategorizationâ.. a and â..classificationâ..). ..). ). At 11:55 PM 6/25/2010, Ronald G. Ross wrote: All, At Thursday's face-to-face meeting in Minneapolis, I believe the consensus of the group was that we need to take a step back from the resolution produced from the last meeting (see critique below, in original e-mail), and re-gear for this issue. I came away with the following points of understanding/instructions/guidelines, as I believe Donald recorded in the meeting notes. Feedback welcome. 1. We should avoid the term "fact" in definitions for entries in this section (e.g., for categorization, classification, etc.). Instead, the word "connection" should be used. The point as I understood it is not necessarily that usage of "fact" is wrong, but rather that it conflates meta-levels, and could easily be misunderstood in the fact modeling community (e.g., ORM) in the context of Clause 11. If correct, in my mind this device simply displaces the problem, does not solve it (because "connection" still must be grounded in SBVR). However, I am willing to see what develops on that score. "Connection" is not a bad signifier if it can be properly grounded. 2. It would be useful to include "characterization" among the entries. 3. It is desirable to have both SBVR and natural-language dictionary definitions for each entry. 4. Exposition of the rational for changes in the existing document is necessary for justification purposes. Specifically, what's broken/wrong in the existing specification must be identified. See attached. 5. Each entry should be nominalized (e.g., "association" instead of "associative fact type"). If it can't be nominalized using a term *business people* might naturally use, there is no justification for including the entry in Clause 11. In addition, I believe Mark wanted to see all the entries as categorizing 'meaning'. I have attached a new sketch for a resolution as well as draft SBVR entries, with comments. (As always, sorry about the lack of SBVR-SE.) Generally, I believe this direction represents good progress ... and possibly a huge simplification of the whole subsection. Ron At 03:40 PM 4/19/2010, Ronald G. Ross wrote: All, This draft resolution arose from discussion at the last SBVR meeting. I believe the idea was to give members time to study the proposed resolution and respond as appropriate. After consideration, I find that the draft resolution does not resolve the issue as posed. It also fails to clarify important terms, especially â..categorizationâ.. and â..classificationâ.. (formerly â..rly â â..assortmentâ..). I believe a pve a principal purpurpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution fails to support these goals in important ways. What would a business person mean if they used the words â..categorizationâ... and â..classificlassificationâ..? What example(s) wole(s) would they giveive if you asked for some? Iâ..m quite conconfident nt they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb connceept 'ggeneral concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb concept 'individual cconnceppt specializes concept' or any verb concept that specializes it Obviously the draft resolution defines â..categorization verb conceptâ an; and â..classification verb conceptâ, not simpsimplymply â..categorizationâ and â..classificassificassificationâ, respectively. What are these former conccepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: â..A number of the definitions i in subsecection 11.1.5 are incomprehensible .â.. Unfforturtunately, these replacements are not terribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. Even the original issue 13716 write-up said as much: â. . thesse sse concepts are defined as kinds of ¢..fact typesâ...., but should acthould actually be defined as kinds of *facts*.â The draft rresolution does not fix that core prroblem; it just makes things even more complicated (no mean feat). With respect to the concepts â..categorizatioionâ.. and â..classificationâ..onâ.onâ.., I believe the following fundamental capabiabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use â..categorizationâ.. a and â..classifi.classificationâ.. as standa standard SBVR terms so when people say ay them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say â..That > represents oror creates a categorization (or a classification). 3. To be able to ask business people for real-life examples from their business . aannd have definiitions to fall back on if they give something inappropriate. The parts of the draft resolution that address â..trueâ.. verb concepts (fact (fact tfact types) are acceptable, even notable improvements. Below is what I propose as a resolution to Issue 13716. The definitions I propose are these (sorry, I donâ..t do SBVR-SE): r> > * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find â..is-role-of fact [type]â and â.Ţis-facet-ocet-of fact [type]â in the above schemme because therre are no natural business terms (in English at least) for those concepts. (â..Rollificationâ and â â..facetificationâ h have been facetiously propoposed, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., â..categorizationâ.. and â..classificationâ..onâ.â.). The term â..element of structructureâ.. is used prominently in my book, Business Rule Concepts 3rd ed. Surely, no one can doubt that: * The three categories above are key meanings in *structuring* a business concept system. * A concept system indeed has structure that needs to be designed (or adopted) by the business to operate. Here is a proposed definition for â..elementnt of structureâ. (again, sorry for the lack of SBVR--SE): the categorization scheme of the concept â..m.meaningâ.. that that classifies a meaning based od on its part in organizing a communityâ..s concept pt system Finally, I re recommend that the strange concepts â..categorization v verb conceptâ. and â..classification verb con conceptâ b be eliminated from the proposed resolutioon and from SBVR completely. Again, simpler is better. Ron At 09:29 PM 4/10/2010, keri wrote: All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" < Don.Baisley@microsoft.com> wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept â..individual concncept specializes concnceptâ.. or any verb concept that at specializes it it categorization verb concept Definition: the verb concept â..general c c concept specializes conceptâ.. or any verb concencept th that specializes it contextualization verb concept Definition: the verb concept â..rolole ranges over general conceptâ.. or the verb cb concept â..concept haept has facetâ.. or any verb conce concept that specialializes either of them is-role-of verb concept Definition: the verb concept â..role ranges over general conceptâ.. or anyor any veany verb concept that specializes it is-facet-of verb concept Definition: the verb concept â..concept has facetâ. or any verb concept that spt specializes it Option: in the definitions above, we can change each case of â..verb concept that spspecialalizesâ to â..binary fact type that specializelizesâ.. if we want to narrow the definitions ns in that way. Be sure to fix the examples. I recommend not using â.formulated. in these business-facing examples. Examplees should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: TN2l42EVM1mxEllX14uPKvbOdcY4J4dOQ1XM7BXV3UITRZi 9Yy07hcOpPL2Y6.MKnc.y_x3W_c8lzmE7HbAcUy7l_BiUc25zJkM1cFBG9.z D8LsT3t1OguPoHaSsw4iXB6faBiIO.BefRFWqHaC.Z40nW8Bg5RXt_t_0DNE ZKK4UQ.td4xuwkKMbYJozx9kGSvTvZD3PQ5ejSSQmnlceUmHFZm0d9rY8Jfn v2CxgQ8pdEgPX0WNfSnlG5jhD_FAOLL6XjdAClHRZzJecGVSBgU..eQyVDea ck_HcjN7ibw-- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 24 Aug 2010 13:18:39 -0500 To: Mark H Linehan , sbvr-rtf@omg.org From: "Ronald G. Ross" Subject: RE: issue 13716 - Refactoring of Clause 11.1.5 At 08:36 AM 8/24/2010, Mark H Linehan wrote: Regarding "classification" -- with the definition proposed by Don, what's the difference between "categorization" and "classification"? I think the real problem is that the term "classification" is wrong. One idea -- how about "instantiation"? A business person would never say "instantiation" (and even if they did, they would probably be talking about a database or something). But they do talk about classifying/classification. I don't have any problem with Don's definition (or the original one for that matter). I don't think "assortment" is a true synonym of either "classification" or "instantiation". I think of "assortment" as in this example: "the gift basket contains an assortment of cheeses". From Merriam-Webster Online, I get that an assortment is "2: a collection of assorted things or persons ", where "assorted" means "2: consisting of various kinds ". I do think it makes sense to have "assortment" as a concept in this section with a definition such as "fact that a given verb concept means various kinds of some concept are collected within another concept". I'm willing to discard "assortment". We came up with that only because in years past we weren't able to say "classification". I forget what the problem was exactly, but it has since disappeared. I think "attribution" is good. I bet somebody won't like it. I like "composition". I suggest that the definitions for "association" and the other verb-concept-based entries follow the pattern of "fact that ..." just like "categorization" (etc.) For example, "assocation" would be better-defined as "fact that a given verb concept has more than one role ...". I believe you might be mixing meta-levels. From the business-facing perspective of Clause 11, if someone speaks of "customer places order" they mean a verb concept. That verb concept happens to be an association. Clause 11 shouldn't get into any deconstruction of that verb concept. Similarly, "composition" could be defined as "fact that a given verb concept means a given part is in the composition of a given whole". To me, the use of "fact that ...." is much clearer than embedding "actuality" somewhere within the definition. Ditto. The question is, what is it from a Clause 11 perspective? It is what is, a special category of verb concept. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com From: Don Baisley To: "Ronald G. Ross" , "sbvr-rtf@omg.org" Date: 08/23/2010 01:29 PM Subject: RE: issue 13716 - Refactoring of Clause 11.1.5 Ron, You asked for an alternative definition for classification. How about this? Definition: fact that a given thing is an instance of a given general concept Your example can be more direct. That is, remove this: Example: The individual concept Switzerland specializes the general concept country. and replace it with this: Example: Switzerland is a country . Or, if you prefer the wordier form, you can use this: Example: Switzerland is an instance of the general concept country . I like the shorter example, which is formulated logically using an instantiation formulation. I think the shorter version is what business people would use. It more directly captures what a business person would want to say. Best regards, Don From: Ronald G. Ross [mailto:rross@BRSolutions.com] Sent: Friday, August 20, 2010 1:55 PM To: Don Baisley; sbvr-rtf@omg.org Subject: RE: issue 13716 - Refactoring of Clause 11.1.5 At 01:32 PM 8/20/2010, Don Baisley wrote: Ron is correct that there is no need for anything called ..concept connection. Focusing on usefuseful words is a good approach. Thanks, Don. Specific replies below. I see some problems with the terms in the Word document Ron sent out. 1. The use of the signifier ..propererty for the concept defined in the document troublees me. Note that SBVR adopts ISO..s definitionion of ..characteristic which uses the word .property in its more widely-used sense: ..abstraction of a property of an object [thing] or of a set of objects. Also, the ..Dictionary Bay Basis given in the document matches the ISO usage, nnot the defined concept. The defined concept seems more aligned with the programming / data modeling notion. Doesn't trouble me. But in the interest of seeking solutions, I see three other possibilities. 1. Drop the concept from SBVR. I am against doing that. This is a useful concept in the real world. 2. Keep the existing signifier "is-property-of". Not elegant, but I could live with it. 3. Call it "attribution". We could base it on the following MWUD definitions: * [attribution] 4: the fact of being an attribute : the logical relation of an attribute to its subject * [attribute] 2: an object closely associated with and thought of as belonging to a specific person, thing, or office 2. The signifiers ..inclusion. and composition don..t seem to me tto me to be words that people use to refer to verb concepts of any sort. The definition in the document is unlike anything I find in dictionaries. I checked. I agree with you on "inclusion". As for "composition", how about the following definition from MWUD? (Note: "arrangement" is probably wrong, but "combination" seems O.K.). [composition] 2a : the particular arrangement or combination of parts of a unit or whole Since this concept is adopted from ISO, I think we should keep it. I could live with the existing signifiers: "part-whole verb concept" and "partitive verb concept". Not elegant, but oh well. 3. a ..classification seems to me to most typicalically involve a thing and a class or type, not an individual concept and a more general concept. In other words, a ..classification is typically an objectjectification of ..instance of, not an objectificafication of ..specializes. It..s about the out the correspondence relation. Which of these facts are classifications?: 1. Ron is a person. 2. Ron is an instance of the general concept ..person... 3. The indhe individual concept ..Ron.. specializes the generageneral concept ..person... Definitely itely 2, and 1 because it really says the same thing (its logical formulation is an instantiation formulation). But 3? I'll leave this to the logics-trained people on the team. I will simply say I'm not sure how you can prove to me that when I classify something, that something is not just in my head(?). Of course, I *am* Ron. And it *is* my head. Anyway, please propose alternate definition. Ron Best regards, Don From: Ronald G. Ross [ mailto:rross@BRSolutions.com ] Sent: Friday, August 20, 2010 9:18 AM To: Mark H Linehan; sbvr-rtf@omg.org Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 All, I would like to pick this discussion back up. In response to Mark's comments below, a revised resolution is attached. There are two fundamental principles on which this resolution is based. 1. Classifications, categorizations and characterizations are facts. (So there is no value add in the concept "concept connection".) 2. The (only) utility of Clause 11.1.5 lies with providing standardization for terms (signifiers) business people and business analysts might actually use in developing vocabulary, not in creating new names (signifiers) for (sometimes obscure) concepts. If we can all agree these principles, and the resulting simple resolution, then we might finally put this issue to rest. Ron P.S. This e-mail contains much of the most recent discussion below. At 06:13 PM 6/28/2010, Ronald G. Ross wrote: At 09:27 AM 6/28/2010, Mark H Linehan wrote: Ron, Overall, I like your approach. I think that "concept connection" is unnecessary and adds complexity. I agree. I included it simply because it was requested during the meeting. I think it would be just as meaningful to define "categorization " as "fact that a given general concept specializes a given general concept" instead of "concept connection that a given general concept specializes a given general concept". If we use "fact", then we appeal to business persons' intuitive understanding of "fact" as well as the formal meaning in SBVR ("proposition taken as true"). If we use "concept connection", then both business people and SBVR specialists just have to go look at the definition of this unfamiliar term. Again, I agree. Perhaps once everyone has a chance to think through all the discussion below (we weren't really prepared meeting-time, including myself), they'll see how simple and useful this all (finally) becomes. Ron -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com "Ronald G. Ross" < rross@BRSolutions.com > 06/26/2010 02:36 PM To SBVR RTF < sbvr-rtf@omg.org> cc Subject Re: issue 13716 - Refactoring of Clause 11.1.5 All, Off-line, I have already had 2 bits of feedback about my message yesterday. Allow me to clarify. * Re: Point 5. Since "categorization", "classification" and "characterization" are nouns, the point applies only to those 'concept connections' that are left, which are all fact types, not facts. As I understand it, SBVR uses "nominalized" only for fact types. * Categorization", "classification" and "characterization" as *business people* would use the terms are facts, not fact types. That was a major problem with the draft resolution coming out of the previous meeting. Below is what I had written (4/19/2010) about that crucial point. I strongly suggest that to discuss this point further, we take *examples* and work them through. The working draft I sent yesterday does include examples ... we can use those or others. Ron [4/19/2010]: I believe a principal purpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution [coming out of the previous meeting] fails to support these goals in important ways. What would a business person mean if they used the words â..categorizizationâ.. . and â..classificationâ..? What exa? What exhat example(s) would they give if you asked for some? Iâ..m.m quite confident they would not mean th the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb cooncept 'general concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb conceeptt 'individual concept specializes concept' or any verb concept that specializes it Obviously the draft resolution defines â..categorization verb conceptâ157; and â..classification verb conceptâ, not sot simply â..categorizationâ and and â..classifclassificationâ, respectively. Wha What are these former cconcepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: â..A number o of the definitions in sububsection 11.1.5 are incomprehensible .â. Unforfortunately, these replacements s are not teerribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. ... the original issue 13716 write-up said as much: â.. . thesehese concepts are definefined as kinds of â..facct typesâ..., bu, but should actually be defined as kinds of *facts**.â The draft resolution does not fix that core problem; it just makes things even more complicated (no mean feat). With respect to the concepts â..categorizationâ.. and â..classificationâ.ionâ.., I believe the following fundandamental capabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use â..categorizatioionâ.. and â..classi.classificationââ. as standard SBVR terms so when people sa say them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say â..That represesents or creates a categorization (or a classification).â 3. To be able to ask businesss people ffor real-life examples from their business . aand have definitions to fall back on if theey give something inappropriate. ... The definitions I propose are these (sorry, I donâ..t do SBVR-SE): br * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find â.isis-role-of fact [type]â and â..is-face-facet-of faf fact [type]â in the above scheme becausee there arre no natural business terms (in English at least) for those concepts. (â..Rollificationâ and â..â.facetificationâ have have been facetiously proposed,, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., â..catategorizationâ.. a and â..classificationâ..). ..). ). At 11:55 PM 6/25/2010, Ronald G. Ross wrote: All, At Thursday's face-to-face meeting in Minneapolis, I believe the consensus of the group was that we need to take a step back from the resolution produced from the last meeting (see critique below, in original e-mail), and re-gear for this issue. I came away with the following points of understanding/instructions/guidelines, as I believe Donald recorded in the meeting notes. Feedback welcome. 1. We should avoid the term "fact" in definitions for entries in this section (e.g., for categorization, classification, etc.). Instead, the word "connection" should be used. The point as I understood it is not necessarily that usage of "fact" is wrong, but rather that it conflates meta-levels, and could easily be misunderstood in the fact modeling community (e.g., ORM) in the context of Clause 11. If correct, in my mind this device simply displaces the problem, does not solve it (because "connection" still must be grounded in SBVR). However, I am willing to see what develops on that score. "Connection" is not a bad signifier if it can be properly grounded. 2. It would be useful to include "characterization" among the entries. 3. It is desirable to have both SBVR and natural-language dictionary definitions for each entry. 4. Exposition of the rational for changes in the existing document is necessary for justification purposes. Specifically, what's broken/wrong in the existing specification must be identified. See attached. 5. Each entry should be nominalized (e.g., "association" instead of "associative fact type"). If it can't be nominalized using a term *business people* might naturally use, there is no justification for including the entry in Clause 11. In addition, I believe Mark wanted to see all the entries as categorizing 'meaning'. I have attached a new sketch for a resolution as well as draft SBVR entries, with comments. (As always, sorry about the lack of SBVR-SE.) Generally, I believe this direction represents good progress ... and possibly a huge simplification of the whole subsection. Ron At 03:40 PM 4/19/2010, Ronald G. Ross wrote: All, This draft resolution arose from discussion at the last SBVR meeting. I believe the idea was to give members time to study the proposed resolution and respond as appropriate. After consideration, I find that the draft resolution does not resolve the issue as posed. It also fails to clarify important terms, especially â..categorizationâ.. and â..classificationâ.. (formerly â..rly â â..assortmentâ..). I believe a pve a principal purpurpose of Clause 11 in general, as well as Clause 11.1.5 in particular, is to provide an intuitive, business-friendly, common-sense vocabulary for business analysts and others in building concept systems for their communities. As much as possible, it should also give clarity and sharp delineation to terms they would naturally use for that purpose. The draft resolution fails to support these goals in important ways. What would a business person mean if they used the words â..categorizationâ... and â..classificlassificationâ..? What example(s) wole(s) would they giveive if you asked for some? Iâ..m quite conconfident nt they would not mean the following (quoting directly from the draft resolution). Nor would they indicate the following as the true examples. * categorization verb concept . the verb connceept 'ggeneral concept specializes concept' or any verb concept that specializes it * classification verb concept . the verb concept 'individual cconnceppt specializes concept' or any verb concept that specializes it Obviously the draft resolution defines â..categorization verb conceptâ an; and â..classification verb conceptâ, not simpsimplymply â..categorizationâ and â..classificassificassificationâ, respectively. What are these former conccepts? Where did they come from? Who would naturally use them? What purpose do they serve? The problem is not that the definitions are technically wrong; the problem is that the concepts are simply strange. The issue write-up said: â..A number of the definitions i in subsecection 11.1.5 are incomprehensible .â.. Unfforturtunately, these replacements are not terribly much less so. Be that as it may, I am completely unconvinced that classifications and categorizations are verb concepts (fact types) in any meaningful sense. Even the original issue 13716 write-up said as much: â. . thesse sse concepts are defined as kinds of ¢..fact typesâ...., but should acthould actually be defined as kinds of *facts*.â The draft rresolution does not fix that core prroblem; it just makes things even more complicated (no mean feat). With respect to the concepts â..categorizatioionâ.. and â..classificationâ..onâ.onâ.., I believe the following fundamental capabiabilities are needed. Indeed, I believe these are reasons the concepts came into SBVR in the first place. 1. To be able to use â..categorizationâ.. a and â..classifi.classificationâ.. as standa standard SBVR terms so when people say ay them, the terms have a standard meanings. 2. To be able to point at something, whether definition or graphic notation or whatever, and say â..That > represents oror creates a categorization (or a classification). 3. To be able to ask business people for real-life examples from their business . aannd have definiitions to fall back on if they give something inappropriate. The parts of the draft resolution that address â..trueâ.. verb concepts (fact (fact tfact types) are acceptable, even notable improvements. Below is what I propose as a resolution to Issue 13716. The definitions I propose are these (sorry, I donâ..t do SBVR-SE): r> > * Categorization: fact that a given general concept specializes a given general concept * Classification: fact that a given individual concept specializes a given general concept You do not find â..is-role-of fact [type]â and â.Ţis-facet-ocet-of fact [type]â in the above schemme because therre are no natural business terms (in English at least) for those concepts. (â..Rollificationâ and â â..facetificationâ h have been facetiously propoposed, which illustrates my point very effectively.) I recommend that these concepts be eliminated from the proposed resolution and from SBVR completely (along with "contextualization verb context"). Simpler is better. Be that as it may, the scheme I propose is obviously not complete. There is no need for it to be. Nonetheless, the scheme is sufficient because it covers (a) verb concepts that business people give signifiers for, and (b) structural members in concept systems that business people have actual names for (i.e., â..categorizationâ.. and â..classificationâ..onâ.â.). The term â..element of structructureâ.. is used prominently in my book, Business Rule Concepts 3rd ed. Surely, no one can doubt that: * The three categories above are key meanings in *structuring* a business concept system. * A concept system indeed has structure that needs to be designed (or adopted) by the business to operate. Here is a proposed definition for â..elementnt of structureâ. (again, sorry for the lack of SBVR--SE): the categorization scheme of the concept â..m.meaningâ.. that that classifies a meaning based od on its part in organizing a communityâ..s concept pt system Finally, I re recommend that the strange concepts â..categorization v verb conceptâ. and â..classification verb con conceptâ b be eliminated from the proposed resolutioon and from SBVR completely. Again, simpler is better. Ron At 09:29 PM 4/10/2010, keri wrote: All, As promised, attached is the Resolution document (change instructions) for 13716, updated to reflect the March meeting discussion. Regards, Keri On 3/26/10 4:15 AM, "keri" < keri_ah@mac.com > wrote: All, Attached is a rework of the view of 11.1.5 (and other bits). If I don't hear of any problems, I will begin work on the "change instruction" writeup of the resolution. A big 'thank you' to Don for supplying the patterns. Note that I opted to recast the current 'examples' as 'Note:' clauses. Keri On 3/25/10 4:47 AM, "Don Baisley" < Don.Baisley@microsoft.com > wrote: Here is what I agreed to do for this issue. classification verb concept Definition: the verb concept â..individual concncept specializes concnceptâ.. or any verb concept that at specializes it it categorization verb concept Definition: the verb concept â..general c c concept specializes conceptâ.. or any verb concencept th that specializes it contextualization verb concept Definition: the verb concept â..rolole ranges over general conceptâ.. or the verb cb concept â..concept haept has facetâ.. or any verb conce concept that specialializes either of them is-role-of verb concept Definition: the verb concept â..role ranges over general conceptâ.. or anyor any veany verb concept that specializes it is-facet-of verb concept Definition: the verb concept â..concept has facetâ. or any verb concept that spt specializes it Option: in the definitions above, we can change each case of â..verb concept that spspecialalizesâ to â..binary fact type that specializelizesâ.. if we want to narrow the definitions ns in that way. Be sure to fix the examples. I recommend not using â.formulated. in these business-facing examples. Examplees should be instances, so the examples should be the identified verb concept in each case and, optionally (if you want to get carried away) some made-up specialization. Best regards, Don Date: Tue, 05 Oct 2010 11:46:20 -0400 From: Edward Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: "Ronald G. Ross" CC: "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: Re: [13716] Re: issue 15450 -- SBVR RTF issue - Resolution X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edward.barkmeyer@nist.gov Ron, you wrote: Ed, You have convinced me of something, but perhaps not exactly what you thought. What you have convinced me of is that we need the concept "property" in SBVR. That is *certainly* a real-world term, and people use it a lot, so SBVR needs to own up to it. Thanks, man! That is my main point! SBVR not only doesn't have the term; it doesn't explicitly have the concept. That is the problem I see. But I'm not sure that the impact of adding the concept, and using it instead of some of the existing work-arounds, isn't beyond what the RTF should do. It depends on how the SBVR implementors see the impact on their tools. In our case, we have the 'property' concept in the tools; our problem is how to use SBVR exchange forms to convey it. In issue *13716* (Refactoring of Clause 11.1.5) we have been trying to come to grips with "is-property-of" ... which today earlier I called "property association". But how can you have a "property association" (or a 'is-property-of') if you don't know what a "property" is? The tail has been wagging the dog. I'm not sure that adding "property" to SBVR can be included under the scope of 13716. If not, I will be more than happy to create a new issue for it. Please advise. There are many issues in 13716, and I would not try to smuggle the property concept in among them. Once "property" is properly included in SBVR, then the term "is-property-of" is no longer needed. Why would you say "is-property-of" if you could just say "is property of" and be understood?! People don't speak in hyphens. Well, my understanding of 'is-property-of' is that it is a coined term for a category of fact types that create a property concept, or perhaps just a fact type that enunciates a property, like: (date) is the birthdate of (person) And for the record, those things are grammatically weird -- you have to do a lot of work in natural language tooling to handle them properly. Donald and others are very concerned about categorizing noun concepts and fact types within a vocabulary. That is not about business usage, it is solely about philosophically sorting out conceptualizations, so as to aid in clarifying them. It is not my thing, it is a (different) pedagogy, but I assume it has its place. 'is-property-of fact type' is just one of those conceptualization categories. I don't see that adding a "property" concept to SBVR removes the category. It just makes it easier to identify the instances of it. It just means that when the business person says "birthdate" is a property of persons, it implies that '(date) is the birthdate of (person)', aka 'person has birthdate', is an 'is-property-of' fact type in the SBVR formal model. -Ed Ron At 06:31 PM 10/4/2010, Ed Barkmeyer wrote: OK. You don't like 'attributive namespace'. Neither do I (but somehow we allowed the XML term 'namespace' to creep into clause 8). I hope Ron and Don are talking about the same concept, but I am no longer sure. In response to Keri's (and Ron's) concern about business semantics here, what Don and I intended is a "designation for a property of a thing". (Unfortunately, SBVR doesn't have the concept type 'property of a thing'. It only has 'role of a thing'.) The fact type is the way in which the possession of the property is stated, which makes the property a role in that fact type. But not all fact types describe properties. We are not just interested in 'thing plays role in actuality'; we are interested in 'thing1 plays role in relation to thing2', where the 'role' is considered to be a property of thing2. That is, in 'George was born on 22 February 1732', '22 Feb 1732' plays the *role* "birthdate", but "birthdate" is a *property* of the *person* 'George'. The role has a *range* (date); the property has an *owner* (person). And you often need to know what kind of thing the owner is in order to correctly identify the property concept that is intended. For example, "ceiling" denotes a property of a room and a property of an aircraft, but they are very different concepts. So "property"/"attribute" signifiers are usually dependent on a context concept -- the kind of thing that has the property. A different (usually the other) role in the fact type characterizes the thing that possesses the property. And in SBVR, the "range" of that "owner" role is the type of the possessor -- the context for the interpretation of the property signifier. This is the concept that I intended, and I'm pretty sure this is the one Don intended. It may well be different from what Ron has in mind. Ronald G. Ross wrote: Don, I don't think we're talking about the same concept. * I defined fact type role designation as "designation for a role in a fact type". "designation for a role in a fact type" is a useful business concept, although I would have said it is only useful in the sense "designation for a role in an actuality" -- the situations that are instances of the fact type. But "designation for a property of a thing" is a narrower concept, and it is also useful. Not every fact involving a thing is a property of the thing, but every property of a thing is expressible as a fact about the thing. Here we are concerned with "properties of things", not arbitrary facts about the thing. So we are concerned about a specific kind of fact type role, not an arbitrary fact type role. Further, roles are always relative to something. Fact type roles are relative to specific actualities. Situational roles are relative to "situations" -- more general collections of actualities. A "property" is always relative to a specific thing. (Yes, that relationship is an actuality, but the concept is the relationship to the thing,) Let's look at the example concept: George's birthdate. 'birthdate' is indeed a designation for a role in a fact type. It refers to the role of 'date' in 'person was born on 'date'. But what do we mean by "George's birthdate"? We mean the property of the person (George) that is conveyed by that fact type. The other fact type role -- 'person' -- is not a property of the date. The corresponding business concept there is merely "role in actuality". Similarly, consider: 'Keri goes to the market. Keri buys bananas.' In those two fact types, 'person goes to place' and 'person buys goods', the 'place' and the 'goods' are not properties of Keri; they are just designations for roles in fact types. One might argue that the market sees Keri as a "customer", or as the "buyer" of bananas, but those are different business views that are assigning a "property" concept to the 'person' role, where the owner concept is the market or the product (bananas). * You defined it as "designation that is recognizable as representing a fact type role in a context of being attributed to instances of another role of the same fact type". I agree that is a strange statement of the intent, but it is no worse than many of the other circumlocutions in SBVR, several of which are in clause 11. The point of Don's definition is that it does not refer to arbitrary fact type roles -- it refers to roles that designate attributes of ("being attributed to") instances of another role. Perhaps your concept is needed, I don't know. But since I couldn't begin to explain it to any business analyst or business person, it doesn't belong in Clause 11. I think the concept Don is trying to define IS a useful business concept. The problem is only that a business person probably cannot make sense of that definition. The business concept is "designation for a property of a specific thing". In SBVR, that designation takes the form that Don describes -- a designation for one role in a fact type in which the specific thing plays a different role. Seems to me we're making a simple thing really hard. Nothing more complicated than the concept I defined above is needed for Clause 11. I disagree. I think Ron is making the problem simpler than it is. Vocabularies really do need a concept of "attribute" or "property" designation. And since "fact type role designation" is virtually the same as "designation for a role in a fact type" maybe we just don't need it at all. Well, I can agree with that. It is possible that Don and I are reading into 'fact type role designation' a useful business vocabularies concept that was never intended to be part of SBVR. -Ed Ron At 03:29 PM 10/4/2010, Don Baisley wrote: I recommend the following resolution. The concept is not defined in terms of placeholders because it is independent of the use of fact type forms. It makes no reference to attributive namespace, but by definition it is based on the same notion. This can stay in clause 11. fact type role designation Definition: designation that is recognizable as representing a fact type role in a context of being attributed to instances of another role of the same fact type Necessity: No fact type role designation is a placeholder Note: A fact type role designation typically combines the senses of both a noun and a verb, as in the examples below. Example: the fact type role designation buyerused in the phrase, the buyer of a product, to refer to the _person_role in _person_ buys _product_(a.k.a. _product_ has _buyer_). Example: the fact type role designation birthdateused in the phrase, the persons birthdate, to refer to the _date_role in _person_ is born on _date_(a.k.a. _person_ has _birthdate_). Enjoy, Don *From:* keri [ mailto:keri_ah@mac.com] *Sent:* Monday, October 04, 2010 12:58 PM *To:* Ed Barkmeyer; SBVR RTF *Subject:* Re: issue 15450 -- SBVR RTF issue - Resolution Ed, I was trying to work up something along the lines of what you've now written up -- 2 examples with some questions about the involved concepts. (Attached). (The intent was that these could be the basis of a discussion Friday.) You will see that I have used your "concept1 specializes concept2" as the example in the second file. And, yes, as I was writing this up I was musing about whether "placeholder uses designation" was a red herring in understanding 'fact type role designation'. Problem is, I'm still fuzzy on how this can be explained, in business-facing terms (which, up to now, has not needed to dip into "attributive namespace"-speak). My brain churns when I hear you say, "Its relationship to a fact type role is that it refers to the things that play that role relative to a given player of some other role in a given fact type." Huh?!? And a business person would use this how/when??? If this concept is useful, in a Clause 11 sense, then why is it not used (or illustrated) anywhere, except perhaps in H.3.2 ... assuming that there is agreement that "fact type role designation" is what is being illustrated there, as the designation written on the line outside the 'box'. Bottom line, if an understanding of this concept needs to draw on an understanding of "attributive namespace" then I propose this entry be moved into 8.3.5 ("Namespaces"). Keri (2 attachments) On 10/4/10 12:05 PM, "Ed Barkmeyer" > wrote: I agree with Mark that the proposed resolution is confused. First, the intent of 'placeholder uses designation' was that the placeholder is or includes the signifier for the noun concept that is the range of the role. Example: In 'concept1 specializes concept2', the placeholder 'concept1' uses the designation 'concept', to signify the range of the role designated by 'concept1'. So I believe that 'placeholder uses designation' is completely irrelevant to the clause 11 term 'fact type role designation'. Second, as I posted before, 'fact type role designation' is intended to refer to the designations that appear in an 'attribute namespace', and might be better called 'attribute designations'. It is a term for things that have a particular relationship to another thing. That relationship is conveyed by some fact type, and the term itself is contained within some synonymous form of the fact type designation itself. Don Baisley and I disagree about almost every aspect of this, except one: The designation has to do with roles, but it has nothing whatever to do with placeholders. The example was: 'person /buys/ product'. It has the derived forms 'person /is the buyer of /product' and 'product /has buyer/ person', in which 'buyer' denotes, relative to a given product, the person who buys that product. Thus 'buyer' belongs to the attributive namespace for 'product'. 'Buyer' is not a placeholder in any of those fact types, ever, broken Structured English markup conventions notwithstanding. In both cases of its appearance, it is part of the verb designation. 'buyer of product' is what SBVR calls the 'noun form of the fact type'. > Less the 'of product', it is the term in the attribute namespace of 'product'. The whole idea of an attribute namespace is that each term in it has the implicit 'of ' form in actual use. The noun form 'the buyer of the product' is actually an abbreviation of the restricted noun concept 'person that /is the buyer of/ the product', which is the basis for its expression in formal logic, in SBVR logical representation, and in database transactions. The concept 'fact type role designation' in clause 11 is a very useful concept. Its relationship to a fact type role is that it refers to the things that play that role relative to a given player of some other role in a given fact type. But there is no predictable relationship between the signifier of the 'fact type role designations' and the placeholder expressions in any fact type form. (I am reminded of the Wizard of Oz pulling out the heart trophy and saying it was awarded to "phila.. um > philoth... um... good-deed-doers".) Don't be misled by the SBVR choice of Structured English conventions. -Ed Mark H Linehan wrote: I disagree with the conclusion (cited below) that "fact type role designation" is not just a role of "designation". I looked again at the proposed resolution, and I considered the the first example under "fact type form" in clause 8.3.4., which reads "customer rents car". The discussion of the example says that "One placeholder uses the designation customer..." Doesn't this simple example violate the proposed Necessity that "No _fact type role designation_ /is/ a _placeholder_." , since "customer" is the placeholder and (applying the text of the example to the proposed resolution), "customer" must also be the "_designation_ /of/ (the) _fact type role_ that /is used by/ (the) _placeholder_ that /represents/(the) _fact type role_"? I don't understand what the first proposed Note means. "Note: A fact type role designation is recognizable as representing a fact type role in a context of being attributed to instances of another role of the same fact type." What does it mean to be "... attributed to instances of another role ..."? Fact type roles and fact type forms are about representations of fact types, not about instances of roles of fact types. I also don't understand the second proposed Note "Note: A fact type role designation typically combines the senses of both a noun and a verb, as in the examples below.". None of the proposed example fact type role designations have the sense of a verb. One does not "buyer" or "birthdate" or "lowest cash rental" something. In the three examples given, it is not clear how the phrases given relate to the fact type forms that are given. Are these Synonymous Forms? -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Inactive hide details for keri ---10/03/2010 06:18:22 PM---Responses below. An updated Resolution document is attached, improvkeri ---10/03/2010 06:18:22 PM---Responses below. An updated Resolution document is attached, improving the notes & examples, and pr From: keri > To: Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF > Date: 10/03/2010 06:18 PM Subject: Re: issue 15450 -- SBVR RTF issue - Resolution ------------------------------------------------------------------------ Responses below. An updated Resolution document is attached, improving the notes & examples, and providing a reference to an Annex section. ~ Keri On 9/27/10 10:47 AM, "Mark H Linehan" > wrote: Ah, I completely missed the existing "placeholder uses designation". I suggest that other readers are likely to also miss it. So I suggest: 1) Making "fact type role designation" a role of "designation". I too thought it should be a 'role' (rather than a category) but that was rejected during the meeting. 2) Changing "placeholder uses designation" to instead be "placeholder uses fact type role designation". That could be done, if this entry was in the vocabulary that introduces "placeholder uses designation" but as things stand, it can't. 3) Moving the "fact type role designation" glossary entry next to "placeholder uses designation/fact type role designation" in clause 8.3.4. Or moving the latter after the former in clause 11.2.1.2. If it is agreed to move this up into 8 I can reflect that in this write-up. Could the fact type be moved to 11? I understood that it was needed in the earlier vocabularies. ~ Keri I think that this solution will be much clearer than the proposed resolution. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com From: keri > To: Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF > Date: 09/25/2010 04:44 PM Subject: Re: issue 15450 -- SBVR RTF issue - Resolution ------------------------------------------------------------------------ On 9/24/10 11:43 AM, "Mark H Linehan" > wrote: I still find this confusing. 1. The definition of "placeholder" is "designation /of /a fact type role within a fact type form marking a place where, in uses of the fact type form, an expression denotes what fills the fact type role ". Substituting this into the word "placeholder" in the proposed definition of "fact type role designation" reading "_designation_ /of/ a _fact type role_ that /is used by/ a _placeholder_ that /represents/ that _fact type role_", I get "_designation_ /of/ a _fact type role_ that /is used by/ a designation /of /a fact type role within a fact type form marking a place where, in uses of the fact type form, an expression denotes what fills the fact type role that /represents/ that _fact type role_". That's unreadable and nonsensical. I would imagine that substituting any of our more wordy definitions for its term would increase confusion rather than simplify. 2. We do not have a fact type "placeholder uses designation" as referenced in the proposed Note. It's on p. 33-34. 3. Are there any other cases where a placeholder and a fact type role designation for the same fact type role are distinct? Other than the case where a placeholder does not use a designation? If so, they should be added as examples. If not, then the case where a fact type form has no designation for some role should simply be acknowledged with a Possibility statement, perhaps on "fact type form has placeholder". Take a look at the Examples above, in particular the third one. Does that give you the additional illustration you are looking for? 4. I think we are missing a fact type that relates "fact type role designation" to "fact type". Perhaps "fact type form has fact type role designation". Or maybe the relationship is between placeholders and fact type role designations. Either way, defining this relationship will help explain what this mysterious "fact type role designation" really is. We should have enough connections to reflect what's needed. They just are not conveniently pulled together in one Figure in the SBVR publication. Here are some of them. ~ Keri [attachment "Issue15450-RESOLUTION v2.doc" deleted by Mark H Linehan/Watson/IBM] -- 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." -- 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." X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010050121 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-05_06:2010-10-05,2010-10-05,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 05 Oct 2010 11:00:15 -0700 Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 From: keri To: "Ronald G. Ross" , SBVR RTF Thread-topic: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 Thread-index: ActktymaaB9z3NCqEd+qzAARJM+Cgg== On 10/4/10 10:31 AM, "Ronald G. Ross" wrote: ... For example, "is-role-of fact type" has no natural business-facing signifier (as per Don, "rollification"?!?) and should be discarded. At 06:12 PM 10/4/2010, keri wrote: I would not like to see this dropped ... it still needs to be accounted for. How about "role-playing" ("roll-playing fact")? On 10/4/10 5:41 PM, "Ronald G. Ross" wrote: Are you suggesting the concept is a fact, not a fact type? If so that's new. No, not new. is-role-of has always been part of the set of connection types that we've been attempting to sort out. When you specify a role, you must indicate what concept it is a role of. It's intrinsic to the meaning. You have no choice. So why would a business person or business analyst need a term to talk about the *connection* of a role to the concept it is a role of? That forces people unnecessarily to cross a mental meta-level. It's the same rationale as for categorization and classification. And SBVR does illustrate/discuss the use of this kind of connection (in the EU-Rent Annex, and elsewhere). In any case, at issue here is one of the general principles for refactoring Clause 11.1.5. The only reasonable basis for deciding what's in and what's out of this section is to work *back* from terms that already exist in the real world (e.g., classification, categorization, characterization, association) ...perhaps making allowances for ISO (composition?). If there's not already a natural term for it, that's a good indication for 11.1.5 that no special term is needed. It doesn't mean the concept doesn't exist in SBVR; it just means there's no special name for it. We're just going to get into trouble otherwise (which is one reason this section has been so problematic). This then would change the orientation of 11.1.5, which was (originally) intended to present a categorization scheme for the various kinds of elements used in fact modeling. For example, here is a model diagram from Annex E, annotated with 6 of the kinds of connections it uses (is-facet-of and characteristic are not shown in this example but are also categories covered by the scheme). The "reasonable basis" for inclusion in 11.1.5 was that it was a kind of connection that was useful in fact modeling. Of course not all practitioners will necessarily use all categories, but the full set of categories needs to be laid out for those whose practice does. In particular, SBVR covers the use of "is-role-of" in the Annexes. If that concept is not presented in 11.1.5, where would it be introduced? Keri X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010050126 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-05_06:2010-10-05,2010-10-05,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 05 Oct 2010 11:22:21 -0700 Subject: RE: issue 13716 - Refactoring of Clause 11.1.5 From: keri To: "Ronald G. Ross" , SBVR RTF Thread-topic: issue 13716 - Refactoring of Clause 11.1.5 Thread-index: Actkuj/2fouE5dCtEd+qzAARJM+Cgg== Ron, The scheme used to include "characteristic" (unary fact type/verb concept) as a category of "verb concept" ... Your sketch shows a box for "characterization", which is not under "verb concept". Is "characterization" a new concept, or is it an attempt to redefine/reallocate "characteristic"? (Ref. annotated sketch, below.) - Keri From: Don Baisley To: keri , "Ronald G. Ross" , SBVR RTF Subject: RE: issue 13716 - Refactoring of Clause 11.1.5 Thread-Topic: issue 13716 - Refactoring of Clause 11.1.5 Thread-Index: AQHLZLr3sZ7n9Id95UCDMpyiYQuHQJMyrRXQ Date: Tue, 5 Oct 2010 18:47:41 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.78] .Categorization., .classification. and .characterization. would fall under .proposition. (or under .fact. if taken to be true). Introducing .property. into SBVR is interesting. I hope we don.t invent a new idea of .property.. I hope we take the notion from physics and not the one from computer programming. I don.t see how .property. specializes .association. in either case. Examples of properties: Some properties of a particular rental car: red three years old uses gasoline The abstractions of these properties are characteristics (per the definition of .characteristic. adopted from ISO). The characteristics are of different types (.characteristic types.) which could be called color, age and fuel type. Note that being three years old is the property illustrated in the example, not the fact type role .age. and not the fact type .car has age.. We need to keep our metalevels clear. Enjoy, Don From: keri [mailto:keri_ah@mac.com] Sent: Tuesday, October 05, 2010 11:22 AM To: Ronald G. Ross; SBVR RTF Subject: RE: issue 13716 - Refactoring of Clause 11.1.5 Ron, The scheme used to include "characteristic" (unary fact type/verb concept) as a category of "verb concept" ... Your sketch shows a box for "characterization", which is not under "verb concept". Is "characterization" a new concept, or is it an attempt to redefine/reallocate "characteristic"? (Ref. annotated sketch, below.) - Keri Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 From: keri Date: Tue, 05 Oct 2010 12:06:55 -0700 Cc: "Ronald G. Ross" , SBVR RTF To: Don Baisley X-Mailer: Apple Mail (2.1081) Okay, so I hear you say these are two different notions -- characterization & characteristic. In that case, "characteristic" (unary fact type) needs to be shown as a category under fact type (verb concept) in the sketch ... unless unary fact type has been removed from SBVR and I missed it. Thanks. Keri On Oct 5, 2010, at 11:47 AM, Don Baisley wrote: .Categorization., .classification. and .characterization. would fall under .proposition. (or under .fact. if taken to be true). Introducing .property. into SBVR is interesting. I hope we don.t invent a new idea of .property.. I hope we take the notion from physics and not the one from computer programming. I don.t see how .property. specializes .association. in either case. Examples of properties: Some properties of a particular rental car: red three years old uses gasoline The abstractions of these properties are characteristics (per the definition of .characteristic. adopted from ISO). The characteristics are of different types (.characteristic types.) which could be called color, age and fuel type. Note that being three years old is the property illustrated in the example, not the fact type role .age. and not the fact type .car has age.. We need to keep our metalevels clear. Enjoy, Don From: keri [mailto:keri_ah@mac.com] Sent: Tuesday, October 05, 2010 11:22 AM To: Ronald G. Ross; SBVR RTF Subject: RE: issue 13716 - Refactoring of Clause 11.1.5 Ron, The scheme used to include "characteristic" (unary fact type/verb concept) as a category of "verb concept" ... Your sketch shows a box for "characterization", which is not under "verb concept". Is "characterization" a new concept, or is it an attempt to redefine/reallocate "characteristic"? (Ref. annotated sketch, below.) - Keri X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: exq5KLoVM1n7nnhQ0ohA7iOJZAru8iAZnHJxL4P_Drg3OVy zw90kAAmjfKOhiovHqBr_aUM5BBBY33PurogAZ33RkaU7XKy6JO6_WbfalMU AO9A8LO8aB0x5uw0l28YSPr3z.YGU4aKPam5YhSPDjg1J41z5xR_b9YTj5jy 6wU3lzPMhfP2Fh0R7VSKfJUbXL.APZeOJx5uol4lR4rFZJUvIEPZjeBKrXrP AbPudBoPnqecFm2NElaMhtNGhlZEMEA-- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 05 Oct 2010 17:55:53 -0500 To: keri , SBVR RTF From: "Ronald G. Ross" Subject: [off-line] RE: issue 13716 - Refactoring of Clause 11.1.5 At 01:22 PM 10/5/2010, keri wrote: Ron, The scheme used to include "characteristic" (unary fact type/verb concept) as a category of "verb concept" ... Your sketch shows a box for "characterization", which is not under "verb concept". Is "characterization" a new concept, Yes. See circulated write-up. Definition: fact that a given concept incorporates a given concept. This notion has been discussed and seems pretty well accepted. (Certainly wasn't any priority for me.) or is it an attempt to redefine/reallocate "characteristic"? No. (Ref. annotated sketch, below.) - Keri From: Don Baisley To: "Ronald G. Ross" , keri , SBVR RTF Subject: RE: [off-line] RE: issue 13716 - Refactoring of Clause 11.1.5 Thread-Topic: [off-line] RE: issue 13716 - Refactoring of Clause 11.1.5 Thread-Index: AQHLZLr3sZ7n9Id95UCDMpyiYQuHQJMzbM+A//+L/OA= Date: Tue, 5 Oct 2010 23:02:23 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Correction to Ron.s definition of .characterization.: fact that a given concept incorporates a given characteristic Don From: Ronald G. Ross [mailto:rross@BRSolutions.com] Sent: Tuesday, October 05, 2010 3:56 PM To: keri; SBVR RTF Subject: [off-line] RE: issue 13716 - Refactoring of Clause 11.1.5 At 01:22 PM 10/5/2010, keri wrote: Ron, The scheme used to include "characteristic" (unary fact type/verb concept) as a category of "verb concept" ... Your sketch shows a box for "characterization", which is not under "verb concept". Is "characterization" a new concept, Yes. See circulated write-up. Definition: fact that a given concept incorporates a given concept. This notion has been discussed and seems pretty well accepted. (Certainly wasn't any priority for me.) or is it an attempt to redefine/reallocate "characteristic"? No. (Ref. annotated sketch, below.) - Keri X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010060024 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-06_04:2010-10-06,2010-10-06,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 06 Oct 2010 03:30:46 -0700 Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 From: keri To: "Ronald G. Ross" , SBVR RTF Thread-topic: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 Thread-index: ActlQYk9x5EZdNE0Ed+btgARJM+Cgg== On 10/5/10 3:09 PM, "Ronald G. Ross" wrote: I ask, can SBVR 'understand' if someone says "is role of"? I believe it can ... if not, we're in big trouble. SBVR "understands" ranges over but there is nothing that supports an understanding of "is role of", which is why it is here (in 11.1.5). - Keri X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: 69RMtvcVM1mdbU3ExpctxhDxY6UdxxCxm4Yv0XZMLILNl5D e9olQeT.AukSu9Gy0fNUAQREsi5kc9gnHu0QaE7qHgvWNMDPLLBtxkPIrQet 9PuJf7zp0TpQyT2.21EvU0FUGv.csnFLC3Hn3qAOLPpqP9waffSLKYLcG4PX zSApx3fz89FoHFxEGTw2Dms6bSzOXF4ncvjVxuyKEO1CvJN628nikVrAjZDW w0yTenQWBviICgEcw.6jmtHIe3Zx7boxs6XJYBHBynco- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Oct 2010 10:47:08 -0500 To: keri , SBVR RTF From: "Ronald G. Ross" Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 At 05:30 AM 10/6/2010, keri wrote: On 10/5/10 3:09 PM, "Ronald G. Ross" wrote: I ask, can SBVR 'understand' if someone says "is role of"? I believe it can ... if not, we're in big trouble. SBVR "understands" ranges over but there is nothing that supports an understanding of "is role of", which is why it is here (in 11.1.5). This is worth testing. It's a key point and perhaps I am wrong (patience please). Let's take an example (from SBVR): signifier Definition: expression that is a linguistic unit or pattern, such as a succession of speech sounds, written symbols or gestures, used in a designation of a concept Concept Type: role * SBVR can certainly digest that, right? * This could be expressed as the fact: The role "signifier" ranges over expression. ...right? * It could also be expressed: "Signifier" is a role that ranges over expression. ... right? * SBVR can understand that prepositions represent fact types, right? ... right? * So SBVR could understand the fact: "Signifier is a role of expression." ... right? Is it too big a leap to say that SBVR can spot 'is role of'' facts?? ~~~~~ Note: I've looked back through the document trail, but I am having a little trouble finding "is-role-of" treated as a fact(?). I found something where it is treated as a fact type: Definition: the verb concept 'role ranges over general concept' or any verb concept that specializes it Is that the latest? Ron - Keri Date: Wed, 06 Oct 2010 12:28:59 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: keri CC: SBVR RTF Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: o96GT4lp019698 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1286987347.08328@LAzApwwugVpW0w6XkT0egA X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov keri wrote: On 10/5/10 3:09 PM, "Ronald G. Ross" wrote: I ask, can SBVR 'understand' if someone says "is role of"? I believe it can ... if not, we're in big trouble. SBVR "understands" /ranges over /but there is nothing that supports an /understanding /of "is role of", which is why it is here (in 11.1.5). Hmm. That suggests we need a synonymous form for (role) ranges over (concept), to wit: (role) is role of (concept) Example fact: 'teacher' is role of 'person' But I don't think that is the verb concept that is intended. The fact type that is intended is rather: (role) is played by (thing) Example fact: "Don Baisley" is a project manager. SBVR currently supports that with: (thing) is instance of (concept), because it is not clear that 'project manager' isn't an object type. No situation is identified. We have to add the knowledge that 'project manager' is a situational role, but then the above sentence is half of a meaningful fact. The situation is not identified. The definition of is-role-of fact type suggests that the intended fact type form is: (thing) plays (role) in (situation). Example fact: "Miss Jones" is a teacher at MLKing High School. And I agree with Keri that that fact type does not appear in SBVR. -Ed - Keri -- 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." X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: dtcdanIVM1nzurZTKhwdwPkSIDiDsaUuNj9hgVo3mUUc84V VMNpkF6rtmP.VlEwxJNdIO2OZaZuW.jcionKctBGmqXY5YJOo5Y32gp8DZ6M M13YlIpvHwMrzWjzC0VJujpY1gaAZ8a0SgFhiTy9rsFLcpk0AjPp.nsYn8Ff fdArl7wk0fYe.uOfrA5ZPIapIQaWUeMXw7kyS6lRXB.F1LfPeWyAynXsu4Zv vwZ4w7zhoELg26TAQW1ZOaOf3ljBzbugTb31G9rgqLZLDTjaiKR53bK.6N6w ar7N70B..XDY- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Oct 2010 12:04:14 -0500 To: edbark@nist.gov, keri From: "Ronald G. Ross" Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 Cc: SBVR RTF At 11:28 AM 10/6/2010, Ed Barkmeyer wrote: keri wrote: On 10/5/10 3:09 PM, "Ronald G. Ross" wrote: I ask, can SBVR 'understand' if someone says "is role of"? I believe it can ... if not, we're in big trouble. SBVR "understands" /ranges over /but there is nothing that supports an /understanding /of "is role of", which is why it is here (in 11.1.5). Hmm. That suggests we need a synonymous form for (role) ranges over (concept), to wit: (role) is role of (concept) Example fact: 'teacher' is role of 'person' But I don't think that is the verb concept that is intended. Yes, I believe that *was* the concept intended for 11.1.5. The fact type that is intended is rather: (role) is played by (thing) Example fact: "Don Baisley" is a project manager. SBVR currently supports that with: (thing) is instance of (concept), because it is not clear that 'project manager' isn't an object type. No situation is identified. We have to add the knowledge that 'project manager' is a situational role, but then the above sentence is half of a meaningful fact. The situation is not identified. The definition of is-role-of fact type suggests that the intended fact type form is: (thing) plays (role) in (situation). Example fact: "Miss Jones" is a teacher at MLKing High School. No, I don't believe that's what was intended for 11.1.5. I'm pretty sure about it. Keri? Agree? Ron And I agree with Keri that that fact type does not appear in SBVR. -Ed - Keri -- 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: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 2010-10-06-2007 Date: Wed, 6 Oct 2010 20:06:00 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 2010-10-06-2007 thread-index: ActleLgW8Ui4GTVOSzCkFGuvHxAPLwAB7TFE From: "Sjir Nijssen" To: "Ronald G. Ross" , , "keri" Cc: "SBVR RTF" -------------------------------------------------------------------------------- From: Ronald G. Ross [mailto:rross@BRSolutions.com] Sent: Wed 10/6/2010 7:04 PM To: edbark@nist.gov; keri Cc: SBVR RTF Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 At 11:28 AM 10/6/2010, Ed Barkmeyer wrote: >keri wrote: >>On 10/5/10 3:09 PM, "Ronald G. Ross" wrote: >> >> I ask, can SBVR 'understand' if someone says "is role of"? I >> believe it can ... if not, we're in big trouble. >> >>SBVR "understands" /ranges over /but there is nothing that supports >>an /understanding /of "is role of", which is why it is here (in 11.1.5). > >Hmm. That suggests we need a synonymous form for (role) ranges over >(concept), to wit: > (role) is role of (concept) >Example fact: 'teacher' is role of 'person' [[Sjir: to increase precision: this is not a ground fact but part of a verbalization of a domain specific conceptual schema. ]] > >But I don't think that is the verb concept that is intended. Yes, I believe that *was* the concept intended for 11.1.5. > The fact type that is intended is rather: > (role) is played by (thing) >Example fact: "Don Baisley" is a project manager. [[Sjir: this is an example of a ground fact; may I propose to qualify the three kind of facts as 1. Ground facts 2. Domain specific schema fact 3. Generic schema fact. I am convinced that the systematic use of this distinction will increase the quality of the SBVR spec.]] >SBVR currently supports that with: (thing) is instance of (concept), >because it is not clear that 'project manager' isn't an object >type. No situation is identified. We have to add the knowledge >that 'project manager' is a situational role, but then the above >sentence is half of a meaningful fact. The situation is not identified. > >The definition of is-role-of fact type suggests that the intended >fact type form is: (thing) plays (role) in (situation). >Example fact: "Miss Jones" is a teacher at MLKing High School. No, I don't believe that's what was intended for 11.1.5. I'm pretty sure about it. Keri? Agree? Ron >And I agree with Keri that that fact type does not appear in SBVR. > >-Ed > >> >>- Keri > >-- >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." > X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010060123 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-06_10:2010-10-06,2010-10-06,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 06 Oct 2010 12:30:55 -0700 Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 From: keri To: Ed Barkmeyer Cc: SBVR RTF Thread-topic: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 Thread-index: ActljP6CPR+J0tGAEd+TwAARJM+Cgg== Ed, I'll start with yours, and then move back to Ron's.... On 10/6/10 9:28 AM, "Ed Barkmeyer" wrote: > keri wrote: >> On 10/5/10 3:09 PM, "Ronald G. Ross" wrote: >> >> I ask, can SBVR 'understand' if someone says "is role of"? I >> believe it can ... if not, we're in big trouble. >> >> SBVR "understands" /ranges over /but there is nothing that supports an >> /understanding /of "is role of", which is why it is here (in 11.1.5). > > Hmm. That suggests we need a synonymous form for (role) ranges over > (concept), to wit: > (role) is role of (concept) > Example fact: 'teacher' is role of 'person' Yes, that would help. Good suggestion. > But I don't think that is the verb concept that is intended. Actually, that is what is intended. I go back to what 11.1.5 is about -- presenting (and giving standard terms for) the various kinds of constructs that can appear in a fact model (or whatever we are calling that these days) -- be it a model diagram, like we see in the EU-Rent Annex, or a text vocabulary, such as the ones we compose with SBVR Structured English. More on this, in my reply to Ron. - Keri > The fact type that is intended is rather: > (role) is played by (thing) > Example fact: "Don Baisley" is a project manager. > SBVR currently supports that with: (thing) is instance of (concept), > because it is not clear that 'project manager' isn't an object type. No > situation is identified. We have to add the knowledge that 'project > manager' is a situational role, but then the above sentence is half of a > meaningful fact. The situation is not identified. > > The definition of is-role-of fact type suggests that the intended fact > type form is: > (thing) plays (role) in (situation). > Example fact: "Miss Jones" is a teacher at MLKing High School. > > And I agree with Keri that that fact type does not appear in SBVR. > > -Ed > >> >> - Keri X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010060124 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-06_10:2010-10-06,2010-10-06,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 06 Oct 2010 12:36:53 -0700 Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 From: keri To: "Ronald G. Ross" , SBVR RTF Thread-topic: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 Thread-index: ActljdPlEoxCBdGBEd+TwAARJM+Cgg== On 10/6/10 8:47 AM, "Ronald G. Ross" wrote: At 05:30 AM 10/6/2010, keri wrote: On 10/5/10 3:09 PM, "Ronald G. Ross" wrote: I ask, can SBVR 'understand' if someone says "is role of"? I believe it can ... if not, we're in big trouble. SBVR "understands" ranges over but there is nothing that supports an understanding of "is role of", which is why it is here (in 11.1.5). This is worth testing. It's a key point and perhaps I am wrong (patience please). Let's take an example (from SBVR): signifier Definition: expression that is a linguistic unit or pattern, such as a succession of speech sounds, written symbols or gestures, used in a designation of a concept Concept Type: role * SBVR can certainly digest that, right? * This could be expressed as the fact: The role "signifier" ranges over expression. ...right? * It could also be expressed: "Signifier" is a role that ranges over expression. ... right? * SBVR can understand that prepositions represent fact types, right? ... right? * So SBVR could understand the fact: "Signifier is a role of expression." ... right? I will leave the fine parsing of your example to experts (... but I did spot that your second bullet probably needs to be: The role 'signifier' ranges over the object type 'expression'). Is it too big a leap to say that SBVR can spot 'is role of'' facts?? Whether or not SBVR can (or not) through some intricate concept trace, figure this out is an interesting question. (There are some leaps you've made that I'm not grasping.) However, that tempting challenge/question is moving the issue off the mark. The point of the business-facing vocabularies is to give the humans some standardized vocabulary. Let me try this.... Back to my example diagram from EU-Rent... say that I am standing before a class and point to the kind of line labeled (F). What term do I use to refer to that when I teach people how to draw a diagram like that? (Or to write the various kinds of textual vocabulary entries.) I would like to say, "That is a _____." (or "That represents a _____." if I'm being more precise.) Now, if someone in my class goes to another class next week . one taught by Fred Jones down the street . and Fred terms that same notion something different, is that a problem? Can we ask a vendor, "How do you support these 8 or 9 kinds of connections in your tool?" Rather than saying "these" (and pointing), wouldn't it be nice to simply list them, using SBVR-defined terms so that we all understand that we are meaning the same thing? I appreciate that you don't have some of these categories in your practice and thus do not have a need to talk to your business folks using terms for these constructs . nor are you likely to hear people around you talking in such terms. But others on the team (and other users of SBVR) do, which is why these concepts are there in the first place. Consider, for example, is-facet-of ... I'm guessing that your users don't talk about facets (or the connections that implement them). But how about Markus' or John's users? Maybe they do talk in those terms. Where is "is facet of" going in your proposed re-orientation of 11.1.5? Is that also on the chopping block, simply because it doesn't have a gerund that you have heard business people uttering? ~~~~~ Note: I've looked back through the document trail, but I am having a little trouble finding "is-role-of" treated as a fact(?). (From memory, and a quick check through my files) our first pass (and the issue write-up) attempted to cast these as kinds of 'fact' (as in meta-model facts, not as in Ed's real world renditions sent this a.m.). IOW, we were still referring to the kinds of "lines" shown on diagrams (like the one above . or kinds of vocabulary entries) but as uses of a particular SBVR fact type to depict things like categories, roles, etc. That proved confusing (and troublesome for the taxonomy) because now were were bringing together, into one scheme, both fact types and ("metamodel") facts. This was in early 2009. Eventually, Ed (I believe) pointed out that what we really had here was still a mix of all fact types, except that some were single, SBVR-defined fact types (like concept specializes concept) and that the "lines" on the model were uses of those fact types. That gave birth to the attempt to cast these all as fact types (which made it easier for the scheme), and to define them in terms of the SBVR (what I call) "built-ins". That is the approach we were pursuing when I turned this over to you in May (when I headed out of the country). Except for a pesky problem with "fact type" (in Clause 8), which was largely to do with lack of a convenience document at the time, we were close.... I found something where it is treated as a fact type: Definition: the verb concept 'role ranges over general concept' or any verb concept that specializes it Is that the latest? Yes. The last Resolution write-up was a file named "SBVR Issue 13716 (v7C).doc" - Keri X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: lYmruCAVM1nGEwWo8AIdOpVQhKwtXNy5mzgIxkRYpDjxB3H hmBuSpcAiVqHO.m0p5BeM7AlgXSe_gfGh6eyZ.uPU0wEBrOrSg9hB4s1eeEM w1_01IqmBTQz58kAXZaWvQPGHwE7rwBbvmQ4aJn_a4l52HPutbv_l3mSvppf lx2_GKJMTY1q.ZCTtqYPOl3PcGJJf8IaO38uOS2UOlpCCSIGxpWjz60v5gOI sz36Xrqb6LZ4Dd8ppUUVwyP4UQqk.kt_O8.i3v9OwTZlChse2rc1mPx0wb6r lC8m0MNHawA-- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Oct 2010 14:59:27 -0500 To: keri , Ed Barkmeyer From: "Ronald G. Ross" Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 Cc: SBVR RTF Comment like this. At 02:30 PM 10/6/2010, keri wrote: Ed, I'll start with yours, and then move back to Ron's.... On 10/6/10 9:28 AM, "Ed Barkmeyer" wrote: > keri wrote: >> On 10/5/10 3:09 PM, "Ronald G. Ross" wrote: >> >> I ask, can SBVR 'understand' if someone says "is role of"? I >> believe it can ... if not, we're in big trouble. >> >> SBVR "understands" /ranges over /but there is nothing that supports an >> /understanding /of "is role of", which is why it is here (in 11.1.5). > > Hmm. That suggests we need a synonymous form for (role) ranges over > (concept), to wit: > (role) is role of (concept) > Example fact: 'teacher' is role of 'person' Yes, that would help. Good suggestion. > But I don't think that is the verb concept that is intended. Actually, that is what is intended. If this flies, let's adopt this quickly as the solution and everyone will be happy. No hyphens (business people don't speak in hyphens). No wonky definition to confuse things. Then let's solve "is-property-of", which we're working on. Then fix or preferably eliminate "is-facet-of" (not "facet", just "is-facet-of"). We must reduce the complexity of 11.1.5. Ron I go back to what 11.1.5 is about -- presenting (and giving standard terms for) the various kinds of constructs that can appear in a fact model (or whatever we are calling that these days) -- be it a model diagram, like we see in the EU-Rent Annex, or a text vocabulary, such as the ones we compose with SBVR Structured English. More on this, in my reply to Ron. - Keri > The fact type that is intended is rather: > (role) is played by (thing) > Example fact: "Don Baisley" is a project manager. > SBVR currently supports that with: (thing) is instance of (concept), > because it is not clear that 'project manager' isn't an object type. No > situation is identified. We have to add the knowledge that 'project > manager' is a situational role, but then the above sentence is half of a > meaningful fact. The situation is not identified. > > The definition of is-role-of fact type suggests that the intended fact > type form is: > (thing) plays (role) in (situation). > Example fact: "Miss Jones" is a teacher at MLKing High School. > > And I agree with Keri that that fact type does not appear in SBVR. > > -Ed > >> >> - Keri X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: AI91RZUVM1liIujWpU.5hg9cxLQiYKjWga_MgBheoZ9HgNw lgfzZSpeB1FVtMwChFBL22NNJj_emGzMbMQdc6GLOfpvc0Fog635KXvD0pL5 jtkwETR0Rx5OsghD3lWyZ8.iehAySGgTl6OqtYBEefoj5sG9EE1J6guo6cx9 W6UXnIS_9_h3aH2AU5ZlQdaTGLUsAGScITwKQgAHuuMMSkITtJuiub3.oIng 5N6YYYy3hpvTcZ8WYZfuz3FbzfmITCefOFPsQEqbbBWoPFB2yjT6Ljp7e88Q gxwtJRU1hgA-- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Oct 2010 15:16:43 -0500 To: keri , SBVR RTF From: "Ronald G. Ross" Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 At 02:36 PM 10/6/2010, keri wrote: On 10/6/10 8:47 AM, "Ronald G. Ross" wrote: At 05:30 AM 10/6/2010, keri wrote: On 10/5/10 3:09 PM, "Ronald G. Ross" wrote: I ask, can SBVR 'understand' if someone says "is role of"? I believe it can ... if not, we're in big trouble. SBVR "understands" ranges over but there is nothing that supports an understanding of "is role of", which is why it is here (in 11.1.5). This is worth testing. It's a key point and perhaps I am wrong (patience please). Let's take an example (from SBVR): signifier Definition: expression that is a linguistic unit or pattern, such as a succession of speech sounds, written symbols or gestures, used in a designation of a concept Concept Type: role * SBVR can certainly digest that, right? * This could be expressed as the fact: The role "signifier" ranges over expression. ...right? * It could also be expressed: "Signifier" is a role that ranges over expression. ... right? * SBVR can understand that prepositions represent fact types, right? ... right? * So SBVR could understand the fact: "Signifier is a role of expression." ... right? I will leave the fine parsing of your example to experts (... but I did spot that your second bullet probably needs to be: The role 'signifier' ranges over the object type 'expression'). Is it too big a leap to say that SBVR can spot 'is role of'' facts?? Whether or not SBVR can (or not) through some intricate concept trace, figure this out is an interesting question. (There are some leaps you've made that I'm not grasping.) However, that tempting challenge/question is moving the issue off the mark. The point of the business-facing vocabularies is to give the humans some standardized vocabulary. Let me try this.... Back to my example diagram from EU-Rent... say that I am standing before a class and point to the kind of line labeled (F). What term do I use to refer to that when I teach people how to draw a diagram like that? (Or to write the various kinds of textual vocabulary entries.) I would like to say, "That is a _____." (or "That represents a _____." if I'm being more precise.) Now, if someone in my class goes to another class next week one taught by Fred Jones down the street and Fred terms that same notion something different, is that a problem? Can we ask a vendor, "How do you support these 8 or 9 kinds of connections in your tool?" Rather than saying "these" (and pointing), wouldn't it be nice to simply list them, using SBVR-defined terms so that we all understand that we are meaning the same thing? [Let's see if Ed's suggestion in the other e-mail flies about "is role of". See other e-mail.] General comment re: above]: It's been made abundantly clear time and time again that 11.1.5 causes great angst. It's easy to point to as an area of great complexity. It replicates things SBVR already supports, just giving names to them. That's confusing (and is not explained since Clause 11 is text-less ... let's not get into that!). Some of these names are made up (e.g., "is-role-of") rather than natural. That's simply bad business-facing practice. I have been told so many times that it's up to Annexes, books and lectures to point out and explain capabilities I have nightmares about it. Bottom line: Unless we can use natural (or ISO or native SBVR) terms, and give crystal-clear meanings, the point-to-it-and-name-it capability you mention is not worth the cost in complexity. How long has it taken for *team* members to get it!? We (the original members of the BRG) should set the example here, so we can turn critically to other areas of SBVR and do the same. Ron I appreciate that you don't have some of these categories in your practice and thus do not have a need to talk to your business folks using terms for these constructs nor are you likely to hear people around you talking in such terms. But others on the team (and other users of SBVR) do, which is why these concepts are there in the first place. Consider, for example, is-facet-of ... I'm guessing that your users don't talk about facets (or the connections that implement them). But how about Markus' or John's users? Maybe they do talk in those terms. Where is "is facet of" going in your proposed re-orientation of 11.1.5? Is that also on the chopping block, simply because it doesn't have a gerund that you have heard business people uttering? ~~~~~ Note: I've looked back through the document trail, but I am having a little trouble finding "is-role-of" treated as a fact(?). (From memory, and a quick check through my files) our first pass (and the issue write-up) attempted to cast these as kinds of 'fact' (as in meta-model facts, not as in Ed's real world renditions sent this a.m.). IOW, we were still referring to the kinds of "lines" shown on diagrams (like the one above or kinds of vocabulary entries) but as uses of a particular SBVR fact type to depict things like categories, roles, etc. That proved confusing (and troublesome for the taxonomy) because now were were bringing together, into one scheme, both fact types and ("metamodel") facts. This was in early 2009. Eventually, Ed (I believe) pointed out that what we really had here was still a mix of all fact types, except that some were single, SBVR-defined fact types (like concept specializes concept) and that the "lines" on the model were uses of those fact types. That gave birth to the attempt to cast these all as fact types (which made it easier for the scheme), and to define them in terms of the SBVR (what I call) "built-ins". That is the approach we were pursuing when I turned this over to you in May (when I headed out of the country). Except for a pesky problem with "fact type" (in Clause 8), which was largely to do with lack of a convenience document at the time, we were close.... I found something where it is treated as a fact type: Definition: the verb concept 'role ranges over general concept' or any verb concept that specializes it Is that the latest? Yes. The last Resolution write-up was a file named "SBVR Issue 13716 (v7C).doc" - Keri Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 From: keri Date: Wed, 06 Oct 2010 13:35:25 -0700 Cc: SBVR RTF To: "Ronald G. Ross" X-Mailer: Apple Mail (2.1081) On Oct 6, 2010, at 1:16 PM, Ronald G. Ross wrote: Bottom line: Unless we can use natural (or ISO or native SBVR) terms, and give crystal-clear meanings, the point-to-it-and-name-it capability you mention is not worth the cost in complexity. How long has it taken for *team* members to get it!? We (the original members of the BRG) should set the example here, so we can turn critically to other areas of SBVR and do the same. I suggest that you submit a new issue to propose the work you envision. If you read what this issue is about, it is not about the things you have outlined. Actually, this calls into question whether it is even under the purview of an RTF to do a mass delete of an existing section (or a thinly-disguided rewrite of it, in order to turn it into something not originally intended). This issue was, basically, about improving the definitions of four entries, and rearranging the entries of this section into a better (more cohesive) order. Back in May we were very close to closure on that more modest scope. I recommend that we go back to that scope, clean up what we had, and wrap this up. If this issue has "set an example" of anything it is about how difficult it is to do work via email, over an extended period of time where things get picked up, set down, and picked up again days (or weeks, or months) later. - Keri X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: 5LS3ugUVM1nEWIRFCBgbtCwqRbNBPbrSdGLnb0zHTNGQ0LJ BVbURx0WRAQWxsw9gowpYTJvczR5gX4b_89GG1H4NvcJjlVnKdve5QJJtZok WGfmc1K_LYw3vDXYFY9HcwuzUiMBlHrNkpz1087GOjLRCzh.TNFyPzPHqWem Mljvjk94yx73fYmqOe7GmRtLBvMOX9Tfizd9rNHd2_uYK.FaO6b.SLXfSJeb NjnvBy1o6.w2vn2CH2.aXkx_KRCOq X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Oct 2010 15:51:21 -0500 To: keri From: "Ronald G. Ross" Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 Cc: SBVR RTF At 03:35 PM 10/6/2010, keri wrote: On Oct 6, 2010, at 1:16 PM, Ronald G. Ross wrote: Bottom line: Unless we can use natural (or ISO or native SBVR) terms, and give crystal-clear meanings, the point-to-it-and-name-it capability you mention is not worth the cost in complexity. How long has it taken for *team* members to get it!? We (the original members of the BRG) should set the example here, so we can turn critically to other areas of SBVR and do the same. I suggest that you submit a new issue to propose the work you envision. If you read what this issue is about, it is not about the things you have outlined. Actually, this calls into question whether it is even under the purview of an RTF to do a mass delete of an existing section (or a thinly-disguided rewrite of it, in order to turn it into something not originally intended). This issue was, basically, about improving the definitions of four entries, and rearranging the entries of this section into a better (more cohesive) order. Back in May we were very close to closure on that more modest scope. I beg to differ. The definitions from that point in time were incomprehensible. As a co-author of the issue, my judgement was that they were worse than what we had. In fact, *they* didn't address the issue as stated. That's what got this round started. I recommend that we go back to that scope, clean up what we had, and wrap this up. Obviously there is fundamental misunderstanding (or lack of understanding) about section 11.1.5. I recommend that we solve the basic problem. Can we stay focused on solutions? Ron If this issue has "set an example" of anything it is about how difficult it is to do work via email, over an extended period of time where things get picked up, set down, and picked up again days (or weeks, or months) later. - Keri X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010060138 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-06_11:2010-10-06,2010-10-06,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 06 Oct 2010 14:06:05 -0700 Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 From: keri To: "Ronald G. Ross" Cc: SBVR RTF Thread-topic: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 Thread-index: ActlmknviKNxkNGNEd+aHgARJM+Cgg== On 10/6/10 1:51 PM, "Ronald G. Ross" wrote: Obviously there is fundamental misunderstanding (or lack of understanding) about section 11.1.5. I recommend that we solve the basic problem. Can we stay focused on solutions? Yes. Now that we have a Convenience Document, I can clean up and distribute an updated Resolution write-up ... or I can mock up what a re-factored 11.1.5 would look like. Whichever the team feels would be more useful. - Keri X-Yahoo-Newman-Id: 413780.48869.bm@omp1044.mail.ne1.yahoo.com X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: AAXXQaIVM1nGqif3zr5DWgy3_flZcfOFBYryG5KMAwYM6up FUZ5_KHDGtvW.eCvg4vb6GQHdfkrVzrdJ.HCTUBvpikTA1fGD8F8bfqfVGGe lQG81dB7Rkps2u0wpkLR3qDHIIPI5oWwRBUgsNdqtCdpnyyaRvgYs_62S1s. LIgAFB_8I_Uwvemru2hr39OHDh_nGo8VVVsusMxYwnR6bNnEDcNDaj_nIUX. 1MAGsrsk29.1wUlFmQQugPeoqmCw0wV1Xx3Y3hzp9rslYkzkdtmPNhDnqZDr jQ7wxy_Ajlg-- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Oct 2010 22:58:17 -0500 To: keri From: "Ronald G. Ross" Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 Cc: SBVR RTF At 04:06 PM 10/6/2010, keri wrote: On 10/6/10 1:51 PM, "Ronald G. Ross" wrote: Obviously there is fundamental misunderstanding (or lack of understanding) about section 11.1.5. I recommend that we solve the basic problem. Can we stay focused on solutions? Yes. Now that we have a Convenience Document, I can clean up and distribute an updated Resolution write-up ... or I can mock up what a re-factored 11.1.5 would look like. Whichever the team feels would be more useful. Just for clarification, I distributed current working documents for these purposes the other day. See the message that said READ FIRST. Ron - Keri X-Yahoo-Newman-Id: 413780.48869.bm@omp1044.mail.ne1.yahoo.com X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: AAXXQaIVM1nGqif3zr5DWgy3_flZcfOFBYryG5KMAwYM6up FUZ5_KHDGtvW.eCvg4vb6GQHdfkrVzrdJ.HCTUBvpikTA1fGD8F8bfqfVGGe lQG81dB7Rkps2u0wpkLR3qDHIIPI5oWwRBUgsNdqtCdpnyyaRvgYs_62S1s. LIgAFB_8I_Uwvemru2hr39OHDh_nGo8VVVsusMxYwnR6bNnEDcNDaj_nIUX. 1MAGsrsk29.1wUlFmQQugPeoqmCw0wV1Xx3Y3hzp9rslYkzkdtmPNhDnqZDr jQ7wxy_Ajlg-- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 06 Oct 2010 22:58:17 -0500 To: keri From: "Ronald G. Ross" Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 Cc: SBVR RTF At 04:06 PM 10/6/2010, keri wrote: On 10/6/10 1:51 PM, "Ronald G. Ross" wrote: Obviously there is fundamental misunderstanding (or lack of understanding) about section 11.1.5. I recommend that we solve the basic problem. Can we stay focused on solutions? Yes. Now that we have a Convenience Document, I can clean up and distribute an updated Resolution write-up ... or I can mock up what a re-factored 11.1.5 would look like. Whichever the team feels would be more useful. Just for clarification, I distributed current working documents for these purposes the other day. See the message that said READ FIRST. Ron - Keri X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010070035 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-07_07:2010-10-07,2010-10-07,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 07 Oct 2010 04:10:58 -0700 Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 From: keri To: "Ronald G. Ross" , SBVR RTF Thread-topic: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 Thread-index: ActmEFFRj6xza9IDEd+4rQARJM+Cgg== On 10/6/10 8:58 PM, "Ronald G. Ross" wrote: At 04:06 PM 10/6/2010, keri wrote: On 10/6/10 1:51 PM, "Ronald G. Ross" wrote: Obviously there is fundamental misunderstanding (or lack of understanding) about section 11.1.5. I recommend that we solve the basic problem. Can we stay focused on solutions? Yes. Now that we have a Convenience Document, I can clean up and distribute an updated Resolution write-up ... or I can mock up what a re-factored 11.1.5 would look like. Whichever the team feels would be more useful. Just for clarification, I distributed current working documents for these purposes the other day. See the message that said READ FIRST. Right. That set included a file (that had "version 8" in its name). It contained some working notes for some of the proposed entries. The document I was offering is an updated draft of this Issue's Resolution write-up . something that communicates the scope of what is being proposed for addition vs. deletion vs. revision. When I responded to "stay focused on solutions" I was referring to bringing the scope back to match what the Issue statement outlined, namely: A number of the definitions in subsection 11.1.5 are incomprehensible, and not well integrated with the rest of the SBVR vocabulary. These definitions center on: assortment fact type, categorization fact type, is-role-of fact type, and is-facet-of fact type. Also, these concepts are defined as kinds of "fact types", but should actually be defined as kinds of *facts*. Finally, the order of the entries needs adjustment as a result of the above. IOW, fix these four entries and do some re-arranging. Somehow this issue has grown to take on all other sorts of grand causes. We need to pull things back in so that we can get to completion. - Keri Date: Thu, 07 Oct 2010 11:47:44 -0400 From: Edward Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Sjir Nijssen CC: SBVR RTF Subject: Re: "knowledge segregation" from [READ FIRST] Re: issue 13716 - Refactoring ... X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edward.barkmeyer@nist.gov Sjir raises a totally different issue: Categorization of facts from the viewpoint of segregating knowledge. I don't think clause 11 tries to do this at all, so I wouldn't know where to place this concept set. This is much closer to the MOF "metalevel" stuff: what is "metaschema" (M2), what is "conceptual schema" (M1), and what is "data" (M0). "metaschema" is conceptual schema for schemas -- the concepts that are part of the language in which the conceptual schemas are written. It represents the invariant linguistic and semantic knowledge of the modeling tool builders, the facts that they insist must be true of schemas. A metaschema is prescriptive. "conceptual schema" (aka "domain ontology") is the supposed invariant knowledge of the domain experts. The facts that they take to be _necessarily_ true. The intent of a conceptual schema is descriptive (of the domain), but it is prescriptive in that it provides all of the vocabulary that can be used in some set of statements of "data". [Terminology analysis: "conceptual schema" is a database word, "information model" is the 1985-2000 systems analysis word, "domain ontology" is the current vogue term. Each has a different concept of the kind of semantic formalism in the metaschema. That said, the 1984 ISO TR 8002 "The conceptual schema and the information base" (van Griethuysen, Nijssen, Steele, et al.) used the term "conceptual schema" with the intent of "information model" -- it described domain semantics, not database semantics. But the better known publications -- the ANSI 3-schema architecture and the ISO 10032 Reference Model for Data Management --.use "conceptual schema" to refer to the integrated master database schema."] "data" is the facts that represent local/current knowledge of the business persons acting in the domain. It is descriptive, and it is (technically) subject to change. Sjir suggests some terms for kinds of facts that relate the facts to the above categories. His "generic schema fact" is a "metaschema" fact. His "domain specific schema fact" is a "conceptual schema" fact. His "ground fact" is a "data" fact. I have a problem with the last term. Logicians and information analysts commonly use "ground fact" to refer to facts about individuals that are taken to be invariant knowledge. That is, the common interpretation of "ground fact" is a fact about individuals (rather than classes) that appears in the conceptual schema (or in the case of language elements, in the metaschema). The fact that "317 is an Integer" is a "ground fact" that is (usually implicitly) contained in the conceptual schema, and used in its semantic model. The fact that "ISO 639 is the reference registry for language identifiers" or that "DUNS is an instance of 'registry for business identifiers'" are common "ground facts" in conceptual schemas. I have to agree that the distinction between invariant facts about object types and invariant facts about individuals has no significant philosophical basis. The distinction is itself a vestige of the database and computational heritage of knowledge engineering. But SBVR also makes that distinction in several ways, not the least of which is that designations apply only to concepts (types) and not to things/res (individuals). So I am a bit hesitant to promulgate the term "ground fact" as the signifier for "local/current knowledge that is only true in a given world, and may be subject to change over time." In the words of Bernd Wenzel, it is likely to violate the Law of Least Astonishment. (I don't like "data fact"; either, that just fell out of using MOF-like terminology.) BTW, I believe that operational rules and some rules that appear to be structural rules (sufficient conditions for some operational categorization) are a body of knowledge that is separate from the conceptual schema. This is precisely because their intent is prescriptive, and the states/actions they describe are understood not necessarily to hold. We find in the case of supply-chain interactions that this is a useful segregation, because it is possible to build a general domain ontology that needs only minor tweaks as the supply chain evolves, but the set of operational business rules varies with every business partner, and enforcement and recovery is a black art. We also see this separation in the formalization of security policies (a proposed OMG MARS RFP). Their architecture describes a domain ontology that provides the vocabulary and the conceptual schema for the information, and a separate body of policy in a separate rules language that uses the domain vocabulary in specifying the business rules for access to the information. -Ed Sjir Nijssen wrote: ------------------------------------------------------------------------ *From:* Ronald G. Ross [mailto:rross@BRSolutions.com] *Sent:* Wed 10/6/2010 7:04 PM *To:* edbark@nist.gov; keri *Cc:* SBVR RTF *Subject:* Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 At 11:28 AM 10/6/2010, Ed Barkmeyer wrote: >keri wrote: >>On 10/5/10 3:09 PM, "Ronald G. Ross" wrote: >> >> I ask, can SBVR 'understand' if someone says "is role of"? I >> believe it can ... if not, we're in big trouble. >> >>SBVR "understands" /ranges over /but there is nothing that supports >>an /understanding /of "is role of", which is why it is here (in 11.1.5). > >Hmm. That suggests we need a synonymous form for (role) ranges over >(concept), to wit: > (role) is role of (concept) >/Example fact:/ 'teacher' is role of 'person' *[[Sjir: to increase precision: this is not a ground fact but part of a verbalization of a domain specific conceptual schema. ]]* > >But I don't think that is the verb concept that is intended. Yes, I believe that *was* the concept intended for 11.1.5. > The fact type that is intended is rather: > (role) is played by (thing) >/Example fact/: "Don Baisley" is a project manager. *[[Sjir: this is an example of a ground fact; may I propose to qualify the three kind of facts as * *1. Ground facts* *2. Domain specific schema fact* *3. Generic schema fact.* *I am convinced that the systematic use of this distinction will increase the quality of the SBVR spec.]]* >SBVR currently supports that with: (thing) is instance of (concept), >because it is not clear that 'project manager' isn't an object >type. No situation is identified. We have to add the knowledge >that 'project manager' is a situational role, but then the above >sentence is half of a meaningful fact. The situation is not identified. > >The definition of is-role-of fact type suggests that the intended >fact type form is: (thing) plays (role) in (situation). >Example fact: "Miss Jones" is a teacher at MLKing High School. No, I don't believe that's what was intended for 11.1.5. I'm pretty sure about it. Keri? Agree? Ron >And I agree with Keri that that fact type does not appear in SBVR. > >-Ed > >> >>- Keri > >-- >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." > -- 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: "Donald Chapin" To: Subject: RE: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 -- Three General Principles Date: Thu, 7 Oct 2010 20:58:40 +0100 X-Mailer: Microsoft Office Outlook 11 Thread-Index: ActmWgg5vjSo7/ayROaKx7z7Cg5ECQ== X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0301.4CAE2678.000A, actions=TAG X-Junkmail-Status: score=10/50, host=c2bthomr07.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0201.4CAE2683.020B,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false All, Some additional perspective is helpful on two of the general principles Ron proposed below. Please see additional information in line below. Donald -------------------------------------------------------------------------------- From: Ronald G. Ross [mailto:rross@BRSolutions.com] Sent: 04 October 2010 18:32 To: Mark H Linehan; sbvr-rtf@omg.org Subject: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 All, In preparation for Friday's special meeting, I would like to pick up the discussion of Issue 13716. I think a lot of the actual work can be (should be) done by e-mail beforehand. Attached are documents circulated August 20. I will comment in follow-up e-mails since that time separately. First, however, I do believe we need to agree some general principles, as follows. There is no point in discussing details if there is disagreement or misunderstanding on these basic points. 1. Classifications, categorizations and characterizations are facts. (So there is no value add in the concept "concept connection".) There is no need to introduce a new anomaly into the SBVR specification by saying that part of the content of an SBVR model is facts and where the rest of it isn.t. To maintain the present consistency, either every entry in an SBVR model is a fact or none of them are. All we have to do to avoid this is to clarify the definitions of the existing .kind of fact type. concepts by wording them in more layman.s language, along the lines of these two examples: categorization fact type Definition: fact type that defines a relation between a given concept and another narrower concept, that is a category of the given concept, such that each instance of the category is also an instance of the given concept 2. Associative fact types (associations), Is-property-of fact types, and part-whole fact types are indeed fact types from the perspective of 11.1.5. partitive fact type Definition: binary fact type that defines a relation between things in the extension of the two concepts playing the fact type roles such that each instance of one concept is a given part in the composition of a given whole that is an instance of the other concept 3. Clause 11.1.5 is business-facing. This is part of the story, but not the whole story. Historically - and this may be new to people who were not on the Business Rules Team that produced the original adopted SBVR specification, the split between Clause 8 and Clause 11 happened because there were two differing views of what the required core vocabulary concepts are and which ones are optional. The compromise solution was to split the vocabulary clause into two clauses. Thus Clause 11 was born. As well as containing business-facing concepts, Clause 11, inevitably as part of the compromise, contains some non-business-facing concepts. This explains what some on the SBVR RTF have expressed as an artificial division between Clause 8 and Clause 11. Its (only) utility lies with providing standardization for terms (signifiers) business people and business analysts *might actually use* in developing vocabulary, not in creating new names (signifiers) for (sometimes obscure) concepts. For example, "is-role-of fact type" has no natural business-facing signifier (as per Don, "rollification"?!?) and should be discarded. Ron Date: Thu, 07 Oct 2010 19:07:27 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Donald Chapin CC: "sbvr-rtf@omg.org" Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 -- Three General Principles X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: o97N7XvK015111 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1287097654.51848@IaKybP75iP1LhJihI2YU6A X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Quoting Ron, Donald Chapin wrote: All we have to do to avoid this is to clarify the definitions of the existing .kind of fact type. concepts by wording them in more layman.s language, along the lines of these two examples: categorization fact type Definition: fact type that defines a relation between a given concept and another narrower concept, that is a category of the given concept, such that each instance of the category is also an instance of the given concept There is exactly one such fact type. It is 'concept specializes concept' in clause 8. There may be many such facts. But every specialization of this fact type is an individual concept -- a fact. This goes to Keri's original concern that the intent was to categorize facts 2. Associative fact types (associations), Is-property-of fact types, and part-whole fact types are indeed fact types from the perspective of 11.1.5. partitive fact type Definition: binary fact type that defines a relation between things in the extension of the two concepts playing the fact type roles such that each instance of one concept is a given part in the composition of a given whole that is an instance of the other concept This definition is a very wordy way of saying: binary fact type that characterizes a relationship between two things, such that the thing that plays one role (the 'part') is a part of the thing that plays the other role (the 'whole'). The definition does not convey any clear axiom for the interpretation of 'is a part of' or "is a given part in the composition of". For example: 1) if a given X is a part of one Y, can it also be a part of another Y? UML distinguishes two cases: The black diamond is exclusive; the answer is No. The white diamond just means "logically contained in", like 'set contains thing'; the answer is Yes. Is 'set contains thing' a partitive fact type? Since UML uses 'composition' to refer to the exclusive relationship, I assume the intent here is 'no'. But an anthology is usually 'composed of' works which were separately published, and may be re-published (by permission) in other anthologies. 2) If X is a part of Y, is X also a part (in the same way) of everything Y is a part of? If a wheel is part of a car, and the car is part of a fleet, is the wheel a part of the fleet? Or are those 'is part of's different partitive relations with the same signifier (but different contexts)? 3) If X is a part of Y and Y is lost or deleted or destroyed, is X also lost/deleted/destroyed? If the car is totaled, does the wheel go with it? If you eliminate a business unit in the org chart, what happens to the employees who are 'part of' that business unit? 4) If X is a part of Y, and X is altered/lost/deleted/destroyed, is Y altered/lost/etc.? If a ship is part of a convoy, and the ship is sunk, does the convoy still exist, and is it the same one? If you change the engine, do you still have a race car? (This is the "ship of Theseus" or "my grandfather's ax" problem: This is my grandfather's ax; my father replaced the handle, and I replaced the head.) Or are these questions irrelevant? Does partitive fact type just mean we think of it as a part-whole relationship, whatever that may mean? There are multiple 'is part of' fact types that have different axioms associated, as in the above. And each may have specializations that restrict the roles. So I think 'partitive fact type' may have many instances, but it doesn't have a definition. 3. Clause 11.1.5 is business-facing. This is part of the story, but not the whole story. Historically - and this may be new to people who were not on the Business Rules Team that produced the original adopted SBVR specification, the split between Clause 8 and Clause 11 happened because there were two differing views of what the required core vocabulary concepts are and which ones are optional. The compromise solution was to split the vocabulary clause into two clauses. Thus Clause 11 was born. As well as containing business-facing concepts, Clause 11, inevitably as part of the compromise, contains some non-business-facing concepts. This explains what some on the SBVR RTF have expressed as an artificial division between Clause 8 and Clause 11. So the issue here is whether these concepts are part of core conformance to SBVR, or part of some compliance point? Its (only) utility lies with providing standardization for terms (signifiers) business people and business analysts *might actually use* in developing vocabulary, not in creating new names (signifiers) for (sometimes obscure) concepts. For example, "is-role-of fact type" has no natural business-facing signifier (as per Don, "rollification"?!?) and should be discarded. With Keri's clarification, I think there is only one is-role-of fact type: role ranges over concept, which just needs an alternative "business facing" signifier. So we have 2 categories that have one member each, and one category that is weakly defined. Ron -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." Date: Thu, 07 Oct 2010 19:16:29 -0400 From: Edward Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: "Ronald G. Ross" CC: SBVR RTF Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edward.barkmeyer@nist.gov Ronald G. Ross wrote: At 11:28 AM 10/6/2010, Ed Barkmeyer wrote: keri wrote: On 10/5/10 3:09 PM, "Ronald G. Ross" wrote: I ask, can SBVR 'understand' if someone says "is role of"? I believe it can ... if not, we're in big trouble. SBVR "understands" /ranges over /but there is nothing that supports an /understanding /of "is role of", which is why it is here (in 11.1.5). Hmm. That suggests we need a synonymous form for (role) ranges over (concept), to wit: (role) is role of (concept) Example fact: 'teacher' is role of 'person' But I don't think that is the verb concept that is intended. Yes, I believe that *was* the concept intended for 11.1.5. OK. I stand corrected. I was trying to guess, from the existing text and the flurry of discussion, which of the two or three concepts was intended. I assumed from Keri's email that the intended concept wasn't a synonym for role ranges over concept. Perhaps the problem is only to realize that they are the same concept. -Ed The fact type that is intended is rather: (role) is played by (thing) Example fact: "Don Baisley" is a project manager. SBVR currently supports that with: (thing) is instance of (concept), because it is not clear that 'project manager' isn't an object type. No situation is identified. We have to add the knowledge that 'project manager' is a situational role, but then the above sentence is half of a meaningful fact. The situation is not identified. The definition of is-role-of fact type suggests that the intended fact type form is: (thing) plays (role) in (situation). Example fact: "Miss Jones" is a teacher at MLKing High School. No, I don't believe that's what was intended for 11.1.5. I'm pretty sure about it. Keri? Agree? Ron And I agree with Keri that that fact type does not appear in SBVR. -Ed - Keri -- 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." -- 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." X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: 1Zr.TvUVM1kFpg.SylAKXRDBur82LrJHBzcXYj6TL8MH74w Xf3bcYoMUqNHic4g9hAngjJ0Jea43ZOErdcO9e1XXrvYWqemGzGcGdwZw_ZZ ZdRRnJmBCwPT7mPAesTW1pggz5cG6M66ZJv.856djfAyT_wNcbthNhw4cion epmHymN4Wn36hWmzgPkbROEpnBhYms_w2wm9sJ6003DrH6yPE7qfm4oPq1g9 9aXF1.WC0qwnSt.AWkbHGGVXIRnwblQJEQ8ju3fdgovtsi2GZvtNqtisNVBr X4GUG3GgETA-- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Oct 2010 18:44:20 -0500 To: edbark@nist.gov From: "Ronald G. Ross" Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 Cc: SBVR RTF At 06:16 PM 10/7/2010, Edward Barkmeyer wrote: Ronald G. Ross wrote: At 11:28 AM 10/6/2010, Ed Barkmeyer wrote: keri wrote: On 10/5/10 3:09 PM, "Ronald G. Ross" wrote: I ask, can SBVR 'understand' if someone says "is role of"? I believe it can ... if not, we're in big trouble. SBVR "understands" /ranges over /but there is nothing that supports an /understanding /of "is role of", which is why it is here (in 11.1.5). Hmm. That suggests we need a synonymous form for (role) ranges over (concept), to wit: (role) is role of (concept) Example fact: 'teacher' is role of 'person' But I don't think that is the verb concept that is intended. Yes, I believe that *was* the concept intended for 11.1.5. OK. I stand corrected. I was trying to guess, from the existing text and the flurry of discussion, which of the two or three concepts was intended. I assumed from Keri's email that the intended concept wasn't a synonym for role ranges over concept. Perhaps the problem is only to realize that they are the same concept. It sure seems like a great solution if it flies. Business-friendly wording ("is role of") and no need for any new definition at all (so greatly simplifying). Ron P.S. Now please try to find a simple solution like that for "is-facet-of". -Ed The fact type that is intended is rather: (role) is played by (thing) Example fact: "Don Baisley" is a project manager. SBVR currently supports that with: (thing) is instance of (concept), because it is not clear that 'project manager' isn't an object type. No situation is identified. We have to add the knowledge that 'project manager' is a situational role, but then the above sentence is half of a meaningful fact. The situation is not identified. The definition of is-role-of fact type suggests that the intended fact type form is: (thing) plays (role) in (situation). Example fact: "Miss Jones" is a teacher at MLKing High School. No, I don't believe that's what was intended for 11.1.5. I'm pretty sure about it. Keri? Agree? Ron And I agree with Keri that that fact type does not appear in SBVR. -Ed - Keri -- 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." -- 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." X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: _e1gHEwVM1m0CMuSt6cTsZQX9mFNWzouF0KJRw.sbscP9SU YZP.oh0bbj.EJ0W57r0HJs52C1w1K.sW_5swOA3TNFG1stvzSDjq4kWuybCC aLtsSmz7esqSe9GODxZi8tV6lL0y3UwZI3kDExFrFFh7_3BVyRJ7iiV_DQ5R KKTHk_5BdJcWDcYU3.k_LUV_zjSmjzjUeCwe6q89gT.Fla.gVmfvAGCnwA_D q8HEFkhJ7BWToxBDTuhccg2vceNNGsPk5_OprME84T1izXFvNs3mICfHrFko d X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 07 Oct 2010 18:56:16 -0500 To: edbark@nist.gov, Donald Chapin From: "Ronald G. Ross" Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 -- Three General Principles Cc: "sbvr-rtf@omg.org" X-SpamInfo: FortiGuard - AntiSpam ip, connection black ip 69.147.65.187 At 06:07 PM 10/7/2010, Ed Barkmeyer wrote: Its (only) utility lies with providing standardization for terms (signifiers) business people and business analysts *might actually use* in developing vocabulary, not in creating new names (signifiers) for (sometimes obscure) concepts. For example, "is-role-of fact type" has no natural business-facing signifier (as per Don, "rollification"?!?) and should be discarded. With Keri's clarification, I think there is only one is-role-of fact type: role ranges over concept, which just needs an alternative "business facing" signifier. Ed, Let's be careful here. Example: * Buyer is a role of party. * Insured is a role of party. * Destination is a role of location. There are *three* connections (facts) there. The need is to point to any one of those three and say "There is a 'is role of' connection (fact)." So under the one fact type "role ranges over concept" (whose synonymous form is proposed to be "role is role of concept"), there are many (at least three) of those thingees you want to point at. Ron So we have 2 categories that have one member each, and one category that is weakly defined. Ron -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." X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010080063 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-08_09:2010-10-08,2010-10-08,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 08 Oct 2010 06:21:36 -0700 Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 -- Three General Principles From: keri To: Ed Barkmeyer , Donald Chapin Cc: SBVR RTF Thread-topic: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 -- Three General Principles Thread-index: Actm67uL+e5SW9LeEd+mQQARJM+Cgg== On 10/7/10 4:07 PM, "Ed Barkmeyer" wrote: Quoting Ron, Donald Chapin wrote: There is no need to introduce a new anomaly into the SBVR specification by saying that part of the content of an SBVR model is facts and where the rest of it isn.t. ... All we have to do to avoid this is to clarify the definitions of the existing .kind of fact type. concepts by wording them in more layman.s language, along the lines of these two examples: ... On 10/7/10 4:07 PM, "Ed Barkmeyer" wrote: There is exactly one such fact type. It is 'concept specializes concept' in clause 8. There may be many such facts. But every specialization of this fact type is an individual concept -- a fact. This goes to Keri's original concern that the intent was to categorize facts If we are to NOT introduce "facts" in 11.1.5 (as Donald says) then, yes, Ed is correct . there is one fact type in each of these categories. For example, for "categorization" we had: Definition: the fact type 'general concept specializes concept' or any fact type that specializes it (Note -- Mark had pointed out that there could possibly be specializations of the one SBVR fact type, which resulted in the wording at the end of the Definition.) Ed, to clarify my "original intent" (the wording of the original problem), the problem statement did suggest that the solution was to cast these as facts. I would be equally happy to stick with these four being fact types and reword each of the four Definitions so that each correctly characterizes the corresponding SBVR fact type. Be they 'fact type' or 'fact' we should be able to word examples in sufficiently business-friendly terms to make this clear. Also, Mark suggested that an annotated model diagram could be used to help illustrate. That could be added as introductory narrative for 11.1.5, or added to an existing Annex and referenced via a Note. - Keri X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010080069 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-08_09:2010-10-08,2010-10-08,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 08 Oct 2010 06:57:05 -0700 Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 From: keri To: SBVR RTF Thread-topic: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 Thread-index: Actm67uL+e5SW9LeEd+mQQARJM+CggABPT7/ All, I developed this sketch for my own note-taking/reference in today's meeting. I'm sending it on, if you find it useful. - Keri Fig11.5 V7.2D-sketch.jpg Subject: RE: "knowledge segregation" from [READ FIRST] Re: issue 13716 - Refactoring ... 2010-10-08-1621-CET Date: Fri, 8 Oct 2010 16:19:33 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: "knowledge segregation" from [READ FIRST] Re: issue 13716 - Refactoring ... 2010-10-08-1621-CET thread-index: ActmNwr9JR80ErxuQUeEfVfS7Gj3TAAt6cwp From: "Sjir Nijssen" To: Cc: "SBVR RTF" Ed and others, Ed, thank you for your extensive answer. I believe it can help SBVR. See my answer and suggestions below between [[ ]] Regards Sjir -------------------------------------------------------------------------------- From: Edward Barkmeyer [mailto:edward.barkmeyer@nist.gov] Sent: Thu 10/7/2010 5:47 PM To: Sjir Nijssen Cc: SBVR RTF Subject: Re: "knowledge segregation" from [READ FIRST] Re: issue 13716 - Refactoring ... Sjir raises a totally different issue: Categorization of facts from the viewpoint of segregating knowledge. [[Sjir: this categorization is in my opinion essential for validation purposes, including validation of the SBVR specs. It helps not only in practical business modeling with SBVR but also with the modeling of SBVR itself.]] I don't think clause 11 tries to do this at all, so I wouldn't know where to place this concept set. [[Sjir: I believe the proper Clause is 8. ]] This is much closer to the MOF "metalevel" stuff: what is "metaschema" (M2), what is "conceptual schema" (M1), and what is "data" (M0). [[Sjir: the three levels of knowledge were already published in the seventies by Dr. Mike Senko and myself in a 1978 ISO proposal. Hence long before the MMM of MOF came into existence. Is there a special reason why M3 is not mentioned?]] "metaschema" is conceptual schema for schemas -- the concepts that are part of the language in which the conceptual schemas are written. It represents the invariant linguistic and semantic knowledge of the modeling tool builders [[Sjir: and modelers]] , the facts that they insist must be true of schemas. A metaschema is prescriptive. "conceptual schema" (aka "domain ontology") is the supposed invariant [[Sjir: during a certain period]] knowledge of the domain experts. The facts that they take to be _necessarily_ true. The intent of a conceptual schema is descriptive (of the domain), but it is prescriptive in that it provides all of the vocabulary that can be used in some set of statements of "data". [Terminology analysis: "conceptual schema" is a database word, [[Sjir: Conceptual schema was used in the ISO TR9007 (1987), independent of databases as Ed states also in his email.]] "information model" is the 1985-2000 systems analysis word, "domain ontology" is the current vogue term. Each has a different concept of the kind of semantic formalism in the metaschema. That said, the 1984 ISO TR 8002 "The conceptual schema and the information base" (van Griethuysen, Nijssen, Steele, et al.) used the term "conceptual schema" with the intent of "information model" -- it described domain semantics, not database semantics. [[Sjir: there is the 100% principle in ISO TR9007: All relevant general static and dynamic aspects, i.e. all rules, laws, etc., of the universe of discourse should be described in the conceptual schema. I have not seen any ontology that comes even close to 50%, including OWL. There is also the Conceptualization principle in ISO TR9007: A conceptual schema should only include conceptually relevant aspects, both static and dynamic, of the universie of discourse, thus excluding all aspects of data representation. ]] But the better known publications -- the ANSI 3-schema architecture and the ISO 10032 Reference Model for Data Management --.use "conceptual schema" to refer to the integrated master database schema."] "data" is the facts that represent local/current knowledge of the business persons acting in the domain. It is descriptive, and it is (technically) subject to change. Sjir suggests some terms for kinds of facts that relate the facts to the above categories. His "generic schema fact" is a "metaschema" fact. His "domain specific schema fact" is a "conceptual schema" fact. His "ground fact" is a "data" fact. I have a problem with the last term. [[Sjir: let us then find a better term; I hope we will not use M0-fact, or M1-fact, or M2-fact.]] Logicians and information analysts commonly use "ground fact" to refer to facts about individuals that are taken to be invariant knowledge. That is, the common interpretation of "ground fact" is a fact about individuals (rather than classes) that appears in the conceptual schema (or in the case of language elements, in the metaschema). The fact that "317 is an Integer" is a "ground fact" that is (usually implicitly) contained in the conceptual schema, and used in its semantic model. The fact that "ISO 639 is the reference registry for language identifiers" or that "DUNS is an instance of 'registry for business identifiers'" are common "ground facts" in conceptual schemas. I have to agree that the distinction between invariant facts about object types and invariant facts about individuals has no significant philosophical basis. The distinction is itself a vestige of the [[Sjir: semantic]] database and computational heritage of knowledge engineering. But SBVR also makes that distinction in several ways, not the least of which is that designations apply only to concepts (types) and not to things/res (individuals). So I am a bit hesitant to promulgate the term "ground fact" as the signifier for "local/current knowledge that is only true in a given world, and may be subject to change over time." In the words of Bernd Wenzel, it is likely to violate the Law of Least Astonishment. (I don't like "data fact"; either, that just fell out of using MOF-like terminology.) BTW, I believe that operational rules and some rules that appear to be structural rules (sufficient conditions for some operational categorization) are a body of knowledge that is separate from the conceptual schema. [[Sjir: that is not the point of view of ISO TR9007; however this is the popular view in the ontology community.]] This is precisely because their intent is prescriptive, and the states/actions they describe are understood not necessarily to hold. We find in the case of supply-chain interactions that this is a useful segregation, because it is possible to build a general domain ontology that needs only minor tweaks as the supply chain evolves, but the set of operational business rules varies with every business partner, and enforcement and recovery is a black art. [[Sjir: would it be acceptable to combine ISO TR9007 and SBVR as follows: a conceptual schema in SBVR consists of a. a set of fact types ( to determine the boundary of the UoD or system), b. a set of associated concept definitions (to understand the fact instances associated with the fact types), c. a set of associated fact type forms ( to make community specific communication possible), d. a set of associated validation rules (to restrict the populations of fact instances and their transition to the ones considered useful). e. a set of derivation rules (to derive new facts instances from existing fact instances). An OWL ontology consists of a (with the restriction that all fact types need to be unary or binary) and some d and e.]] [[The segragation mentioned by Ed in the paragraph above can then be expressed as a useful distinction between the union of a and b, and the full conceptual schema.]] We also see this separation in the formalization of security policies (a proposed OMG MARS RFP). Their architecture describes a domain ontology [[Sjir: the set of a above, plus the subtype hierarchy?]] that provides the vocabulary and the conceptual schema for the information, and a separate body of policy in a separate rules language that uses the domain vocabulary in specifying the business rules for access to the information. -Ed Sjir Nijssen wrote: > > > ------------------------------------------------------------------------ > *From:* Ronald G. Ross [mailto:rross@BRSolutions.com] > *Sent:* Wed 10/6/2010 7:04 PM > *To:* edbark@nist.gov; keri > *Cc:* SBVR RTF > *Subject:* Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 > > At 11:28 AM 10/6/2010, Ed Barkmeyer wrote: > > > >keri wrote: > >>On 10/5/10 3:09 PM, "Ronald G. Ross" wrote: > >> > >> I ask, can SBVR 'understand' if someone says "is role of"? I > >> believe it can ... if not, we're in big trouble. > >> > >>SBVR "understands" /ranges over /but there is nothing that supports > >>an /understanding /of "is role of", which is why it is here (in 11.1.5). > > > >Hmm. That suggests we need a synonymous form for (role) ranges over > >(concept), to wit: > > (role) is role of (concept) > >/Example fact:/ 'teacher' is role of 'person' *[[Sjir: to increase > precision: this is not a ground fact but part of a verbalization of a > domain specific conceptual schema. ]]* > > > >But I don't think that is the verb concept that is intended. > > Yes, I believe that *was* the concept intended for 11.1.5. > > > The fact type that is intended is rather: > > (role) is played by (thing) > >/Example fact/: "Don Baisley" is a project manager. *[[Sjir: this is > an example of a ground fact; may I propose to qualify the three kind > of facts as * > > *1. Ground facts* > > *2. Domain specific schema fact* > > *3. Generic schema fact.* > > *I am convinced that the systematic use of this distinction will > increase the quality of the SBVR spec.]]* > > > >SBVR currently supports that with: (thing) is instance of (concept), > >because it is not clear that 'project manager' isn't an object > >type. No situation is identified. We have to add the knowledge > >that 'project manager' is a situational role, but then the above > >sentence is half of a meaningful fact. The situation is not identified. > > > >The definition of is-role-of fact type suggests that the intended > >fact type form is: (thing) plays (role) in (situation). > >Example fact: "Miss Jones" is a teacher at MLKing High School. > > No, I don't believe that's what was intended for 11.1.5. > > I'm pretty sure about it. Keri? Agree? > > Ron > > > >And I agree with Keri that that fact type does not appear in SBVR. > > > >-Ed > > > >> > >>- Keri > > > >-- > >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." > > > > > -- 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: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 From: keri Date: Fri, 08 Oct 2010 11:29:37 -0700 Cc: sbvr-rtf@omg.org To: Donald Chapin X-Mailer: Apple Mail (2.1081) Donald, Can we not develop this in reference to the text in 11.1.5 of the 1.1 Convenience Document? Part of the confusion that has plagued this Issue has been in each of us trying to recall which bits had morphed in different Issues. Yes, I can write up the Resolution document against the 1.0 text and pages, if that's the process ... but is it the process, BTW? Hmmm... if there are balloted changes now reflected in the content printed in 1.1 do we refer to the 1.1 page numbers (and content) or the 1.0 pages (and content)? Thanks, Keri On Oct 8, 2010, at 10:52 AM, Donald Chapin wrote: Keri, I think to most useful next Issue 13716 document for the SBVR RTF participants would be the proposed new Clause 11.1.5 as change tracked against the attached SBVR v1.0 Clause 11.1.5 Word document. Thanks, Donald -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: 06 October 2010 22:06 To: Ronald G. Ross Cc: SBVR RTF Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 On 10/6/10 1:51 PM, "Ronald G. Ross" wrote: Obviously there is fundamental misunderstanding (or lack of understanding) about section 11.1.5. I recommend that we solve the basic problem. Can we stay focused on solutions? Yes. Now that we have a Convenience Document, I can clean up and distribute an updated Resolution write-up ... or I can mock up what a re-factored 11.1.5 would look like. Whichever the team feels would be more useful. - Keri Date: Fri, 08 Oct 2010 14:45:37 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: keri CC: Donald Chapin , "sbvr-rtf@omg.org" Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: o98Ijgou016469 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1287168348.23015@PwRPvGhZbHc5TAGwfkURgA X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov keri wrote: Donald, Can we not develop this in reference to the text in 11.1.5 of the *1.1 Convenience Document*? No. The RTF report must contain the directives for change to the base document specified in the Charter of the RTF. So, if you specify them against some intermediate version, they have to be fitted to the base document. Part of the confusion that has plagued this Issue has been in each of us trying to recall which bits had morphed in different Issues. What this might mean is that the RTF must merge the text of several issue resolutions into one change set, so that the editor doesn't have to guess the interactions. The last time I had to do that, every change bullet identified the Issue(s) it came from. Yes, I can write up the Resolution document against the 1.0 text and pages, if that's the process ... but is it the process, BTW? Yes. Hmmm... if there are balloted changes now reflected in the content printed in 1.1 do we refer to the 1.1 page numbers (and content) or the 1.0 pages (and content)? Everything in the RTF Report refers to 1.0. The RTF can rescind and revise balloted changes, up to the point at which it delivers its final report. Resolution of a later issue can result in changes to an adopted issue resolution, or to the resulting text. v1.1bis is only for the convenience of the RTF, in trying to get consistency of changes. -Ed Thanks, Keri On Oct 8, 2010, at 10:52 AM, Donald Chapin wrote: Keri, I think to most useful next Issue 13716 document for the SBVR RTF participants would be the proposed new Clause 11.1.5 as change tracked against the attached SBVR v1.0 Clause 11.1.5 Word document. Thanks, Donald ------------------------------------------------------------------------ *From:* keri [mailto:keri_ah@mac.com] *Sent:* 06 October 2010 22:06 *To:* Ronald G. Ross *Cc:* SBVR RTF *Subject:* Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 On 10/6/10 1:51 PM, "Ronald G. Ross" > wrote: *Obviously there is fundamental misunderstanding (or lack of understanding) about section 11.1.5. I recommend that we solve the basic problem. Can we stay focused on solutions?* Yes. Now that we have a Convenience Document, I can clean up and distribute an updated Resolution write-up ... or I can mock up what a re-factored 11.1.5 would look like. Whichever the team feels would be more useful. - Keri -- 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." X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010080119 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-08_14:2010-10-08,2010-10-08,1970-01-01 signatures=0 Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 From: keri Date: Fri, 08 Oct 2010 11:52:08 -0700 Cc: Donald Chapin , "sbvr-rtf@omg.org" To: edbark@nist.gov X-Mailer: Apple Mail (2.1081) Thanks, Ed. In that case, it would still be my preference to develop the "new view" document for 11.1.5 by working from the 1.1 Convenience Document. After all, this is for our working "convenience" in grasping what is specifically changing according to this Issue. Once we have that understood/agreed, I would go back and prepare the change instructions, referencing the 1.0 document (and hope that it isn't the nightmare that Ed has shared ). Donald? Which do you prefer to have used for the view of 11.1.5? - Keri On Oct 8, 2010, at 11:45 AM, Ed Barkmeyer wrote: > > keri wrote: >> Donald, >> >> Can we not develop this in reference to the text in 11.1.5 of the *1.1 Convenience Document*? > > No. The RTF report must contain the directives for change to the base document specified in the Charter of the RTF. > > So, if you specify them against some intermediate version, they have to be fitted to the base document. > >> Part of the confusion that has plagued this Issue has been in each of us trying to recall which bits had morphed in different Issues. > > What this might mean is that the RTF must merge the text of several issue resolutions into one change set, so that the editor doesn't have to guess the interactions. The last time I had to do that, every change bullet identified the Issue(s) it came from. > >> Yes, I can write up the Resolution document against the 1.0 text and pages, if that's the process ... but is it the process, BTW? > > Yes. > >> Hmmm... if there are balloted changes now reflected in the content printed in 1.1 do we refer to the 1.1 page numbers (and content) or the 1.0 pages (and content)? > > Everything in the RTF Report refers to 1.0. The RTF can rescind and revise balloted changes, up to the point at which it delivers its final report. Resolution of a later issue can result in changes to an adopted issue resolution, or to the resulting text. > > v1.1bis is only for the convenience of the RTF, in trying to get consistency of changes. > > -Ed >> >> Thanks, >> >> Keri >> >> On Oct 8, 2010, at 10:52 AM, Donald Chapin wrote: >> >>> Keri, >>> I think to most useful next Issue 13716 document for the SBVR RTF participants would be the proposed new Clause 11.1.5 as change tracked against the attached SBVR v1.0 Clause 11.1.5 Word document. >>> Thanks, >>> Donald >>> ------------------------------------------------------------------------ >>> *From:* keri [mailto:keri_ah@mac.com] *Sent:* 06 October 2010 22:06 >>> *To:* Ronald G. Ross >>> *Cc:* SBVR RTF >>> *Subject:* Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 >>> On 10/6/10 1:51 PM, "Ronald G. Ross" > wrote: >>> >>> >>> *Obviously there is fundamental misunderstanding (or lack of understanding) about section 11.1.5. I recommend that we solve the basic problem. Can we stay focused on solutions?* >>> >>> Yes. Now that we have a Convenience Document, I can clean up and distribute an updated Resolution write-up ... or I can mock up what a re-factored 11.1.5 would look like. Whichever the team feels would be more useful. >>> >>> >>> - Keri >>> >> > > -- > 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: "Donald Chapin" To: "'keri'" Cc: Subject: RE: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 Date: Fri, 8 Oct 2010 20:31:00 +0100 X-Mailer: Microsoft Office Outlook 11 Thread-Index: ActnFplab8LR/HagQvKPlK0gMf4nggAB93pA X-Mirapoint-IP-Reputation: reputation=Good-1, source=Queried, refid=tid=0001.0A0B0301.4CAF7179.0109, actions=tag X-Junkmail-Status: score=10/50, host=c2bthomr13.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0204.4CAF7187.001C,ss=1,fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine X-Junkmail-IWF: false Keri, When we get to the official editing instructions they have to be in terms of SBVR v1.0. Convenience documents have no official status. With respect to the changed-tracked working document I asked about, it.s probably best to work from the convenience document as that reflects what has already been voted on. I just don.t have a Word version of Clause 11.1.5 from the convenience document. Can you extract a Word document from it? If not, I can ask Linda Heaton for something. Donald -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: 08 October 2010 19:30 To: Donald Chapin Cc: sbvr-rtf@omg.org Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 Donald, Can we not develop this in reference to the text in 11.1.5 of the 1.1 Convenience Document? Part of the confusion that has plagued this Issue has been in each of us trying to recall which bits had morphed in different Issues. Yes, I can write up the Resolution document against the 1.0 text and pages, if that's the process ... but is it the process, BTW? Hmmm... if there are balloted changes now reflected in the content printed in 1.1 do we refer to the 1.1 page numbers (and content) or the 1.0 pages (and content)? Thanks, Keri On Oct 8, 2010, at 10:52 AM, Donald Chapin wrote: Keri, I think to most useful next Issue 13716 document for the SBVR RTF participants would be the proposed new Clause 11.1.5 as change tracked against the attached SBVR v1.0 Clause 11.1.5 Word document. Thanks, Donald -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: 06 October 2010 22:06 To: Ronald G. Ross Cc: SBVR RTF Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 On 10/6/10 1:51 PM, "Ronald G. Ross" wrote: Obviously there is fundamental misunderstanding (or lack of understanding) about section 11.1.5. I recommend that we solve the basic problem. Can we stay focused on solutions? Yes. Now that we have a Convenience Document, I can clean up and distribute an updated Resolution write-up ... or I can mock up what a re-factored 11.1.5 would look like. Whichever the team feels would be more useful. - Keri X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010080129 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-08_14:2010-10-08,2010-10-08,1970-01-01 signatures=0 Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 From: keri Date: Fri, 08 Oct 2010 12:58:36 -0700 Cc: sbvr-rtf@omg.org To: Donald Chapin X-Mailer: Apple Mail (2.1081) Yes, I can create one. Thanks. - Keri On Oct 8, 2010, at 12:31 PM, Donald Chapin wrote: I just don.t have a Word version of Clause 11.1.5 from the convenience document. Can you extract a Word document from it? X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010080154 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-08_16:2010-10-08,2010-10-08,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 08 Oct 2010 15:13:06 -0700 Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 - BASELINE 11.1.5 From: keri To: Donald Chapin , SBVR RTF Thread-topic: issue 13716 - Refactoring of Clause 11.1.5 - BASELINE 11.1.5 Thread-index: ActnFplab8LR/HagQvKPlK0gMf4nggAB93pAAAXhDQ8= All, Attached is the 11.1.5 that I have extracted from the 1.1 Convenience Document. Please let me know (asap) if you spot any differences. Thanks, Keri On 10/8/10 12:31 PM, "Donald Chapin" wrote: Keri, When we get to the official editing instructions they have to be in terms of SBVR v1.0. Convenience documents have no official status. With respect to the changed-tracked working document I asked about, it.s probably best to work from the convenience document as that reflects what has already been voted on. I just don.t have a Word version of Clause 11.1.5 from the convenience document. Can you extract a Word document from it? If not, I can ask Linda Heaton for something. Donald SBVR 1.1 ch11.1.5 BASELINE.doc X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010080204 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-08_17:2010-10-08,2010-10-08,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Fri, 08 Oct 2010 19:42:07 -0700 Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 From: keri To: Donald Chapin , SBVR RTF Thread-topic: issue 13716 - Refactoring of Clause 11.1.5 Thread-index: ActlmknviKNxkNGNEd+aHgARJM+CggBduuXAABKWr08= Donald, All, As requested . attached. (Using the 1.1 Convenience Document baseline.) Keri On 10/8/10 10:52 AM, "Donald Chapin" wrote: Keri, I think to most useful next Issue 13716 document for the SBVR RTF participants would be the proposed new Clause 11.1.5 as change tracked against the attached SBVR v1.0 Clause 11.1.5 Word document. Thanks, Donald -------------------------------------------------------------------------------- From: keri [mailto:keri_ah@mac.com] Sent: 06 October 2010 22:06 To: Ronald G. Ross Cc: SBVR RTF Subject: Re: [READ FIRST] Re: issue 13716 - Refactoring of Clause 11.1.5 On 10/6/10 1:51 PM, "Ronald G. Ross" wrote: Obviously there is fundamental misunderstanding (or lack of understanding) about section 11.1.5. I recommend that we solve the basic problem. Can we stay focused on solutions? Yes. Now that we have a Convenience Document, I can clean up and distribute an updated Resolution write-up ... or I can mock up what a re-factored 11.1.5 would look like. Whichever the team feels would be more useful. - Keri SBVR 1.1 ch11.1.5 CT v8.1.doc pic38831.gif Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 X-KeepSent: 21A6DF9C:80DC5AC1-852577BA:00692B39; type=4; name=$KeepSent To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Mark H Linehan Date: Tue, 12 Oct 2010 15:40:15 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 10/12/2010 15:40:17 Both the diagram and the "Elements of Structure" categorization scheme are messed-up because they claim to categorize fact types as kinds of propositions. Per 8.1, a fact type is not a proposition. Why not use "property" (Merriam-Webster: "an attribute common to all members of a class" ) as a better name for "property association"? I don't think "property association" is a kind of "association" because the latter "has a nonhierarchical subject-oriented connection" whereas "property association" seems to be hierarchical. A property of insects is that they have "well-defined heads" (per Merriam-Webster). A property of a head is having a mouth, which may be large, small, etc. This example seems hierarchical to me. A "property association" is a binary fact type, whereas an "association" may have more than 2 roles. How about "composition" or "inclusion" as a better name for "partitive verb concept"? The proposed definition of "classification" only applies to individual concepts but in general usage, we also classify instances. For example, consider a parking lot full of rental cars that a branch manager classifies as "rentable" and "unrentable". Why is "categorization" listed under "contextualization" instead of under "Elements of Structure"? How about "participation" as a better name for "is-role-of proposition"? How about "consideration" or "contemplation" for "is-facet-of proposition" (from Merriam Webster, "facet", 2: "any of the definable aspects that make up a subject (as of contemplation) or an object (as of consideration) "). -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010120117 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-12_12:2010-10-12,2010-10-12,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 12 Oct 2010 13:34:55 -0700 Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 From: keri To: Mark H Linehan , SBVR RTF Thread-topic: issue 13716 - Refactoring of Clause 11.1.5 Thread-index: ActqTO3OLEksydZAEd+04wARJM+Cgg== On 10/12/10 12:40 PM, "Mark H Linehan" wrote: Both the diagram and the "Elements of Structure" categorization scheme are messed-up because they claim to categorize fact types as kinds of propositions. Per 8.1, a fact type is not a proposition. Absolutely! My bad. An updated draft is attached. (Also, corrected the bits missing from the front of the Definition of 'classification' and the replicated Necessity under 'characterization'.) Why not use "property" (Merriam-Webster: "an attribute common to all members of a class " ) as a better name for "property association"? It is my understanding that this was proposed and rejected. But I will put this on the list for discussion. I don't think "property association" is a kind of "association" because the latter "has a nonhierarchical subject-oriented connection" whereas "property association" seems to be hierarchical. A property of insects is that they have "well-defined heads" (per Merriam-Webster). A property of a head is having a mouth, which may be large, small, etc. This example seems hierarchical to me. This usage of "hierarchical" in the definition of 'association' comes from ISO, in which it only means either a generic (specialization/generalization) relation or a partitive relation . contrasted with associative relation which is "non-hierarchical." A "property association" is a binary fact type, whereas an "association" may have more than 2 roles. Yes, which is why it is a special case (specialization) of 'association'. How about "composition" or "inclusion" as a better name for "partitive verb concept"? It is my understanding that these were proposed and rejected. I will put this on the list for discussion. The proposed definition of "classification" only applies to individual concepts but in general usage, we also classify instances. For example, consider a parking lot full of rental cars that a branch manager classifies as "rentable" and "unrentable". This came from the June notes. ... on the list for discussion. Why is "categorization" listed under "contextualization" instead of under "Elements of Structure"? The intent is to eventually reorganize the items within 11.1.5. However, trying to do that . with change tracking on . while the entries were undergoing extensive change made the changes too hard to follow. This will come once everyone is happy with the individual items. For now, please ignore both the order of the items and the existing headings of the latter sub-sections. How about "participation" as a better name for "is-role-of proposition"? ... on the list for discussion. How about "consideration" or "contemplation" for "is-facet-of proposition" (from Merriam Webster, "facet", 2: "any of the definable aspects that make up a subject (as of contemplation) or an object (as of consideration) "). ... on the list for discussion. ~ Keri SBVR 1.1 ch11.1.5 CT v8.2.doc X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=5 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1010120119 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-12_12:2010-10-12,2010-10-12,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 12 Oct 2010 14:00:28 -0700 Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 From: keri To: SBVR RTF Thread-topic: issue 13716 - Refactoring of Clause 11.1.5 Thread-index: ActqTO3OLEksydZAEd+04wARJM+CggAA5G/X On 10/12/10 1:34 PM, "keri" wrote: ... An updated draft is attached. In our last telcon discussion we illustrated the various "Elements of Structure" concepts by pointing at the various kinds of lines/artifacts on an annotated EU-Rent model diagram, and that seemed to help our communication/understanding. One of the new (as of June) entries is for "characterization". Can someone give me a reference to how this is reflected on a diagram (or in text form, vocabulary document) -- preferably using one of the EU-Rent diagrams, or a sketch (or vocabulary snippet) that would show a business person what this looks like. Thanks. Keri X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: VL35Me4VM1nSQ7DiE_6LCZyVBD2SGEJ8.cgxGZ5Fu_EFY7f cXi2.S.cWvLLtdXK2OWkqsrhrnY3vBtn45K4oNH.cgPz2dHCPpH6rMrUJxjL Pw.XGEGxLVKEUf79jpX3nKQsyU5TC1uP.q2Ym4rbtaZJ31nMDiIdOxEpdt7L UxJO810c9k.AQYS6D46MQaQj21Bl3UZPrWMl.NaJ8Lg6fVf74kcyX6F9WpjH NMphWvvhhKNE.pSQta2PbBouZk.DzLHKVohXcMU7y0kNOGsxXLDH6zjFI5o_ NqXbve_ifakgY9_w- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 12 Oct 2010 17:48:16 -0500 To: keri , Mark H Linehan , SBVR RTF From: "Ronald G. Ross" Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 This version is much better. Responses below like this. Ron At 03:34 PM 10/12/2010, keri wrote: On 10/12/10 12:40 PM, "Mark H Linehan" wrote: Both the diagram and the "Elements of Structure" categorization scheme are messed-up because they claim to categorize fact types as kinds of propositions. Per 8.1, a fact type is not a proposition. Absolutely! My bad. An updated draft is attached. (Also, corrected the bits missing from the front of the Definition of 'classification' and the replicated Necessity under 'characterization'.) Why not use "property" (Merriam-Webster: "an attribute common to all members of a class " ) as a better name for "property association"? It is my understanding that this was proposed and rejected. But I will put this on the list for discussion. Discussion of "property" per se now goes under Issue 15684. In this issue (13716) we're not talking about a property per se. We're talking about a structural connection involving a property. I don't think "property association" is a kind of "association" because the latter "has a nonhierarchical subject-oriented connection" whereas "property association" seems to be hierarchical. A property of insects is that they have "well-defined heads" (per Merriam-Webster). A property of a head is having a mouth, which may be large, small, etc. This example seems hierarchical to me. This usage of "hierarchical" in the definition of 'association' comes from ISO, in which it only means either a generic (specialization/generalization) relation or a partitive relation contrasted with associative relation which is "non-hierarchical." A "property association" is a binary fact type, whereas an "association" may have more than 2 roles. Yes, which is why it is a special case (specialization) of 'association'. How about "composition" or "inclusion" as a better name for "partitive verb concept"? It is my understanding that these were proposed and rejected. I will put this on the list for discussion. My understanding of the problem with both terms is that they seem to refer to specific connections (propositions), rather than the partitive fact types on which those propositions are based. Someone correct me if I am wrong. That being the case, would "composition structure" work any better? After all, these are elements of structure. The proposed definition of "classification" only applies to individual concepts but in general usage, we also classify instances. For example, consider a parking lot full of rental cars that a branch manager classifies as "rentable" and "unrentable". This came from the June notes. ... on the list for discussion. I believe Don penned a definition to that effect at one point, but I haven't had time to look for the e-mail. Why is "categorization" listed under "contextualization" instead of under "Elements of Structure"? The intent is to eventually reorganize the items within 11.1.5. However, trying to do that with change tracking on while the entries were undergoing extensive change made the changes too hard to follow. This will come once everyone is happy with the individual items. For now, please ignore both the order of the items and the existing headings of the latter sub-sections. How about "participation" as a better name for "is-role-of proposition"? ... on the list for discussion. The reference is not to a person or thing playing a part, but to a proposition that structurally sets a role up in SBVR (e.g., insured is a role of Party in 'policy insures party'.) So you have to be very careful about the term chosen here. I see no need for the term. There is no natural term business people would use to talk about the notion. Nothing in natural language that SBVR needs to understand. It's even counterproductive in explaining SBVR to people. You *might* get business people to understand "proposition" in its natural English sense, but then to turn it around to talk about how structural notions are handled within SBVR is ... a pretty big stretch. Mind hoops. How about "consideration" or "contemplation" for "is-facet-of proposition" (from Merriam Webster, "facet", 2: "any of the definable aspects that make up a subject (as of contemplation) or an object (as of consideration) "). ... on the list for discussion. Those words have many other connotations than the one intended here. And ditto all the arguments above for "is-role-of proposition". Ron ~ Keri X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1010190000 definitions=main-1011280181 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-11-29_02:2010-11-27,2010-11-29,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Sun, 28 Nov 2010 19:13:25 -1000 Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 From: keri To: Donald Chapin , SBVR RTF Thread-topic: issue 13716 - Refactoring of Clause 11.1.5 Thread-index: ActnFplab8LR/HagQvKPlK0gMf4nggAB93pAChlrvgI= Hi, All, Ninth time's a charm ... here is the reworked Resolution, reflecting the discussion/agreement from our meeting. As I worked through the material (especially the Annex narratives) it occurred to me that more natural terms for our much-struggled-with pair of concepts might simply be: role-of connection facet-of connection What do you think? ... plus (of course) anything else you may spot. ~ Keri SBVR Issue 13716 (v9).doc To: sbvr-rtf@omg.org Subject: Fw: issue 13716 - Refactoring of Clause 11.1.5 X-KeepSent: BC538D01:FC81C276-852577EC:004E9CA0; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Mark H Linehan Date: Wed, 1 Dec 2010 09:31:12 -0500 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP6|July 15, 2010) at 12/01/2010 09:31:14, Serialize complete at 12/01/2010 09:31:14 X-Content-Scanned: Fidelis XPS MAILER Minor editorial comments: * I notice that existing SBVR spec examples and some of the new ones initialize the first word and end with a period, whereas some of the proposed examples use lower-case initial characters and omit the final period. I think we should use consistent styles in the specification, and I favor the initial-cap and trailing period. * I assume we are keeping the old terms as synonyms just to provide traceability to the previous version of the spec? If so, I reluctantly agree. Otherwise I'd be in favor of dropping the old terms completely. * Some of the new text uses "verb concept" whereas other new text uses "fact type" (e.g. the new definition for 'partitive verb concept'). We should be consistent. * Some of the new Notes include cross-references to various Annexes, which is fine. However, I think the text "... as well as the EU-Rent examples in Annex E." is redundant since Annex E provides examples for the whole spec. Regarding Keri's proposal to use ".... connection" as terms -- I'm not in favor because "connection" doesn't mean anything in SBVR. "Role-of connection" sounds like it should be a kind of "connection". Here's one idea: how about "role-of proposition" and "facet-of proposition" instead of "is-role-of proposition", etc. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com ----- Forwarded by Mark H Linehan/Watson/IBM on 12/01/2010 09:18 AM ----- From: keri To: Donald Chapin , SBVR RTF Date: 11/29/2010 12:16 AM Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 -------------------------------------------------------------------------------- Hi, All, Ninth time's a charm ... here is the reworked Resolution, reflecting the discussion/agreement from our meeting. As I worked through the material (especially the Annex narratives) it occurred to me that more natural terms for our much-struggled-with pair of concepts might simply be: role-of connection facet-of connection What do you think? ... plus (of course) anything else you may spot. ~ Keri [attachment "SBVR Issue 13716 (v9).doc" deleted by Mark H Linehan/Watson/IBM] X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1010190000 definitions=main-1012010069 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-12-01_08:2010-12-01,2010-12-01,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 01 Dec 2010 05:44:45 -1000 Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 From: keri To: Mark H Linehan , SBVR RTF Thread-topic: issue 13716 - Refactoring of Clause 11.1.5 Thread-index: AcuRbq1L7BlVq/1hEd+YTgARJM+Cgg== Mark, Thanks for the feedback. My responses are below. On 12/1/10 4:31 AM, "Mark H Linehan" wrote: Minor editorial comments: * I notice that existing SBVR spec examples and some of the new ones initialize the first word and end with a period, whereas some of the proposed examples use lower-case initial characters and omit the final period. I think we should use consistent styles in the specification, and I favor the initial-cap and trailing period. Where the example is a complete sentence, it begins with a capital and ends with a period. Those examples that are not complete sentences begin with lower-case and have no ending punctuation. * I assume we are keeping the old terms as synonyms just to provide traceability to the previous version of the spec? If so, I reluctantly agree. Otherwise I'd be in favor of dropping the old terms completely. The old terms were retained where the old terminology is in use, in the spec. itself and/or by some vendors and existing publications (books). * Some of the new text uses "verb concept" whereas other new text uses "fact type" (e.g. the new definition for 'partitive verb concept'). We should be consistent. I have used "verb concept" everywhere possible. I was told earlier that the lead term of an entry, for example for ''partitive verb concept', needs to be the primary term for the concept, not one of the synonymous terms . hence the use of "fact type" as the more general concept term used in the Definition. * Some of the new Notes include cross-references to various Annexes, which is fine. However, I think the text "... as well as the EU-Rent examples in Annex E." is redundant since Annex E provides examples for the whole spec. Since the Note calls out specific (other) Annexes, it seemed like omitting a reference to Annex E in the Note might be read as lack of coverage there. Regarding Keri's proposal to use ".... connection" as terms -- I'm not in favor because "connection" doesn't mean anything in SBVR. "Role-of connection" sounds like it should be a kind of "connection". Here's one idea: how about "role-of proposition" and "facet-of proposition" instead of "is-role-of proposition", etc. "Connection" is now used in SBVR -- note the name of the categorization scheme that includes these elements. Since these are two of the "kinds of connection" it seemed reasonable to use that word in their terming. - Keri -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com ----- Forwarded by Mark H Linehan/Watson/IBM on 12/01/2010 09:18 AM ----- From: keri To: Donald Chapin , SBVR RTF Date: 11/29/2010 12:16 AM Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 -------------------------------------------------------------------------------- Hi, All, Ninth time's a charm ... here is the reworked Resolution, reflecting the discussion/agreement from our meeting. As I worked through the material (especially the Annex narratives) it occurred to me that more natural terms for our much-struggled-with pair of concepts might simply be: role-of connection facet-of connection What do you think? ... plus (of course) anything else you may spot. ~ Keri [attachment "SBVR Issue 13716 (v9).doc" deleted by Mark H Linehan/Watson/IBM] X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: nZEk5oMVM1n_Xb68AxJ_L1ifU341ti_xOuviUV7.m_7B19G 6kvugZI.SKik9.n3nQmu2ShF7zy5QCp8HVJYq.8xY_zxq_Jgru8dD9izY19p xdAMVhOVlr13fmSRFQ688eg6MWFw_mGZ3f.lvN9ISNC96NsE1dV2I4fQR6NX aGEZiPDYDqZ8jM1nR3UZG2Geed3qcuid1TlvUbriiOhaAraRhzUnvBnCRTJN bmUkOACOYA019fhSc6fpRCV1aLMhP8ww6BRN4YBA- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 08 Dec 2010 12:01:38 -0600 To: keri , SBVR RTF From: "Ronald G. Ross" Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 [v9.3 Updated to reflect Ron's suggestion] Cc: Donald Chapin At 06:45 PM 12/5/2010, keri wrote: Having heard no objections to Ron's suggestion, an updated version is attached. It was a little difficult to find the new change instruction, but I finally find it on p. 9 (correct?), which is, of course, the logical place for it to go. Ron - Keri On 12/1/10 12:41 PM, "Ronald G. Ross" wrote: At 04:24 PM 12/1/2010, keri wrote: Ron, Is your suggestion that the entire entry for "Elements of Concept System Structure" be moved up, so that it comes before the 11.1.5.1 sub-heading (and with the currently-lonely "unary" entry)? If so, yes, I think that's an improvement. Yes. Really doesn't work where it sits now, unless I'm missing something. Ron - Keri On Dec 1, 2010, at 12:19 PM, Ronald G. Ross wrote: All, In reviewing this new version, I have a question (refer to attached): * The entries highlighted in yellow include a Necessity about characteristic (unary fact type), which is highlighted in violet. Therefore shouldn't all those entries also go *above* the heading "11.1.5.1 Kinds of Connection"? Am I missing something about the organization of the material / sequence of changes? We moved the entry for unary fact type itself above the heading because it's not a "connection". Everything else looks pretty much in order in my first pass. Ron At 12:34 PM 12/1/2010, keri wrote: Please use these two documents (v9.2) and toss what I just sent out. I had missed reflecting some of the changes in the "how to re-order" section of the write-up. - Keri On 12/1/10 8:06 AM, "keri" wrote: Attached is the updated Resolution (v9.1), reflecting the changes from today's meeting. (A change-tracked ["CT"] version is also provided.) - Keri X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-12-08_09:2010-12-08,2010-12-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1010190000 definitions=main-1012080112 Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 [v9.3 Updated to reflect Ron's suggestion] From: keri Date: Wed, 08 Dec 2010 08:51:07 -1000 Cc: SBVR RTF , Donald Chapin To: "Ronald G. Ross" X-Mailer: Apple Mail (2.1082) Ron, Yes, it is reflected in the part of the instructions that specifies the ordering of headings & entries. Are you happy with what you see there? - Keri On Dec 8, 2010, at 8:01 AM, Ronald G. Ross wrote: At 06:45 PM 12/5/2010, keri wrote: Having heard no objections to Ron's suggestion, an updated version is attached. It was a little difficult to find the new change instruction, but I finally find it on p. 9 (correct?), which is, of course, the logical place for it to go. Ron - Keri On 12/1/10 12:41 PM, "Ronald G. Ross" wrote: At 04:24 PM 12/1/2010, keri wrote: Ron, Is your suggestion that the entire entry for "Elements of Concept System Structure" be moved up, so that it comes before the 11.1.5.1 sub-heading (and with the currently-lonely "unary" entry)? If so, yes, I think that's an improvement. Yes. Really doesn't work where it sits now, unless I'm missing something. Ron - Keri On Dec 1, 2010, at 12:19 PM, Ronald G. Ross wrote: All, In reviewing this new version, I have a question (refer to attached): * The entries highlighted in yellow include a Necessity about characteristic (unary fact type), which is highlighted in violet. Therefore shouldn't all those entries also go *above* the heading "11.1.5.1 Kinds of Connection"? Am I missing something about the organization of the material / sequence of changes? We moved the entry for unary fact type itself above the heading because it's not a "connection". Everything else looks pretty much in order in my first pass. Ron At 12:34 PM 12/1/2010, keri wrote: Please use these two documents (v9.2) and toss what I just sent out. I had missed reflecting some of the changes in the "how to re-order" section of the write-up. - Keri On 12/1/10 8:06 AM, "keri" wrote: Attached is the updated Resolution (v9.1), reflecting the changes from today's meeting. (A change-tracked ["CT"] version is also provided.) - Keri X-Yahoo-Newman-Id: 124427.14582.bm@omp1059.mail.ne1.yahoo.com X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: GsIEH6EVM1kazWMojeNcD9kXge3bBofVoWmGS9WeMrZrIj. x75qIVZ5T5Lb2Kz4M3wh02cqU0Gaj2Aedrf9fLnwzVBKt08lZ3iMPEQJyrxP TMSy_pLRexS6mQAnqeoL1FtYiIT.0Pr0T2Tg35zMYSzeuLOumVXNfrQgkASz cBAsQfqb1lesdWqRrMdrxL5JDKuQRjqi3JVC6VQz6cxxDlSFxPLF0gKGKpUt 8JvD6zwA8Khcm__62qeMN1UCzJT7suGnMccpEOGTx4A5BO9qFsrvYtZrfXFc F6qQftnYyXpprdBSJXQ-- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 08 Dec 2010 13:01:33 -0600 To: keri From: "Ronald G. Ross" Subject: Re: issue 13716 - Refactoring of Clause 11.1.5 [v9.3 Updated to reflect Ron's suggestion] Cc: SBVR RTF , Donald Chapin At 12:51 PM 12/8/2010, keri wrote: Ron, Yes, it is reflected in the part of the instructions that specifies the ordering of headings & entries. Are you happy with what you see there? Seems right to me. Ron - Keri On Dec 8, 2010, at 8:01 AM, Ronald G. Ross wrote: At 06:45 PM 12/5/2010, keri wrote: Having heard no objections to Ron's suggestion, an updated version is attached. It was a little difficult to find the new change instruction, but I finally find it on p. 9 (correct?), which is, of course, the logical place for it to go. Ron - Keri On 12/1/10 12:41 PM, "Ronald G. Ross" wrote: At 04:24 PM 12/1/2010, keri wrote: Ron, Is your suggestion that the entire entry for "Elements of Concept System Structure" be moved up, so that it comes before the 11.1.5.1 sub-heading (and with the currently-lonely "unary" entry)? If so, yes, I think that's an improvement. Yes. Really doesn't work where it sits now, unless I'm missing something. Ron - Keri On Dec 1, 2010, at 12:19 PM, Ronald G. Ross wrote: All, In reviewing this new version, I have a question (refer to attached): * The entries highlighted in yellow include a Necessity about characteristic (unary fact type), which is highlighted in violet. Therefore shouldn't all those entries also go *above* the heading "11.1.5.1 Kinds of Connection"? Am I missing something about the organization of the material / sequence of changes? We moved the entry for unary fact type itself above the heading because it's not a "connection". Everything else looks pretty much in order in my first pass. Ron At 12:34 PM 12/1/2010, keri wrote: Please use these two documents (v9.2) and toss what I just sent out. I had missed reflecting some of the changes in the "how to re-order" section of the write-up. - Keri On 12/1/10 8:06 AM, "keri" wrote: Attached is the updated Resolution (v9.1), reflecting the changes from today's meeting. (A change-tracked ["CT"] version is also provided.) - Keri