UProLa

Неокріпші думки

Модель класифікатора/колектора знань

with 2 comments

Напишу все-таки своє бачення ідеального класифікатора/колектора знань.

Класифікатор/колектор знань – це середовище, що дозволяє централізовано наповнювати певну абстрактну базу даних знаннями людини про навколишній світ.

На сьогоднішній день існують децентралізовані колектори знань і поодиничні класифікатори. Типовими прикладами є каталоги, енциклопедії, орієнтовані на нейромережі системи. Всі вони мають свої переваги, проте також мають свої недоліки. Енциклопедії і каталоги дуже обмежені. Аналогічними обмеженнями володіє HTML перед XML. Системи з нейромережами і семантичним пошуком працюють для людини, проте не містять потрібного детермінізму для промислового використання.

Власне я пропоную на суд людей свою ідею (поки-що тільки ідею, технічних складностей занадто багато для її реалізації) такого об’єднуючого класифікатора/колектора.

Базові принципи

Модель ККЗ включає в себе наступні 4 ключові частини:

  • Модель – описує зв’язок між об’єктами, класами та різноманнітям інших сутностей
  • Дані – складаються з конкретних одиниць знання, у будь-якому форматі
  • Проекція – певний фільтр, який перетворює існуючі дані у інший формат
  • Точка зору – версія одиниці знань, з точки зору історії, людини, корпорації тощо.

Розпишу більше подробиць про зв’язок між цими поняттями.

Модель є ключовою частиною класифікатора. Модель, в розумінні даного опису, є системою, тобто набір об’єктів і зв’язків між ними. За рахунок того, що модель описується у текстовому вигляді і може приймати візуальне відображення, її створення перестає бути перешкодою на шляху створення класифікатора. Більше про формат моделі буде написано нижче.

Дані зберігаються у базі даних і прив’язуються до об’єктів/зв’язків відповідної моделі. Оскільки окремі моделі можуть зв’язуватись між собою, окремі дані мають певне реляційне відношення. В банальному випадку, дані можна записати в реляційні БД при відповідності колонок і об’єктів моделі. У більш складних випадках можна використовувати такі абстракції як “файлова система”, нереляційні бази даних, посилання тощо. Моделі і проекції – це також дані. Важливо те, що спосіб збереження даних зовсім не важливий, важливо тільки існування проекцій цих даних.

Проекція є алгоритмом перетворення конкретних даних у конкретний вигляд. Проекція ховає формат збереження даних. На даний момент я придумав тільки два типи проекцій: це людиноорієнтована і машиноорієнтована. Перша має аналог у сучасному світі під назвою “стаття”. Те, що здається написаним людиною, насправді є згенерованим по існуючим моделям і даним. Проекція не обмежується лише поняттям “стаття”, це може бути інтерактивна програма, зображення, графік, таблиця… Машиноорієнтована проекція є певного роду фільтром даних, тобто перетворення існуючих даних у формат, зручний для обробки машиною – бінарний, конфігураційний, xml, …

“Точка зору” не входила в базову модель ККЗ, проте її наявність є важливою складовою при роботи з людиною. Точка зору відображає одиницю даних (в тому числі і модель) з, наприклад, точки зору історії (аналог – історія правок у Вікіпедії). Інший приклад – політична система може мати безліч точок зору, від відверто критичних до боготворячих за рахунок складності прогнозування подій. Поняття “інтегралу” повинно бути по-різному написане для новачка, студента і професійного математика. “Точка зору” може застосовуватись до будь-якої одиниці даних, вирішуючи 2 проблеми:

  1. Збереження усіх-усіх знань, з усіх-усіх точок зору (Вікіпедія по своїй природі не може зберігати щось інше, ніж енциклопедична стаття)
  2. Відсутність обмеження по точці зору людини (присутнє наразі на Вікіпедії)

Модель

Створення моделі є найпродуманішим у всій цій системі. Власне, як вже було згадано, система – це набір об’єктів і зв’язків. Для спрощення було введено ще одне поняття – атрибут. Атрибут (або тег) є об’єктом і прив’язується до існуючого об’єкта або зв’язка.

Як це виглядає?

Об’єкт --> Об’єкт2

Це означає, що об’єкт породжує об’єкт2.

[Мати, людина] --> [Син, людина]
[Батько, людина] --> Син

Дана модель візуально складається з 3 блоків “Мати”, “Батько” і “Син” і читається як “Батько і мати породжують сина”. Символічна змінна (без дужок) є ідентифікатором об’єкту. Квадратні дужки обмежують об’єкт. Перше слово (до коми) є ідентифікатором об’єкту, всі наступні – атрибутами. В даному випадку за допомогою атрибутів було вказано, що усі 3 об’єкти є об’єктами класу “людина”. Клас є таким же об’єктом і банально визначається як

object --[,наслідування]--> Клас --[,наслідування]--> людина

Атрибут “наслідування” відноситься до системних атрибутів зв’язків. Окрім наслідування може існувати безліч інших зв’язків, як от “породження”, “еквівалентність”, “перетворення”, “вплив” тощо.

Мова створення моделей досить потужна, в механізмі атрибутів можна вгледіти всю силу CSS, а у зв’язках – можливість графічної демонстрації моделі. Власне, першопочатково це був формат створення блок-схем у текстовому вигляді. В принципі, ніщо не забороняє використовувати додатково такі механізми, як групування і стилі для об’єднання семантичної моделі і графічного відображення.

{[Мати, людина] [Батько, людина], вертикально} --[,наслідування]--> [Син, людина]

Фігурні дужки групують об’єкти і приписують групі певні атрибути. Програма візуалізатор може використовувати ці атрибути для зміни способу відображення.

Ця мова має також цілу низку недоліків, починаючи від недостатньої однорідності і закінчуючи відсутністю готових моделей. Можливо колись я все-таки формалізую її, тоді можна буде спробувати використати її для моделювання світу =)

Дані і бази даних

Хоч база збереження даних може бути будь-якого формату, вона повинна володіти наступною ососбливістю: глобальний бекап. Що це значить? Усі дані повинні дублюватись безмежну кількість раз для неможливості простого централізованого знищення. Я бачу це як зберігання даних у кодуванні Ріда-Соломона на усіх можливих публічних серверах – контролю версій, файлопомийках, вебархівах, картинко-зберігачах, відеохостингах. Такий ресурс є впринципі невичерпним навіть при застосуванні об’ємомісткого кодування і багаточисленого дублювання. Звичайні реляційні бази даних можуть використовуватись як кеш.

Не виключено використання асиметричної криптографії, осільки децентралізація майже зажди грозить фальсифікаціями.

Відкритість

Відкритість інформації є хорошою ідеєю. Її варто дотриматись і в даному ККЗ. Відкритість також включає можливість редагування будь-ким, благо за рахунок механізму “точок зору” не доведеться боротись з спамерами.

Від автора

В даному коротком нарисі було визначено ідейні межі для класифікатора/колектора знань загального призначення. Хоч його створення є досить трудомістким, його ідеї можуть бути успішно застосовані через років 50-100.

Written by danbst

Червень 12, 2011 at 09:25

Оприлюднено в Програмування

Відповідей: 2

Subscribe to comments with RSS.

  1. Ще не дочитав а вже виникають питання:
    Що таке колектор, класифікатор, CSS (Cascading Style Sheets?) ?

    Мова для моделі мені нагадала dot.

    bunyk

    Червень 13, 2011 at 06:26

    • Так, схожа на dot. Коли придумував, ще не знав про graphviz, думав, такого софту не існує.

      CSS – так, каскадні таблиці стилів. Колектор – ну блін, це ж зрозуміло, що “збирач”, “накопичувавач”. Класифікатор – “той що виконує класифікацію”.

      danbst

      Червень 13, 2011 at 08:45


Залишити відповідь

Заповніть поля нижче або авторизуйтесь клікнувши по іконці

Лого WordPress.com

Ви коментуєте, використовуючи свій обліковий запис WordPress.com. Log Out / Змінити )

Twitter picture

Ви коментуєте, використовуючи свій обліковий запис Twitter. Log Out / Змінити )

Facebook photo

Ви коментуєте, використовуючи свій обліковий запис Facebook. Log Out / Змінити )

Google+ photo

Ви коментуєте, використовуючи свій обліковий запис Google+. Log Out / Змінити )

З’єднання з %s

%d блогерам подобається це: