Issue 15450: [SBVR] fact type role designation (sbvr-rtf) Source: Business Rule Solutions, LLC (Ms. Keri Anderson Healy, keri_ah(at)mac.com) Nature: Uncategorized Issue Severity: Summary: In 11.2.1 we have an entry for something termed 'fact type role designation' -- its definition says that it is a "designation that represents a fact type role and that is not a placeholder " (See diagram, below.) There is nothing beyond a Definition for this concept. This entry doesn't make sense. I recommend it be dropped. (Or, if someone does see some usefulness for it, then please augment it with some notes and examples.) Resolution: Revised Text: Actions taken: September 8, 2010: received issue\ Discussion: End of Annotations:===== m -r issue15450 m -r issue15450 fpoint-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=6.0.2-1004200000 definitions=main-1009070202 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-09-07_11:2010-09-07,2010-09-07,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 07 Sep 2010 18:15:54 -0700 Subject: [SBVR] fact type role designation From: keri To: SBVR RTF Cc: OMG issues Thread-topic: [SBVR] fact type role designation Thread-index: AQHLThPlysr+c0tsbky7bcq4paNxvJMG0pywgAB4AMk= In 11.2.1 we have an entry for something termed 'fact type role designation' -- its definition says that it is a "designation that represents a fact type role and that is not a placeholder " (See diagram, below.) There is nothing beyond a Definition for this concept. This entry doesn't make sense. I recommend it be dropped. (Or, if someone does see some usefulness for it, then please augment it with some notes and examples.) Regards, Keri Date: Thu, 09 Sep 2010 13:10:54 -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] Issue 15450: fact type role designation X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: o89HAxIu015899 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1284657062.90345@ijj8Ne7Jy3MOIo8TksGcyQ X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Keri wrote: In 11.2.1 we have an entry for something termed 'fact type role designation' -- its definition says that it is a "designation that /represents /a fact type role and that /is /not a placeholder " (See diagram, below.) There is nothing beyond a Definition for this concept. This entry doesn't make sense. I recommend it be dropped. (Or, if someone does see some usefulness for it, then please augment it with some notes and examples.) I think the purpose of this thing is to cover the many glossary entries that are described as Concept Type: Role. What they really are is terms in an attribute namespace that appear as nouns or in/as noun forms of a 'has'/'of' fact type. I think the term 'attribute designation' may be more consistent with the SBVR usage. In 'has' fact type forms (and some others) the expression of these designations is marked as a placeholder, but it isn't one, it is the signifier of the attribute/role designation. Placeholders never appear in statements using the fact type -- concepts or individuals replace them -- but role/attribute designations do appear in statements using the fact type. E.g. In 'concept has instance', 'instance' is said to be concept type Role. "Instance" is a 'fact type role designation'. It is not a placeholder in the fact type form. When we speak of "an instance of _rental agreement_", we are using 'instance' as an attribute designation -- the term in the attributive namespace for '_rental agreement_', not as a placeholder. We mean "a thing that plays the role 'instance' in an actuality of 'concept has instance', in which the 'concept' role/placeholder is filled by _rental agreement_." Role designations can also appear in fact types that are not 'has' fact types. In 'concept specializes more general concept', the expression "more general concept" is both a role designation and a placeholder. One can say "bomber specializes aircraft", and in that use of the form, "more general concept" is just the placeholder for the role that is filled by 'aircraft'. On the other hand, we can say: "'Aircraft' is a more general concept of 'bomber'", and in that case, we are using "more general concept" as an attribute designation that is derived from the same fact type role. That is, 'more general concept' is an attribute of 'concept' that is defined by the fact type role in 'concept specializes more general concept', just as 'instance' is an attribute of 'concept' that is defined by the fact type role in 'concept has instance'. All of that said, it is not clear why '(fact type) role designation' appears in diagram 11.6, since the diagram does not deal with the relationships of kinds of designations to kinds of concepts. It would seem more appropriate for this concept to appear in Figure 8.4. Relative to section 8.3, a placeholder that is not an "attribute designation" ("fact type role designation") _is not_ a designation for the fact type role in the vocabulary (namespace) that contains the fact type -- it _never_ refers to the fact type role when it appears in a sentence. When a placeholder expression appears in a sentence, its vocabulary meaning is either an object type or a role type. The placeholder expression _is_, however, a designation for the fact type role within the Definition of the fact type (if any). In effect, a terminology entry for a fact type creates a local namespace in which the placeholder expression always refers to the fact type role. Outside of that entry, the placeholder expression has its vocabulary meaning (if any). From the above, my preferred resolution to this issue would be to move the concept to clause 8.3.4, where we currently blither about noun forms of fact types, and rename it "attribute designation", to go with the 'attribute namespace' concept in 8.3.5, which is intended to have exactly these creatures as its entries. -Ed __ Regards, 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: Don Baisley To: "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: RE: issue 15450 -- SBVR RTF issue Thread-Topic: issue 15450 -- SBVR RTF issue Thread-Index: AQHLT5N5awRgzau4KUyQLqD8wBfXKJMJ9EfQ Date: Thu, 9 Sep 2010 19:07:23 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.75] Here is an example glossary that should illustrate a fact type role designation, but it is hard to find it in this example. insurance policy purchase agreement effective date Definition: date on which something becomes effective Concept Type: role insurance policy has effective date insurance policy is new purchase agreement has effective date The reason it.s hard to find a fact type role designation is because we tend to leave attributive namespaces of concepts as implicit, based on fact type forms. Fact type form designations are explicit in the glossary below, which makes attributive namespaces explicit. You can see two fact type role designations below, both with the same signifier. The style of presentation below is not from SBVR structured English. It is simply a different glossary style. insurance policy Attributive Namespace: effective date (fact type role in .insurance policy has effective date.) new (characteristic) purchase agreement Attributive Namespace: effective date (fact type role in .purchase agreement has effective date.) effective date Definition: date on which something becomes effective Concept Type: role Note that a term defined in a glossary based on SBVR Structured English with its concept type given as .role. is for a situational role, not a fact type role . this is plainly stated in SBVR C.6. So the last occurrence of .effective date. above is not a fact type role designation. The concept .fact type role designation. is not interesting to me when looking at terms in the context of being used. Consider the following rule statement: Rule: An insurance policy for a car is always a new insurance policy if it has the same effective date as the purchase agreement for the car. If .effective date. in the rule statement above is a .fact type role designation., then it is two of them at the same time because it binds to two different fact type roles, one in each of the fact types defined above. .Effective date. is a term for a situational role defined in the glossary (in both styles above), and that.s how I prefer to think of it in this context of being used. My preference would be to remove .fact type role designation. from SBVR simply because nobody uses that term. But if people want to keep it for business-facing purposes, please keep it in clause 11 and give it a better, but brief, explanation. Best regards, Don From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, September 08, 2010 1:18 PM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 15450 -- SBVR RTF issue 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=6.0.2-1004200000 definitions=main-1009070202 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-09-07_11:2010-09-07,2010-09-07,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 07 Sep 2010 18:15:54 -0700 Subject: [SBVR] fact type role designation From: keri To: SBVR RTF Cc: OMG issues Thread-topic: [SBVR] fact type role designation Thread-index: AQHLThPlysr+c0tsbky7bcq4paNxvJMG0pywgAB4AMk= In 11.2.1 we have an entry for something termed 'fact type role designation' -- its definition says that it is a "designation that represents a fact type role and that is not a placeholder " (See diagram, below.) There is nothing beyond a Definition for this concept. This entry doesn't make sense. I recommend it be dropped. (Or, if someone does see some usefulness for it, then please augment it with some notes and examples.) Regards, Keri Date: Thu, 09 Sep 2010 19:23:38 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Don Baisley CC: "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: Re: issue 15450 -- SBVR RTF issue X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: o89NNhBi017599 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1284679425.57271@lMXZta7YMvHHcWCJuyYAxg X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Don Baisley wrote: Here is an example glossary that should illustrate a fact type role designation, but it is hard to find it in this example. insurance policy purchase agreement effective date Definition: date on which something becomes effective Concept Type: role insurance policy has effective date insurance policy is new purchase agreement has effective date The reason it.s hard to find a fact type role designation is because we tend to leave attributive namespaces of concepts as implicit, based on fact type forms. Fact type form designations are explicit in the glossary below, which makes attributive namespaces explicit. You can see two fact type role designations below, both with the same signifier. The style of presentation below is not from SBVR structured English. It is simply a different glossary style. insurance policy Attributive Namespace: effective date (fact type role in .insurance policy has effective date.) new (characteristic) purchase agreement Attributive Namespace: effective date (fact type role in .purchase agreement has effective date.) effective date Definition: date on which something becomes effective Concept Type: role As I read this, I think I agree. Note the definition of 'effective date': "date on which something becomes effective" This is formalized as: A date such that there is a/some thing that becomes effective on that date. By comparison, the effective date of an insurance policy is 'the date on which the policy becomes effective'. There is no doubt that the effective date of an insurance policy is an instance of 'effective date' by Don's definition, but its definition is importantly different. Its definition refers to the insurance policy in question, not to an arbitrary thing or even an arbitrary insurance policy. So the "effective date" concept for the insurance policy is not the concept that has the definition given for "effective date". As a consequence, the 'effective date' in the attribute namespace of 'insurance policy' is a different designation from the 'effective date' in the outer vocabulary; it refers to a different concept. And the same is true of the "effective date" of the purchase agreement. So there are three different concepts with the signifier 'effective date', and three different designations. That is what Don's second model shows. Will any business person ever use the vocabulary concept "effective date", as distinct from the two property concepts? No. That concept is not usefully distinct from "date". The business concept that one might want is this one: thing Attribute Namespace: effective date: Date on which the thing becomes effective (from 'thing has effective date') Then 'insurance policy' and 'purchase agreement' inherit the 'effective date' property from 'thing'. The idea here is that these 'attribute role designations' are always "of" some particular thing, and they are always defined with reference to a particular thing. Note that a term defined in a glossary based on SBVR Structured English with its concept type given as .role. is for a situational role, not a fact type role . this is plainly stated in SBVR C.6. So the last occurrence of .effective date. above is not a fact type role designation. If that is true, then SBVR is very confused. SBVR apparently declares 'cardinality' and 'maximum cardinality' to be situational roles, when in fact, the first is an attribute of a 'set', and the second is an attribute of a constraint formulation. And SBVR 'more general concept' is apparently declared to be a situational role, not an attribute of a concept, even though it is only meaningful with respect to an instance of 'concept'. In every case I have found in SBVR, the item with Concept Type: role is declared immediately before the fact type that uses that role as a "placeholder", and in every case, the meaning is an attribute of the other concept in the fact type. The useful meaning is always relative to an instance of the concept that has the namespace. (And in each case, the definition given is analogous to the useless "date of something" in Don's example above.) So apparently C.6 should be revised to correct the statement that conflicts with the actual usage. Situational roles relate to states and events that may be characterized by multiple fact types and multiple facts. They are the kinds of properties that are not linked to a specific thing. For example, "teacher" and "senior executive" are situational roles of "person". The notion 'teacher' relates to the responsibility of conveying knowledge to some other persons, but not any particular ones, usually in groups and at some times, past, present, or future. SBVR itself defines no situational roles, but the EU Rent example does: 'rental car' is a situational role of 'car', for example. It relates to having the current or past purpose of being rented, and to actually being rented under some contracts at some times, but no particular ones. The concept .fact type role designation. is not interesting to me when looking at terms in the context of being used. Consider the following rule statement: Rule: An insurance policy for a car is always a new insurance policy if it has the same effective date as the purchase agreement for the car. If .effective date. in the rule statement above is a .fact type role designation., then it is two of them at the same time because it binds to two different fact type roles, one in each of the fact types defined above. That is correct. If the term for the date the car is purchased is 'date of purchase', instead of 'effective date', the rule above would have to be rewritten: "An insurance policy for a car is always a new insurance policy if the effective date of the insurance policy is the same as the date of purchase on the purchase agreement for the car." What is actually being required is the equality of two dates, one of which is a property of the insurance policy, and is called "effective date" in the context of the insurance policy, and the other is a property of the purchase agreement, which is called "effective date" in the context of the purchase agreement. Those are in fact two different designations for two different concepts, as Don says. Attribute namespaces allow us to distinguish these designations. So Don's rule could be carefully written: "An insurance policy for a car is always a new insurance policy if the effective date of the insurance policy is the same as the effective date of the purchase agreement for the car." In this rewrite, each occurrence of 'effective date' is a different designation. OTOH, the rule as Don wrote it originally works if we add the "thing has effective date" fact type I suggested above. Then 'effective date' refers to a single property concept -- the date the thing is effective -- and the same concept applies to 'insurance policy' and 'purchase agreement', because they are both 'things'. .Effective date. is a term for a situational role defined in the glossary (in both styles above), and that.s how I prefer to think of it in this context of being used. The problem with this is that the only relationship between the situational role as defined and the insurance policy is the fact type referenced by the attribute designation. So if the intent is not to refer to the attribute designation, the presumption would have to be that that relationship is meant because there is no other relationship between 'insurance policy' and the situational role 'effective date' (which refers to no particular thing). But if you consider the example: student has math teacher student has English teacher student has gym teacher then a reference to 'the teacher of the student' refers to a situational role (teacher) but not to any specific fact type that relates the student to an instance of 'teacher', and it is ambiguous. Don would presumably require us to create more situational roles: math teacher, English teacher, gym teacher, etc. But it is entirely possible that one student's math teacher might be someone else's gym teacher. So the relationship between the student and an instance of the math teacher situational role might also be a relationship between the student and an instance of the gym teacher situational role, but it is not what is intended by "the gym teacher of the student". In each case, what is intended is the teacher that is related by an actuality of a specific fact type -- the one referenced by the attribute designation. So the idea of using a situational role and finding a default relationship doesn't work in general. Further, there is no particular reason why attributes/roles with the same name should have the some general object type. Consider 'contract has term' where 'term' is a role of 'business rule', and 'insurance policy has term', where 'term' is a role of 'time period'. It is obvious in this case that 'term' is the signifier of two different designations. In this case, the attribute namespaces containing 'term' prevent 'term' from being ambiguous. The meaning of 'term' is clear when the concept following 'term of' is identified. But no single situational role named 'term' will ever solve this problem. My preference would be to remove .fact type role designation. from SBVR simply because nobody uses that term. I can accept that. If we try to improve the confusion about roles in SBVR, we will have more endless discussions. But if people want to keep it for business-facing purposes, please keep it in clause 11 and give it a better, but brief, explanation. Keri doesn't want to keep it for business-facing purposes, because it doesn't have a 'business meaning'. From the signifier itself -- 'fact type role designation' -- one can see that this is a concept that was intended to be part of clause 8.3. Best regards, -Ed Best regards, Don From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, September 08, 2010 1:18 PM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 15450 -- SBVR RTF issue 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=6.0.2-1004200000 definitions=main-1009070202 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-09-07_11:2010-09-07,2010-09-07,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 07 Sep 2010 18:15:54 -0700 Subject: [SBVR] fact type role designation From: keri To: SBVR RTF Cc: OMG issues Thread-topic: [SBVR] fact type role designation Thread-index: AQHLThPlysr+c0tsbky7bcq4paNxvJMG0pywgAB4AMk= In 11.2.1 we have an entry for something termed 'fact type role designation' -- its definition says that it is a "designation that represents a fact type role and that is not a placeholder " (See diagram, below.) There is nothing beyond a Definition for this concept. This entry doesn't make sense. I recommend it be dropped. (Or, if someone does see some usefulness for it, then please augment it with some notes and examples.) Regards, 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 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1009220189 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-09-22_10:2010-09-22,2010-09-22,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Wed, 22 Sep 2010 13:33:05 -0700 Subject: Re: [Issue 15450] fact type role designation From: keri To: "Donald R. Chapin" , SBVR RTF Thread-topic: [Issue 15450] fact type role designation Thread-index: AQHLThPlysr+c0tsbky7bcq4paNxvJMG0pywgAB4AMmAF0P0Gg== Thanks to Ed and Don for the clarifying discussion. My preference is still to remove this entry, but if it is to be retained here is an improved definition: ~ Keri On 9/7/10 6:15 PM, "keri" wrote: In 11.2.1 we have an entry for something termed 'fact type role designation' -- its definition says that it is a "designation that represents a fact type role and that is not a placeholder " (See diagram, below.) There is nothing beyond a Definition for this concept. This entry doesn't make sense. I recommend it be dropped. (Or, if someone does see some usefulness for it, then please augment it with some notes and examples.) 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=6.0.2-1004200000 definitions=main-1009230203 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-09-23_14:2010-09-24,2010-09-23,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Thu, 23 Sep 2010 15:27:56 -0700 Subject: Re: issue 15450 -- SBVR RTF issue - Resolution From: keri To: SBVR RTF Thread-topic: issue 15450 -- SBVR RTF issue - Resolution Thread-index: ActbbpG/0Hi7UcdhEd+JjgARJM+Cgg== All, As discussed at today's meeting, I have attached a proposed Resolution. Keri On 9/8/10 1:18 PM, "Juergen Boldt" wrote: 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=6.0.2-1004200000 definitions=main-1009070202 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-09-07_11:2010-09-07,2010-09-07,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 07 Sep 2010 18:15:54 -0700 Subject: [SBVR] fact type role designation From: keri To: SBVR RTF Cc: OMG issues Thread-topic: [SBVR] fact type role designation Thread-index: AQHLThPlysr+c0tsbky7bcq4paNxvJMG0pywgAB4AMk= In 11.2.1 we have an entry for something termed 'fact type role designation' -- its definition says that it is a "designation that represents a fact type role and that is not a placeholder " (See diagram, below.) There is nothing beyond a Definition for this concept. This entry doesn't make sense. I recommend it be dropped. (Or, if someone does see some usefulness for it, then please augment it with some notes and examples.) Regards, Keri -------------------------------------------------------------------------------- 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 Issue15450-RESOLUTION.doc To: sbvr-rtf@omg.org Subject: Re: issue 15450 -- SBVR RTF issue - Resolution X-KeepSent: 486EB8A3:A6E6A1F6-852577A8:00658973; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Mark H Linehan Date: Fri, 24 Sep 2010 14:43:31 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 09/24/2010 14:43:35, Serialize complete at 09/24/2010 14:43:35 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. 2. We do not have a fact type "placeholder uses designation" as referenced in the proposed Note. 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". 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. -------------------------------- 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 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1004200000 definitions=main-1009250138 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-09-25_06:2010-09-25,2010-09-25,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Sat, 25 Sep 2010 13:44:31 -0700 Subject: Re: issue 15450 -- SBVR RTF issue - Resolution From: keri To: Mark H Linehan , SBVR RTF Thread-topic: issue 15450 -- SBVR RTF issue - Resolution Thread-index: Actc8nQbsuLXG8jlEd+6YAARJM+Cgg== 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 To: sbvr-rtf@omg.org Subject: Re: issue 15450 -- SBVR RTF issue - Resolution X-KeepSent: B63DAF80:97661690-852577AB:00616517; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Mark H Linehan Date: Mon, 27 Sep 2010 13:47:39 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 09/27/2010 13:47:41, Serialize complete at 09/27/2010 13:47:41 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". 2) Changing "placeholder uses designation" to instead be "placeholder uses fact type role designation". 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. 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 fpoint-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=6.0.2-1004200000 definitions=main-1010030149 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-10-03_07:2010-10-03,2010-10-03,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Sun, 03 Oct 2010 15:14:32 -0700 Subject: Re: issue 15450 -- SBVR RTF issue - Resolution From: keri To: Mark H Linehan , SBVR RTF Thread-topic: issue 15450 -- SBVR RTF issue - Resolution Thread-index: ActjSFqomW1VgM87Ed+2MAARJM+Cgg== 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 Issue15450-RESOLUTION v2.doc Subject: Re: issue 15450 -- SBVR RTF issue - Resolution X-KeepSent: F6CDBD8A:0BE759B5-852577B2:00447217; type=4; name=$KeepSent To: SBVR RTF X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Mark H Linehan Date: Mon, 4 Oct 2010 08:53:16 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 10/04/2010 08:53:42 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 keri ---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] 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=6.0.2-1004200000 definitions=main-1010040099 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-10-04_07:2010-10-04,2010-10-04,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 04 Oct 2010 08:28:58 -0700 Subject: Re: issue 15450 -- SBVR RTF issue - Resolution From: keri To: Donald Chapin Cc: Mark H Linehan , SBVR RTF Thread-topic: issue 15450 -- SBVR RTF issue - Resolution Thread-index: Actj2NzgG5gLFs/MEd+XXwARJM+Cgg== Donald, Please put this issue on Friday's agenda. It looks like it needs more discussion. Thanks. Keri On 10/4/10 5:53 AM, "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 keri ---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] Date: Mon, 04 Oct 2010 15:05:36 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Mark H Linehan CC: SBVR RTF Subject: Re: issue 15450 -- SBVR RTF issue - Resolution X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: o94J5fXo015660 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1286823946.82178@FP4MoAk+sDlbxUTHH1gJgQ X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov 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." 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-1010040160 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-10-04_07:2010-10-04,2010-10-04,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 04 Oct 2010 12:58:29 -0700 Subject: Re: issue 15450 -- SBVR RTF issue - Resolution From: keri To: Ed Barkmeyer , SBVR RTF Thread-topic: issue 15450 -- SBVR RTF issue - Resolution Thread-index: Actj/oOLwicLD8/xEd+0TwARJM+Cgg== 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] Issue15450-EXAMPLE1.doc Issue15450-EXAMPLE2.doc X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: EsW_S2YVM1lRBVaF.zTsAPpF1qm92Y4RdwS6Vl.ig8SivT6 acRepWy8uUPzwlumqluNYj3K3pQ2rSJt0XQPLiTtdn3Inm_DfcIwvQ0oG0yk 8EQJUaZuOq1cUJskKdeBY_grchy7B8e46.VXv0IdyDdNdRgLsRP7ELZ2ASMy uJO.r_ojW9ZVWHsE33vxr2janF2UP9Yc0tgEL3zgsaeqlWzQJCTldJ.gB6gN SqkKAWg.trYbkTWqC7ORoAdFHb_mC4f8- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 04 Oct 2010 15:28:50 -0500 To: keri , Ed Barkmeyer , SBVR RTF From: "Ronald G. Ross" Subject: Re: issue 15450 -- SBVR RTF issue - Resolution All, I strongly agree with Keri that discussion of "attributive name space" has no place in Clause 11, a business-facing side of SBVR. The need for "fact type role designation" in Clause 11 is straightforward. Example: Noun concept: Party Noun concept: Policy Fact Type: Party holds Policy Role of Party: Policyholder Fact Type with Role of Party: Party [Policyholder] holds Policy "Policyholder" is a fact type role designation in: Party [Policyholder] holds Policy It shouldn't require hoops to define something that straightforward. From a Clause 11 perspective, it is simply 'designation for a role in a fact type'. The meaning of that statement (definition) is surely understandable from the content of the other Clauses(?!). If not, SBVR is in trouble. Clause 11 isn't trying to define anything new here. What am I missing? Ron At 02:58 PM 10/4/2010, keri wrote: 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] From: Don Baisley To: "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: RE: issue 15450 -- SBVR RTF issue - Resolution Thread-Topic: issue 15450 -- SBVR RTF issue - Resolution Thread-Index: ActkAKXDs1WD5lKYS4CF4rlwTMBwxg== Date: Mon, 4 Oct 2010 20:29:57 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] 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 .buyer. used 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 .birthdate. used in the phrase, .the person.s 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] From: Don Baisley To: SBVR RTF Subject: RE: issue 15450 -- SBVR RTF issue - Resolution Thread-Topic: issue 15450 -- SBVR RTF issue - Resolution Thread-Index: AQHLW27i0mnjVfOBkkyGf6NFlWIriJMh7z+AgAG0JICAAvM/gIAJuI4AgAD1hACAAGgHAIAADseAgAAIegD//4vsoA== Date: Mon, 4 Oct 2010 20:37:22 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] I agree with Ron. I hope the proposed resolution I just sent out fits his need. Ron.s example is a good one and could be used in place of either of the examples I gave. .policyholder. is a fact type role designation for the .party. role in the fact type .party holds policy.. Regards, Don From: Ronald G. Ross [mailto:rross@BRSolutions.com] Sent: Monday, October 04, 2010 1:29 PM To: keri; Ed Barkmeyer; SBVR RTF Subject: Re: issue 15450 -- SBVR RTF issue - Resolution All, I strongly agree with Keri that discussion of "attributive name space" has no place in Clause 11, a business-facing side of SBVR. The need for "fact type role designation" in Clause 11 is straightforward. Example: Noun concept: Party Noun concept: Policy Fact Type: Party holds Policy Role of Party: Policyholder Fact Type with Role of Party: Party [Policyholder] holds Policy "Policyholder" is a fact type role designation in: Party [Policyholder] holds Policy It shouldn't require hoops to define something that straightforward. From a Clause 11 perspective, it is simply 'designation for a role in a fact type'. The meaning of that statement (definition) is surely understandable from the content of the other Clauses(?!). If not, SBVR is in trouble. Clause 11 isn't trying to define anything new here. What am I missing? Ron At 02:58 PM 10/4/2010, keri wrote: 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] Subject: Re: issue 15450 -- SBVR RTF issue - Resolution X-KeepSent: 7FD37C86:D83AE4B5-852577B2:0075712A; type=4; name=$KeepSent To: SBVR RTF X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Mark H Linehan Date: Mon, 4 Oct 2010 17:29:16 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 10/04/2010 17:29:43 Comments 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 "Ronald G. Ross" ---10/04/2010 04:31:22 PM---All, I strongly agree with Keri that discussion of "attributive name space" has no place i From: "Ronald G. Ross" To: keri , Ed Barkmeyer , SBVR RTF Date: 10/04/2010 04:31 PM Subject: Re: issue 15450 -- SBVR RTF issue - Resolution -------------------------------------------------------------------------------- All, I strongly agree with Keri that discussion of "attributive name space" has no place in Clause 11, a business-facing side of SBVR. The need for "fact type role designation" in Clause 11 is straightforward. Example: Noun concept: Party Noun concept: Policy Fact Type: Party holds Policy Role of Party: Policyholder Fact Type with Role of Party: Party [Policyholder] holds Policy This is not a syntax described in SBVR Structured English annex C.3.1. I believe you would do it this way: Policyholder Concept Type: role General Concept: Party Policyholder holds Policy "Policyholder" is a fact type role designation in: Party [Policyholder] holds Policy "Policyholder" is a placeholder in the fact type form "Policyholder holds Policy" for a fact type role that ranges over the situational role "policyholder". It shouldn't require hoops to define something that straightforward. From a Clause 11 perspective, it is simply 'designation for a role in a fact type'. The meaning of that statement (definition) is surely understandable from the content of the other Clauses(?!). If not, SBVR is in trouble. Clause 11 isn't trying to define anything new here. What am I missing? "Designation for a role in a fact type" sounds a lot like the definition of "placeholder", which 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 " I agree with Ron's comment in another email, that we should just drop "fact type role designation". Ron At 02:58 PM 10/4/2010, keri wrote: 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] To: sbvr-rtf@omg.org Subject: RE: issue 15450 -- SBVR RTF issue - Resolution X-KeepSent: 26AC8951:74C14C4D-852577B2:00760D12; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Mark H Linehan Date: Mon, 4 Oct 2010 17:33:12 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 10/04/2010 17:33:13, Serialize complete at 10/04/2010 17:33:13 Comments 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 From: Don Baisley To: "'SBVR RTF' (sbvr-rtf@omg.org)" Date: 10/04/2010 04:31 PM Subject: RE: issue 15450 -- SBVR RTF issue - Resolution -------------------------------------------------------------------------------- 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 I don't know what "in a context of being attributed to instances of another role of the same fact type" means. The designation of one role is attributed to another role?? Necessity: No fact type role designation is a placeholder Even though placeholders are designations for fact type roles? Note: A fact type role designation typically combines the senses of both a noun and a verb, as in the examples below.The examples do not support this note. Example: the fact type role designation âbuyerâ used in the phrase, âthe buyer of a productâ, to refer to the âpersonâ role in âperson buys productâ (a.k.a. âproduct has buyerâ). "Buyer" is never a verb. One does not "buyer a product". Example: the fact type role designation âbirthdateâ used in the phrase, âthe personâs birthdateâ, to refer to the âdateâ role in âperson is born on dateâ (a.k.a. âperson has birthdateâ). "Birthdate" is never a verb. 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] From: Don Baisley To: "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: RE: issue 15450 -- SBVR RTF issue - Resolution Thread-Topic: issue 15450 -- SBVR RTF issue - Resolution Thread-Index: ActkAKXDs1WD5lKYS4CF4rlwTMBwxgABoPl/AAFf3RA= Date: Mon, 4 Oct 2010 21:47:28 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Ron, You have convinced me. We should do one of two things: 1. Drop the term .fact type role designation. from SBVR. OR 2. Define it simply as .designation of a fact type role.. With this simple definition we don.t care whether it is a placeholder. How about this? fact type role designation Definition: designation of a fact type role Example: the fact type role designation 'policyholder' whose meaning is the 'party' role in the fact type 'party holds policy' Regards, Don From: Ronald G. Ross [mailto:rross@BRSolutions.com] Sent: Monday, October 04, 2010 2:00 PM To: Don Baisley; 'SBVR RTF' (sbvr-rtf@omg.org) Subject: RE: issue 15450 -- SBVR RTF issue - Resolution 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". * 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". 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. Seems to me we're making a simple thing really hard. Nothing more complicated that the concept I defined above is needed for Clause 11. 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. 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 ?buyer? used 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 ?birthdate? used in the phrase, ?the person?s 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] Date: Mon, 04 Oct 2010 19:31:29 -0400 From: Ed 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: issue 15450 -- SBVR RTF issue - Resolution X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: o94NVYFp005959 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1286839896.46589@WlYmiT3Fi570b1R+VyzuCQ X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov 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 person 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." To: sbvr-rtf@omg.org Subject: RE: issue 15450 -- SBVR RTF issue - Resolution X-KeepSent: A8AFE25D:E1995CC7-852577B3:0005ACA1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Mark H Linehan Date: Mon, 4 Oct 2010 21:05:18 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 10/04/2010 21:05:19, Serialize complete at 10/04/2010 21:05:19 I prefer #1. With #2, we can't ignore that we also have "placeholder" defined as "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 ". I think it would incumbent on us to explain how a "fact type role designation" is different from a "placeholder". Otherwise, if vendors ever implement this stuff, some may regard designations of fact type roles as "placeholders" and others will pick "fact type role designation" and both will be right and they will not interoperate. -------------------------------- 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: "'SBVR RTF' (sbvr-rtf@omg.org)" Date: 10/04/2010 05:50 PM Subject: RE: issue 15450 -- SBVR RTF issue - Resolution -------------------------------------------------------------------------------- Ron, You have convinced me. We should do one of two things: 1. Drop the term âfact type role designationâ from SBVR. OR 2. Define it simply as âdesignation of a fact type roleâ. With this simple definition we donât care whether it is a placeholder. How about this? fact type role designation Definition: designation of a fact type role Example: the fact type role designation 'policyholder' whose meaning is the 'party' role in the fact type 'party holds policy' Regards, Don From: Ronald G. Ross [mailto:rross@BRSolutions.com] Sent: Monday, October 04, 2010 2:00 PM To: Don Baisley; 'SBVR RTF' (sbvr-rtf@omg.org) Subject: RE: issue 15450 -- SBVR RTF issue - Resolution 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". * 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". 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. Seems to me we're making a simple thing really hard. Nothing more complicated that the concept I defined above is needed for Clause 11. 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. 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 ?buyer? used 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 ?birthdate? used in the phrase, ?the person?s 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] 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-1010040224 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15,1.0.148,0.0.0000 definitions=2010-10-04_09:2010-10-05,2010-10-04,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Mon, 04 Oct 2010 18:15:01 -0700 Subject: Re: issue 15450 -- SBVR RTF issue - Resolution From: keri To: Mark H Linehan , SBVR RTF Thread-topic: issue 15450 -- SBVR RTF issue - Resolution Thread-index: ActkKruo+japstAdEd+wYwARJM+Cgg== I agree with Mark. The definition is now so simple that we really don't need a special concept/term for it ... we can just say "designation of a fact type role" when that's what we mean. - Keri On 10/4/10 6:05 PM, "Mark H Linehan" wrote: I prefer #1. With #2, we can't ignore that we also have "placeholder" defined as "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 ". I think it would incumbent on us to explain how a "fact type role designation" is different from a "placeholder". Otherwise, if vendors ever implement this stuff, some may regard designations of fact type roles as "placeholders" and others will pick "fact type role designation" and both will be right and they will not interoperate. -------------------------------- 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: "'SBVR RTF' (sbvr-rtf@omg.org)" Date: 10/04/2010 05:50 PM Subject: RE: issue 15450 -- SBVR RTF issue - Resolution -------------------------------------------------------------------------------- Ron, You have convinced me. We should do one of two things: 1. Drop the term .fact type role designation. from SBVR. OR 2. Define it simply as .designation of a fact type role.. With this simple definition we don.t care whether it is a placeholder. How about this? fact type role designation Definition: designation of a fact type role Example: the fact type role designation 'policyholder' whose meaning is the 'party' role in the fact type 'party holds policy' Regards, Don From: Ronald G. Ross [mailto:rross@BRSolutions.com ] Sent: Monday, October 04, 2010 2:00 PM To: Don Baisley; 'SBVR RTF' (sbvr-rtf@omg.org) Subject: RE: issue 15450 -- SBVR RTF issue - Resolution 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". * 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". 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. Seems to me we're making a simple thing really hard. Nothing more complicated that the concept I defined above is needed for Clause 11. 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. 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 ?buyer? used 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 ?birthdate? used in the phrase, ?the person?s 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] From: Don Baisley To: keri , Mark H Linehan , SBVR RTF Subject: RE: issue 15450 -- SBVR RTF issue - Resolution Thread-Topic: issue 15450 -- SBVR RTF issue - Resolution Thread-Index: ActkAKXDs1WD5lKYS4CF4rlwTMBwxgABoPl/AAFf3RAAFdjbAAAAVuCAAA28D3A= Date: Tue, 5 Oct 2010 01:45:58 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Like Keri and Mark, I am happy with option 1. But if option 1 is unacceptable, then .placeholder. clearly specializes .fact type role designation. as defined below because .placeholder. incorporates the additional characteristic of being within a fact type form, marking a place .. The definitions are different, so the concepts are different. Enjoy, Don From: keri [mailto:keri_ah@mac.com] Sent: Monday, October 04, 2010 6:15 PM To: Mark H Linehan; SBVR RTF Subject: Re: issue 15450 -- SBVR RTF issue - Resolution I agree with Mark. The definition is now so simple that we really don't need a special concept/term for it ... we can just say "designation of a fact type role" when that's what we mean. - Keri On 10/4/10 6:05 PM, "Mark H Linehan" wrote: I prefer #1. With #2, we can't ignore that we also have "placeholder" defined as "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 ". I think it would incumbent on us to explain how a "fact type role designation" is different from a "placeholder". Otherwise, if vendors ever implement this stuff, some may regard designations of fact type roles as "placeholders" and others will pick "fact type role designation" and both will be right and they will not interoperate. -------------------------------- 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: "'SBVR RTF' (sbvr-rtf@omg.org)" Date: 10/04/2010 05:50 PM Subject: RE: issue 15450 -- SBVR RTF issue - Resolution -------------------------------------------------------------------------------- Ron, You have convinced me. We should do one of two things: 1. Drop the term .fact type role designation. from SBVR. OR 2. Define it simply as .designation of a fact type role.. With this simple definition we don.t care whether it is a placeholder. How about this? fact type role designation Definition: designation of a fact type role Example: the fact type role designation 'policyholder' whose meaning is the 'party' role in the fact type 'party holds policy' Regards, Don From: Ronald G. Ross [mailto:rross@BRSolutions.com ] Sent: Monday, October 04, 2010 2:00 PM To: Don Baisley; 'SBVR RTF' (sbvr-rtf@omg.org) Subject: RE: issue 15450 -- SBVR RTF issue - Resolution 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". * 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". 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. Seems to me we're making a simple thing really hard. Nothing more complicated that the concept I defined above is needed for Clause 11. 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. 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 ?buyer? used 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 ?birthdate? used in the phrase, ?the person?s 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] Date: Tue, 05 Oct 2010 11:18:36 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Don Baisley CC: SBVR RTF Subject: Re: issue 15450 -- SBVR RTF issue - Resolution X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: o95FIfeb019360 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1286896725.76943@oZr5TNY6iElScu4WZyZfUg X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Don Baisley wrote: Like Keri and Mark, I am happy with option 1. Frankly, Scarlett... But if option 1 is unacceptable, then .placeholder. clearly specializes .fact type role designation. as defined below because .placeholder. incorporates the additional characteristic of being within a fact type form, marking a place .. The definitions are different, so the concepts are different. I think they are importantly different. As defined, a placeholder is a syntactic convention -- a syntactic slot that is replaced in every use of the fact type. Thus, the placeholder _never_ appears in a sentence; it has no business usage. The intent of a "fact type role designation" is that it is a term used in business to denote the thing that plays a given role in some actualities of the fact type. That said, it is not clear to me what is used to denote the role in the Definition of the fact type. Dictionaries define fact types by synonyms and circumlocutions for the verb, and occasionally include parenthetical expressions to refer to the concepts that play the roles. Formal logic defines fact types by explicitly denoting the roles with "variable names" (as does clause 9) and then using the variables in the definition. I believe that the SBVR practice is similar to the formal logic practice -- the placeholders are used to refer to the fact type roles within the Definitions. And one sees that clause 13 maps placeholders to column names (owned ends of Associations), which means that they do appear in SQL and Java sentences -- they do have a technical business usage. All in all, I think SBVR confuses "placeholder" -- a syntactic thingy -- with "role designation" -- a term for the fact type role that has some business usage in fairly well-defined contexts. In most cases, that context is the fact type itself -- its definitions and discussions or its explicit usage in qualifying the signifier. And in most cases outside of that context, the role signifier refers to the concept that is the 'range' of the role, rather than to the role, e.g. "date" is the role designation in 'person is born on date', but it refers to the general concept 'date' in most business uses. The exception is role designations like "birthdate", which is used as a designation for the role in a much wider context than the terminological entry and its technical derivatives. -Ed P.S. I keep writing this stuff, because this has been a big issue in the development of our tooling, and we have sought to get a clear resolution, but the FTF and RTF have been of little assistance in doing so. Enjoy, Don *From:* keri [mailto:keri_ah@mac.com] *Sent:* Monday, October 04, 2010 6:15 PM *To:* Mark H Linehan; SBVR RTF *Subject:* Re: issue 15450 -- SBVR RTF issue - Resolution I agree with Mark. The definition is now so simple that we really don't need a special concept/term for it ... we can just say "designation of a fact type role" when that's what we mean. - Keri On 10/4/10 6:05 PM, "Mark H Linehan" > wrote: I prefer #1. With #2, we can't ignore that we also have "placeholder" defined as "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 ". I think it would incumbent on us to explain how a "fact type role designation" is different from a "placeholder". Otherwise, if vendors ever implement this stuff, some may regard designations of fact type roles as "placeholders" and others will pick "fact type role designation" and both will be right and they will not interoperate. -------------------------------- 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: "'SBVR RTF' (sbvr-rtf@omg.org )" > Date: 10/04/2010 05:50 PM Subject: RE: issue 15450 -- SBVR RTF issue - Resolution ------------------------------------------------------------------------ Ron, You have convinced me. We should do one of two things: 1. Drop the term .fact type role designation. from SBVR. OR 2. Define it simply as .designation of a fact type role.. With this simple definition we don.t care whether it is a placeholder. How about this? fact type role designation Definition: designation of a fact type role Example: the fact type role designation 'policyholder' whose meaning is the '_party_' role in the fact type '_party_ holds _policy_' Regards, Don *From:* Ronald G. Ross [mailto:rross@BRSolutions.com ] *Sent:* Monday, October 04, 2010 2:00 PM *To:* Don Baisley; 'SBVR RTF' (sbvr-rtf@omg.org ) *Subject:* RE: issue 15450 -- SBVR RTF issue - Resolution 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". * 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". 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. Seems to me we're making a simple thing really hard. Nothing more complicated that the concept I defined above is needed for Clause 11. 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. 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 ?buyer? used 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 ?birthdate? used in the phrase, ?the person?s 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" <_edbark@nist.gov_ > 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 <_keri_ah@mac.com_ > >> To: Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF <_sbvr-rtf@omg.org_ > >> 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" <_mlinehan@us.ibm.com_ > 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 <_keri_ah@mac.com_ > >> To: Mark H Linehan/Watson/IBM@IBMUS, SBVR RTF >> <_sbvr-rtf@omg.org_ > >> 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" >> <_mlinehan@us.ibm.com_ > 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." From: Don Baisley To: "'SBVR RTF' (sbvr-rtf@omg.org)" Subject: RE: issue 15450 -- SBVR RTF issue Thread-Topic: issue 15450 -- SBVR RTF issue Thread-Index: AQHLT5N5awRgzau4KUyQLqD8wBfXKJRF+tZw Date: Tue, 29 Mar 2011 20:21:06 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.70] In our SBVR meeting I agreed to carefully look over the example in .13.6.4 XML Patterns for Fact Types. for .Synonymous Form: example1 has prior example.. I checked it and it is correct. An XML tag that caught our attention in the meeting was .sbvr:thing1IsThing2.. It is used because the example has a term that is a fact type role designation, but neither of the concepts .term. and .fact type role designation. is a specialization of the other. So the XML has a separate element for each of those concepts. The .sbvr:thing1IsThing2. tag indicates that the two elements are for the same thing. This is all correct. Regards, Don From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, September 08, 2010 1:18 PM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 15450 -- SBVR RTF issue 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=6.0.2-1004200000 definitions=main-1009070202 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-09-07_11:2010-09-07,2010-09-07,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 07 Sep 2010 18:15:54 -0700 Subject: [SBVR] fact type role designation From: keri To: SBVR RTF Cc: OMG issues Thread-topic: [SBVR] fact type role designation Thread-index: AQHLThPlysr+c0tsbky7bcq4paNxvJMG0pywgAB4AMk= In 11.2.1 we have an entry for something termed 'fact type role designation' -- its definition says that it is a "designation that represents a fact type role and that is not a placeholder " (See diagram, below.) There is nothing beyond a Definition for this concept. This entry doesn't make sense. I recommend it be dropped. (Or, if someone does see some usefulness for it, then please augment it with some notes and examples.) Regards, Keri From: Don Baisley To: "sbvr-rtf@omg.org" Subject: RE: issue 15450 -- SBVR RTF issue Thread-Topic: issue 15450 -- SBVR RTF issue Thread-Index: AQHLT5N5awRgzau4KUyQLqD8wBfXKJTFF0Pg Date: Sat, 18 Jun 2011 19:08:52 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] A resolution to SBVR issue 15450 is attached. It is based on notes from the March 24 SBVR meeting: Ø Issue 15450 .fact type role designation. § Add a Note explaining the usefulness of having names (fact type role designations) for Fact Type Roles separate from any Fact Type Form, and make it clear that fact type role designations existing in the model separate from any Fact Type Form. § Adding a note on how to disambiguation situational role names from fact type role names if they have the same signifier. § Make it clear that fact type role designations are not required to define a placeholder, but that they can be used to do so. § Add a Note pointing out examples of fact type role designations in Clause 13.6.4 · Used independent of any fact type form · Used to specify a placeholder of a fact type form § Add a note to contrast fact type roles and their names from situational roles and their names making it clear that fact type roles exist only in the context of a given fact type and that situational roles exist separate from any fact type, but are defined in terms of one or more specific fact type roles. § There may a missing SBVR fact type to connect situational role to the fact type roles that define it. [The connection is through definition.] § Don B. will verify the correctness of the examples in Clause 13.6.4. [Verified. OK] Regards, Don From: Juergen Boldt [mailto:juergen@omg.org] Sent: Wednesday, September 08, 2010 1:18 PM To: issues@omg.org; sbvr-rtf@omg.org Subject: issue 15450 -- SBVR RTF issue 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=6.0.2-1004200000 definitions=main-1009070202 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.0.10011,1.0.148,0.0.0000 definitions=2010-09-07_11:2010-09-07,2010-09-07,1970-01-01 signatures=0 User-Agent: Microsoft-Entourage/11.4.0.080122 Date: Tue, 07 Sep 2010 18:15:54 -0700 Subject: [SBVR] fact type role designation From: keri To: SBVR RTF Cc: OMG issues Thread-topic: [SBVR] fact type role designation Thread-index: AQHLThPlysr+c0tsbky7bcq4paNxvJMG0pywgAB4AMk= In 11.2.1 we have an entry for something termed 'fact type role designation' -- its definition says that it is a "designation that represents a fact type role and that is not a placeholder " (See diagram, below.) There is nothing beyond a Definition for this concept. This entry doesn't make sense. I recommend it be dropped. (Or, if someone does see some usefulness for it, then please augment it with some notes and examples.) Regards, Keri SBVR Issue 15450.doc Disposition: Resolved OMG Issue No: 15450 Title: Fact Type Role Designation Source: Keri Anderson Healy, keri_ah@mac.com Summary: In 11.2.1 we have an entry for something termed .fact type role designation. . its definition says that it is a .designation that represents a fact type role and that is not a placeholder.. There is nothing beyond a Definition for this concept. This entry doesn.t make sense. I recommend it be dropped. (Or, if someone does see some usefulness for it, then please augment it with some notes and examples.). Resolution: Add notes and examples to clarify the use of fact type role designations. Revised Text: In 11.2.1.2 ADD the following to the end of the entry for .fact type role designation.. Note: A placeholder is a designation of a fact type role that is within a fact type form. By convention in this specification (see C.1.2), a binary fact type form fitting the pattern . has . (e.g., .corporation has CEO.) whose first placeholder uses a designation of an object type (e.g., .corporation.) implies that an attributive namespace of that object type includes a fact type role designation having the same expression as the second placeholder (e.g., .CEO.). The fact type role designation is not the placeholder because it is understood independently of the fact type form and can exist even when there is no fact type form. Some conventions and tools lead to business vocabularies that include fact type role designations explicitly within attributive namespaces rather than including fact type forms of the pattern . has .. Example: Using UML attribute notation, a binary fact type is defined. One role has a fact type role designation, .CEO.. Note: A fact type role designation should not be confused with a designation for a situational role. Example: The fact type role designation, .CEO., for a role in the fact type .corporation has CEO. does not represent a situational role, .CEO.. The fact type role designation always represents the role in the fact type, as in the phrases .EU-Rent.s CEO. and .the CEO of some corporation.. But the situational role, even if defined in terms of the fact type, can be used independently, as in the statement .Every CEO is a person.. Note: Clause 13.6.4 shows an example of a fact type role designation, .prior example., and also shows examples of fact type roles having no fact type role designation. Disposition: Resolved From: Don Baisley To: "sbvr-rtf@omg.org" Subject: RE: issue 15450 -- SBVR RTF issue Thread-Topic: issue 15450 -- SBVR RTF issue Thread-Index: AQHLT5N5awRgzau4KUyQLqD8wBfXKJTFF0PggAyy/BA= Date: Sun, 26 Jun 2011 19:11:44 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.35] Here is an updated resolution to issue 15450 based on discussion at the last SBVR meeting. Best regards, Don SBVR Issue 154501.doc Disposition: Resolved OMG Issue No: 15450 Title: Fact Type Role Designation Source: Keri Anderson Healy, keri_ah@mac.com Summary: In 11.2.1 we have an entry for something termed .fact type role designation. . its definition says that it is a .designation that represents a fact type role and that is not a placeholder.. There is nothing beyond a Definition for this concept. This entry doesn.t make sense. I recommend it be dropped. (Or, if someone does see some usefulness for it, then please augment it with some notes and examples.). Resolution: Revise the definition of .fact type role designation. and add structural rules, notes and an example. Also, correct a problem in the XML example of a fact type role designation which mistakenly showed the fact type role designation as being a term. A clarification to the representation of multiclassification in models is added. Revised Text: In 11.2.1.2 REPLACE definition in the entry for .fact type role designation. with the following: Definition: designation that is of a fact type role and that is recognizable in use in the context of being attributed to what fills another role of the same fact type Necessity: No fact type role designation is a term. Necessity: No fact type role designation is a placeholder. Note: A fact type role designation should not be confused with a term for a situational role. A situational role is an object type and is not a fact type role. Note: A fact type role designation should not be confused with a placeholder, which is part of a fact type form. In uses of a fact type form, placeholders are replaced, so a fact type role designation can replace a placeholder in a use of a fact type form, but the two are not the same designation. Example: The fact type role designation, .CEO., for a role in the fact type .corporation has CEO. does not represent a situational role, .CEO. and is not the same thing as the .CEO. placeholder, in that fact type form. The fact type role designation represents the role in the fact type, as in the phrases .EU-Rent.s CEO. and .the CEO of some corporation.. But the situational role, even if defined in terms of the fact type, can be used independently, as in the statement .Every CEO is a person.. The placeholder .CEO. of the fact type form .corporation has CEO. is part of the form and gets replaced in each use of the form. Note: Clause 13.6.4 shows an example of a fact type role designation, .prior example., and also shows examples of fact type roles having no fact type role designation. At the end of the first paragraph of 13.3.1 ADD the following sentence: A consumer of a model in which two elements represent the same thing should not assume that each fact about the thing is represented redundantly using two links, one to each element. In 13.6.4 in the XML shown for .Synonymous Form: example1 has prior example., REMOVE the following two lines: Immediately above the two removed lines, in the line that looks like this: REPLACE .term. with .factTypeRoleDesignation. so that the line looks like this: Disposition: Resolved Subject: RE: issue 15450 -- SBVR RTF issue X-KeepSent: 2139D365:DF7A69B1-852578BC:00087490; type=4; name=$KeepSent To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Sun, 26 Jun 2011 21:52:38 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 06/26/2011 21:52:39 X-MIME-Autoconverted: from base64 to 8bit by amethyst.omg.org id p5R1jRc1020210 For me, at least, this doesn't really resolve the open issue. The proposed definition is "designation that is of a fact type role and that is recognizable in use in the context of being attributed to what fills another role of the same fact type". This sounds like a backdoor means for introducing attributes into SBVR. If that's what it's about, then I think the proper approach is to define the concept of attributes and say that a fact type role designation is a designation of an attribute. Comment: presumably a fact type role designation is in the namespace of whatever "fills another role of the same fact type". It would help if a note said that. I think the Necessity: "No fact type role designation is a placeholder." needs further explanation. I know you try to address it in the Note and Example, but the reason just doesn't come through. In the fact type form, "corporation has CEO", clearly the designation "CEO" is a placeholder. Then the assertion that "The fact type role designation, âCEOâ, ... is not the same thing as the âCEOâ placeholder, in that fact type form" deserves an explanation as to why not. I THINK what you are saying is that propositions that use the designation CEO, in uses of this fact type, are referring explicitly to the attribute "corporation's CEO". So the distinction is between the placeholder in the fact type form itself, and the fact type role designation in a proposition based on the fact type. Is that right? If so, we should say so. Suggestion: consider renaming "fact type role designation" as "attribute" or "attribute designation" because that's what it is. The proposed additional sentence for 13.3.1 reads "A consumer of a model in which two elements represent the same thing should not assume that each fact about the thing is represented redundantly using two links, one to each element." This is again a statement in the negative. I think it would be much more useful to make a positive statement, such as "When two elements represent the same thing, properties of one element also apply to the other element. A producer of a model may associate properties with either of two elements that represent the same thing. A consumer of a model in which two elements represent the same thing should accept that properties of one of the two elements also apply to the other element." -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Don Baisley To: "sbvr-rtf@omg.org" Date: 06/26/2011 03:13 PM Subject: RE: issue 15450 -- SBVR RTF issue Here is an updated resolution to issue 15450 based on discussion at the last SBVR meeting. Best regards, Don [attachment "SBVR Issue 15450.doc" deleted by Mark H Linehan/Watson/IBM] Date: Tue, 28 Jun 2011 11:41:48 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: Mark H Linehan CC: "sbvr-rtf@omg.org" Subject: Re: issue 15450 -- SBVR RTF issue X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: p5SFfqsV001284 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1309880519.05673@A6N/H8S4uNK5t2z0Kmv0PQ X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Mark H Linehan wrote: For me, at least, this doesn't really resolve the open issue. The proposed definition is "designation that is of a fact type role and that is recognizable in use in the context of being attributed to what fills another role of the same fact type". This sounds like a backdoor means for introducing attributes into SBVR. If that's what it's about, then I think the proper approach is to define the concept of attributes and say that a fact type role designation is a designation of an attribute. I think this "backdoor" means of introducing attributes has always been there. That is what the 'attributive namespace' is about, and we noticed that sometime in the first FTF. At the same time, Mark is right -- SBVR does not actually have the 'attribute' concept, or what Ron Ross called the 'property' concept, clearly defined anywhere. The idea is touched on in 'attributive namespaces' and the use of 'of' as a verb, and the 'fact type role designation', and the 'noun form of fact types'. Comment: presumably a fact type role designation is in the namespace of whatever "fills another role of the same fact type". It would help if a note said that. I think the Necessity: "No fact type role designation is a placeholder." needs further explanation. I know you try to address it in the Note and Example, but the reason just doesn't come through. In the fact type form, "corporation has CEO", clearly the designation "CEO" is a placeholder. Then the assertion that "The fact type role designation, âCEOâ, ... is not the same thing as the âCEOâ placeholder, in that fact type form" deserves an explanation as to why not. I THINK what you are saying is that propositions that use the designation CEO, in uses of this fact type, are referring explicitly to the attribute "corporation's CEO". So the distinction is between the placeholder in the fact type form itself, and the fact type role designation in a proposition based on the fact type. Is that right? If so, we should say so. Agree. Suggestion: consider renaming "fact type role designation" as "attribute" or "attribute designation" because that's what it is. Strongly agree. The term 'fact type role designation' is a poor and confusing choice. 'fact type role designation' clearly should be a synonym for 'placeholder', since it apparently refers to the role as it appears in the definition of the fact type. The whole idea of an 'attribute designation' is that it is derived from the fact type but is attached to an 'owner' noun concept -- the range of the/some other role in that fact type. The 'attribute designation' refers to things related to the owner noun concept by actualities of that fact type. And the attribute designation is in the 'attributive namespace' of the owner noun concept. We note that Clause 13 makes precisely this kind of transformation in creating the UML model for 'attributes' that appear in reference schemes. The UML association ends -- the fact type roles -- are owned by the association -- the fact type. They are 'placeholders'. But Clause 13 then introduces a derived attribute (based on the association -- the fact type) for one of the participating classes (noun concepts). The point here is that UML almost got this right, and SBVR got it wrong. And clause 13 patches the SBVR model to get the intended semantic model of 'attribute'. A further note: The function of 'has'/'of' fact types in SBVR is to introduce 'attribute designations', not 'situational roles'. For example, 'more general concept' and 'cardinality' are attribute designations in the context of the noun concepts 'concept' and 'set', respectively. But that is, of course, a much bigger pill for the RTF to swallow. The proposed additional sentence for 13.3.1 reads "A consumer of a model in which two elements represent the same thing should not assume that each fact about the thing is represented redundantly using two links, one to each element." This is again a statement in the negative. I think it would be much more useful to make a positive statement, such as "When two elements represent the same thing, properties of one element also apply to the other element. A producer of a model may associate properties with either of two elements that represent the same thing. A consumer of a model in which two elements represent the same thing should accept that properties of one of the two elements also apply to the other element." Yes, a definite improvement. I'm not sure what portion of this we can legitimately address in the RTF, because we are talking about recognizing a significant first-class concept that was smuggled into the adopted specification under a number of dirty blankets. To correct this properly would require several changes in the way things are presented in SBVR. And we all know that ain't gonna happen. -Ed -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Don Baisley To: "sbvr-rtf@omg.org" Date: 06/26/2011 03:13 PM Subject: RE: issue 15450 -- SBVR RTF issue Here is an updated resolution to issue 15450 based on discussion at the last SBVR meeting. Best regards, Don [attachment "SBVR Issue 15450.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 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." X-Yahoo-Newman-Id: 146984.78615.bm@omp1027.access.mail.sp2.yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1309281316; bh=a1AanJOcoV65xpgJbuEM3KqbM9mfnr/5PgvvByDTGSY=; h=Message-ID:Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:X-Mailer:Date:To:From:Subject:Cc:In-Reply-To:References:Mime-Version:Content-Type:Content-Transfer-Encoding; b=suQlze/nVoztz89Ltu99L9fJ3rk9MOkXrOCTgrvVgf9aylaqdEZ+CUIM0G3FkJIRiVGk7IE67xVRpz+Q8HtWd0WI9wO2NmOj1lRvOckaBESmCynHf2OXASneHz2UC/TP9YASPbbipf42f26mJfdmHXtAsVcITciPdHBJwhcIBeU= X-Yahoo-SMTP: MhfrpU2swBDLgYiYhNQDHBu0cE4o.vu2We1FRN9o X-YMail-OSG: VnRdbuUVM1mXlO0pPUZ_krztYXaA9eREVNYBKZH5BEK59i7 hithID3p1th03ZMtWEPo_DM1kDuq2VJR4VcbDyeABFCz.feNc2PJpHgbgHa5 fPsq3uN1PAlRWSqW.54o06hUOwVbSZ2eZfhiQvdm7X1hJxYxha.abVZNjCWI 0ap00ZvUAWeuOdV7.rrk_V9uQgcBFn3NRJaNLtuBvaG1p2wjI9OYxSuZTq46 VsGkgan0neJ6Obg9ZxzrFHSP1zh7VsPQ4.9w2k21C5w0pyEhaMkfdEvxHLkg 8Cm5eUqKPRte.FbKWI3r_V0Oni5UaMbVXTon8hZFjzC3ZAw85T4A7nMireI4 xEC8Fw_CucJVe3Yneo6EbYA-- X-Yahoo-Newman-Property: ymail-3 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 28 Jun 2011 12:15:01 -0500 To: edbark@nist.gov, Mark H Linehan From: "Ronald G. Ross" Subject: Re: issue 15450 -- SBVR RTF issue Cc: "sbvr-rtf@omg.org" Quick clarification ... At 10:41 AM 6/28/2011, Ed Barkmeyer wrote: Mark H Linehan wrote: For me, at least, this doesn't really resolve the open issue. The proposed definition is "designation that is of a fact type role and that is recognizable in use in the context of being attributed to what fills another role of the same fact type". This sounds like a backdoor means for introducing attributes into SBVR. If that's what it's about, then I think the proper approach is to define the concept of attributes and say that a fact type role designation is a designation of an attribute. I think this "backdoor" means of introducing attributes has always been there. That is what the 'attributive namespace' is about, and we noticed that sometime in the first FTF. At the same time, Mark is right -- SBVR does not actually have the 'attribute' concept, or what Ron Ross called the 'property' concept, clearly defined anywhere. I think we do have "property"... See Issue 15684 ... which I think(?) was voted and approved. Perhaps I misunderstand what you mean? The idea is touched on in 'attributive namespaces' and the use of 'of' as a verb, and the 'fact type role designation', and the 'noun form of fact types'. Comment: presumably a fact type role designation is in the namespace of whatever "fills another role of the same fact type". It would help if a note said that. I think the Necessity: "No fact type role designation is a placeholder." needs further explanation. I know you try to address it in the Note and Example, but the reason just doesn't come through. In the fact type form, "corporation has CEO", clearly the designation "CEO" is a placeholder. Then the assertion that "The fact type role designation, âCEOâ, ... is not the same thing as the âCEOâ placeholder, in that fact type form" deserves an explanation as to why not. I THINK what you are saying is that propositions that use the designation CEO, in uses of this fact type, are referring explicitly to the attribute "corporation's CEO". So the distinction is between the placeholder in the fact type form itself, and the fact type role designation in a proposition based on the fact type. Is that right? If so, we should say so. Agree. Suggestion: consider renaming "fact type role designation" as "attribute" or "attribute designation" because that's what it is. Strongly agree. The term 'fact type role designation' is a poor and confusing choice. 'fact type role designation' clearly should be a synonym for 'placeholder', since it apparently refers to the role as it appears in the definition of the fact type. The whole idea of an 'attribute designation' is that it is derived from the fact type but is attached to an 'owner' noun concept -- the range of the/some other role in that fact type. The 'attribute designation' refers to things related to the owner noun concept by actualities of that fact type. And the attribute designation is in the 'attributive namespace' of the owner noun concept. We note that Clause 13 makes precisely this kind of transformation in creating the UML model for 'attributes' that appear in reference schemes. The UML association ends -- the fact type roles -- are owned by the association -- the fact type. They are 'placeholders'. But Clause 13 then introduces a derived attribute (based on the association -- the fact type) for one of the participating classes (noun concepts). The point here is that UML almost got this right, and SBVR got it wrong. And clause 13 patches the SBVR model to get the intended semantic model of 'attribute'. A further note: The function of 'has'/'of' fact types in SBVR is to introduce 'attribute designations', not 'situational roles'. For example, 'more general concept' and 'cardinality' are attribute designations in the context of the noun concepts 'concept' and 'set', respectively. But that is, of course, a much bigger pill for the RTF to swallow. The proposed additional sentence for 13.3.1 reads "A consumer of a model in which two elements represent the same thing should not assume that each fact about the thing is represented redundantly using two links, one to each element." This is again a statement in the negative. I think it would be much more useful to make a positive statement, such as "When two elements represent the same thing, properties of one element also apply to the other element. A producer of a model may associate properties with either of two elements that represent the same thing. A consumer of a model in which two elements represent the same thing should accept that properties of one of the two elements also apply to the other element." Yes, a definite improvement. I'm not sure what portion of this we can legitimately address in the RTF, because we are talking about recognizing a significant first-class concept that was smuggled into the adopted specification under a number of dirty blankets. To correct this properly would require several changes in the way things are presented in SBVR. And we all know that ain't gonna happen. -Ed -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Don Baisley To: "sbvr-rtf@omg.org" Date: 06/26/2011 03:13 PM Subject: RE: issue 15450 -- SBVR RTF issue Here is an updated resolution to issue 15450 based on discussion at the last SBVR meeting. Best regards, Don [attachment "SBVR Issue 15450.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 Cel: +1 240-672-5800 "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: issue 15450 -- SBVR RTF issue X-KeepSent: BE615E7A:4DBB644D-852578BD:005F3BE1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Tue, 28 Jun 2011 13:26:45 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 06/28/2011 13:26:47, Serialize complete at 06/28/2011 13:26:47 I agree, we do have "attributive namespace" and we do have "property". What we don't have is "attribute". This "fact type role designation" should really be called "attribute designation", meaning a designation for an attribute. And then we should have a proper definition of "attribute". Defining "attribute" would tie together these disparate ideas of SBVR, extend it to cover a mode of speaking that frequently used in real English, and cover a gap compared to XML schema, OWL, and UML. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Ronald G. Ross" To: edbark@nist.gov, Mark H Linehan/Watson/IBM@IBMUS Cc: "sbvr-rtf@omg.org" Date: 06/28/2011 01:18 PM Subject: Re: issue 15450 -- SBVR RTF issue -------------------------------------------------------------------------------- Quick clarification ... At 10:41 AM 6/28/2011, Ed Barkmeyer wrote: Mark H Linehan wrote: For me, at least, this doesn't really resolve the open issue. The proposed definition is "designation that is of a fact type role and that is recognizable in use in the context of being attributed to what fills another role of the same fact type". This sounds like a backdoor means for introducing attributes into SBVR. If that's what it's about, then I think the proper approach is to define the concept of attributes and say that a fact type role designation is a designation of an attribute. I think this "backdoor" means of introducing attributes has always been there. That is what the 'attributive namespace' is about, and we noticed that sometime in the first FTF. At the same time, Mark is right -- SBVR does not actually have the 'attribute' concept, or what Ron Ross called the 'property' concept, clearly defined anywhere. I think we do have "property"... See Issue 15684 ... which I think(?) was voted and approved. Perhaps I misunderstand what you mean? The idea is touched on in 'attributive namespaces' and the use of 'of' as a verb, and the 'fact type role designation', and the 'noun form of fact types'. Comment: presumably a fact type role designation is in the namespace of whatever "fills another role of the same fact type". It would help if a note said that. I think the Necessity: "No fact type role designation is a placeholder." needs further explanation. I know you try to address it in the Note and Example, but the reason just doesn't come through. In the fact type form, "corporation has CEO", clearly the designation "CEO" is a placeholder. Then the assertion that "The fact type role designation, â..CEOâ.., ... is not the same thing as the â..CEOâ.. placeholder,older, in that fact type form" deserves an explanation as to why not. I THINK what you are saying is that propositions that use the designation CEO, in uses of this fact type, are referring explicitly to the attribute "corporation's CEO". So the distinction is between the placeholder in the fact type form itself, and the fact type role designation in a proposition based on the fact type. Is that right? If so, we should say so. Agree. Suggestion: consider renaming "fact type role designation" as "attribute" or "attribute designation" because that's what it is. Strongly agree. The term 'fact type role designation' is a poor and confusing choice. 'fact type role designation' clearly should be a synonym for 'placeholder', since it apparently refers to the role as it appears in the definition of the fact type. The whole idea of an 'attribute designation' is that it is derived from the fact type but is attached to an 'owner' noun concept -- the range of the/some other role in that fact type. The 'attribute designation' refers to things related to the owner noun concept by actualities of that fact type. And the attribute designation is in the 'attributive namespace' of the owner noun concept. We note that Clause 13 makes precisely this kind of transformation in creating the UML model for 'attributes' that appear in reference schemes. The UML association ends -- the fact type roles -- are owned by the association -- the fact type. They are 'placeholders'. But Clause 13 then introduces a derived attribute (based on the association -- the fact type) for one of the participating classes (noun concepts). The point here is that UML almost got this right, and SBVR got it wrong. And clause 13 patches the SBVR model to get the intended semantic model of 'attribute'. A further note: The function of 'has'/'of' fact types in SBVR is to introduce 'attribute designations', not 'situational roles'. For example, 'more general concept' and 'cardinality' are attribute designations in the context of the noun concepts 'concept' and 'set', respectively. But that is, of course, a much bigger pill for the RTF to swallow. The proposed additional sentence for 13.3.1 reads "A consumer of a model in which two elements represent the same thing should not assume that each fact about the thing is represented redundantly using two links, one to each element." This is again a statement in the negative. I think it would be much more useful to make a positive statement, such as "When two elements represent the same thing, properties of one element also apply to the other element. A producer of a model may associate properties with either of two elements that represent the same thing. A consumer of a model in which two elements represent the same thing should accept that properties of one of the two elements also apply to the other element." Yes, a definite improvement. I'm not sure what portion of this we can legitimately address in the RTF, because we are talking about recognizing a significant first-class concept that was smuggled into the adopted specification under a number of dirty blankets. To correct this properly would require several changes in the way things are presented in SBVR. And we all know that ain't gonna happen. -Ed -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Don Baisley To: "sbvr-rtf@omg.org" Date: 06/26/2011 03:13 PM Subject: RE: issue 15450 -- SBVR RTF issue Here is an updated resolution to issue 15450 based on discussion at the last SBVR meeting. Best regards, Don [attachment "SBVR Issue 15450.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 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Tue, 28 Jun 2011 15:09:41 -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: Mark H Linehan , "sbvr-rtf@omg.org" Subject: Re: issue 15450 -- SBVR RTF issue X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edward.barkmeyer@nist.gov I wrote: I think this "backdoor" means of introducing attributes has always been there. That is what the 'attributive namespace' is about, and we noticed that sometime in the first FTF. At the same time, Mark is right -- SBVR does not actually have the 'attribute' concept, or what Ron Ross called the 'property' concept, clearly defined anywhere. Ron wrote: I think we do have "property"... See Issue 15684 ... which I think(?) was voted and approved. Perhaps I misunderstand what you mean? I see. We do have 'property' in 15684. According to the Notes in that entry, for a fact type like meeting has start time 'start time' is _not_ a 'property' of a 'meeting'. Having a start time of 1 P.M. is a 'property' of a meeting. Mark's point is that 'start time' is an 'attribute' of a 'meeting'. And SBVR does not have that concept. As I said: The idea is touched on in 'attributive namespaces' and the use of 'of' as a verb, and the 'fact type role designation', and the 'noun form of fact types'. All of these talk about the syntactic aspects of 'attributes' without ever introducing the concept. Sorry for the confusion. Thanks, Ron, for pointing this out. The fight we will have about 'meeting has start time' is that SBVR says 'start time' is a 'situational role'. The problem with 'situational role' is that a majority of the FTF apparently sees the following definitions as identical: 'the time at which an event starts' 'the time at which at least 1 event starts' 'the time at which a given event starts' The first is ambiguous. It means one of the second and third. The second is a situational role. It means any time that is the start of any event, you don't care what event is involved. The third is an 'attribute' of 'event'. It means the time associated in that way with a specific event. SBVR has confused these two ideas all along. I became convinced that the SBVR FTF was unable to understand the distinction. The example that I used to sort them out was this: Miss Allgood teaches English at R.E.Lee High School. Mr. Brown teaches History and English at R.E. Lee High School. Miss Allgood is an English teacher. (situational role) Mr. Brown is an English teacher. (situational role) Mr. Brown is a History teacher. (situational role) Jean Smith is a student at R.E. Lee High School. (situational role) Jean Smith has an English teacher. (attribute) Jean Smith has Mr. Brown for History. Her English teacher is Miss Allgood. Mr. Brown is an 'English teacher' (situational role), but not Jean's 'English teacher' (attribute). Mr. Brown teaches English to at least 1 student, but not to the given student -- Jean Smith. SBVR needs two concepts to make this distinction. It does not have the 'attribute' concept, and it confuses 'attribute' with 'situational role'. Now, think about what that means for every occurrence of Concept Type: role. -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 Cel: +1 240-672-5800 "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: issue 15450 -- SBVR RTF issue X-KeepSent: E69750FA:D1DB0A2B-852578BD:0069B57E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Tue, 28 Jun 2011 15:20:05 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 06/28/2011 15:20:10, Serialize complete at 06/28/2011 15:20:10 I agree with Ed. But I want to point out that Don's proposed resolution for issue 15450 of June 26 has the following Note: "A fact type role designation should not be confused with a term for a situational role. A situational role is an object type and is not a fact type role." And he gives an Example to illustrate the difference between a fact type role designation (i.e. "attribute designation") and a situational role: "The fact type role designation, âCEOâ, for a role in the fact type âcorporation has CEOâ does not represent a situational role, âCEOâ and is not the same thing as the âCEOâ placeholder, in that fact type form. The fact type role designation represents the role in the fact type, as in the phrases âEU-Rentâs CEOâ and âthe CEO of some corporationâ. But the situational role, even if defined in terms of the fact type, can be used independently, as in the statement âEvery CEO is a personâ. The placeholder âCEOâ of the fact type form âcorporation has CEOâ is part of the form and gets replaced in each use of the form." So I agree that the SBVR specification text confuses "attribute" with "situational role" but apparently Don is clear about the difference between them. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Edward Barkmeyer To: "Ronald G. Ross" Cc: Mark H Linehan/Watson/IBM@IBMUS, "sbvr-rtf@omg.org" Date: 06/28/2011 03:11 PM Subject: Re: issue 15450 -- SBVR RTF issue -------------------------------------------------------------------------------- I wrote: >> I think this "backdoor" means of introducing attributes has always >> been there. That is what the 'attributive namespace' is about, and >> we noticed that sometime in the first FTF. At the same time, Mark is >> right -- SBVR does not actually have the 'attribute' concept, or what >> Ron Ross called the 'property' concept, clearly defined anywhere. Ron wrote: > I think we do have "property"... See Issue 15684 ... which I think(?) > was voted and approved. > > Perhaps I misunderstand what you mean? I see. We do have 'property' in 15684. According to the Notes in that entry, for a fact type like meeting has start time 'start time' is _not_ a 'property' of a 'meeting'. Having a start time of 1 P.M. is a 'property' of a meeting. Mark's point is that 'start time' is an 'attribute' of a 'meeting'. And SBVR does not have that concept. As I said: >> The idea is touched on in 'attributive namespaces' and the use of >> 'of' as a verb, and the 'fact type role designation', and the 'noun >> form of fact types'. All of these talk about the syntactic aspects of 'attributes' without ever introducing the concept. Sorry for the confusion. Thanks, Ron, for pointing this out. The fight we will have about 'meeting has start time' is that SBVR says 'start time' is a 'situational role'. The problem with 'situational role' is that a majority of the FTF apparently sees the following definitions as identical: 'the time at which an event starts' 'the time at which at least 1 event starts' 'the time at which a given event starts' The first is ambiguous. It means one of the second and third. The second is a situational role. It means any time that is the start of any event, you don't care what event is involved. The third is an 'attribute' of 'event'. It means the time associated in that way with a specific event. SBVR has confused these two ideas all along. I became convinced that the SBVR FTF was unable to understand the distinction. The example that I used to sort them out was this: Miss Allgood teaches English at R.E.Lee High School. Mr. Brown teaches History and English at R.E. Lee High School. Miss Allgood is an English teacher. (situational role) Mr. Brown is an English teacher. (situational role) Mr. Brown is a History teacher. (situational role) Jean Smith is a student at R.E. Lee High School. (situational role) Jean Smith has an English teacher. (attribute) Jean Smith has Mr. Brown for History. Her English teacher is Miss Allgood. Mr. Brown is an 'English teacher' (situational role), but not Jean's 'English teacher' (attribute). Mr. Brown teaches English to at least 1 student, but not to the given student -- Jean Smith. SBVR needs two concepts to make this distinction. It does not have the 'attribute' concept, and it confuses 'attribute' with 'situational role'. Now, think about what that means for every occurrence of Concept Type: role. -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 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." From: "Donald Chapin" To: "'Mark H Linehan'" , Subject: RE: issue 15450 -- SBVR RTF issue Date: Tue, 28 Jun 2011 16:24:00 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acw1yHpjEIakZP1FQBaSgw/Y3jNwCwAB323A X-Mirapoint-IP-Reputation: reputation=Good-1, source=Queried, refid=tid=0001.0A0B0302.4E0A3864.0051, actions=tag X-Junkmail-Premium-Raw: score=7/50, refid=2.7.2:2011.6.28.192714:17:7.944, ip=184.74.140.210, rules=__TO_MALFORMED_2, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, DATE_TZ_NA, __HAS_MSGID, __SANE_MSGID, INVALID_MSGID_NO_FQDN, __MIME_VERSION, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __HAS_X_MAILER, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, __URI_NO_WWW, __URI_NO_PATH, __FRAUD_CONTACT_NUM, __C230066_P5, __HTML_MSWORD, __HTML_FONT_BLUE, __HAS_HTML, BODY_SIZE_10000_PLUS, __MIME_HTML, __TAG_EXISTS_HTML, __STYLE_RATWARE_2, RDNS_GENERIC_POOLED, HTML_70_90, RDNS_SUSP_GENERIC, __OUTLOOK_MUA, RDNS_SUSP, FORGED_MUA_OUTLOOK X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0203.4E0A386F.0007,ss=1,fgs=0, ip=184.74.140.210, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine X-Junkmail-IWF: false Mark & Ed, I agree that we do not want to bring the class-attribute-relationship paradigm for modeling into SBVR by the back door or any other way. There is a transform from a subject-verb-object paradigm to a class-attribute-relationship paradigm. The topic of fact type roles and situational roles is orthogonal to specifying one of the fact type roles in a fact type as being a property role as SBVR defines property . which is very different from attribute in UML & data models. Fact type roles are noun concepts, but not object types. As such they can have terms, just like object types. It was my understanding that fact type role designation is a term for a fact type role noun concept . nothing more or less. Mark, can you point out what in the SBVR specification or the proposed resolution to Issue 15450 makes it look like we are bring attributes into SBVR. Whatever that is needs to be fixed. Donald -------------------------------------------------------------------------------- From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: 28 June 2011 15:20 To: sbvr-rtf@omg.org Subject: Re: issue 15450 -- SBVR RTF issue I agree with Ed. But I want to point out that Don's proposed resolution for issue 15450 of June 26 has the following Note: "A fact type role designation should not be confused with a term for a situational role. A situational role is an object type and is not a fact type role." And he gives an Example to illustrate the difference between a fact type role designation (i.e. "attribute designation") and a situational role: "The fact type role designation, .CEO., for a role in the fact type .corporation has CEO. does not represent a situational role, .CEO. and is not the same thing as the .CEO. placeholder, in that fact type form. The fact type role designation represents the role in the fact type, as in the phrases .EU-Rent.s CEO. and .the CEO of some corporation.. But the situational role, even if defined in terms of the fact type, can be used independently, as in the statement .Every CEO is a person.. The placeholder .CEO. of the fact type form .corporation has CEO. is part of the form and gets replaced in each use of the form." So I agree that the SBVR specification text confuses "attribute" with "situational role" but apparently Don is clear about the difference between them. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Edward Barkmeyer To: "Ronald G. Ross" Cc: Mark H Linehan/Watson/IBM@IBMUS, "sbvr-rtf@omg.org" Date: 06/28/2011 03:11 PM Subject: Re: issue 15450 -- SBVR RTF issue -------------------------------------------------------------------------------- I wrote: >> I think this "backdoor" means of introducing attributes has always >> been there. That is what the 'attributive namespace' is about, and >> we noticed that sometime in the first FTF. At the same time, Mark is >> right -- SBVR does not actually have the 'attribute' concept, or what >> Ron Ross called the 'property' concept, clearly defined anywhere. Ron wrote: > I think we do have "property"... See Issue 15684 ... which I think(?) > was voted and approved. > > Perhaps I misunderstand what you mean? I see. We do have 'property' in 15684. According to the Notes in that entry, for a fact type like meeting has start time 'start time' is _not_ a 'property' of a 'meeting'. Having a start time of 1 P.M. is a 'property' of a meeting. Mark's point is that 'start time' is an 'attribute' of a 'meeting'. And SBVR does not have that concept. As I said: >> The idea is touched on in 'attributive namespaces' and the use of >> 'of' as a verb, and the 'fact type role designation', and the 'noun >> form of fact types'. All of these talk about the syntactic aspects of 'attributes' without ever introducing the concept. Sorry for the confusion. Thanks, Ron, for pointing this out. The fight we will have about 'meeting has start time' is that SBVR says 'start time' is a 'situational role'. The problem with 'situational role' is that a majority of the FTF apparently sees the following definitions as identical: 'the time at which an event starts' 'the time at which at least 1 event starts' 'the time at which a given event starts' The first is ambiguous. It means one of the second and third. The second is a situational role. It means any time that is the start of any event, you don't care what event is involved. The third is an 'attribute' of 'event'. It means the time associated in that way with a specific event. SBVR has confused these two ideas all along. I became convinced that the SBVR FTF was unable to understand the distinction. The example that I used to sort them out was this: Miss Allgood teaches English at R.E.Lee High School. Mr. Brown teaches History and English at R.E. Lee High School. Miss Allgood is an English teacher. (situational role) Mr. Brown is an English teacher. (situational role) Mr. Brown is a History teacher. (situational role) Jean Smith is a student at R.E. Lee High School. (situational role) Jean Smith has an English teacher. (attribute) Jean Smith has Mr. Brown for History. Her English teacher is Miss Allgood. Mr. Brown is an 'English teacher' (situational role), but not Jean's 'English teacher' (attribute). Mr. Brown teaches English to at least 1 student, but not to the given student -- Jean Smith. SBVR needs two concepts to make this distinction. It does not have the 'attribute' concept, and it confuses 'attribute' with 'situational role'. Now, think about what that means for every occurrence of Concept Type: role. -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 Cel: +1 240-672-5800 "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: issue 15450 -- SBVR RTF issue X-KeepSent: F102DDD8:114DED7B-852578BD:0075518A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Wed, 29 Jun 2011 08:34:16 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 06/29/2011 08:34:19, Serialize complete at 06/29/2011 08:34:19 Donald, Regarding "Fact type roles are noun concepts, but not object types. As such they can have terms, just like object types. It was my understanding that fact type role designation is a term for a fact type role noun concept . nothing more or leess." We already have two terms for designations for fact type roles: "placeholder" and "situational role". If "fact type role designation" is "nothing more or less" than "a term for a fact type role noun concept" then why do we need a third such term? The answer that I get from the proposed resolution is that a "fact type role designation" is a designation that is used both in a placeholder of a fact type and for the corresponding role in *uses* of the fact type. For example, "name" in "person has name" is used as a "fact type role designation" in propositions that use the fact type, such as "The name of each person must not be blank". Regarding "can you point out what in the SBVR specification or the proposed resolution to Issue 15450 makes it look like we are bring attributes into SBVR". The proposed definition sure makes "fact type role designation" sound like an attribute: "designation that is of a fact type role and that is recognizable in use in the context of being attributed to what fills another role of the same fact type". The Example also makes it sound like "fact type role designation" means a designation for an attribute. And in SBVR, attributes are implied by the concept "attributive namespace" and by the mapping to MOF that is described in clause 13.2.5. Also see clause C.3.1, last paragraph, where it says "Having a designation for the second fact type role in an attributive namespace means that the designation is recognized as representing the role when it is used in the context of being attributed to instances of the subject concept. " In my view, attributes are not just an IT concept. They exist in the real world and ordinary language implicitly recognizes them. Don's proposed resolution of 15450 suggests the difference in usage between ordinary verb concepts and attributive verb concepts. Take, for example, "driver drives car", where "driver" ranges over "person" and "car" ranges over "car". When we use this ordinary binary verb concept, we usually substitute the ranged-over concepts for the placeholders, as in "each person that drives some car". But with attributive verb concepts, the usage is different. For example, with "person has name" where "person" ranges over "person" and "name" ranges over "text", we would say "the name of each person" rather than "the text of each person". The point is that the role name distinguishes the attribute in the *use* of the verb concept. And, as Don says in his proposed resolution, a "fact type role designation" is not the same as a "situational role". In my example, "name" has no special standing as a concept, independent of its participation in "name of person" -- unless a semantic community chooses to make "name" a situational role. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: "Donald Chapin" To: Mark H Linehan/Watson/IBM@IBMUS, Date: 06/28/2011 04:31 PM Subject: RE: issue 15450 -- SBVR RTF issue -------------------------------------------------------------------------------- Mark & Ed, I agree that we do not want to bring the class-attribute-relationship paradigm for modeling into SBVR by the back door or any other way. There is a transform from a subject-verb-object paradigm to a class-attribute-relationship paradigm. The topic of fact type roles and situational roles is orthogonal to specifying one of the fact type roles in a fact type as being a property role as SBVR defines property . which is very different from attribute in UML & ddata models. Fact type roles are noun concepts, but not object types. As such they can have terms, just like object types. It was my understanding that fact type role designation is a term for a fact type role noun concept . nothing more or less. Mark, can you point out what in the SBVR specification or the proposed resolution to Issue 15450 makes it look like we are bring attributes into SBVR. Whatever that is needs to be fixed. Donald -------------------------------------------------------------------------------- From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: 28 June 2011 15:20 To: sbvr-rtf@omg.org Subject: Re: issue 15450 -- SBVR RTF issue I agree with Ed. But I want to point out that Don's proposed resolution for issue 15450 of June 26 has the following Note: "A fact type role designation should not be confused with a term for a situational role. A situational role is an object type and is not a fact type role." And he gives an Example to illustrate the difference between a fact type role designation (i.e. "attribute designation") and a situational role: "The fact type role designation, âCEOâ, for a role in the fact type âcorporation has CEOâ does not represent a situational role, âCEOâ and is not the same thing as the âCEOâ placeholder, in that fact type form. The fact type role designation represents the role in the fact type, as in the phrases âEU-Rentâs CEOâ and âthe CEO of some corporationâ. But the situational role, even if defined in terms of the fact type, can be used independently, as in the statement âEvery CEO is a personâ. The placeholder âCEOâ of the fact type form âcorporation has CEOâ is part of the form and gets replaced in each use of the form." So I agree that the SBVR specification text confuses "attribute" with "situational role" but apparently Don is clear about the difference between them. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Edward Barkmeyer To: "Ronald G. Ross" Cc: Mark H Linehan/Watson/IBM@IBMUS, "sbvr-rtf@omg.org" Date: 06/28/2011 03:11 PM Subject: Re: issue 15450 -- SBVR RTF issue -------------------------------------------------------------------------------- I wrote: >> I think this "backdoor" means of introducing attributes has always >> been there. That is what the 'attributive namespace' is about, and >> we noticed that sometime in the first FTF. At the same time, Mark is >> right -- SBVR does not actually have the 'attribute' concept, or what >> Ron Ross called the 'property' concept, clearly defined anywhere. Ron wrote: > I think we do have "property"... See Issue 15684 ... which I think(?) > was voted and approved. > > Perhaps I misunderstand what you mean? I see. We do have 'property' in 15684. According to the Notes in that entry, for a fact type like meeting has start time 'start time' is _not_ a 'property' of a 'meeting'. Having a start time of 1 P.M. is a 'property' of a meeting. Mark's point is that 'start time' is an 'attribute' of a 'meeting'. And SBVR does not have that concept. As I said: >> The idea is touched on in 'attributive namespaces' and the use of >> 'of' as a verb, and the 'fact type role designation', and the 'noun >> form of fact types'. All of these talk about the syntactic aspects of 'attributes' without ever introducing the concept. Sorry for the confusion. Thanks, Ron, for pointing this out. The fight we will have about 'meeting has start time' is that SBVR says 'start time' is a 'situational role'. The problem with 'situational role' is that a majority of the FTF apparently sees the following definitions as identical: 'the time at which an event starts' 'the time at which at least 1 event starts' 'the time at which a given event starts' The first is ambiguous. It means one of the second and third. The second is a situational role. It means any time that is the start of any event, you don't care what event is involved. The third is an 'attribute' of 'event'. It means the time associated in that way with a specific event. SBVR has confused these two ideas all along. I became convinced that the SBVR FTF was unable to understand the distinction. The example that I used to sort them out was this: Miss Allgood teaches English at R.E.Lee High School. Mr. Brown teaches History and English at R.E. Lee High School. Miss Allgood is an English teacher. (situational role) Mr. Brown is an English teacher. (situational role) Mr. Brown is a History teacher. (situational role) Jean Smith is a student at R.E. Lee High School. (situational role) Jean Smith has an English teacher. (attribute) Jean Smith has Mr. Brown for History. Her English teacher is Miss Allgood. Mr. Brown is an 'English teacher' (situational role), but not Jean's 'English teacher' (attribute). Mr. Brown teaches English to at least 1 student, but not to the given student -- Jean Smith. SBVR needs two concepts to make this distinction. It does not have the 'attribute' concept, and it confuses 'attribute' with 'situational role'. Now, think about what that means for every occurrence of Concept Type: role. -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 Cel: +1 240-672-5800 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." From: Don Baisley To: Don Baisley , "sbvr-rtf@omg.org" Subject: RE: issue 15450 -- SBVR RTF issue Thread-Topic: issue 15450 -- SBVR RTF issue Thread-Index: AQHLT5N5awRgzau4KUyQLqD8wBfXKJTFF0PggAyy/BCAKpY2QA== Date: Sat, 23 Jul 2011 21:32:23 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] Here is an updated resolution to issue 15450 based on discussion at the July 1 SBVR meeting. Best regards, Don SBVR Issue 154502.doc Disposition: Resolved OMG Issue No: 15450 Title: Fact Type Role Designation Source: Keri Anderson Healy, keri_ah@mac.com Summary: In 11.2.1 we have an entry for something termed .fact type role designation. . its definition says that it is a .designation that represents a fact type role and that is not a placeholder.. There is nothing beyond a Definition for this concept. This entry doesn.t make sense. I recommend it be dropped. (Or, if someone does see some usefulness for it, then please augment it with some notes and examples.). Resolution: Revise the definition of .fact type role designation. and add structural rules, notes and an example. Also, correct a problem in the XML example of a fact type role designation which mistakenly showed the fact type role designation as being a term. A clarification to the representation of multiclassification in models is added. Revised Text: In 11.2.1.2 REPLACE definition in the entry for .fact type role designation. with the following: Definition: designation that is of a fact type role and that is recognizable in use in the context of another role of the same fact type Necessity: No fact type role designation is a term. Necessity: No fact type role designation is a placeholder. Necessity: No fact type role designation represents a situational role. Note: A fact type role designation should not be confused with a term for a situational role. A situational role is an object type and is not a fact type role. Note: A fact type role designation should not be confused with a placeholder, which is part of a fact type form. In uses of a fact type form, placeholders are replaced. A fact type role designation can replace a placeholder. Fact type role designations occur in statements and definitions to refer to what fills the role. Example: The fact type role designation, .CEO., for a role in the fact type .corporation has CEO. does not represent a situational role and is not the same thing as the .CEO. placeholder in that fact type form. The fact type role designation represents the role in the fact type, as in the phrases .EU-Rent.s CEO. and .the CEO of some corporation.. But a situational role, even if defined in terms of the fact type, can be used independently, as in the statement .Every CEO is a person.. The placeholder .CEO. of the fact type form .corporation has CEO. is part of the form and gets replaced in each use of the form. In the statement, .EU-Rent has exactly one CEO., the .CEO. placeholder of the fact type form .corporation has CEO. is replace by .exactly one CEO., comprised of a quantifier and the fact type role designation .CEO., which is understood to represent the fact type role because of its context: it is used in relation to a corporation. Note: Clause 13.6.4 shows an example of a fact type role designation, .prior example., and also shows examples of fact type roles having no fact type role designation. At the end of the first paragraph of 13.3.1 ADD the following sentence: A consumer of a model in which two elements represent the same thing should not assume that each fact about the thing is represented redundantly using two links, one to each element. In 13.6.4 in the XML shown for .Synonymous Form: example1 has prior example., REMOVE the following two lines: Immediately above the two removed lines, in the line that looks like this: REPLACE .term. with .factTypeRoleDesignation. so that the line looks like this: Disposition: Resolved From: Don Baisley To: "'sbvr-rtf@omg.org'" Subject: RE: issue 15450 -- SBVR RTF issue Thread-Topic: issue 15450 -- SBVR RTF issue Thread-Index: AQHLT5N5awRgzau4KUyQLqD8wBfXKJTFF0PggAyy/BCAKpY2QIAdzcOw Date: Thu, 11 Aug 2011 20:39:53 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.76] Here is an updated resolution to issue 15450 based on discussion at the August 5 SBVR meeting. Thanks go to Keri for providing an updated diagram. Best regards, Don SBVR Issue 154503.doc Disposition: Resolved OMG Issue No: 15450 Title: Fact Type Role Designation Source: Keri Anderson Healy, keri_ah@mac.com Summary: In 11.2.1 we have an entry for something termed .fact type role designation. . its definition says that it is a .designation that represents a fact type role and that is not a placeholder.. There is nothing beyond a Definition for this concept. This entry doesn.t make sense. I recommend it be dropped. (Or, if someone does see some usefulness for it, then please augment it with some notes and examples.). Resolution: Revise the definition of .fact type role designation. and add structural rules, notes and an example. Also, correct a problem in the XML example of a fact type role designation which mistakenly showed the fact type role designation as being a term. A clarification to the representation of multiclassification in models is added. Revised Text: In 11.2.1 REPLACE Figure 11.6 with this figure: In 11.2.1.2 REPLACE definition in the entry for .fact type role designation. with the following: Definition: designation that is of a fact type role and that is recognizable in use in the context of another role of the same fact type Necessity: No fact type role designation is a term. Necessity: No fact type role designation is a placeholder. Necessity: No fact type role designation represents a situational role. Note: A fact type role designation should not be confused with a term for a situational role. A situational role is an object type and is not a fact type role. Note: A fact type role designation should not be confused with a placeholder, which is part of a fact type form. In uses of a fact type form, placeholders are replaced. A fact type role designation can replace a placeholder. Fact type role designations occur in statements and definitions to refer to what fills the role. Example: The fact type role designation, .CEO., for a role in the fact type .corporation has CEO. does not represent a situational role and is not the same thing as the .CEO. placeholder in that fact type form. The fact type role designation represents the role in the fact type, as in the phrases .EU-Rent.s CEO. and .the CEO of some corporation.. But a situational role, even if defined in terms of the fact type, can be used independently, as in the statement .Every CEO is a person.. The placeholder .CEO. of the fact type form .corporation has CEO. is part of the form and gets replaced in each use of the form. In the statement, .EU-Rent has exactly one CEO., the .CEO. placeholder of the fact type form .corporation has CEO. is replaced by .exactly one CEO., comprised of a quantifier and the fact type role designation .CEO., which is understood to represent the fact type role because of its context: it is used in relation to a corporation. Note: Clause 13.6.4 shows an example of a fact type role designation, .prior example., and also shows examples of fact type roles having no fact type role designation. At the end of the first paragraph of 13.3.1 ADD the following sentence: A consumer of a model in which two elements represent the same thing should assume that a fact represented in reference to either element applies to both elements (since they both represent the same thing). In 13.6.4 in the XML shown for .Synonymous Form: example1 has prior example., REMOVE the following two lines: Immediately above the two removed lines, in the line that looks like this: REPLACE .term. with .factTypeRoleDesignation. so that the line looks like this: Disposition: Resolved To: sbvr-rtf@omg.org Subject: RE: issue 15450 -- SBVR RTF issue X-KeepSent: 17EDC227:37C3A84C-852578EA:006E2FA4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Fri, 12 Aug 2011 16:19:51 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 08/12/2011 16:19:54 I still think there's something missing in this resolution. In the example about CEO's, given in the issue resolution, the signifier "CEO" is used for a fact type role designation (e.g. "EU Rent's CEO"), as a placeholder (e.g. "corporation has CEO"), and as a situational role (e.g. "every CEO is a person"). The same resolution has these three Necessities: Necessity: No fact type role designation is a term. Necessity: No fact type role designation is a placeholder. Necessity: No fact type role designation represents a situational role. The only way I can square the example with the Necessities is to realize that a fact type role designation, a placeholder, and a situation role can all have the same signifier (e.g. "CEO") even if they are not the same thing. This is certainly possible in SBVR, since one signifier can represent multiple meanings. If this is the correct way to understand the example, then I think it would be helpful to add a Possibility along the lines of "A signifier can be the expression of a fact type role designation and of a place holder, and can designate a situational role". And maybe also a note that explicitly says that a placeholder and a fact type role designation are not the same thing even if they have the same signifier. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Don Baisley To: "'sbvr-rtf@omg.org'" Date: 08/11/2011 04:44 PM Subject: RE: issue 15450 -- SBVR RTF issue -------------------------------------------------------------------------------- Here is an updated resolution to issue 15450 based on discussion at the August 5 SBVR meeting. Thanks go to Keri for providing an updated diagram. Best regards, Don SBVR Issue 154504.doc From: Don Baisley To: Mark H Linehan , "sbvr-rtf@omg.org" Subject: RE: issue 15450 -- SBVR RTF issue Thread-Topic: issue 15450 -- SBVR RTF issue Thread-Index: AQHLT5N5awRgzau4KUyQLqD8wBfXKJTFF0PggAyy/BCAKpY2QIAdzcOwgAICWoD//7Qb0A== Date: Fri, 12 Aug 2011 23:02:46 +0000 Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.72] Hi Mark, The clause 8 introduction says, .a single expression can have multiple meanings., and the relationship is shown in 8.3 with no multiplicity constraint on either side. Similarly, the association from .designation to signifier. is shown many-to-one (a designation has one signifier and a signifier is the expression for any number of designations). I don.t see how repeating the possibility of an expression representing more than one meaning is in the scope of this issue. SBVR is already pretty big without repeating things in many places, but if there is some reason to say so again, that could be a separate issue on .expression. or .signifier.. Regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Friday, August 12, 2011 1:20 PM To: sbvr-rtf@omg.org Subject: RE: issue 15450 -- SBVR RTF issue I still think there's something missing in this resolution. In the example about CEO's, given in the issue resolution, the signifier "CEO" is used for a fact type role designation (e.g. "EU Rent's CEO"), as a placeholder (e.g. "corporation has CEO"), and as a situational role (e.g. "every CEO is a person"). The same resolution has these three Necessities: Necessity: No fact type role designation is a term. Necessity: No fact type role designation is a placeholder. Necessity: No fact type role designation represents a situational role. The only way I can square the example with the Necessities is to realize that a fact type role designation, a placeholder, and a situation role can all have the same signifier (e.g. "CEO") even if they are not the same thing. This is certainly possible in SBVR, since one signifier can represent multiple meanings. If this is the correct way to understand the example, then I think it would be helpful to add a Possibility along the lines of "A signifier can be the expression of a fact type role designation and of a place holder, and can designate a situational role". And maybe also a note that explicitly says that a placeholder and a fact type role designation are not the same thing even if they have the same signifier. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Don Baisley To: "'sbvr-rtf@omg.org'" Date: 08/11/2011 04:44 PM Subject: RE: issue 15450 -- SBVR RTF issue -------------------------------------------------------------------------------- Here is an updated resolution to issue 15450 based on discussion at the August 5 SBVR meeting. Thanks go to Keri for providing an updated diagram. Best regards, Don To: sbvr-rtf@omg.org Subject: RE: issue 15450 -- SBVR RTF issue X-KeepSent: 8F478EA2:9EBE6F3C-852578ED:0044E198; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 From: Mark H Linehan Date: Mon, 15 Aug 2011 17:04:14 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 08/15/2011 17:04:15, Serialize complete at 08/15/2011 17:04:15 I am not suggesting a Possibility in 8.3. I am suggesting adding a Possibility right after the Necessities cited below, as part of the glossary entry for "fact type role designation". I think that should be part of this resolution. This would help explain to readers how the "CEO" in the example can be the signifier of a fact type role designation, a placeholder, and a situation yet these three are not the same thing. Otherwise, readers either (a) will not understand; or (b) dismiss the specification as self-contradictory and thus not worthy of respect. We already have enough of both (a) and (b). Why not explain how this apparent contradiction can be? -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Don Baisley To: Mark H Linehan/Watson/IBM@IBMUS, "sbvr-rtf@omg.org" Date: 08/12/2011 07:04 PM Subject: RE: issue 15450 -- SBVR RTF issue -------------------------------------------------------------------------------- Hi Mark, The clause 8 introduction says, âa single expression can have multiple meaningsâ, and the relationship is shown in 8.3 with no multiplicity constraint on either side. Similarly, the association from âdesignation to signifierâ is shown many-to-one (a designation has one signifier and a signifier is the expression for any number of designations). I donât see how repeating the possibility of an expression representing more than one meaning is in the scope of this issue. SBVR is already pretty big without repeating things in many places, but if there is some reason to say so again, that could be a separate issue on âexpressionâ or âsignifierâ. Regards, Don From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Friday, August 12, 2011 1:20 PM To: sbvr-rtf@omg.org Subject: RE: issue 15450 -- SBVR RTF issue I still think there's something missing in this resolution. In the example about CEO's, given in the issue resolution, the signifier "CEO" is used for a fact type role designation (e.g. "EU Rent's CEO"), as a placeholder (e.g. "corporation has CEO"), and as a situational role (e.g. "every CEO is a person"). The same resolution has these three Necessities: Necessity: No fact type role designation is a term. Necessity: No fact type role designation is a placeholder. Necessity: No fact type role designation represents a situational role. The only way I can square the example with the Necessities is to realize that a fact type role designation, a placeholder, and a situation role can all have the same signifier (e.g. "CEO") even if they are not the same thing. This is certainly possible in SBVR, since one signifier can represent multiple meanings. If this is the correct way to understand the example, then I think it would be helpful to add a Possibility along the lines of "A signifier can be the expression of a fact type role designation and of a place holder, and can designate a situational role". And maybe also a note that explicitly says that a placeholder and a fact type role designation are not the same thing even if they have the same signifier. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Don Baisley To: "'sbvr-rtf@omg.org'" Date: 08/11/2011 04:44 PM Subject: RE: issue 15450 -- SBVR RTF issue -------------------------------------------------------------------------------- Here is an updated resolution to issue 15450 based on discussion at the August 5 SBVR meeting. Thanks go to Keri for providing an updated diagram. Best regards, Don From: Don Baisley To: "'sbvr-rtf@omg.org'" Subject: RE: issue 15450 -- SBVR RTF issue Thread-Topic: issue 15450 -- SBVR RTF issue Thread-Index: AQHLT5N5awRgzau4KUyQLqD8wBfXKJTFF0PggAyy/BCAKpY2QIAdzcOwgAu0LQA= Date: Fri, 19 Aug 2011 07:27:56 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.36] Here is an updated resolution to issue 15450 which adds an explanatory statement to the example about multiple designations having the same signifier, .CEO.. This change was motivated by a comment from Mark. Best regards, Don SBVR Issue 154505.doc Disposition: Resolved OMG Issue No: 15450 Title: Fact Type Role Designation Source: Keri Anderson Healy, keri_ah@mac.com Summary: In 11.2.1 we have an entry for something termed .fact type role designation. . its definition says that it is a .designation that represents a fact type role and that is not a placeholder.. There is nothing beyond a Definition for this concept. This entry doesn.t make sense. I recommend it be dropped. (Or, if someone does see some usefulness for it, then please augment it with some notes and examples.). Resolution: Revise the definition of .fact type role designation. and add structural rules, notes and an example. Also, correct a problem in the XML example of a fact type role designation which mistakenly showed the fact type role designation as being a term. A clarification to the representation of multiclassification in models is added. Revised Text: In 11.2.1 REPLACE Figure 11.6 with this figure: In 11.2.1.2 REPLACE definition in the entry for .fact type role designation. with the following: Definition: designation that is of a fact type role and that is recognizable in use in the context of another role of the same fact type Necessity: No fact type role designation is a term. Necessity: No fact type role designation is a placeholder. Necessity: No fact type role designation represents a situational role. Note: A fact type role designation should not be confused with a term for a situational role. A situational role is an object type and is not a fact type role. Note: A fact type role designation should not be confused with a placeholder, which is part of a fact type form. In uses of a fact type form, placeholders are replaced. A fact type role designation can replace a placeholder. Fact type role designations occur in statements and definitions to refer to what fills the role. Example: The fact type role designation, .CEO., for a role in the fact type .corporation has CEO. does not represent a situational role and is not the same thing as the .CEO. placeholder in that fact type form. Here we see different designations have the same signifier, .CEO.. The fact type role designation represents the fact type role in the context of using the fact type, such as in the phrases .EU-Rent.s CEO. and .the CEO of some corporation.. But a situational role, even if defined in terms of the fact type, can be used independently, as in the statement, .Every CEO is a person.. The placeholder .CEO. of the fact type form .corporation has CEO. is part of the form and gets replaced in each use of the form. In the statement, .EU-Rent has exactly one CEO., the .CEO. placeholder of the fact type form .corporation has CEO. is replaced by .exactly one CEO., comprised of a quantifier and the fact type role designation .CEO., which is understood to represent the fact type role because of its context: it is used in relation to a corporation. Note: Clause 13.6.4 shows an example of a fact type role designation, .prior example., and also shows examples of fact type roles having no fact type role designation. At the end of the first paragraph of 13.3.1 ADD the following sentence: A consumer of a model in which two elements represent the same thing should assume that a fact represented in reference to either element applies to both elements (since they both represent the same thing). In 13.6.4 in the XML shown for .Synonymous Form: example1 has prior example., REMOVE the following two lines: Immediately above the two removed lines, in the line that looks like this: REPLACE .term. with .factTypeRoleDesignation. so that the line looks like this: Disposition: Resolved From: Don Baisley To: "'sbvr-rtf@omg.org'" Subject: RE: issue 15450 -- SBVR RTF issue Thread-Topic: issue 15450 -- SBVR RTF issue Thread-Index: AQHLT5N5awRgzau4KUyQLqD8wBfXKJTFF0PggAyy/BCAKpY2QIAdzcOwgAu0LQCAC58R4A== Date: Fri, 26 Aug 2011 16:55:08 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.73] Here is the resolution to issue 15450 as approved for ballot in today.s SBVR call. Best regards, Don SBVR Issue 154506.doc Disposition: Resolved OMG Issue No: 15450 Title: Fact Type Role Designation Source: Keri Anderson Healy, keri_ah@mac.com Summary: In 11.2.1 we have an entry for something termed .fact type role designation. . its definition says that it is a .designation that represents a fact type role and that is not a placeholder.. There is nothing beyond a Definition for this concept. This entry doesn.t make sense. I recommend it be dropped. (Or, if someone does see some usefulness for it, then please augment it with some notes and examples.). Resolution: Revise the definition of .fact type role designation. and add structural rules, notes and an example. Also, correct a problem in the XML example of a fact type role designation which mistakenly showed the fact type role designation as being a term. A clarification to the representation of multiclassification in models is added. Revised Text: In 11.2.1 REPLACE Figure 11.6 with this figure: In 11.2.1.2 REPLACE definition in the entry for .fact type role designation. with the following: Definition: designation that is of a fact type role and that is recognizable in use in the context of another role of the same fact type Necessity: No fact type role designation is a term. Necessity: No fact type role designation is a placeholder. Necessity: No fact type role designation represents a situational role. Note: A fact type role designation should not be confused with a placeholder or with a term for a situational role, even though all of these can have the same expression. A situational role is an object type and is not a fact type role. Note: A fact type role designation should not be confused with a placeholder, which is part of a fact type form. In uses of a fact type form, placeholders are replaced. A fact type role designation can replace a placeholder. Fact type role designations occur in statements and definitions to refer to what fills the role. Example: The fact type role designation, .CEO., for a role in the fact type .corporation has CEO. does not represent a situational role and is not the same thing as the .CEO. placeholder in that fact type form. Here we see different designations have the same signifier, .CEO.. The fact type role designation represents the fact type role in the context of using the fact type, such as in the phrases .EU-Rent.s CEO. and .the CEO of some corporation.. But a situational role, even if defined in terms of the fact type, can be used independently, as in the statement, .Every CEO is a person.. The placeholder .CEO. of the fact type form .corporation has CEO. is part of the form and gets replaced in each use of the form. In the statement, .EU-Rent has exactly one CEO., the .CEO. placeholder of the fact type form .corporation has CEO. is replaced by .exactly one CEO., comprised of a quantifier and the fact type role designation .CEO., which is understood to represent the fact type role because of its context: it is used in relation to a corporation. Note: Clause 13.6.4 shows an example of a fact type role designation, .prior example., and also shows examples of fact type roles having no fact type role designation. At the end of the first paragraph of 13.3.1 ADD the following sentence: A consumer of a model in which two elements represent the same thing should assume that a fact represented in reference to either element applies to both elements (since they both represent the same thing). In 13.6.4 in the XML shown for .Synonymous Form: example1 has prior example., REMOVE the following two lines: Immediately above the two removed lines, in the line that looks like this: REPLACE .term. with .factTypeRoleDesignation. so that the line looks like this: Disposition: Resolved