What's New In Senzing v4 Beta

New System Requirements

New Capabilities

Here are just some of the great new capabilities in the Senzing v4 Beta release:

Revamped Python and Java SDK for greater easy of use as well as the addition of .NET. code-snippets are provided in the Senzing GitHub for all languages
Support for semantic embedding and cosign similarity
CJK (Chinese, Japanese, Korean writing systems) cross-script matching for names and addresses

118, Fengcheng 10th Road, Xi'an, Weiyang District, Shaanxi 710000
vs
710000陕西未央区西安凤城十路118

1-1 Chuo-ku Osaka Osaka 540-0002
vs
〒540-0002大阪府大阪市中央区1-1

Ping An Insurance
vs
平安保険

Alibaba Group
vs
アリババグループ

Regional address models for superior parsing
Enhanced PlaceKey support that will also leverage the address component for matching as well as the name and address components for key creation . BUSINESS usage type allowed. (Note that this was done in RustC just to prove plugins can be written in Rust)

222-224@5x4-4b6-mff
vs
14xyqtz6ty@5x4-4b6-mff

whySearch function to give whyEntities explainability to search requests. In case you ever wondered why Senzing did or did not match a particular entity when searching.
MATCH_KEY_DETAILS section of response documents has three sections to describe MATCH_KEY confirmations, denials, and disclosed relationships. This is a JSON structured representation of the MATCH_KEY which also provides the details on specifically what supported the token in the MATCH_KEY

      "MATCH_KEY_DETAILS": {
        "CONFIRMATIONS": [
          {
            "TOKEN": "ADDRESS",
            "FTYPE_CODE": "ADDRESS",
            "SCORE_BEHAVIOR": "FF",
            "SOURCE": "ADDRESS",
            "SCORE": 100,
            "ADDITIONAL_SCORES": {
              "FULL_SCORE": 100
            },
            "INBOUND_FEAT_ID": 2,
            "INBOUND_FEAT_DESC": "111 1st St, Las Vegas, NV 89111",
            "CANDIDATE_FEAT_ID": 2,
            "CANDIDATE_FEAT_DESC": "111 1st St, Las Vegas, NV 89111",
            "SCORE_BUCKET": "SAME"
          }
        ]
      }

SZ_ENTITY_INCLUDE_RECORD_FEATURE_DETAILS flag enables section mapping attributes to features for get_record, get_entity, and search_by_attributes response documents. This tracks specifically which JSON key/values created the feature

      "FEATURES": {
          "NAME": [
              {
                  "LIB_FEAT_ID": 1,
                  "USAGE_TYPE": "PRIMARY",
                  "FEAT_DESC": "George Washington",
                  "ATTRIBUTES": {
                      "PRIMARY_NAME_LAST": "Washington",
                      "PRIMARY_NAME_FIRST": "George"
                  }
              }
          ]
      }

preprocess_record() function that allows preprocessing of a record, with output similar to get_record(). Great for evaluating JSON record mapping or generating statistics prior to loading data
Newly created configurations will leverage Metaphone 3 for key generation
Optimized tables and indexes to reduce size and improve query plans
macOS supports Apple Silicon instead of Intel
Overused FTYPE logic now uses most common feature values for the entities instead of completely disabling the FTYPE
Reduced entity ID movement. If a record is updated, the existing ID will be re-used if possible
RES_ENT table has an ENT_STATE column flagging entities that were shown to need reevaluation, but not yet reevaluated. This is a bit flag that may get used for other things in the future
sz_command DB performance check command, check_datastore_performance, now checks all nodes if using a multi-node repository backend
Factory/Environment object to make the init calls more intuitive

What's New In Senzing v4 Beta

New System Requirements

New Capabilities

Migration Guides