Entity Graph и модель данных «Матчасти»

1. Главное решение

2. Базовый принцип: сущность, утверждение, источник

Wikidata представляет знания через statements вида subject → predicate → object и позволяет добавлять qualifiers, например время действия связи. W3C PROV отдельно подчёркивает provenance: происхождение данных, агента, активность и историю формирования объекта. Для «Матчасти» эти два принципа объединяются.

3. Entity ≠ Public Page

Это защищает IA от тонких автоматических страниц и позволяет сначала накопить граф, а потом решать, что публиковать.

4. Core entity types

5. Почему Organization, Legal Entity и Brand нельзя слить

Schema.org отдельно различает Organization и Brand; Google Organization markup также различает display name и legalName, а идентификаторы могут использоваться для disambiguation.

6. Canonical entity ID

Public slug никогда не используется как primary key.

7. Идентификаторы

OpenCorporates строит идентификацию компаний на паре jurisdiction + company number. Google Organization markup поддерживает реальные business identifiers и отдельно рекомендует identifier-поля для disambiguation. Для России «Матчасть» должна хранить локальные идентификаторы отдельно, а не в одной строке «ИНН/ОГРН».

8. Таблица identifiers

9. Названия и aliases

Это позволит нормально решать rebranding, исторические имена, транслитерации и entity matching.

10. Не хранить «бывшее название» в одном текстовом поле

11. Relations / edges

12. Каждая связь должна быть временной

Wikidata использует qualifiers вроде start time/end time для отношений. Для «Матчасти» это критично: сотрудник, владелец бренда или статус компании меняются.

13. Claim ≠ Fact

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

14. Facts vs claims в физической модели

То есть модель гибридная: relational core + provenance-aware claims.

15. Provenance

W3C PROV рассматривает provenance как информацию об объектах, действиях и агентах, участвовавших в создании данных. «Матчасть» не обязана реализовывать PROV-O буквально, но должна перенять его логику.

16. Source entity

17. Source ≠ citation text

Один источник может подтверждать несколько claims и использоваться в нескольких публикациях. Поэтому источник хранится отдельной сущностью, а citation в статье ссылается на source_id.

18. Trust tiers для источников

Trust tier не означает автоматически «правда/ложь». Это input для verification workflow.

19. Confidence score

20. Organization table

21. Legal entities

22. Person / Expert

Sensitive personal data не должно собираться «на всякий случай». Public expert graph хранит только данные, необходимые продукту и имеющие законное основание.

23. Role не является колонкой Person

24. Topics

Topic aliases участвуют в search/entity resolution, но не создают отдельные public pages.

25. Industry taxonomy

26. Product и Service

Schema.org различает Product, Service и Brand. «Матчасти» стоит хранить продукты уже на раннем этапе, потому что AI Visibility часто относится не только к компании, но и к конкретному продукту/категории.

27. Publication как entity

28. Publication content и entity graph разделены

29. Mention graph

Помимо сильных семантических отношений нужен более лёгкий слой mentions.

AI может извлекать candidates, но публично значимые entity relations подтверждаются редактором или строгим rule engine.

30. AI не создаёт verified entity relation автоматически

31. Entity resolution

32. Entity resolution scoring

33. Merge

34. Split

Поэтому merge не должен физически уничтожать историю. Должен быть reversible admin operation с audit trail.

35. Verification уровни

Детально — Mathchast_20.

36. Profile completeness ≠ verification

Полная анкета может быть полностью непроверенной. Короткая карточка с реестровым ID может быть highly verified.

37. Index eligibility score

Это отдельный score от verification и commercial status.

38. Public claims presentation

39. Temporal snapshots

Для AI/Search reports особенно важно знать, как entity выглядела в конкретный момент.

40. Audit events

Для критических изменений не полагаться только на application logs.

41. Source snapshots

Нельзя бездумно архивировать чужие полные copyrighted pages. Snapshot policy должна учитывать права и тип источника.

42. Publication versioning

Документ 16 уже требует immutable published versions. В data model:

43. Address

Не хранить один «адрес» без понимания его роли: юридический, офис, филиал, исторический.

44. Domain ownership

45. Почему domain — сильный, но не вечный ID

Домены продаются, истекают и меняют владельцев. Поэтому domain нельзя использовать как immutable entity key. Он является identifier relation с временем и проверкой.

46. External same-entity mappings

Schema.org sameAs определяет URL как однозначную ссылку на тот же объект. Поэтому в будущем structured data нельзя заполнять sameAs любыми страницами, где компания просто упомянута.

47. Schema.org mapping

Внутренняя модель не должна ограничиваться Schema.org. Structured data — экспортная проекция, а не primary database schema.

48. Важный нюанс ProfilePage

Следствие для будущего Mathchast_21:

• автор/эксперт, реально публикующийся на «Матчасти», может подходить под creator profile model;
• обычная карточка внешней компании в business directory не должна автоматически размечаться как Google ProfilePage только потому, что это «профиль» в интерфейсе;
• для company page безопаснее проектировать WebPage + mainEntity Organization и затем проверить актуальные Google requirements.

49. Ownership/management permissions отдельно от entity

Это фундамент для agency workspace и передачи управления профилем.

50. Agency не владеет entity клиента

51. Commercial relationships

Коммерческая связь тоже является данными, но не должна смешиваться с business ownership.

52. Не хранить advertising status только в тексте статьи

legal_status, advertiser relation и sponsor relation должны быть структурированными полями, чтобы:

• рендерить маркировку;
• строить ОРД workflow;
• применять Link Policy;
• фильтровать partner content;
• аудировать конфликт интересов.

53. Search / semantic retrieval

Векторное сходство не должно автоматически сливать entities.

54. Embeddings

Хранить model/version, потому что embeddings разных моделей нельзя считать стабильным вечным идентификатором.

55. AI Visibility data не смешивать с core facts

AI observation — событие измерения, не свойство компании.

56. Future AI observation schema

Детально — Mathchast_33.

57. Search observations

Тот же принцип:

Не записывать «позиция Google = 4» прямо в publication record.

58. Data ownership

59. Не перетирать editorial description маркетинговым текстом клиента

60. Data retention и deletion

Удаление account/person data, снятие публикации и удаление business entity — разные операции. Data model должна поддерживать:

Политика privacy будет детализирована позже; схема должна позволять исполнить её без разрушения всего graph.

61. Physical PostgreSQL modules

Физическое разделение schema можно упростить на MVP, но доменные границы полезно держать в архитектуре.

62. JSONB: где использовать

63. IDs и foreign keys

Все core relations должны иметь реальные foreign keys. Human-readable slug и external identifier не заменяют внутренний ID.

64. Constraints

Не вводить ложный global UNIQUE на company name или domain без временной модели.

65. Event model

66. Entity Graph API

67. Company Page query

68. Source traceability in UI

Не обязательно превращать страницу в Wikidata. Но важные факты должны иметь лёгкий путь к источнику:

69. Public provenance levels

70. Business advantage

71. Что не строить в MVP

72. MVP data entities

73. Migration strategy

74. Решение документа

75. Что этот документ разблокирует

Источники исследования

• Google Search Central — Organization structured data: name, legalName, identifiers, logo, address, online presence и disambiguation
• Google Search Central — ProfilePage: mainEntity Person/Organization и ограничения use case
• Schema.org — Brand
• Schema.org — brand relation для Organization/Person/Product/Service
• Wikidata — Data model: entity statements subject/predicate/object, qualifiers и временные свойства
• W3C PROV Model Primer — provenance, entities, activities, agents, responsibility, roles and time
• W3C PROV Overview — provenance как основа оценки качества, надёжности и доверия к данным
• OpenCorporates Data Dictionary — company_number + jurisdiction_code как идентификационная основа и отдельное хранение legal name/company type

Конкретная SQL-схема, relation vocabulary, verification levels, index eligibility, trust tiers и module boundaries являются проектными решениями «Матчасти». Schema.org и Google markup не используются как primary database schema: они рассматриваются как будущие внешние представления внутренней более богатой модели.