Сущность

Такое понимание опирается на модель «сущность — связь» Питера Чена и описание ресурсов в RDF — модели представления информации в вебе. Оба подхода отделяют описываемый объект от сведений о нём. ^{[1, 6]} Например, слово «Север» может обозначать спортивный клуб или магазин: чтобы выбрать нужную сущность, понадобится контекст.

Кратко

Название, объект и карточка с его описанием — разные вещи.
Идентификатор помогает ссылаться на конкретный объект; свойства рассказывают о нём, связи соединяют его с другими объектами.
Одинаковые названия не доказывают, что перед нами одна сущность.
Проверить правильность описания и проверить его использование поисковиком — две разные задачи.

Происхождение и история термина

В статье 1976 года Питер Чен предложил модель «сущность — связь» для проектирования баз данных. В ней отдельно рассматриваются различимые объекты, отношения между ними и их характеристики. Так, сотрудник и проект — объекты, а участие сотрудника в проекте связывает их. Работа показывает научное употребление понятия задолго до современного поискового маркетинга; она не устанавливает происхождение самого английского слова entity. ^[6]

В поиске эта идея получила наглядное объяснение при запуске Google Knowledge Graph 16 мая 2012 года. Амит Сингхал показал, что один запрос может относиться к разным объектам: например, название Taj Mahal — к памятнику или музыканту. Задача состояла в различении объектов и представлении связанных с ними сведений. Это описание исторического запуска, а не гарантия безошибочности сегодняшнего поиска. ^[4]

Суть и механизм

Представим редакционный справочник. У спортивного клуба есть карточка с локальным кодом S-01, названием «Север», видом спорта и ссылкой на источник сведений. Код нужен для работы внутри справочника: если название изменится, редактор сможет сохранить связь старых публикаций с тем же клубом. Само назначение кода ещё не доказывает, что сведения в карточке верны. Это учебная организация данных, а не обязательный формат поисковой системы.

Свойство отвечает на вопрос об объекте: как он называется, где находится, когда создан. Связь позволяет перейти к другому объекту: клуб участвует в турнире, а турнир проводится в городе. В RDF 1.1 простое утверждение записывают тройкой: субъект — о чём говорится, предикат — какое отношение задано, объект — с чем установлено отношение. Набор таких записей образует граф. ^[1] В учебной записи «клуб S-01 — участвует в — турнире T-04» видны все три части; истинность участия проверяется отдельно.

Поэтому сущность и граф знаний различаются по масштабу. В нашем примере клуб — один описываемый объект, а клуб, турнир, город и отношения между ними образуют связанную модель. Если ошибочно соединить карточку клуба с карточкой магазина, сведения будут относиться уже не к тому объекту, сколько бы подробностей мы ни добавили.

Для веб-страниц часто обсуждают Schema.org — словарь типов объектов и их свойств. В его базовом типе Thing предусмотрены name для имени, alternateName для другого имени и identifier для идентификатора. Свойство sameAs содержит ссылку на страницу, однозначно указывающую, какой объект описывается. ^[2] Ссылка на обзор местных клубов не становится такой ссылкой только потому, что в обзоре встречается слово «Север».

Виды и классификации

Тип объединяет объекты с общими признаками, но не заменяет конкретный объект. В документации Google среди типов названы люди, организации, места, книги, события и спортивные команды. ^[3] Таблица ниже — учебное разграничение уровней описания, а не новая классификация поисковика.

Что описываем	Учебный пример	Для чего нужно
Тип	Спортивная команда	Выбрать подходящий набор характеристик
Сущность	Конкретная команда «Север»	Понять, кому относятся сведения
Имя	«Север»	Назвать объект в тексте
Локальный идентификатор	`S-01`	Связать записи внутри справочника
Связь	Участие в турнире `T-04`	Соединить два описания

Выбор модели зависит от задачи. Чен отмечал: то, что в одном описании выделяют как сущность, в другом могут представить отношением. ^[6] Для редакционного справочника полезно заранее договориться, что получает собственную карточку: например, турнир целиком или каждый его отдельный матч. Это предлагаемое правило организации работы, а не требование к любому сайту.

Как применяется на практике

Учебный пример. В архиве регионального издания есть материалы о клубе «Север», магазине «Север» и музыкальной группе с тем же названием. Редактор заводит три карточки: S-01, S-02 и S-03. В этой условной базе у каждой указан свой тип и источник, позволяющий отличить объект от двух остальных.

Материал о матче привязывается к клубу, новость об открытии торговой точки — к магазину, рецензия на концерт — к группе. Но короткую заметку «Север получил награду» редактор пока оставляет без привязки: одного заголовка недостаточно. Он читает текст и проверяет, кто именно назван в исходном сообщении. Неопределённость становится отдельной задачей проверки, а не поводом выбрать первую подходящую карточку.

Для сайта это даёт практическую последовательность: сначала выяснить, об одном ли объекте говорят материалы, затем согласовать его описание и только после этого связывать записи. Так можно проверить причину каждого объединения и исправить ошибочную связь, не переименовывая все объекты с похожим названием.

Российский пример применения — семантическая разметка в Яндекс Вебмастере. Это дополнительные обозначения в коде страницы, помогающие программе распознать тип и свойства описанного объекта. Справка Яндекса объясняет применение Schema.org и использование размеченных данных в сервисах, включая представление организаций в поиске. При этом сведения могут индексироваться и без разметки. ^[5] Следовательно, работу над понятным описанием нельзя свести к заполнению технических полей.

Как измерить или проверить

Для своего справочника можно ввести показатель: доля карточек с проверенным источником идентификации. В нашем учебном правиле карточка засчитывается, только если ссылка открывается и её содержание позволяет установить именно описываемый объект. Это редакционная метрика, а не показатель ранжирования или авторитетности сайта.

Допустим, на 23 октября 2026 года в проверяемой подборке 50 карточек. Ссылки есть у 40, но пять ведут к одноимённым чужим объектам. Поэтому наличие ссылки и подтверждённая идентификация дают разные результаты:

40 / 50 × 100\% = 80\%;\qquad (40 - 5) / 50 × 100\% = 70\%.

В первом расчёте числитель — все карточки со ссылкой, во втором — 35 карточек, прошедших содержательную проверку. Знаменатель в обоих случаях — вся подборка из 50 карточек. Остаются 15 неподтверждённых: десять без ссылки и пять с неверной привязкой. Если карточек нет, долю не вычисляют. Даже результат 100% по этому правилу не проверял бы все адреса, даты и другие свойства: для них нужны отдельные основания.

При проверке разметки редактор сначала сопоставляет данные с видимым описанием, затем проверяет выбранные свойства и техническую корректность записи. Например, правильно записанное sameAs всё равно ошибочно по смыслу, если ведёт на сайт другого «Севера». Назначение свойства требует совпадения объекта, а не сходства названия. ^[2]

Ошибки, ограничения и спорные вопросы

Имя легко принять за идентификатор, а заполненную карточку — за доказанную биографию объекта. Учебный пример показывает обе опасности: название объединяет разные объекты, наличие ссылки скрывает неверную привязку. Предлагаемая мера проверки — сохранять основание выбора объекта и отдельно отмечать спорные сведения.

Описания также нуждаются в привязке ко времени. В RDF граф представляет статический снимок сведений; временные аспекты можно выразить подходящими свойствами. ^[1] Поэтому в нашем справочнике дату проверки адреса следует хранить отдельно: прежний адрес магазина не становится текущим только оттого, что карточка сохранила свой код.

Нельзя судить о всей базе поисковика по одному внешнему интерфейсу. Google Knowledge Graph Search API — программный интерфейс поиска сущностей — возвращает отдельные результаты, а не взаимосвязанный граф. Его документация предупреждает о критической зависимости продукта от API и сообщает о переходе к Cloud Enterprise Knowledge Graph. ^[3] Это ограничения указанного интерфейса; проверка нашего справочника не измеряет полноту или качество внутренней базы Google.

Частые вопросы