Omni Linked Entity Recognition (Omni LER) Explainer

Omni Linked Entity Recognition (LER) is one method Schema App uses for their Entity Linking service. This document describes the Omni LER feature offered by Schema App, what it is, what it does, and how Schema App implements it. It provides content considerations, and notes current limitations and future enhancements for this feature.

TABLE OF CONTENTS

• What is Omni Linked Entity Recognition?
• What does Omni LER do?
• How does Omni LER work?
• How is Omni LER implemented?
• What types can Omni LER identify?
• How do I know Omni LER is working?
• General Content Considerations
  • 1. Use standardized names
  • 2. Capitalization Is Important!
  • 3. Consider surrounding content
• Omni LER Limitations
  • 1. Limitations of API
  • 2. Highlighter Subtemplates

What is Omni Linked Entity Recognition?

Linked Entity Recognition (LER) is the automated process of identifying named entities in text and then linking them to external identifiers from authoritative knowledge bases (like Wikipedia and the Google Knowledge Graph). Schema App's Omni LER feature automatically embeds identified entities within your Schema Markup.

What does Omni LER do?

Once embedded in your markup, these entities provide additional semantic value to your metadata. They help Google (and other web crawlers) better understand your content by pulling in known entities. This reduces ambiguity in the interpretation of your content and supports more accurate matching to user queries.

How does Omni LER work?

Omni LER tags can be applied to Schema App’s Highlighter templates. Once applied, Omni LER runs text through an API to identify linked entities. If URIs for those entities are found, the API returns the following information:

• Type (e.g. Organization)
• name (e.g. Apple)
• Wikipedia URI (e.g. https://en.wikipedia.org/wiki/Apple_Inc.)
• Wikidata URI (e.g. https://www.wikidata.org/entity/Q312)
• Google Knowledge Graph URI (e.g. kg:/m/0k8z)

URIs from external sources are added to the entity using the sameAs property. As a result, the markup will look something like this:

How is Omni LER implemented?

First, you’ll consult with your Customer Success Manager (CSM) to find a page set with content that contains entities: people, places, things, or concepts. Then, you and your CSM will decide which schema.org property to use for mapping the returned entities. 

If you expect to receive entities of many different types, you'll want to use a property that expects schema.org/Thing so that entities of any type can be added to your content.

Example: if applying to the article body of a BlogPosting, use the mentions property to capture entities of any type.

You can also restrict the results to only one type in order to use more precise properties.

Example: if you want to say a Service has an areaServed, the Omni LER results will need to be restricted to the Place type.

Example: if you want to say a Product if from a brand, the Omni LER results will need to be restricted to the Organization type.

What types can Omni LER identify?

Omni LER identifies entities with the following schema.org types:

• Date
• ContactPoint
• CreativeWork
• Event (Thing)
• Number
• Offer
• Organization
• Person
• Place
• PostalAddress
• Product (Thing)
• Thing

Note: The API is able to identify entities typed as Product and Event. However, since these types can be eligible for Rich Results, they trigger errors in Google Search Console. As a result, we have chosen to type Product and Event entities as Thing to prevent errors from appearing in Google Search Console enhancement reports.

How do I know Omni LER is working?

Your CSM will validate whether Omni LER is working by:

• Validating sample URLs in the Schema Validator tool
• Checking the Response in the Console Network tab
• Running a report in Schema App's administrator tools

Omni LER reporting is available at the following levels:

• Project (website)
• Highlighter Template
• Individual Omni LER tags

General Content Considerations

1. Use standardized names

When possible, use terms that can be found on authorities like Wikipedia or Wikidata. Provide additional content that includes language familiar to users. This way your content is optimized for both entity SEO and content SEO.

2. Capitalization Is Important!

Proper nouns are differentiated from common nouns with the same name by capitalization. Ensure that proper nouns are consistently capitalized to facilitate Omni LER matches.

Example: Apple, the “American multinational technology company” and apple, the “fruit of the apple tree”.

3. Consider surrounding content

What other entities are relevant to your primary entity? Take Amazon, for example. When surrounded by other keywords like “technology”, “e-commerce” and “digital streaming”, it is identified as the Amazon the company, whereas keywords such as “tropical”, “trees”, or “biodiversity”  make it clear that the entity being mentioned is the Amazon rainforest in Brasil.

This approach isn’t that different from keyword clusters in content SEO. The only difference is that it takes NLP APIs into account alongside human users searching for content. 

Omni LER Limitations

1. Limitations of API

The API used for Omni LER occasionally matches to entities that are incorrect (for example, matching to Hamilton the person, rather than Hamilton the place). In cases like this, it’s best to omit the impacted URL from the Highlighter page set to avoid deploying inaccurate markup. This is a limitation of the API itself.

Our testing found API results to be correct 83% of the time.

An enhancement to enable more control over the results is planned.

2. Highlighter Subtemplates

If an Omni LER tag is added to a subtemplate that iterates through html elements (e.g. <li> in a <ul>) it will only process the first element.

To start implementing Omni LER on your account, get in touch with one of our Customer Success Managers at support@schemaapp.com