Issue 15635: Placeholder concepts model SBVR Structured English syntax (sbvr-rtf) Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov) Nature: Revision Severity: Minor Summary: In clause 8.3.4 of SBVR v1.0, the concepts: 'placeholder has starting character position' and 'placeholder uses designation' model the syntax of the non-normative Structured English language described in Annex C of the spec. These may not be properties of the syntax of other vocabulary and rules languages, and are unsuitable for graphical languages. The abstract syntax of any such language must be that a placeholder is an expression and must be unique within the fact type form. These requirements should be stated in the definition of placeholder. The placeholder expression is a designation for the role that is used only in definitions of the fact type, and its forms and roles. The idea of its "character position" is meaningless in graphical languages. The idea specified in 'placeholder uses designation' is a language convention that is not consistently used in SBVR and may well be different in other languages. The semantics of that syntactic construct is captured by 'role ranges over object type' in 8.1.1. Any convention for the syntax used by a tool is out of scope for SBVR. Therefore, both of these fact types should be deleted from the normative specification. Resolution: Revised Text: Actions taken: September 23, 2010: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 23 Sep 2010 18:48:36 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Ed Barkmeyer Employer: NIST mailFrom: edbark@nist.gov Terms_Agreement: I agree Specification: SBVR Section: 8.3.4 FormalNumber: formal/2008-01-02 Version: 1.0 Doc_Year: Year Doc_Month: Month Doc_Day: Day Page: 31 Title: Placeholder concepts model SBVR Structured English syntax Nature: Revision Severity: Minor CODE: 3TMw8 B1: Report Issue Description: In clause 8.3.4 of SBVR v1.0, the concepts: 'placeholder has starting character position' and 'placeholder uses designation' model the syntax of the non-normative Structured English language described in Annex C of the spec. These may not be properties of the syntax of other vocabulary and rules languages, and are unsuitable for graphical languages. The abstract syntax of any such language must be that a placeholder is an expression and must be unique within the fact type form. These requirements should be stated in the definition of placeholder. The placeholder expression is a designation for the role that is used only in definitions of the fact type, and its forms and roles. The idea of its "character position" is meaningless in graphical languages. The idea specified in 'placeholder uses designation' is a language convention that is not consistently used in SBVR and may well be different in other languages. The semantics of that syntactic construct is captured by 'role ranges over object type' in 8.1.1. Any convention for the syntax used by a tool is out of scope for SBVR. Therefore, both of these fact types should be deleted from the normative specification. Date: Wed, 13 Oct 2010 14:42:50 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: SBVR RTF Subject: SBVR: Proposed resolution of Issue 15635 X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: o9DIgtPe011196 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1287600179.789@BQqAQBwojDnKxRnUqrvoBg X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov As I promised on Friday, I attach a draft of the resolution. Comments, revisions, welcome. Unfortunately, I just noticed that these fact types are used in clause 13.6 as examples of how to exchange information, and those examples will also need modification. This is truly unfortunate, because it means that clause 13 gives guidance that foreseeably only applies to SBVR SE. Before I take the trouble to work on these examples, I want to know whether this resolution will be thrown away. I don't want to waste any more of the taxpayer's money. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 Issue 15635-d1.doc Subject: Re: SBVR: Proposed resolution of Issue 15635 X-KeepSent: A9E699E1:BAF75A1F-852577BB:006EA729; type=4; name=$KeepSent To: sbvr-rtf@omg.org X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Mark H Linehan Date: Wed, 13 Oct 2010 16:12:48 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 10/13/2010 16:12:52 I agree with Ed's proposed resolution. Removing the two fact types from clause 13.6 could in theory affect tools, but I think the information provided by these fact types was not really needed. It should be easy for tools to drop any dependency on these fact types. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com To: sbvr-rtf@omg.org Subject: Re: SBVR: Proposed resolution of Issue 15635 X-KeepSent: CC2AEAC9:5342A2A3-852577BD:005121F7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Mark H Linehan Date: Fri, 15 Oct 2010 11:22:07 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 10/15/2010 11:22:08, Serialize complete at 10/15/2010 11:22:08 Thinking further about the proposed resolution, I am concerned about this proposed Note: "The placeholder for the fact type role is not a designation in the vocabulary that contains the fact type designation. The placeholder itself never appears in a fact that is expressed using the fact type form. It is used only within the terminological entry." I don't think this statement is entirely true: 1. The proposed Example includes this example âRental 879 has the return date 30 June 2006â, where "Rental" and "rental date" seem to be uses of placeholders. 2. Rules often seem to use placeholders. Consider the first EU-Rent Introductory Example rule in Annex E.1.4: "It is necessary that each rental has exactly one requested car group. ", which uses the supporting fact type "rental has requested car group ". 3. Points #1 and #2 are not limited to placeholders in "of/has" verb concepts. Annex E.1.4 example 4 shows a use of the "location penalty charge " placeholder of the verb concept "rental incurs location penalty charge " in the rule "It is obligatory that the rental incurs a location penalty charge if ...." What seems to be true of all these examples, is that a corresponding object type or situation role is also declared for the placeholder. For example, "requested car group" is defined as: requested car group Concept Type: role Definition: car group that is requested for a rental Necessity: At a given date/time each rental has exactly one requested car group. I think the Note should read: "The placeholder for the fact type role is not itself a designation in the vocabulary that contains the fact type designation. The vocabulary may have another terminological entry (e.g. for an object type or situational role) with the same signifier, in which case the role ranges over that concept. Rules and facts may appear to reference placeholders but actually are referencing the concepts ranged over by the roles designated by the placeholders." -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Date: Fri, 15 Oct 2010 16:26:01 -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: SBVR: Proposed resolution of Issue 15635 X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: o9FKQ5K0006789 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1287779168.19442@QDYq5os9EOnXD+BoHiR5Gg X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov Mark Linehan wrote: Thinking further about the proposed resolution, I am concerned about this proposed Note: "The placeholder for the fact type role is not a designation in the vocabulary that contains the fact type designation. The placeholder itself never appears in a fact that is expressed using the fact type form. It is used only within the terminological entry." I don't think this statement is entirely true: If placeholders are what they are defined to be, then it must be true -- "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". Whatever that expression is is what actually appears in usage. 1. The proposed Example includes this example .Rental 879 has the return date 30 June 2006., where "Rental" and "rental date" seem to be uses of placeholders. "Rental 879" is a proper name, an individual concept designation. It happens to contain the expression that is the signifier for the object type "rental". Its only relationship to the placeholder is that the expressions overlap. Similarly, the occurrence of "return date" in the above cannot be a "placeholder", since "30 June 2006" is what is substituted for the placeholder "return date" -- it is the expression that denotes what plays the fact type role. The current SBVR explanation appears to be that "return date" in that usage is a kind of "cast" of the date 30 June 2006 to the situational role 'return date'. (This "cast" idea -- declaring a thing to be an instance of a narrower type in a given usage -- is explained in Annex C with doubletalk, because SBVR has no such concept.) In any case, the only thing this occurrence of 'return date' has in common with the placeholder is the expression. 2. Rules often seem to use placeholders. Consider the first EU-Rent Introductory Example rule in Annex E.1.4: "It is necessary that each rental has exactly one requested car group. ", which uses the supporting fact type "rental has requested car group ". As I understand Annex C, "requested car group" in the rule is the signifier for a situational role, which is treated as a noun concept. That term is therefore in the vocabulary. The one in the fact type form is a placeholder. (In my grammar, 'requested car group' is a "property" of a 'rental', but that is a separate issue.) 3. Points #1 and #2 are not limited to placeholders in "of/has" verb concepts. Annex E.1.4 example 4 shows a use of the "location penalty charge " placeholder of the verb concept "rental incurs location penalty charge " in the rule "It is obligatory that the rental incurs a location penalty charge if ...." Same as above. "location penalty charge" is the signifier for a fact type role of "incurs" and is therefore a placeholder, and it is also a signifier for a situational role. What seems to be true of all these examples, is that a corresponding object type or situation role is also declared for the placeholder. Yes. That is, the 'situational role' is derived from the fact type. For example, "requested car group" is defined as: requested car group Concept Type: role Definition: car group that is requested for a rental Necessity: At a given date/time each rental has exactly one requested car group. Technically, this definition is ambiguous. Is the intended interpretation of 'a rental' 'any rental ever' or 'a given rental'? SBVR currently plays on this ambiguity and uses the term in both senses. I think the Note should read: "The placeholder for the fact type role is not itself a designation in the vocabulary that contains the fact type designation. The vocabulary may have another terminological entry (e.g. for an object type or situational role) with the same signifier Yes. , in which case the role ranges over that concept. This is only a convention of SBVR Structured English. It is not a requirement for the behavior of placeholders in other languages. In some languages, the required term is the range of the role, and if no placeholder designation is provided, then the signifier for the range is used as the signifier for the placeholder or created from it in such a way as to be unique. In other languages, two terms are required in the fact type form: the fact type form creates the placeholder (role term) and references the range term. And in some languages, the placeholders are only artificial -- they are always called p1, p2, etc. It just happens that SBVR SE tries to do both jobs with one expression -- name the role and define its range. If we want to make requirements like this, we must make SBVR SE normative. That was the whole point of my issue. Rules and facts may appear to reference placeholders but actually are referencing the concepts ranged over by the roles designated by the placeholders." Right. We can edit the Note to say this. The important idea in the note is that a placeholder is not a vocabulary entry; and one should not confuse the placeholder with designations for object types and situational roles that have similar expressions. -Ed -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Date: Fri, 15 Oct 2010 18:25:06 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) To: SBVR RTF Subject: SBVR: rethink of Issue 15635 - fact type forms in vocabularies X-NISTMEL-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: o9FMPAEC017365 X-NISTMEL-MailScanner: Found to be clean X-NISTMEL-MailScanner-SpamCheck: X-NISTMEL-MailScanner-From: edbark@nist.gov X-NISTMEL-MailScanner-Watermark: 1287786314.9064@yi6ZyPCna20A+hqNEi6N7w X-Spam-Status: No X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: edbark@nist.gov I realized after looking at the examples in clause 13.6 that SBVR makes a problematic assumption about fact type forms. SBVR makes the assumption that a fact type form has a simple text representation, and the requirement is to recognize the placeholder in that text string. So 'starting character position' denotes the character position at which the placeholder String occurs in the String that is the natural language "reading" of the fact type form. This is obviously a purely computational model. The real question is what we are assuming about the nature of a 'fact type form' when we say that it is an entry in a conceptual schema. A 'pattern of use' in a language clearly depends somewhat on the syntax of the language. What really troubles me is the idea that a 'pattern of use' in one language will have any meaning as a 'pattern of use' to a tool that speaks a significantly different language. For example, my tool uses the form: (category: concept) specializes (more general concept: concept) A LISP-like tool might write the form as: (roles category more-general-concept)(specializes category more-general-concept) In general, the form of a fact type template in some unspecified language might not naturally be a string, and when 'stringified', might use some other markup to denote placeholders. For example, the stringified form of a fact type form might be an expression that is an XML structure. E.g. category specializes more general concept I cannot imagine what use Don's tool, or Markus's tool can make of these. I don't think we intend that syntactic templates like these are what goes into the conceptual schema. They can't usefully be exchanged between tools. So we must be much clearer in stating the structural requirement for a fact type form in the exchange. A fact type form is NOT a pattern of use in the chosen language; it is a "reading" of the fact type in nearly natural language, regardless of the formal structure of the chosen language. We mean a fact type form to be an unmarked text string in which the placeholders occur as text. And then, as Don noted, there is either the additional requirement that each placeholder expression occur exactly once in the text string, or the requirement that each placeholder have a 'starting character position' in that text string. Both of these approaches uniquely identify the text of the placeholder within the text string. But if we use a unique occurrence rule, concept specializes more general concept is not a valid fact type form, because the signifier for the first role 'concept' is not unique within the fact type form. That is why we chose 'starting character position' as the means of finding the placeholder in the form. One of the rules must be that markup is permitted only within placeholder expressions, and they are considered to be verbatim. So my form: (category: concept) specializes (more general concept: concept) implies that the placeholder for the 'category' role is: "(category: concept)" and that is the expression one expects to see as the role signifier in any use, such as the text of a definition. Since that is not what is intended, I have to send: category specializes more general concept regardless of what fact type forms in my language look like. But there is a related problem: the placeholder has only one use -- the representation of the role in a particular form. Each placeholder does belong to a unique fact type form. Its relationship to placeholders in other fact type forms is that it refers to the same fact type role. The same expression can appear as a placeholder in more than one form of the same fact type, but each is a distinct placeholder, with a distinct starting character position. That being the case, what expression is used to refer to a fact type role in a Definition? In the definition, we are using some/any placeholder as a signifier for the role. So there must be a requirement that the placeholder expression cannot be used to denote any other fact type role in any fact type form for the same fact type. So, much of what issue 15635 says is /false/! SBVR /does/ specify the syntax of a fact type form, because it must be interchanged verbatim. If you have a graphical language or a LISP-like language, the fact type form still has to be the text "reading", not the actual form. We do need 'starting character position' to support the specified syntax, and we need additional rules to make the use of placeholders in definitions unambiguous. So we get to start over on the resolution. I believe that this is what happened to the original issue, but the resolution didn't change the text to make this clear. And of course, the deletion of placeholder uses designation (to capture the range of the role) is a purely Structured English convention. That should in any case be deleted. I will work on draft2, taking Mark's comments into account. I have no idea what the grammar for a natural language "reading" of a fact type form might look like. But we can't interchange fact type forms if we don't specify it. I think the pattern is: placeholder verb-element ( placeholder | verb-element )* That is: one placeholder followed by one verb-element is required, and there may then follow any number of placeholders or verb-elements in any order. Some combination of verb-elements must be a signifier for the fact type, but since we really use the fact type form as the signifier in the vocabulary, and the actual language syntax can be something significantly different, that is an academic issue. E.g. DateTime has: time point1 /through/ time point2 /defines/ time period. time period /is defined as/ timepoint1 /through/ time point2. but a German fact type form might be Zeitperiode /wird als/ Zeitpunkt1 /bis/ Zeitpunkt2 /definiert/. The fundamental verb form is "wird definiert" (is defined). -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Subject: Re: SBVR: rethink of Issue 15635 - fact type forms in vocabularies X-KeepSent: 408D7F70:FDFD71FB-852577C6:000D14D2; type=4; name=$KeepSent To: SBVR RTF X-Mailer: Lotus Notes Release 8.5.1FP1 SHF20 February 10, 2010 From: Mark H Linehan Date: Sat, 23 Oct 2010 22:34:10 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.0.2FP4|December 10, 2009) at 10/23/2010 22:59:03 Ed, Several points: 1) Instead of a rule that each placeholder has a unique occurrence in the fact type form, we could have a "best match rule". In the example verb concept "concept specializes more general concept", it's easy to understand that the placeholder "more general concept" best matches the 2nd placeholder of the fact type form, and the other placeholder "concept" then best matches the first placeholder. The rule is something like "longest match wins". Furthermore, we could allow that the "best match rule" may be dependent upon the fact type form language or style. For example, if a fact type form reading is given aurally then there must be some quite different algorithm for matching placeholders to fact type forms (!) Of course, this raises the issue of how one defines this "best match" -- I think the one for Structured English must be hard to express in SBVR. And I guess we would have to say that any set of tools that want to exchange SBVR XMI files have to agree on the fact type forms and corresponding "best match rules" that they jointly support. But that's not much of a stretch beyond the idea that they should agree on the languages that they support. 2) In the current SBVR model, fact type forms are included in vocabularies, which are expressed in languages. Languages are supposed to be the ISO codes for real human languages, but it would not be much of a stretch to have codes that identify variant fact type forms, such as an XML-based English form. Alternatively, we could invent another labelling mechanism for identifying the format of a fact type form. -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 784-7002 or IBM tieline 863-7002 internet: mlinehan@us.ibm.com Ed Barkmeyer ---10/15/2010 06:26:43 PM---I realized after looking at the examples in clause 13.6 that SBVR makes a problematic assumption ab From: Ed Barkmeyer To: SBVR RTF Date: 10/15/2010 06:26 PM Subject: SBVR: rethink of Issue 15635 - fact type forms in vocabularies -------------------------------------------------------------------------------- I realized after looking at the examples in clause 13.6 that SBVR makes a problematic assumption about fact type forms. SBVR makes the assumption that a fact type form has a simple text representation, and the requirement is to recognize the placeholder in that text string. So 'starting character position' denotes the character position at which the placeholder String occurs in the String that is the natural language "reading" of the fact type form. This is obviously a purely computational model. The real question is what we are assuming about the nature of a 'fact type form' when we say that it is an entry in a conceptual schema. A 'pattern of use' in a language clearly depends somewhat on the syntax of the language. What really troubles me is the idea that a 'pattern of use' in one language will have any meaning as a 'pattern of use' to a tool that speaks a significantly different language. For example, my tool uses the form: (category: concept) specializes (more general concept: concept) A LISP-like tool might write the form as: (roles category more-general-concept)(specializes category more-general-concept) In general, the form of a fact type template in some unspecified language might not naturally be a string, and when 'stringified', might use some other markup to denote placeholders. For example, the stringified form of a fact type form might be an expression that is an XML structure. E.g. category specializes more general concept I cannot imagine what use Don's tool, or Markus's tool can make of these. I don't think we intend that syntactic templates like these are what goes into the conceptual schema. They can't usefully be exchanged between tools. So we must be much clearer in stating the structural requirement for a fact type form in the exchange. A fact type form is NOT a pattern of use in the chosen language; it is a "reading" of the fact type in nearly natural language, regardless of the formal structure of the chosen language. We mean a fact type form to be an unmarked text string in which the placeholders occur as text. And then, as Don noted, there is either the additional requirement that each placeholder expression occur exactly once in the text string, or the requirement that each placeholder have a 'starting character position' in that text string. Both of these approaches uniquely identify the text of the placeholder within the text string. But if we use a unique occurrence rule, concept specializes more general concept is not a valid fact type form, because the signifier for the first role 'concept' is not unique within the fact type form. That is why we chose 'starting character position' as the means of finding the placeholder in the form. One of the rules must be that markup is permitted only within placeholder expressions, and they are considered to be verbatim. So my form: (category: concept) specializes (more general concept: concept) implies that the placeholder for the 'category' role is: "(category: concept)" and that is the expression one expects to see as the role signifier in any use, such as the text of a definition. Since that is not what is intended, I have to send: category specializes more general concept regardless of what fact type forms in my language look like. But there is a related problem: the placeholder has only one use -- the representation of the role in a particular form. Each placeholder does belong to a unique fact type form. Its relationship to placeholders in other fact type forms is that it refers to the same fact type role. The same expression can appear as a placeholder in more than one form of the same fact type, but each is a distinct placeholder, with a distinct starting character position. That being the case, what expression is used to refer to a fact type role in a Definition? In the definition, we are using some/any placeholder as a signifier for the role. So there must be a requirement that the placeholder expression cannot be used to denote any other fact type role in any fact type form for the same fact type. So, much of what issue 15635 says is /false/! SBVR /does/ specify the syntax of a fact type form, because it must be interchanged verbatim. If you have a graphical language or a LISP-like language, the fact type form still has to be the text "reading", not the actual form. We do need 'starting character position' to support the specified syntax, and we need additional rules to make the use of placeholders in definitions unambiguous. So we get to start over on the resolution. I believe that this is what happened to the original issue, but the resolution didn't change the text to make this clear. And of course, the deletion of placeholder uses designation (to capture the range of the role) is a purely Structured English convention. That should in any case be deleted. I will work on draft2, taking Mark's comments into account. I have no idea what the grammar for a natural language "reading" of a fact type form might look like. But we can't interchange fact type forms if we don't specify it. I think the pattern is: placeholder verb-element ( placeholder | verb-element )* That is: one placeholder followed by one verb-element is required, and there may then follow any number of placeholders or verb-elements in any order. Some combination of verb-elements must be a signifier for the fact type, but since we really use the fact type form as the signifier in the vocabulary, and the actual language syntax can be something significantly different, that is an academic issue. E.g. DateTime has: time point1 /through/ time point2 /defines/ time period. time period /is defined as/ timepoint1 /through/ time point2. but a German fact type form might be Zeitperiode /wird als/ Zeitpunkt1 /bis/ Zeitpunkt2 /definiert/. The fundamental verb form is "wird definiert" (is defined). -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." From: Don Baisley To: "sbvr-rtf@omg.org" Subject: RE: issue 15635 -- SBVR RTF issue -- Resolution Thread-Topic: issue 15635 -- SBVR RTF issue -- Resolution Thread-Index: AQHLZZiWKyZcnPwBBkOuqNP2mX5caJS90fTQ Date: Tue, 14 Jun 2011 05:05:48 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.32] The attached resolution is based on the notes from the March 24 SBVR meeting, shown below annotated in square brackets to show what is added and what was verified. ----------------- Issue 15635 .Placeholder Concepts Model SBVR Structured English. · Need to define what is permitted in plain, unmarked up text (text2) and be clear that a plain text version of the expression (text2) is required and any marked up version of the expression (text1) is optional. [ADDED that markup is not considered.] . Need to be absolutely clear that any text in a fact type form that is not part of a placeholder expression text is part of the fact symbol expression text [ADDED.] · Make clear that the expression that represents fact type forms and the expression of each placeholder representation are all separate entries in an SBVR interchange file. [OK. Shown in 13.4 and in 13.6.4] · Make clear that there must be a placeholder representation expression for each starting character position defined for a fact type form. [OK. .starting character position is defined only for placeholder.] · Make clear that placeholders are specific to one given fact type form [OK. First necessity under .placeholder.] · Make clear that the end of the placeholder and beginning of the next part of the fact symbol is determined by matching each placeholder representation expression for the fact type form to the representation expression of the fact type form until a match is found; that a not found is an SBVR model error; and that the length of the placeholder in the fact type form expression is the length of the placeholder expression. [ADDED.] · Make clear that placeholders, which are designations, are designations for .fact type role. concepts. Verify that we have an SBVR fact type to support this. [OK. stated in definition of .placeholder. and in necessity in that entry] · Add note pointing to Clause 13.6.4 examples drawing out how they illustrate each aspect of fact type forms, starting character positions and placeholder representation expressions. [ADDED.] · Clarify purpose and usage of .placeholder uses designation. and point to examples in Clause 13.6.4. [ADDED.] . Make that that the semantics connections for .placeholder uses designation. are provided by .role ranges over object type. [ADDED.] . Make clear how .placeholder uses designation. works when using placeholder representation expressions + placeholder starting character position to determine the end of the placeholder and the beginning of the next part of the fact symbol in the fact type form. [ADDED.] SBVR Issue 15635.doc Disposition: Resolved OMG Issue No: 15635 Title: Placeholder concepts model SBVR Structured English syntax Source: Ed Barkmeyer, NIST, edbark@nist.gov Summary: In clause 8.3.4 of SBVR v1.0, the concepts: 'placeholder has starting character position' and 'placeholder uses designation' model the syntax of the non-normative Structured English language described in Annex C of the spec. These may not be properties of the syntax of other vocabulary and rules languages, and are unsuitable for graphical languages. The abstract syntax of any such language must be that a placeholder is an expression and must be unique within the fact type form. These requirements should be stated in the definition of placeholder. The placeholder expression is a designation for the role that is used only in definitions of the fact type, and its forms and roles. The idea of its "character position" is meaningless in graphical languages. The idea specified in 'placeholder uses designation' is a language convention that is not consistently used in SBVR and may well be different in other languages. The semantics of that syntactic construct is captured by 'role ranges over object type' in 8.1.1. Any convention for the syntax used by a tool is out of scope for SBVR. Therefore, both of these fact types should be deleted from the normative specification. Resolution: The use of a starting character position to locate a placeholder within a fact type form is meaningful only for fact type forms whose expressions are sequences of characters. Business vocabularies are generally defined using such expressions and so are SBVR.s own vocabularies. However, fact types can be represented by expressions that are not sequences of characters. SBVR provides a reference scheme only for placeholders in fact type forms that are sequences of characters. SBVR does not prohibit use of other reference schemes for placeholders, nor does it prohibit nontextual fact type forms. The text is revised to add clarifying notes regarding textual fact type forms. Revised Text: In 8.2 ADD the following note at the end of the entry for .text.. Note: A text is taken as a sequence of characters. Interpretation of markup is not addressed by this document. In 8.3.4 at the end of the entry for .fact type form demonstrates designation., ADD the following note: Note: If a fact type form demonstrates a designation, the signifier of that designation is what is seen in the expression of the fact type form when placeholder expressions have been removed. MOVE the entire entry for starting character position from clause 8.2 to clause 8.3.4 and place it immediately before the entry for .placeholder is at starting character position.. In 8.3.4 ADD the following notes to the end of the entry for .placeholder is at starting character position.. Note: If a placeholder is at a starting character position within a fact type form, then the expression of the placeholder exactly matches the characters in the expression of the fact type form, character for character, from the starting character position through the full length of the placeholder.s expression. Placeholders. expressions do not overlap each other within the expression of a fact type form. If the fact type form demonstrates a designation, the designation.s signifier appears within the part or parts of the fact type form.s expression that are not occupied by placeholders. Note: See 13.6.4 for detailed examples showing various aspects of fact type forms, placeholders and their starting character positions. In 8.3.4 ADD the following sentences to the end of first note in the entry for .placeholder uses designation.. A placeholder.s use of a designation is part of the template or pattern of a fact type form and aids recognition of uses of the fact type form, as in the following examples. Separately, it is a matter of convention whether a placeholder.s use of a designation implies that the fact type role ranges over the concept represented by the designation. See further examples in 13.6.4. In 13.2.7, Data Values, just before the Rationale section, ADD the following paragraph. Each text value is a Unicode string and is considered without regard to markup. Disposition: Resolved Subject: RE: issue 15635 -- SBVR RTF issue -- Resolution X-KeepSent: BB70471B:2307FC49-852578AF:006BD582; 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: Tue, 14 Jun 2011 15:52:47 -0400 X-MIMETrack: Serialize by Router on D01MC604/01/M/IBM(Release 8.5.2FP1 ZX852FP1HF6|May 2, 2011) at 06/14/2011 15:52:56 One suggestion: add a Note or mention in "fact type form demonstrates designation", referencing "fact symbol" and "fact type form incorporates fact symbol" (11.2.1.2). -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research From: Don Baisley To: "sbvr-rtf@omg.org" Subject: RE: issue 15635 -- SBVR RTF issue -- Resolution Thread-Topic: issue 15635 -- SBVR RTF issue -- Resolution Thread-Index: AQHLZZiWKyZcnPwBBkOuqNP2mX5caJS90fTQgAFxd4CADJCroA== Date: Thu, 23 Jun 2011 02:47:39 +0000 Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [157.54.51.37] The attached proposed resolution adds the note suggested by Mark below and changes a definition as suggested by Ed in last week's call. Regards, Don -----Original Message----- From: Mark H Linehan [mailto:mlinehan@us.ibm.com] Sent: Tuesday, June 14, 2011 12:53 PM To: sbvr-rtf@omg.org Subject: RE: issue 15635 -- SBVR RTF issue -- Resolution One suggestion: add a Note or mention in "fact type form demonstrates designation", referencing "fact symbol" and "fact type form incorporates fact symbol" (11.2.1.2). -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research graycol264.gif