Issue 9946: Section: 8.3 (sbvr-ftf) Source: Business Semantics Ltd. (Mr. Donald R. Chapin, Donald.Chapin(at)BusinessSemantics.com) Nature: Enhancement Severity: Critical Summary: ISSUE: Use URI to Uniquely Identify and Assert the Existence of Every 'Thing' Represented in an SBVR Model to Support Multi-Classification of 'Things' Need to develop a URI pattern for all kinds of representations that can assert the existence of any 'thing' in an SBVR Model. These patterns need to take Speech Community and Symbol Context / Subejct Area into account. The appraoch chosen needs to support composite identifiers and identifiers with a narrow context scope. Topic Maps has an excellent approach for this and has done extensive work with the W3C to identifying the issues with URIs and the best ways to deal with them. For Topic Map / W3C References see: ftp://ftp.omg.org/pub/sbvr-ftf/Issue%20Attachments/Subject%20Identifiers.doc Another benefit of this is that is laying the necessary foundation for mapping to RDF/ORL as well as the Rules Interchange Format Resolution: Deferred to second SBVR Revision Task Force because there were more foundational issues that had to be resolved first, and it was very important SBVR v1.1 out as soon as they were done. Disposition: Deferred Revised Text: Actions taken: July 24, 2006: received issue Discussion: This Issue was received just before the Issue deadline which was only 6 weeks before the FTF report was due, and more basic Issues had to be resolved first. End of Annotations:===== m: webmaster@omg.org Date: 24 Jul 2006 15:46:33 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Donald Chapin Company: Business Semanitcs Ltd mailFrom: Donald.Chapin@btinternet.com Notification: No Specification: SBVR Section: 8.3 FormalNumber: dtc/06-03-02 Version: Interim Specification RevisionDate: March 2006 Page: 22 Nature: Enhancement Severity: Critical HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; InfoPath.1; .NET CLR 2.0.50727) Description ISSUE: Use URI to Uniquely Identify and Assert the Existence of Every 'Thing' Represented in an SBVR Model to Support Multi-Classification of 'Things' Need to develop a URI pattern for all kinds of representations that can assert the existence of any 'thing' in an SBVR Model. These patterns need to take Speech Community and Symbol Context / Subejct Area into account. The appraoch chosen needs to support composite identifiers and identifiers with a narrow context scope. Topic Maps has an excellent approach for this and has done extensive work with the W3C to identifying the issues with URIs and the best ways to deal with them. For Topic Map / W3C References see: ftp://ftp.omg.org/pub/sbvr-ftf/Issue%20Attachments/Subject%20Identifiers.doc Another benefit of this is that is laying the necessary foundation for mapping to RDF/ORL as well as the Rules Interchange Format Date: Mon, 24 Jul 2006 17:18:34 -0400 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: Juergen Boldt Subject: Re: issue 9946 -- SBVR FTF issue X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No Gee, I wonder which OMG specification will be the one to get Issue 10000! At the rate we are going, we should know by the Anaheim meeting! -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 Subject: RE: issue 9946 -- SBVR FTF issue -- URIs for SBVR terms, etc. Date: Tue, 19 Dec 2006 16:27:39 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 9946 -- SBVR FTF issue -- URIs for SBVR terms, etc. Thread-Index: AcavW4Qu+vPSRAvlTaa+4j36NJG+Exzp4GWw From: "Baisley, Donald E" To: X-OriginalArrivalTime: 20 Dec 2006 00:27:40.0010 (UTC) FILETIME=[A82C6CA0:01C723CD] The SBVR namespaces are to be identified by URIs (e.g. http://schema.omg.org/specs/SBVR/1.0/SBVR). We can use the namespace URIs to construct URIs for SBVR designations, fact type forms and placeholders. The URIs can then be used with RDF to state facts in terms of SBVR and for other purposes in a Web context. Below I recommend a pattern for making this happen. I am not recommending that we standardize in SBVR how everyone.s vocabularies should be referenced via URIs. But I am recommending that we state how SBVR.s own vocabulary is referenced using URIs. Others can follow our pattern if they want. I am not sure how the pattern I am recommending fits typical URI formation, but I believe that at least the use of .#. is typical. For each designation d in a vocabulary namespace having URI vn, the URI of the designation is vn#d. where d. is formed by replacing all spaces in the signifier of d with hyphens. Example: http://schema.omg.org/specs/SBVR/1.0/SBVR#proposition for SBVR.s designation .proposition.. For each fact type form ftf in a vocabulary namespace having URI vn, the URI of the designation is vn#ftf. where ftf. is formed by removing any subscripts and replacing all spaces in the expression of ftf with hyphens. Example: http://schema.omg.org/specs/SBVR/1.0/SBVR#statement-expresses-proposition for SBVR.s fact type form .statement expresses proposition.. For each designation d in a role namespace for a concept c within a vocabulary namespace having URI vn, the URI of the designation is vn#c..d. where d. is formed by replacing all spaces in the signifier of d with hyphens and c. is formed from a designation for c by replacing all spaces with hyphens. Example: http://schema.omg.org/specs/SBVR/1.0/SBVR#proposition.statement for SBVR.s designation .statement. in for a role of the fact type .proposition has statement.. For each placeholder p of a fact type form ftf in a vocabulary namespace having URI vn, the URI of the placeholder is vn#ftf..p. where ftf. is formed by replacing all spaces in the expression of ftf with hyphens and p. is formed by replacing all spaces in the expression of the p. All subscripts are raised. Example: http://schema.omg.org/specs/SBVR/1.0/SBVR#statement-expresses-proposition.proposition for the .proposition. placeholder in SBVR.s fact type form .statement expresses proposition.. These four simple patterns would likely work out well for using SBVR concepts with RDF. The first would be used with rdf:type. The second and third both work as the .predicate. in typical RDF subject-predicate-object triples. The fourth would be used with ternary fact types (which must be objectified to work in RDF) in subject-predicate-object triples to relate an actuality (the subject) to an object in a role. I would like to hear from those who are experienced at constructing URIs and those experienced with RDF. Please comment on the recommended patterns. Thanks, Don Subject: RE: [SBVR-FTF] issue 9946 -- URIs for SBVR designations Date: Tue, 6 Feb 2007 16:32:03 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SBVR-FTF] issue 9946 -- URIs for SBVR designations Thread-Index: AcavW4Qu+vPSRAvlTaa+4j36NJG+Exzp4GWwCdHOFCA= From: "Baisley, Donald E" To: , "Cory Casanave" , "Cummins, Fred A" X-OriginalArrivalTime: 07 Feb 2007 00:32:04.0347 (UTC) FILETIME=[63F8CCB0:01C74A4F] It seems that issue 9946 can be easily solved by specifying how a URI is formed for a designation or fact type form in an SBVR namespace (just the namespaces we define in the SBVR specification, not others). We have already defined the URIs for SBVR.s namespaces, so we have a starting point. The rules are simple: Start with a vocabulary namespace.s URI. Append a .#. or ./. [WE MUST DECIDE WHICH TO USE . see blow]. Append the expression of a designation or fact type form that is in the namespace, but with all spaces replaced by hyphens and all subscripts removed. For designations and fact type forms within a role namespace for a concept: Start with a URI for a designation of the concept. Append a period (...). Do step 3 above. Optionally, for placeholders of a fact type form used to refer to a role of the fact type: Start with a URI for a designation of the fact type form. Append a period (...). Append the expression of the placeholder as in step 3 above. If the text appended in step three matches more than one placeholder, append the ordinal position of the placeholder. Examples: http://schema.omg.org/specs/SBVR/1.0/MeaningAndRepresentation/concept http://schema.omg.org/specs/SBVR/1.0/MeaningAndRepresentation/noun-concept http://schema.omg.org/specs/SBVR/1.0/MeaningAndRepresentation/concept-incorporates-characteristic http://schema.omg.org/specs/SBVR/1.0/MeaningAndRepresentation/concept-specializes-concept http://schema.omg.org/specs/SBVR/1.0/MeaningAndRepresentation/concept-specializes-concept.concept1 http://schema.omg.org/specs/SBVR/1.0/MeaningAndRepresentation/concept.definition Adding these simple rules makes SBVR ready to use right out of the box with XML/RDF. Questions to answer: Where should these rules be stated? I think they should be in a normative section. A new chapter 16? A new section in chapter 15? Should we use .#. or ./.? I suspect there is some significance to which we choose. The .#. might be reserved for identifying a part of a document. Since these are pure URIs, we might need to use ./., which I have seen used for Dublin Core and a for a mapping of UML to RDF. But I.m not the expert on this subject. Please respond. Thanks, Don Date: Wed, 07 Feb 2007 18:58:46 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru CC: sbvr-ftf@omg.org, Cory Casanave , "Cummins, Fred A" Subject: Re: [SBVR-FTF] issue 9946 -- URIs for SBVR designations X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No Don Baisley wrote: It seems that issue 9946 can be easily solved by specifying how a URI is formed for a designation or fact type form in an SBVR namespace (just the namespaces we define in the SBVR specification, not others). We have already defined the URIs for SBVR's namespaces, so we have a starting point. The rules are simple: 1. Start with a vocabulary namespace's URI. 2. Append a '#' or '/' [WE MUST DECIDE WHICH TO USE - see blow]. 3. Append the expression of a designation or fact type form that is in the namespace, but with all spaces replaced by hyphens and all subscripts removed. Note: for some reason this is not the algorithm used to specify the MOF names of the concept designations and fact type forms. It would be useful if the normative term transformations were consistent. For designations and fact type forms within a role namespace for a concept: I am having a problem parsing that expression. A "role namespace for a concept" is an SBVR way of saying "attribute namespace" [because "business people" wouldn't use a term like 'attribute']. What I really don't understand is how a fact type form can be in a "role namespace", since the definition of "role namespace" says it contains (only) 'designations', and what it really contains is placeholders that are usually concept names being used as role names. 1. Start with a URI for a designation of the concept. 2. Append a period ("."). 3. Do step 3 above. I think 3 should read: 3. Append the expression of the placeholder that is in the namespace, but with all spaces replaced by hyphens. There should be no subscripts in a placeholder that appears in a role namespace for a concept, but if there are any such subscripts, they must be retained, since the subscript is part of the role name. And in that case, step 4 below applies. Optionally, Why optionally? for placeholders of a fact type form used to refer to a role of the fact type: 1. Start with a URI for a designation of the fact type form. 2. Append a period ("."). 3. Append the expression of the placeholder as in step 3 above. 4. If the text appended in step three matches more than one placeholder, append the ordinal position of the placeholder. Examples: http://schema.omg.org/specs/SBVR/1.0/MeaningAndRepresentation/concept Per RFC 2396, the meaning of this URI is defined by RFC 2616, because the URI begins http:. As a consequence, the meaning of this URI is that there is a resource nominally accessible from schema.omg.org that will be returned by providing this URL to that site. That is because this URI does not contain any character that indicates that any part of this URI is not to be interpreted by the resource locator service as part of the resource location. I believe the correct URI should be: http://schema.omg.org/specs/SBVR/1.0#MeaningAndRepresentation/concept or http://schema.omg.org/specs/SBVR/1.0/MeaningAndRepresentation#concept And which of those is correct depends on the granularity of the accessible resource. Is a MeaningAndRepresentation a separate (e.g. XMI) resource? Or is the only accessible resource the whole SBVR/1.0 specification? Per RFC 2396, the sharp sign (#) indicates the end of the URL and the beginning of a specialized data set that identifies the intended resource within the resource accessible by the locator service. It is clear that the SBVR concept "glossary item" is just such a specialized data set. (See below.) ... Adding these simple rules makes SBVR ready to use right out of the box with XML/RDF. Questions to answer: 1. Where should these rules be stated? I think they should be in a normative section. A new chapter 16? A new section in chapter 15? I agree, and that makes this out of scope for the FTF. This proposes to add an entirely new normative concept. We need SBVR v2 for that, or a proposed change to SBVR in some proposal that responds to a related OMG RFP. We could add this as a non-normative Annex -- a recommended practice, and standardize it later. 2. Should we use "#" or "/"? I suspect there is some significance to which we choose. The "#" might be reserved for identifying a part of a document. See above. It is. Certain characters, such as # and ?, terminate the URL portion of a URI. The software that finds the referenced resource or its provider uses only the part of the URI that precedes that character in finding the resource over the Internet. Once the located resource or its provider is identified, the rest of the URI is used by the provider or the interpreter of the located resource (e.g. the browser) to find the actual resource identified by the whole URI. In an HTML resource, the browser will interpret the value following the # as an anchor. In an XML resource, it will interpret the value as an XML id value if it is a simple value, and as an Xpath if it isn't. In a Javascript resource, everything after the # is interpreted as a parameter list. In a PDF resource, Acrobat will interpret it as a bookmark. (It is customary to use # for passive resources, where the client browser is to interpret the rest, and ? for active providers, like .php scripts, where the server provides its own interpretation of the rest.) So, in the above example, if the URL part refers to an XMI document, the characters "concept" should be the value of some xmi.id. If the URL part refers to a PDF document, the characters "concept" should correspond to a PDF bookmark. All RDF resources use # to separate the vocabulary entry from the vocabulary resource (document) URL. In the vocabulary entry, the RDF:id value is the designation. (And RDF:id is an XML ID value, like xmi.id.) There is some wrangle about using RDF:about this way. I'm not the expert on this subject. Neither am I, but I think this stuff is covered, at least partly, in RFC 2396 or RFC 2616 (HTTP). And I have gotten much of the rest from exposure to our local HTML and XML expert (Josh Lubell). -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-FTF] issue 9946 -- URIs for SBVR designations Date: Wed, 7 Feb 2007 17:40:46 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [SBVR-FTF] issue 9946 -- URIs for SBVR designations Thread-Index: AcdLFCNzRZUfH0cKQPShSs7fVB/twQACWwdg From: "Baisley, Donald E" To: Cc: , "Cory Casanave" , "Cummins, Fred A" X-OriginalArrivalTime: 08 Feb 2007 01:40:46.0577 (UTC) FILETIME=[276CEE10:01C74B22] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id l181WVF1023592 Ed, Thanks for responding and answering some of the questions. Ed wrote: > Note: for some reason this is not the algorithm used to specify the > MOF names of the concept designations and fact type forms. It would > be useful if the normative term transformations were consistent. MOF does not require removal of spaces from names, so original expressions can be preserved with their spaces. But XMI disallows spaces in names, so the normative XMI uses hyphens. Don wrote: >> For designations and fact type forms within a role namespace for a >> concept: Ed answered: > I am having a problem parsing that expression.... What I > really don't understand is how a fact type form can be in a "role > namespace", since the definition of "role namespace" says it > contains (only) 'designations'.... Ed is correct. Strike "and fact type forms" from my statement about role namespaces. Only designations occur in a role namespace. These are designations understood in the context of being attributed to an instance of the concept the role namespace is for. About placeholders Ed wrote: > Why optionally? By optionally, I mean that we, the FTF, should decide one way or the other. I can go either way. Ed wrote: > As a consequence, the meaning of this URI is that there is a > resource nominally accessible from schema.omg.org that will be > returned by providing this URL to that site. Ed, does this mean that our base namespace URI http://schema.omg.org/specs/SBVR/1.0/MeaningAndRepresentation (and several others like it) is incorrect? It does doesn't point at a document until something is added such as "-cmof.xml" or ".xsd" or "-sbvr.xml". It was not intended as a URL, but purely a URI. Regards, Don To: sbvr-ftf@omg.org Subject: RE: [SBVR-FTF] issue 9946 -- URIs for SBVR designations X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006 From: Mark H Linehan Date: Wed, 7 Feb 2007 20:57:42 -0500 X-MIMETrack: Serialize by Router on D01ML083/01/M/IBM(Release 7.0.2 IGS702HF4|January 9, 2006) at 02/07/2007 20:57:43, Serialize complete at 02/07/2007 20:57:43 Andy asked this question: Ed, does this mean that our base namespace URI http://schema.omg.org/specs/SBVR/1.0/MeaningAndRepresentation (and several others like it) is incorrect? It does doesn't point at a document until something is added such as "-cmof.xml" or ".xsd" or "-sbvr.xml". It was not intended as a URL, but purely a URI. I believe this is perfectly fine. A URI can be used as identifiers for resources that are not actually retrievable. My memory is that this is explicitly permitted (even encouraged) in the relevant standards. Whether the URI has something like ".xsd" on the end is irrelevant. I think that references to SBVR-defined concepts should use the form http://schema.omg.org/specs/SBVR/1.0/MeaningAndRepresentation#concept -------------------------------- Mark H. Linehan STSM, Model Driven Business Transformation IBM Research phone: (914) 945-1038 or IBM tieline 862-1038 internet: mlinehan@us.ibm.com "Baisley, Donald E" 02/07/2007 08:40 PM To cc , "Cory Casanave" , "Cummins, Fred A" Subject RE: [SBVR-FTF] issue 9946 -- URIs for SBVR designations Ed, Thanks for responding and answering some of the questions. Ed wrote: > Note: for some reason this is not the algorithm used to specify the > MOF names of the concept designations and fact type forms. It would > be useful if the normative term transformations were consistent. MOF does not require removal of spaces from names, so original expressions can be preserved with their spaces. But XMI disallows spaces in names, so the normative XMI uses hyphens. Don wrote: >> For designations and fact type forms within a role namespace for a >> concept: Ed answered: > I am having a problem parsing that expression.... What I > really don't understand is how a fact type form can be in a "role > namespace", since the definition of "role namespace" says it > contains (only) 'designations'.... Ed is correct. Strike "and fact type forms" from my statement about role namespaces. Only designations occur in a role namespace. These are designations understood in the context of being attributed to an instance of the concept the role namespace is for. About placeholders Ed wrote: > Why optionally? By optionally, I mean that we, the FTF, should decide one way or the other. I can go either way. Ed wrote: > As a consequence, the meaning of this URI is that there is a > resource nominally accessible from schema.omg.org that will be > returned by providing this URL to that site. Ed, does this mean that our base namespace URI http://schema.omg.org/specs/SBVR/1.0/MeaningAndRepresentation (and several others like it) is incorrect? It does doesn't point at a document until something is added such as "-cmof.xml" or ".xsd" or "-sbvr.xml". It was not intended as a URL, but purely a URI. Regards, Don Date: Thu, 08 Feb 2007 11:32:44 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: sbvr-ftf@omg.org Cc: Cory Casanave , "Cummins, Fred A" Subject: Re: [SBVR-FTF] issue 9946 -- URIs for SBVR designations X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: edbark@nist.gov X-Spam-Status: No X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at omg.org Baisley, Donald E wrote: MOF does not require removal of spaces from names, so original expressions can be preserved with their spaces. But XMI disallows spaces in names, so the normative XMI uses hyphens. I know. What I don't understand is why we have two different transforms from the non-normative structured English representation to the normative forms. Most implementors would expect the MOF to XMI transform to be 1-to-1. Ed wrote: As a consequence, the meaning of this URI is that there is a resource nominally accessible from schema.omg.org that will be returned by providing this URL to that site. Ed, does this mean that our base namespace URI http://schema.omg.org/specs/SBVR/1.0/MeaningAndRepresentation (and several others like it) is incorrect? It does doesn't point at a document until something is added such as "-cmof.xml" or ".xsd" or "-sbvr.xml". It was not intended as a URL, but purely a URI. This is exactly the kind of confusion that results from the common usage of URLs as URIs. And it is one of 3 reasons why I disagree with Tim Burners-Lee that HTTP URIs should be the norm. The problem with a URI that looks like a URL is that every software tool that encounters it has a right to treat it as a URL -- if it is a syntactically valid URL, it is a URL. So one should not create a URI that is a URL that is guaranteed to get an Error 404. (That this may occur over time, outside of your control, is reason 2. Reason 3 is that not all valid URLs for a resource are the specified URI for it: what it is called and where you can find a copy of it are importantly different concerns.) There is a set of WWW conventions that determine the defaults employed in "expanding" a URL. If "MeaningAndRepresentation" is a folder/directory within http://schema.omg.org/specs/SBVR/1.0 then the expanded reference is to: http://schema.omg.org/specs/SBVR/1.0/MeaningAndRepresentation/index.htm If "MeaningAndRepresentation" is not a folder, the expanded reference is to: http://schema.omg.org/specs/SBVR/1.0/MeaningAndRepresentation.htm[l] or http://schema.omg.org/specs/SBVR/1.0/MeaningAndRepresentation.xml Finally, it is possible that the HTTP server at schema.omg.org is not just a file locator, and in that case, it defines the interpretation of the rest. The OMG service is plain vanilla, so if .xml is not the intent, MeaningAndRepresentation should have some suffix that completes the filename, like -cmof.xmi or .xsd. The URL should be the "access path" to the resource. I assume that the .xmi file should be the formal reference for the vocabulary. -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."