Рубрика: Semantic Web

Прошедшие выходные я провел за «увлекательным» занятием классификации информационных систем нашей компании. Выгруженные из Configuration management database (CMDB) приложения и из Human Resource management system (HRMS) сотрудники были подвергнуты различным inner, outer и cross join-ам . Естественно, делал это я не в трудовом порыве, а по служебной необходимости. Чтоб время, эмоции и силы были потрачены не совсем зря, изложу своё понимание терминов таксономия, фолксономия, агрегация и композиция в применении к современным информационным системам, в частности к CMDB.

Традиционно под таксономией понимали жесткую классификацию объектов, управляемую централизованно, а под фолксономией классификацию, задаваемую пользователями. В качестве примера часто приводятся метки(теги) и категории. Т.е. добавление тегов к сообщению в блоге – это фолксономия, а категорирование статей – это таксономия. На самом деле, этот пример немного неряшливый. Большинство блогов позволяет менять метки(теги) только автору сообщения (или админстратору), поэтому называть это фолксономией не верно. С другой стороны, категории сообщений довольно похожи на метки и допускают свободное включение сообщений одну или несколько категорий.

Данная гибкость существенно отличает социальное ПО от традиционных бизнес-приложений. Для корпоративных справочников речь даже не идет об использовании тегов или категорий. Ситуация значительно хуже. Сплошь и рядом при разработке корпоративных информационных систем происходит подмена понятий агрегация и композиция. Напомню, что согласно UML агрегация – это такое отношении между классами, при котором один класс является частью другого (обозначается белым ромбиком), а композиция – это частный случай агрегации, когда часть и целое не могут существовать друг без друга(обозначается черным ромбиком). Т.е. программист, пришедший на работу, состоит с ней в отношении агрегации. А вот мысли этого самого программиста находятся с его головой в отношении композиции. Тем не менее, извечной практикой проектировщиков баз данных является прибивание гвоздями объектов, не состоящих друг с другом в отношении композиции.

Категории, подкатегории, классы, типы, группы, разделы, виды, рода и пр. делаются обязательными свойствами тех или иных классов. Это все равно, что в первой строке текстового файла писать имя компьютера на котором он лежит и полный путь к файлу. Но это все делается, причем в качестве обоснования приводится идея наведения порядка и классификации объектов, т.е. таксономия.

На самом деле, разница между таксономией и фолксономией следующая. В случае таксономии, решение о включении или не включении определенного объекта в группу(отнесении к категории) принимает владелец этой группы. Т.е. если компания считает необходимым категорировать документы атрибутом «важно!», то в случае таксономии должен быть назначен сотрудник, отвечающий за присвоение документам данного атрибута. Категорий, подкатегорий и видов классификации, и ответственных за них, может быть произвольное количество. Одни отвечают за иерархию категорий «важно!» , другие за иерархию категорий «срочно!» и т.д. Если же категорирование отдается на откуп авторам документов, то это фолксономия (что, впрочем, не исключает возможности  учета принадлежности объектов  категориям). Возвращаясь к корпоративным справочникам. Если классифицирующие объект поля вносятся в структуру данных объекта, то это – плохая архитектура данных. Никакого отношения ни к таксономии ни к фолксономии такая архитектура не имеет.