Welcome to the SBVR Editor Project

The goal of the Semantics of Business Vocabulary and Rules (SBVR) Editor Project is to create an environment that facilitates the development of formal vocabularies using the OMG November 2013 version 1.2 of the Semantics of Business Vocabulary and Rules (SBVR) Specification found at: http://www.omg.org/spec/SBVR/1.2

• Develop Business Vocabularies from existing governing documents (i.e., Code of Federal Regulations, CFR)
• Load document into Hadoop
• Start with natural language vocabulary
• Collaborative Marking and Annotating with Semantics of SBVR constructs to develop Business Specific Vocabulary from the document
• Collaborated with RTI

Based on the Governance, Risk and Compliance Technology Centre (GTCTC) work On The Road to Regulatory Ontologies

• Create a Collaborative environment for creating and editing Business Vocabulary and Business Rules(SBVR)
• Leverage existing SBVR Editor in the future
• Use Big Data concepts to process and manage voluminous regulations

• Based on COTS products
• Standards Based
• Multi-User collaboration in Real-Time
• Use Big-Data to store data
• Integrate with GRCTC SBVR Editor in future
• Use Operational Transformation (OT) to synchronize changes made by multiple authors

• RTI DDS Connext
  • Routing Service
• HADOOP File System (HDFS)
• NodeJS
  • RTI DDS Connector
• TinyMCE
• Node Webkit (NWK)
• WebHDFS
• PostgreSQL
• HTML
• XML
• CSS
• JavaScript
• Angular JS
• Natural Language Processor
• Linux (Unbuntu)
• MacOSX
• Windows

The following use cases were developed using the OT Visualization site which provides an excellent interactive tool of the flow of data between two OT clients and a server. In this use case, there are three actors:

• Alice
• Bob
• OT Server

Alice and Bob are actively editing the same document, Lorem ipsum. The As alice and Bob edit the document a series of operations for those edits is sent to the OT Server. The OT Server mediates the edits and sends edits back to Alice and Bob.

The initial demonstration looks like this:

The final demonstration looks like this:

The following two files help provided a step by step use-case.

• PDF Version of the Use-Case
• Spreadsheet version of the Use-Case

The following diagram captures the normative “as-is” architecture for the OT server. Initially, there are three main actors:

• Alice
• Bob
• OT Server

All three have the same copy of the Lorem ipsum document. Each of the end-users (i.e., Alice and Bob) indicate that they are synchronized with the OT Server. As edits are made by Alice or Bob, the operations are placed into an operation buffer. The state is changed from Synchronized to Waiting. When the server is ready, it accepts one of the operations that are awaiting processing from either of the editors (i.e., Alice or Bob). The edit operations are applied to the Server's version of Lorem ipsum docment and a virtual cursor of where changes have been made is kept on the server. The server then prepares an operation to be sent to all the editors.

Each of the editors can collect the outstanding edits from the server and apply the edits to their own copy of Lorem ipsum document if necessary. If the operation is its own outstanding operation, then the operation is ignored (its already applied to the local document), the operation stored in the local Await buffer is removed and the next queued operation in the Ops buffer becomes the new Await Buffer value awaiting the OT Server's retrieval.

If the operation taken fro mthe queue is not its own operation (i.e., an operation from Alice received by Bob), then the operation is applied to its own copy of Loren ipsum document.

When all the operations have been drained from each of the editor's operation buffer and there are no more operations stored in the Editor's quues, then everything returns to the initial state as depicted in the diagram.

The following diagram captures the normative “to-be” architecture using multiple OT servers (referred to as engines) connected together using DDS. Each editor (Alice and Bob) have their copy of the OT engine that is listening and publishing on DDS topics. The DDS QoS parameters are set so that one of the OT engines is the “master” and the others are redundant backups that only get used during a failover situation where one of the engines is down or the connection to it fails.

The QoS policies are defined in the OMG DDS Specification or can be found online at: RTI QoS Policies

1. Semantics of Business Vocabulary and Rules (SBVR), Version 1.2, 2013, Object Management Group, http://www.omg.org/spec/SBVR/1.2
2. On the Road to Regulatory Ontologies
3. Mobile Ad hoc Networking (MANET): Routing Protocol Performance Issues and Evaluation Consideration, January 1999, The Internet Society, RFC 2501, https://tools.ietf.org/html/rfc2501

| W3C HTML and CSS |

The software developed for this project will fall under the MIT License Copyright. For reference the License follows:

The MIT License (MIT)

Copyright (c) 2015 Jackrabbit Consulting, Inc

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.

Instructions for Download