Chinese classification

Среди людей занимающихся семантикой распространен мем "китайская классификация" -- таксономия с "плавающим" основанием. Корни этого термина растут из эссе Борхеса "Аналитический язык Джона Уилкинса" в котором он упоминает некую китайскую энциклопедию под названием "Небесная империя благодетельных знаний". На ее древних страницах написано, что животные делятся на:

1. принадлежащих императору;
2. бальзамированных;
3. домашних;
4. молочных поросят;
5. сирен;
6. сказочных;
7. бродячих псов;
8. включённых в эту классификацию;
9. бешеных;
10. бессчетных;
11. нарисованных тончайшей кистью из верблюжьей шерсти;
12. прочих;
13. только что разбивших кувшин;
14. издалека кажущихся мухами.

С точки зрения современного образованного человека китайская классификация выглядит дико. С другой стороны такие классификации встречаются повсеместно, достаточной вспомнить классификатор жанров FB2, библиотечный каталог, или классификатор МКБ-10. ailev вообще высказал мысль о том, что все онтологии -- это замаскированные китайские классификации, ибо именно таковые классификации лежат в основе мира, именно к таким классификациям привыкли люди. Если это так, возникает вопрос, откуда берутся "китайские классификации" и почему люди охотнее создают и пользуются ими вместо строгих таксономий?

Не смотря на кажущуюся сумбурность, "китайская классификация" подчинена определенной внутренней логике. Строгая таксономия делит мир на классы согласно некоторого рационального критерия: принадлежит животное императору или нет; домашнее оно или дикое; существует оно в реальности или же оно вымышленное и т.п. Для "китайской" классификации в качестве основания выступает не рациональный критерий а степень важности некоторого класса. В каноническом примере, создателя классификации равно интересуют, как животные императора, так и домашние животные, независимо от того, кому они принадлежат. Если бы автор пожелал создать на тех же критериях строгую рациональную классификацию, она получилась бы в несколько раз больше и многие ее классы оказались бы невостребованными. "Китайские классификации" стоит рассматривать как оптимизации строгих таксономий под конкретные способы использования.

Очевидно, что любую строгую иерархическую классификацицию можно сделать китайской. Достаточно присвоить классам разные веса и сгруппировать на одном уровне классы с одинаковым весом. Некоторый аналог такого приема в дизайне интерфейсов -- быстрые закладки для часто используемых функций. К сожалению, простого способа обратного преобразования не существует, поскольку невозможно автоматически выделить рациональные критерии из мешанины классов. Единственный достоверный способ на сегодня, это кропотливая ручная обработка. Неудивительно, что инициатива semantic web продвигается с таким скрипом. "Китайские" классификации это объективная часть природы человека, и хотим мы этого или нет, нам придется учиться с ними справляться.

Data about data

Если открыть спецификацию какого-нибудь формата данных, в ней скорее всего обнаружится раздей посвященный метаданным. Иногда, такой раздел превышает остальную спецификацию в несколько раз по объему и по сложности. В то же время, на практике метаданные используют весьма и весьма нечасто. Существуют даже форматы, которые никто так полностью и не имплементировал, по причине невостребованности. Например, тот же ID3v2 (метаданные для MP3) с его несколькими сотнями тегов начиная от автора песни и заканчивая переводами лирики. Или EXIF, которым пользуются ровно потому, что все современные камры пишут в него параметры съемки. Еще ни разу не видел, чтобы из него кто-нибудь использовал разделы описания или копирайта. Или FB2, по поводу метаданных которого регулярно возникают споры на форумах о том, как их заполнять. Или MARC, с правильным заполнением которого проблемы даже у профессиональных библиотекарей, хотя им-то сам бог велел прекрасно разбираться в предметной области. И какой формат ни возьми, с метаданными будет плохо. Или мало, или много, или в самый раз, но совсем не то, что нужно.

Для того чтобы понять почему так происходит, нужно определить, что такое метаданные. Лаконичное определение из заголовка, конечно, прекрасно, но оно ничего не говорит о том, какие это данные. Почти все факты о данных можно представить в виде утверждений <субъект, свойство, значение>. А набор свойств из предметной области и доменов для значений суть онтология. Например, фокусное расстояние это свойство, которое может принимать значение типа длина (а не угол или скорость). В большинстве форматов онтология жестко зафиксирована, так что не бросается в глаза, но она всегда присутствует.

Вернемся к проблеме. Разработчик формата всегда держит в голове какой-то способ использования этого формата. Иначе он в принципе не смог бы разработать ничего полезного. Однако, как только он фиксируеется на способе он начинает представлять себе предметную область с одной, узкой, точки зрения. В результате получается онтология, описывающая каую-то узкую область, которую разработчик считает верной. Однако, у пользователей совсем другое мнение на этот счет. Почти наверняка кто-то будет использовать формат по другому. ID3 созвался для музыки, но его можно использовать для кучи разных вещей: от записи телефонных разговоров, до калибровочных сигналов дефект-детекторов. EXIF хорошо описывает метаданные съемки, но не годится для описания преобразований, проделанных с оригинальным изображением. Проблема в том, что невоможно предусмотреть все способы использования метаданных и разработать всеобъемлющую онтологию. Более того, такие попытки почти всегда приводят либо к излишней общности либо к излишней сложности. И то и другое отталкивает пользователей от использования метаданных. Хуже, когда появляются несколько стандартов метаданных для одного формата. В итоге каждый софт какие-то форматы метаданных поддерживает, а какие-то нет, что еще сильнее отвращает пользователей. Никому не хочется описывать файл, если при следующей обработке или конвертации эти сведения потеряются.

Как можно с этой проблемой справиться? Если вы разработчик формата, не пытайтесь думать за пользователей -- все равно не выйдет. Дайте им возможность определять собственные онтологии и снабдите их парой убедительных примеров для конкретных узких областей. Хороший пример движения в нужном направлении Adobe XMP основанный на RDF. Нельзя сказать, что этот формат идеален, но хоть что-то.

Блеск и нищета Semantic Web

Случайно обнаружил занятный блог о semantic web на хабрахабре. Занятный он хотя бы тем, что гражданин ушел несколько дальше вольного пересказа завлекалок TBL о том как SW приблежает коммунизм в сторону практическую. Гораздо чаще в семантик вебовских кругах встречаются "теоретики" способные умно рассуждать, но не показывающие никакого практического результата. Полагаю, именно поэтому все SW технологии делятся на две категории: неверно используемые (работающие) и сложные (бесполезные). К первым можно отнести RSS, который хоть и основал на RSS, но никакими преимуществами оного не пользуется. Ко вторым тройку RDF, OWL, SPARQL. Со стороны идея выглядит красивой, до тех пор пока она не выходит за рамки простейшей структуры метаданных "Автор: Василий П, Дата публикации 02-10-2001". Красиво, интересно, но абсолютно бесполезно. Никому не нужны запросы по метаданным страницы, когда есть приличный полнотекстовый поиск, википедия и доступный предметные БД вроде того же IMDB. С другой стороны, для более сложных случаев RDF+OWL годится плохо в силу нескольких врожденных недостатков:

Отсутствие механизмов доверия

Приведу пример из жизни. Занимались мы созданием биологической базы знаний. Ну знаете, белок А образует с белком Б комплекс, который влияет на экспрессию гена С. Казалось бы, идеальное поле для RDF: опиши онтологию и клепай утверждения пока не надоест. Хрен. У каждого утверждения есть источник позволяющий отследить, его происхождение и достоверность. Не бывает непреложных истин данных нам свыше. Отсюда требуется как-то определять источник утверждения. RDF такого механизма не предоставляет, нету в тройке <субъект, предикат, объект> такого свойства. Как следствие, затраты на описание непротиворечивой модели взлетают до небес. Возможно есть способ как-то извратиться и, таки, запихать источник в модель, но мне они не известны.

Отсутствие механизмов ограничения области действия утверждения

Возьмем пример <Россия, Столица, Москва> Верно? Не всегда. С 1712 по 1918гг. Столицей России был Петербург. С 1922 по 1991гг. Москва была столицей другого государства, СССР. Более того, царская Россия до 1917 и Российская Федерация это разные государства. Можно сказать, что Петроград столица России? Нет, потому что ни той России ни Петрограда уже и нет в природе. Но сей факт имел место быть в прошлом.

Отсутствие встроенной поддержки метрик

Устройство А потребляет ток 0.5A, а устройство Б всего 500uA. И как быть? RDF не позволяет указывать тип утверждения. Можно, конечно, создавать объектов для каждого значения, но вам не кажется, что это решение несколько кривовато? Оные проблемы не дают использовать RDF+OWL где либо, где используется агрегация данных из нескольких источников, либо сами данные носят противоречивый характер. В принципе, проблему можно решить раз и навсегда, если добавить каждому RDF утверждению URI, позволяющий определить для него контекст. И тип измеряемой величины, и единицы измерения и источник. Например так: <statement_1, specie_3251, средняя длина листьев, 40cm> <statement_2, specie_3251, максимальная длина листьев, 60cm> <statement_3, specie_3251, средняя длина листьев, 50cm> <statement_4, (statement_1, statement_2), источник, "Аквариумные растения"> <statement_5, statement_3, источник, "Пресноводные тропические растения. Том 3">