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 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 it the onky exact match for that internal record ID

  • 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

Migration Guides