Introducing TopBraid Life Sciences Insight—at Bio-IT World 2013

We're looking forward very much to showing TopBraid Life Sciences Insight (TopBraid LSI) at the Bio-IT World conference and expo next week in Boston.

Through our research, we've found efforts in drug discovery, clinical trial research, and other data-intensive life sciences tasks are often hampered by the need for more efficient federated queries across silos, bad alignment of related data, and dependence on expensive, inflexible tools.

Working with experts in the field, we've developed TopBraid LSI as a Logical or Virtual Data Warehouse: coordinated views on multiple data sources that let you query and use these data sources without actually loading them into a single data warehouse. A web-based interface lets users identify alignments between different data sources without requiring them to know the standards used to store and leverage these alignments, and then, using an approach similar to Map-Reduce, queries can be efficiently distributed across the data sources to return federated answer sets. You can learn more about how TopBraid LSI works and how it can help life sciences professionals from our new white paper (PDF) on it.

TopBraid LSI has also been selected as a finalist for Bio-IT's Best of Show award in the Informatics Tools & Data Category, so we're also looking forward to showing it to the judges. And, we're taking part in the conference's New Product Showcase, which has a very interesting mix of cutting edge research and IT tools for the life sciences field. If you'll be at Bio-IT World, stop by and see us at Booth 323, where you can find out more about TopBraid Life Sciences Insight.

Living in the XML and OWL World - Comprehensive Transformations of XML Schemas and XML data to RDF/OWL

Many enterprise information models are expressed using XML Schemas. Data between applications is commonly exchanged in XML, compliant with those schemas. Connecting XML data from different systems in a coherent aggregated way is a challenge that confronts many organizations. Capabilities of RDF/OWL to describe semantics of different data models and aggregate disparate data are a natural fit for addressing these challenges.

For a number of years now, TopBraid Composer included the ability to convert XSDs and associated XML files to RDF/OWL. However, for some XML Schemas our converter did not work as well as customers needed. For the upcoming TopBraid Composer 3.6.0 release, it was significantly improved to have a more comprehensive coverage of XSD constructs and more meaningful conversion to OWL. In parallel, we improved our XML data conversion to RDF so that transformations automatically happen based on the generated OWL models. And we have improved performance of the transformations.

An overview of the approach is illustrated in the following figure:

Since, the conversion occurs automatically, users do not have to worry about writing any rules for commonly needed mappings. However, those users that need to make further transformations can use SPARQL Rules and SPARQLMotion to customize their generated OWL ontology or further transform RDF triples representing the XML data.

The content of this blog is organized as follows:

• XML Schemas converted as part of our tests
• Some challenges in converting XML Schemas to OWL
• Illustrative example of transformation rules
• Another example of transformation rules
• Complete table of supported transformations
• A SPARQL Metric Query
• Concluding remarks

XML Schemas converted as part of our tests

We tested the importer on a broad range of complicated and large-scale industry standard XSD files, and converted many XML instances with impressive results. The XSDs we have tested with the new importer include:

1. Banking
   • FpML, the Financial products Markup Language
   • ISO 20022, a standard for Universal financial industry message scheme


2. Energy and Utilities
   • MultiSpeak, de-facto standard for defining data needed to be exchanged between software applications in order to support the business processes commonly applied at utilities


3. Government
   • DoDAF, the Department of Defense Architecture Framework
   • NIEM, the U.S. National Information Exchange Model


4. Oil and Gas
   • ISO 15926, a standard for integration of life-cycle data for process plants including oil and gas production facilities
   • WITSML, Wellsite Information Transfer Standard Markup Language


5. Healthcare
   • HL7


6. Electronics
   • IP-XACT, the XML Schema for meta-data documenting Intellectual Property (IP) used in the development, implementation and verification of electronic systems


7. Other
   • ATML, the Auto-Test Markup Language
   
   

Some of the converted schemas will be published at LinkedModels.org. To get an early access to converted models or for any other questions, contact us at TopQuadrant.

The examples we use in this blog are mainly from the Financial products Markup Language (FpML). All FpML 5.2 XSD and XML instance files were tested. An example is transparency standard under FpML, for which the transparency.ttl ontology was generated from 23 XSD files.

Some challenges in converting XML Schemas to OWL

Some of the challenges in converting XSD to OWL that were addressed are:

1. Transforming of anonymous types
2. Converting complex types with simple contents


3. Resolving conflicting nested element and attribute names during OWL property generation


4. When and how to distinquish global elements from complex types with similar names during OWL class generation


5. Generating enumerations


6. Handling substitution groups both at the XSD and XML levels


7. Handling the overriding of an XSD type with xsi:type in XML

The example that follows shows the approaches that we have used for the transformation.

Illustrative example of transformation rules

The basic transform for a Complex Type in XSD follows these rules:

1. An OWL class is generated for a complex type.


2. The URI of the class is generated in three different ways. If the complex type is global and named, then the name attribute is used. If the complex type is local and named, then the name attribute of the owner element is used. If the complex type is anonymous, then the names of its owner element and its parent element are used.


3. The xsd:annotation and attribute annotations describing the complex type get generated as dc:description, rdfs:comment and/or skos:definition OWL annotations.


4. Nested or reference children elements of the complex type become OWL allValuesFrom restrictions on the class. If the element has a simple type, then a restriction with an OWL datatype property and an XSD datatype range or a user-defined RDFS datatype range is generated. If the element has a complex type, then a restriction with an OWL object property and an OWL class range is generated. The minOccurs and maxOccurs values become OWL cardinality restrictions.


5. Element group and attribute group references are generated as super classes.


6. Attributes become restrictions with an OWL datatype property and an XSD datatype range or a user-defined RDFS datatype range.

An example of a Complex Type, Trade, in fpml-doc-5-2.xsd of transparency standard is displayed below:

<xsd:complexType name="Trade">
  <xsd:annotation>
    <xsd:documentation xml:lang="en">
    A type defining an FpML trade.</xsd:documentation>
  </xsd:annotation>
  <xsd:sequence>
    <xsd:element name="tradeHeader" type="TradeHeader">
      <xsd:annotation>
        <xsd:documentation xml:lang="en">
         The information on the trade which is not 
         product specific, e.g. trade date.
         </xsd:documentation>
      </xsd:annotation>
    </xsd:element>
    <xsd:group ref="TradeEconomics.model">
      <xsd:annotation>
        <xsd:documentation xml:lang="en">
        The economics of the trade. In the case of an 
        OTC trade, this is the OTC derivative product.
        In the case of a trade of a security,
        it is the instrument trade economoics.
        </xsd:documentation>
      </xsd:annotation>
    </xsd:group>
  </xsd:sequence>
  <xsd:attribute name="id" type="xsd:ID" />
</xsd:complexType>

The following is the graph of the OWL class generated for Trade complex type, which shows the OWL class, restrictions, annotations and superclass.

The following class diagram shows a more sophisticated view of Trade and its related classes downstream in the generated ontology (click on the diagram to open a window with a bigger image).

The diagram highlights these advanced features in generation:

1. A superclass relation exists between Trade, generated from an XSD complex type and TradeEconomics.model, generated from an XSD element group.


2. In the XSD, Swap element has the substitutionGroup Product element. Thus, A_Global-Swap becomes a subclass of A_Global-Product. A_Global- prefix is used to distinguish the element-derived classes from similarly named complex-type-derived classes.


3. dtype:value restrictions are generated to hold the simple contents occuring in complex types. The complex content part of the type become other restrictions.


4. The generated object properties have a Ref suffix to distinguish them from datatype properties with same names. Both types of properties can be used in restrictions on different classes as they may be generated from nested or reference children elements under different complex types.

The instance file, "msg_ex001_new_trade.xml" was imported into the transparency ontology. Here is a peek into that XML file:

...
<trade>
<tradeHeader>
  <partyTradeIdentifier>
    <tradeId tradeIdScheme=
        "http://fpml.org/universal_swap_id">123</tradeId>
    <tradeId tradeIdScheme=]
        "http://fpml.org/submitter_trade_id">456</tradeId>
  </partyTradeIdentifier>
  <tradeInformation>
    ...
    <cleared>true</cleared>
    <nonStandardTerms>false</nonStandardTerms>
    <offMarketPrice>false</offMarketPrice>
    <largeSizeTrade>false</largeSizeTrade>
    ...
  </tradeInformation>
  <tradeDate>2011-02-04</tradeDate>
</tradeHeader>
<swap>
  <productType>InterestRateSwap</productType>
  <assetClass>InterestRates</assetClass>
  <swapStream>
   ...
  </swapStream>
  <swapStream>
    ...
  </swapStream>
</swap>
</trade>
...

The above XML constructs were mapped into the following RDF graph, where you can see how the instances, their relationships and their types are generated with respect to the Trade class diagram (click on the graph to open up a window for a more detailed view).

Another example of transformation rules

The basic transform for an Enumeration in XSD follows these rules:

1. An OWL class is generated from an XSD simple type having XSD enumeration facets. The localname of the class has Enum suffix to distinguish it from classes generated with similar names.


2. This class becomes a subclass of EnumeratedValue in the same namespace as the OWL class, which itself becomes a subclass of dtype:EnumeratedValue.


3. Each XSD enumeration facet becomes an instance of the generated class. dtype:value holds the enumeration value. dtype:order is the order in which the enumeration facet occurs.


4. An Enumeration class in the same namespace as the OWL class is also generated. This class becomes subclass of dtype:Enumeration. An instance of this class is generated as a container to refer to all the instances generated from the current simple type.

Enumerated value instance URIs are generated using a concatenation of the abbreviation of the class localname's upper case letters and the dtype:value literal.

The following figure shows a graph for PremiumQuoteBasisEnum class and the OWL constructs generated from the related XSD enumeration facets (click on the diagram to open a window with a bigger image):

Complete table of supported transformations

For the reader interested in more details a full overview of the mapping transformations is given in the following table:

Table: Conversion from XSD Constructs to OWL Constructs

#	XSD/XML Constructs	OWL Constructs
1	xsd:simpleType	owl:Datatype
2	xsd:simpleType with xsd:enumeration	Becomes an owl:Class as a subclass of EnumeratedValue. Instances are created for every enumerated value. An instance of Enumeration, referring to all the instances, is created as well as the owl:oneOf union over the instances.
3	xsd:complexType over xsd:complexContent	owl:Class
4	xsd:complexType over xsd:simpleContent	owl:Class
5	xsd:element (global) with complex type	owl:Class and subclass of the class generated from the referenced complex type
6	xsd:element (global) with simple type	owl:Datatype
7	xsd:element (local to a type)	owl:DatatypeProperty or owl:ObjectProperty depending on the element type. OWL Restrictions are built for the occurrence.
8	xsd:group	owl:Class and subclass of A_AbstractElementGroup
9	xsd:attributeGroup	owl:Class and subclass of A_AbstractAttributeGroup
10	xsd:minOccurs and xsd:maxOccurs	Cardinality specified in minimum cardinality, maximum cardinality and universal (allValuesFrom) OWL restrictions.
11	Anonymous Complex Type	As for Complex Type except a URI is constructed from the parent element and the nested element reference. Also, the class is defined as a subclass of A_Anon.
12	Anonymous Simple Type	As for Simple Type except a URI is constructed from the parent element and the nested element reference.
13	xsd:default on an attribute	Uses dtype:defaultValue to attach a value to the OWL restriction representing the associated property.
14	Substitution Groups	Subclass statements are generated for the members. Instance files resolve their types by consulting the OWL model at import-time.
15	Annotation attributes on elements	OWL Annotation properties are created and placed directly on the relevant class.
16	Annotations using xsd:annotation	Become, based on user selection, dc:description, rdfs:comment and/or skos:definition OWL annotations.
17	xsi:type on an XML element	Overrides the schema type with the specified type.

A SPARQL Metric Query

As a quick check on the generated OWL models, the following is a useful SPARQL query that counts the number of properties on each OWL class.

 SELECT ?class (COUNT(DISTINCT ?p) AS ?properties)
 WHERE {
     ?class a owl:Class .
     FILTER( afn:namespace( ?class ) = 
        "http://www.fpml.org/FpML-5/transparency#") .
     OPTIONAL {
         ?class rdfs:subClassOf ?r .
         ?r a owl:Restriction .
         ?r owl:onProperty ?p .
     }
 }
 GROUP BY ?class
 ORDER BY DESC( ?properties )

The classes for the transparency ontology have the distribution of properties shown in the following figure (click on the diagram to open a window with a bigger image). For example, TradeInformation has 12 properties:

Concluding remarks

The new capability is easy to use. As before, a convenient import wizard will guide the user. The dialog has a number of new options. XML conversion will happen automatically when users open XML files in TBC or use XML import modules in SPARQLMotion. As long as an XML file is valid against an XSD that it is based on, the XML will be transformed in accordance to the schema. Parts of the XML files that do not validate against a schema will continue to be converted using the default Semantic XML structure. There is also a new option to specify which OWL file to use as a schema when mapping a specific XML file to triples. This feature is also available for spreadsheets and will be covered in a separate blog.

We believe that the importance of this work is not only in its value to harvest XML Schemas. Ability to use the automatic creation of triples from XML instance files directly in applications is proving to be key to a number of customers. For example, TopQuadrant is currently using this approach in a project for the North Sea Oil and Gas industry.

The functionality we have described will be released in TopBraid Composer 3.6.0. This release entered internal beta this week. Please contact us if you want a try these capabilities before general availability, which is currently planned for November.

How to: Publish your Linked Data with TopBraid Live SPARQL Endpoints

SPARQL endpoints are an increasingly popular way to expose linked data. Invoking SPARQL Endpoints from TopBraid Composer's SPARQL view was the subject of a previous TQ blog on SPARQL Endpoints.In this entry we will discuss how TopBraid Live can be used to implement a SPARQL Endpoint using TopBraid Live. SPARQL Endpoints are Web services that conform to the SPARQL protocol. SPARQL queries are passed to a URL where a SPARQL service processes the query and returns results in a defined XML format. A number of SPARQL Endpoints exist for Web data (see the W3C list of current SPARQL Endpoints) and have become important sources for linked data.

A SPARQL Endpoint service implementation is packaged with TopBraid Live and is available out-of-the box for both TopBraid Live Personal Server (TopBraid Composer-ME running on localhost:8083), and TopBraid Live Enterprise Server (for more information, see TBL Home page). Creating a SPARQL Endpoint for your data is therefore an easy three-step process:

1. Load the model you wish to query into your TBL/TBC-ME workspace.
2. Use the GRAPH SPARQL keyword to access any named graph in the workspace.
3. Send a SPARQL query in the query string of a url that access the TBL SPARQL endpoint.

For example, if you have TBC-ME running, the TopBraid Live Personal Server is automatically available. Open a browser window and enter the following URL:

http://localhost:8083/tbl/sparql?query=SELECT DISTINCT ?p WHERE {GRAPH <http://topbraid.org/countries> {?s ?p ?o} }

This URL passes a query string that is applied to the specified graph, the countries.owl example included in the TopBraid library. The query is passed to TopBraid Live and executed using TBL's SPARQL engine. The results are converted to the SPARQL Endpoint format and returned via HTTP. The above URL specifies the TBL Personal Server (via TBC-ME's localhost:8083) as the endpoint. If you have TopBraid Live Enterprise Edition running on a server, just substitute the server address for your Enterprise server.

To further explore the ease of creating SPARQL Endpoints with TopBraid Live,
click here to access a page that defines an HTML form that submits a query to the TBL Personal Server SPARQL Endpoint. Copy and paste the following queries that use some of the example models included in the TopBraid library.

This query finds all countries and their abbreviations from the countries model in TopBraid/Examples:

# Get all countries and abbreviations from countries model
PREFIX countries: <http://topbraid.org/countries#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?name ?abbrev
WHERE
{ GRAPH <http://topbraid.org/countries>
  {  ?country a countries:Country .
     ?country rdfs:label ?name .
     ?country countries:abbreviation ?abbrev .
  }
}

This query finds all children of Joseph Kennedy from the kennedys model in TopBraid/Examples:

# Find Joe Kennedy's children in kennedys model
PREFIX k: <http://topbraid.org/examples/kennedys#>
SELECT ?cname
WHERE
{ GRAPH <http://topbraid.org/examples/kennedys>
  {  k:JosephKennedy k:child ?child .
     ?child k:name ?cname .
  }
}

Again, substitute your Live server address for "localhost:8083" in the action tag of the HTML file to apply queries to your Live server.

Using SPIN functions in SPARQL Endpoints

TopBraid SPARQLMotion Functions and user-defined SPIN functions registered in a Live workspace can also be used in SPARQL Endpoint queries. For example, the following query uses the TopBraid SPARQLMotion Function smf:if() to compute the age of all persons at death or their current age using the example kennedys model. Instead of returning variable bindings via SELECT, this query returns a RDF graph via CONSTRUCT. Since the graph is in RDF/XML format, the file returned by the endpoint can easily be imported into existing RDF/OWL models.

# infer age at death or age as of 2010
PREFIX k: <http://topbraid.org/examples/kennedys#>
PREFIX smf: <http://topbraid.org/sparqlmotionfunctions#>
CONSTRUCT {?person k:age ?age}
WHERE
{ GRAPH <http://topbraid.org/examples/kennedys>
  {  ?person k:birthYear ?byear .
     OPTIONAL {?person k:deathYear ?dyear}
     LET (?age := smf:if(bound(?dyear), ?dyear-?byear, 2010-?byear))
  }
}

Note that the age computation is hardcoded for 2010. A SPARQL query that returns the current year can be defined with a few statements. An example is shown in the kennedysSPIN model in the TopBraid Library, see TopBraid/Examples/kennedysSPIN.rdf in the Composer workspace. If you look at the SPIN function getCurrentYear (defined as a subclass of spin:Functions, which is a subclass of spin:Modules), it finds the current year as the first four characters returned in xsd:dateTime format returned from the function afn:now().

Instead of copying this code into the query, let's register this as a SPIN function so it can be called by any model in the workspace, including SPARQL Endpoints. Do the following:

1. Re-name the file kennedysSPIN.rdf to kennedysSPIN.spin.rdf. Adding the .spin extension registers all of the SPIN functions in this model with the workspace, allowing SPIN functions to be called without importing or opening the files.


2. From the TBC-ME menu, select Scripts > Refresh/Display SPARQLMotion functions... This will register the functions for the current session. When Live or Composer is started, the system will scan the files in the workspace for .spin files and register all functions. The extra step is needed here only if the file name was changed without stopping the Composer session. A Deploy (Export... Deploy in Composer) to a Live server will automatically refresh scripts.

Now try the same query with the following changes:

# infer age at death or age from current year
PREFIX k: <http://topbraid.org/examples/kennedys#>
PREFIX smf: <http://topbraid.org/sparqlmotionfunctions#>
PREFIX kspin: <http://topbraid.org/examples/kennedysSPIN#>
CONSTRUCT {?person k:age ?age}
WHERE
{ GRAPH <http://topbraid.org/examples/kennedys>
  {  ?person k:birthYear ?byear .
     OPTIONAL {?person k:deathYear ?dyear}
     LET (?age := smf:if(bound(?dyear), ?dyear-?byear, kspin:getCurrentYear()-?byear))
  }
}

Note the use of the user-defined SPIN function getCurrentYear(). This feature can be used to call any SPIN function including those that are defined by SPARQLMotion scripts. This raises the potential of using SPARQL endpoints for a wide range of processing capabilities, including importing models from outside of a Live workspace, processing triples before querying, applying queries to inference results, integrating models from different file types, and other kinds of SPARQL and RDFS/OWL processing. For example, a SPARQL Endpoint request could call a SPARQLMotion script that runs standard RDFS or OWL inferences before submitting the query, thus returning results from both inferred and asserted triples.

Advanced SPARQL Protocol: Federated SPARQL Queries

The SPARQL SERVICE keyword sends a query to remote service endpoint. Since TopBraid Live supports the SERVICE keyword, SPARQL endpoint queries to TopBraid Live can call other SPARQL Endpoints! Try the following query in the example query form.

PREFIX k: <http://topbraid.org/examples/kennedys#>
PREFIX smf: <http://topbraid.org/sparqlmotionfunctions#>
CONSTRUCT {?child k:birthDate ?birthdate}
WHERE
{ GRAPH <http://topbraid.org/examples/kennedys>
  {  k:RoseFitzgerald k:child ?child .
     ?child k:firstName ?fname .
     ?child k:lastName ?lname .
     ?child k:gender k:female .
     ?child k:spouse ?spouse .
     ?spouse k:lastName ?slname .
     LET (?dbpRsc := smf:buildURI("http://dbpedia.org/resource/{?fname}_{?lname}_{?slname}"))

     SERVICE <http://dbpedia.org/sparql>
     {  ?dbpRsc <http://dbpedia.org/ontology/Person/birthDate> ?birthdate .
     } .
  }
}

This query is applied to the kennedys example model to query for female children of Rose Fitzgerald and sends a query to the DBPedia SPARQL Endpoint to find their birth dates. The buildURI() function will generate a URI that is known in DBPedia, such as <http://dbpedia.org/resource/Eunice_Kennedy_Shriver>. The results from DBPedia bind the birth date to ?birthdate, which is returned in the TopBraid Live SPARQL endpoint response. As long as DBPedia is up and running, the result federates data from two SPARQL Endpoints, realizing the potential of linked data sources.

Conclusions

SPARQL endpoints are a complement to TopBraid Live's ability to create
RESTful Web services. While Web services are more flexible, allowing data to be returned in any text-based format, SPARQL endpoints can be used in a variety of applications expecting SPARQL result sets in an XML format. TopBraid Live significantly improves on existing SPARQL Endpoints with capabilities to federate queries and design functions and scripts that process data for external usage.

These examples demonstrate the power of TopBraid Live as an RDF back-end. Using a straightforward HTML form, one can access to full power of TopBraid Live and advanced SPARQL queries. These examples can be directly applied against the Personal Server version of TopBraid Live, packaged in TopBraid Composer-Maestro Edition (TBC-ME), which is freely available for a 30-day trial. TopBraid Live Enterprise Edition is deployed as a Tomcat servlet for Web-enabled access. For more information, see the TopBraid Live web page.

What's new in TopBraid Suite 3.2

3.2 is a minor release of TopBraid Suite, but it adds more than just background improvements such as faster performance and improvements to both memory management and 64-bit support. Each of TopBraid Suite's components includes new features that will ease the development of Semantic Web applications and offer a wider range of features to include in those applications. The following lists some highlights:

TopBraid Composer

TopBraid Composer makes it easy to develop and integrate Semantic Web data models, SPARQL Inferencing Notation (SPIN) inferencing rules, and SPARQLMotion data processing pipelines into a standards-compliant application. New TopBraid Composer features in release 3.2 include:

• OWL 2 support, with features such as property chain axioms, user-defined datatypes, and OWL 2 class axioms. Read more at VP of Product Development Holger Knublach's blog posting OWL 2 Support in TopBraid Composer.
  

• New SPIN features such as spin:fix to implement suggestions for constraint violation fixes, easier control over rule execution, and the ability to distribute rules across devices. An important new improvement is support for user-defined magic properties in SPIN, allowing users to define rules with backward chaining. You can define a magic property, or property function, using SPARQL and then use it as the predicate in another SPARQL expression to compute new values based on the data being queried. Holger's Magic Properties with SPIN blog posting has some good examples.
  

• A new SPARQL debugger that lets you set break points, display intermediate variable bindings, collect statistics, and see the internal algebra of SPARQL queries as they run. Holger's recent blog posting on this topic walks the reader through the underlying logic, the use of the debugger view, and the use of profiling.
  

• More options for the display of long lists in the Properties and Classes view, making it easier to find what you're looking for quickly.
  

• Easier packaging of a project developed with TopBraid Composer for deployment to a server running TopBraid Live for use by multiple users.
  

• Support for the latest major release of the Eclipse platform, release 3.5.
  

TopBraid Ensemble

With TopBraid Ensemble, you can create web-based user interfaces for the applications you develop using Composer. End users, without using Composer, can interact with your application's data using a wide choice of graphical interface components that you customize for them. New Ensemble features in 3.2 include:

• Support for pop-up windows, so that you can build wizards that lead your application's users through a series of steps.
  

• Support for multi-page applications, letting you spread the interface for more complex applications across a series of pages, as with a tabbed interface.
  

• A new, customizable button component that lets your application's users trigger events with a mouse click.
  

• A new SPARQL Relay component, which can listen for events and trigger SPARQLMotion scripts in the background of your application.
  

TopBraid Live

TopBraid Live lets you deploy your application for use by hundreds of users with the screens that you designed with Ensemble, with screens that were custom-built using Adobe Flex, or with an automated web services interface. New features in 3.2 include:

• User and group management, including optional integration with LDAP roles.
  

• Access Control Lists for projects, folders and graphs.
  

• The ability to host an application as a SPARQL end point.
  

• Significant performance improvements when used with Oracle.
  

For a complete list of new features in TopBraid Ensemble release 3.2, see the 3.2 Release Notes.