Стандарты каталогизации
Это продолжение постинга по стандартам производства-в-большом (http://ailev.livejournal.com/851977.html).
Чтобы какая-то деталька X имела шанс попасть в чертеж, а затем ухитрилась быть купленной и попала в продукт "в металле", информация о ней должна быть известна многим людям -- проектировщикам, закупщикам, монтажникам и т.д. Данные об этой детальке распадаются на две существенно пересекающиеся группы мастер-данных: "стороны" (party -- клиент, поставщик, посредник, логистическая компания и т.д.) и "продукт" (product). Чтобы данные о продукте стали известны сторонам, создается промышленный каталог продуктов (parts catalog).
Каталог обладает двумя важнейшими характеристиками:
-- он создается "толпой" (crowdsourcing), ибо в нем заинтересованы поставщики. Вот они и пополняют каталог.
-- данные в нем предварительно аудированы (prequalified). Ибо толпяное качество данных мало кого устраивает. Аудитом занимается поставщик каталога.
Финансовые модели поставщиков каталогов сложны, ибо каталоги сложны и тем самым дороги, а платить за них должен непонятно кто. И главное -- каталоги должны быть созданы по стандартам, которые используют потребители и поставщики информации о каталогизированных серверов. Поэтому создание каталогов сегодня является высокорисковым предпринятием, прибыльность его сомнительна, хлопоты высоки, а выгоды сводятся к уменьшению номенклатуры продукции и увеличению конкуренции поставщиков -- так что заинтересованы в каталогах не только потребители, но и поставщики, но не все потребители и не все поставщики (особенно в российских условиях). Не будем пока обсуждать "кому выгодны эти ваши каталоги" или "кто будет этими вашими каталогами пользоваться". Тут проблемы, которые решаются не только технологически, но и организационно. Единственное, что можно сказать, так это обычно прямое руководство со стороны бизнес-менеджеров проектами по созданию каталогов, ибо отдать эту задачу айтишникам не удается. Каталоги нужны не айтишникам, каталоги нужны бизнесменам -- и им это очень трудно, ибо требует co-opetition (сотрудничества-конкуренции в одном флаконе). Капиталистические ёжики плачут, но упорно взбираются на этот каталоговый кактус -- с весьма переменным успехом.
Тем не менее, за последние несколько лет в области технологии произошли существеннейшие изменения (и речь идет не только о том, что над каталогами можно надстраивать электронную торговлю и делать автоматизацию сделок). Современная (т.е. семантическая/онтологическая) айтишная технология позволяет говорить об облегчении организационных задач, более внятно обеспечивая выгоды каталогов для разных участников этих организационных инициатив, раскиданных по разным стадиям жизненного цикла той отрасли, для которой создается каталог (обычно это отраслевые инициативы).
Технологии каталогизации бурно развиваются, а даны они нам не в ощущениях, а в стандартах. Т.е. организационные договоренности продолжаются технологическими договоренностями: договоренностями по стандартам.
Стандартов для построения и использования каталогов -- море. Вернее, не море, а почти как термин употребляемое "болото" (standard quagmire). Эти стандарты касаются:
-- договорки представления информации о продукте, причем используемой на протяжении всего жизненного цикла (от чертежа и инструкции по монтажу через инструкцию по эксплуатации, данные для периодического тестирования, плюс инструкции по демонтажу и безопасному уничтожению. Фотографии, видеофильмы и прочая медиа-информация приветствуются наряду с данными моделирования, обоснованиями безопасности, ссылками на стандарты и т.д.). Тут модны современные протоколы STEP (прежде всего PLCS, он же AP239 из ISO10303), ISO 15926.
-- договорки представления информации о стороне (адрес поставщика-завода, адрес посредника-от-которого-цена и т.д.). Тут не все просто, но и не очень сложно: проблемы те же, что знакомы любым айтишникам. Никакой особой специфики.
-- договорками о терминологии (словари). Излагать мысли желательно в терминах каких-то глобальных идентификаторов, к которым есть определения. Ибо слово "температура" может означать что угодно -- и интересно, какую именно вы температуру, в какой момент времени с какими допущениями имели ввиду. Тем самым снимаются коллизии типа "темп.макс." и "темп.предельн." и "tmax". Беда в том, что разные тусовки делают для себя разные словари. Китайская тусовка китайский словарь, а турецкая -- турецкий. Что делать с двумя разными словарями обычно непонятно. На эту тему конкурируют ISO 22745 в части oETD и ISO 15926 в части RDL.
-- договорками о классах продукции (классификаторы). Если у вас насос, то это совсем не плита железобетонная. Очень удобно для многих целей. Беда в том, что для разных целей существуют разные классификаторы. Тем не менее, классификаторы круче, чем словари. Классификаторы -- это таксономия, построенная над словарём. Конкурируют всякие "национальные системы классификации", NATO USA H2, ISO 15926 часть четвертая.
-- договорками об ограничениях и связях между элементами данных ("семантика"). Тут ISO 15926 (и отраслевые решения, типа IFC/BIM в домостроительстве).
-- договорками о форматах обмена информацией (тут есть поразительное множество вариантов -- от excel-файлов до хитрых XML схем). Сюда же можно отнести способ запроса информации -- например, выдать SQL-запрос или SPARQL-запрос (почувствуйте разницу!). ISO 29002, ISO 15926-9.
Если вас интересует каталог "для всего жизненного цикла", то у вас начнутся сложности от разнообразия договорок. Прежде всего нам нужно будет различить:
-- договорка о терминологии -- это словари (dictionary, vocabulary). Это самая слабая формализация, оставляющая огромный простор для ошибок при автоматизированной обработке информации и минимизирующая возможности для обработки (но все одно лучше "просто текста со слуха").
-- договорка о классификаторе -- классификатор сам строится как словарь, но при этом указываются иерархические связи между классами (дерево). Иногда этот словарь+классификатор называют таксономией. Это уже много лучше и формальней. Вы сразу много что можете сказать о классифицированном объекте, в отличие от объекта, про который вы можете сказать лишь то, что он есть в словаре.
-- договорка об ограничениях и связах между элементами данных означает то, что вы хотите онтологию. Это словарь+классификатор+другие (неиерархические) связи+разные правила (например, запрещающие множественную классификацию).
Эти договорки существенно различаются, но при создании каталога вам придется с ними разобраться:
-- если вы делаете "каталог для САПР" (комплектующие), то вас интересует онтология. Информация разная, САПРЫ умеют ее обрабатывать, PDM/PLM поддерживать, конструкторы и проектанты любопытны.
-- если вы делаете "каталог для ERP" (предметы поставки), то вас интересует главным образом словарь, и иногда таксономия.
-- если вы пытаетесь объять необъятное (то есть пробежаться по жизненному циклу и сделать "каталог для всех"), то вас интересует самая широкая договорка, и меньше чем онтологией вы вряд ли обойдетесь.
Онтологическая интеграция данных:
На картинке показано, что интеграция данных для малого числа участников может быть "традиционной" -- но при большом числе участников трудности будут нарастать экспоненциально: всем будет нужно разное, коллизии с омонимами и синонимами будут наступать чаще и вам придется либо экспоненциально наращивать время на борьбу с трудностями, либо переходить на онтологические (семантические) технологии, предусматривающие явное формулирование дополнительных связей и правил-ограничений.
Все эти договорки влияют на реализацию традиционных операций по работе с каталогом:
-- характеризации, заключающиеся в определении характеристик типа продуктов (но не их значений!). Вы делаете "пустографку", для "всех насосов" или "всех легкоплавких припоев".
-- идентификации, заключающиеся в заполнении значений характеристик типа продуктов для конкретного продукта. То есть вы определяете, что данный вид насосов весит 5кг и качает 80л/мин, при значении "сила воли" 3 мотивационных единицы.
-- классификации, заключающаяся в присвоении класса из какой-то иерархии (таксономии, "дерева", набора "товарных групп" и т.д.).
-- кодификации, заключающаяся в присвоении кода. Это вовсе не классификация, ибо внутри кода могут быть значения от 0 классификаторов (если код, например, сводится к очередному порядковому номеру) до нескольких разных классификаторов.
Обратите внимание, что ни о каких экземплярах тут речь не идет: пока говорим только о каталоге. Если мы будем рассматривать supply chain (всю цепочку поставок), то там речь пойдет и об экземплярах. А пока мы тут говорим только о каталогах, то есть классах. Онтологическое замечание (оговорюсь: мало кто это место понимает, если три раза не ткнуть носом): даже когда вы пишете строчку по итогам идентификации "насос XAYBZC-817263 весом 5кг черный освященный", то это все равно класс (как и "насосы", в которых вес еще не проставлен, а класс представлен "пустографкой" после характеризации). Класс, ибо его членами являются много-много реальных выпущенных насосов указанного типа, веса, цвета и специальных для некоторых категорий клиентов характеристик, различающихся серийными номерами (которые являются уже экземплярами, а не классами). Контрольная шутка: вы хотите летать на самолете, или на классе самолета (т.е. спецификации самолета)?
Вопрос важный, ибо путаница этих терминов и определений идет даже в некоторых специализированных стандартах, а реализаторам каталога все эти операции и договорки нужно поддерживать конкретными программными кодами, текстами регламентов и путаницу желательно устранить.
Чтобы какая-то деталька X имела шанс попасть в чертеж, а затем ухитрилась быть купленной и попала в продукт "в металле", информация о ней должна быть известна многим людям -- проектировщикам, закупщикам, монтажникам и т.д. Данные об этой детальке распадаются на две существенно пересекающиеся группы мастер-данных: "стороны" (party -- клиент, поставщик, посредник, логистическая компания и т.д.) и "продукт" (product). Чтобы данные о продукте стали известны сторонам, создается промышленный каталог продуктов (parts catalog).
Каталог обладает двумя важнейшими характеристиками:
-- он создается "толпой" (crowdsourcing), ибо в нем заинтересованы поставщики. Вот они и пополняют каталог.
-- данные в нем предварительно аудированы (prequalified). Ибо толпяное качество данных мало кого устраивает. Аудитом занимается поставщик каталога.
Финансовые модели поставщиков каталогов сложны, ибо каталоги сложны и тем самым дороги, а платить за них должен непонятно кто. И главное -- каталоги должны быть созданы по стандартам, которые используют потребители и поставщики информации о каталогизированных серверов. Поэтому создание каталогов сегодня является высокорисковым предпринятием, прибыльность его сомнительна, хлопоты высоки, а выгоды сводятся к уменьшению номенклатуры продукции и увеличению конкуренции поставщиков -- так что заинтересованы в каталогах не только потребители, но и поставщики, но не все потребители и не все поставщики (особенно в российских условиях). Не будем пока обсуждать "кому выгодны эти ваши каталоги" или "кто будет этими вашими каталогами пользоваться". Тут проблемы, которые решаются не только технологически, но и организационно. Единственное, что можно сказать, так это обычно прямое руководство со стороны бизнес-менеджеров проектами по созданию каталогов, ибо отдать эту задачу айтишникам не удается. Каталоги нужны не айтишникам, каталоги нужны бизнесменам -- и им это очень трудно, ибо требует co-opetition (сотрудничества-конкуренции в одном флаконе). Капиталистические ёжики плачут, но упорно взбираются на этот каталоговый кактус -- с весьма переменным успехом.
Тем не менее, за последние несколько лет в области технологии произошли существеннейшие изменения (и речь идет не только о том, что над каталогами можно надстраивать электронную торговлю и делать автоматизацию сделок). Современная (т.е. семантическая/онтологическая) айтишная технология позволяет говорить об облегчении организационных задач, более внятно обеспечивая выгоды каталогов для разных участников этих организационных инициатив, раскиданных по разным стадиям жизненного цикла той отрасли, для которой создается каталог (обычно это отраслевые инициативы).
Технологии каталогизации бурно развиваются, а даны они нам не в ощущениях, а в стандартах. Т.е. организационные договоренности продолжаются технологическими договоренностями: договоренностями по стандартам.
Стандартов для построения и использования каталогов -- море. Вернее, не море, а почти как термин употребляемое "болото" (standard quagmire). Эти стандарты касаются:
-- договорки представления информации о продукте, причем используемой на протяжении всего жизненного цикла (от чертежа и инструкции по монтажу через инструкцию по эксплуатации, данные для периодического тестирования, плюс инструкции по демонтажу и безопасному уничтожению. Фотографии, видеофильмы и прочая медиа-информация приветствуются наряду с данными моделирования, обоснованиями безопасности, ссылками на стандарты и т.д.). Тут модны современные протоколы STEP (прежде всего PLCS, он же AP239 из ISO10303), ISO 15926.
-- договорки представления информации о стороне (адрес поставщика-завода, адрес посредника-от-которого-цена и т.д.). Тут не все просто, но и не очень сложно: проблемы те же, что знакомы любым айтишникам. Никакой особой специфики.
-- договорками о терминологии (словари). Излагать мысли желательно в терминах каких-то глобальных идентификаторов, к которым есть определения. Ибо слово "температура" может означать что угодно -- и интересно, какую именно вы температуру, в какой момент времени с какими допущениями имели ввиду. Тем самым снимаются коллизии типа "темп.макс." и "темп.предельн." и "tmax". Беда в том, что разные тусовки делают для себя разные словари. Китайская тусовка китайский словарь, а турецкая -- турецкий. Что делать с двумя разными словарями обычно непонятно. На эту тему конкурируют ISO 22745 в части oETD и ISO 15926 в части RDL.
-- договорками о классах продукции (классификаторы). Если у вас насос, то это совсем не плита железобетонная. Очень удобно для многих целей. Беда в том, что для разных целей существуют разные классификаторы. Тем не менее, классификаторы круче, чем словари. Классификаторы -- это таксономия, построенная над словарём. Конкурируют всякие "национальные системы классификации", NATO USA H2, ISO 15926 часть четвертая.
-- договорками об ограничениях и связях между элементами данных ("семантика"). Тут ISO 15926 (и отраслевые решения, типа IFC/BIM в домостроительстве).
-- договорками о форматах обмена информацией (тут есть поразительное множество вариантов -- от excel-файлов до хитрых XML схем). Сюда же можно отнести способ запроса информации -- например, выдать SQL-запрос или SPARQL-запрос (почувствуйте разницу!). ISO 29002, ISO 15926-9.
Если вас интересует каталог "для всего жизненного цикла", то у вас начнутся сложности от разнообразия договорок. Прежде всего нам нужно будет различить:
-- договорка о терминологии -- это словари (dictionary, vocabulary). Это самая слабая формализация, оставляющая огромный простор для ошибок при автоматизированной обработке информации и минимизирующая возможности для обработки (но все одно лучше "просто текста со слуха").
-- договорка о классификаторе -- классификатор сам строится как словарь, но при этом указываются иерархические связи между классами (дерево). Иногда этот словарь+классификатор называют таксономией. Это уже много лучше и формальней. Вы сразу много что можете сказать о классифицированном объекте, в отличие от объекта, про который вы можете сказать лишь то, что он есть в словаре.
-- договорка об ограничениях и связах между элементами данных означает то, что вы хотите онтологию. Это словарь+классификатор+другие (неиерархические) связи+разные правила (например, запрещающие множественную классификацию).
Эти договорки существенно различаются, но при создании каталога вам придется с ними разобраться:
-- если вы делаете "каталог для САПР" (комплектующие), то вас интересует онтология. Информация разная, САПРЫ умеют ее обрабатывать, PDM/PLM поддерживать, конструкторы и проектанты любопытны.
-- если вы делаете "каталог для ERP" (предметы поставки), то вас интересует главным образом словарь, и иногда таксономия.
-- если вы пытаетесь объять необъятное (то есть пробежаться по жизненному циклу и сделать "каталог для всех"), то вас интересует самая широкая договорка, и меньше чем онтологией вы вряд ли обойдетесь.
Онтологическая интеграция данных:
На картинке показано, что интеграция данных для малого числа участников может быть "традиционной" -- но при большом числе участников трудности будут нарастать экспоненциально: всем будет нужно разное, коллизии с омонимами и синонимами будут наступать чаще и вам придется либо экспоненциально наращивать время на борьбу с трудностями, либо переходить на онтологические (семантические) технологии, предусматривающие явное формулирование дополнительных связей и правил-ограничений.
Все эти договорки влияют на реализацию традиционных операций по работе с каталогом:
-- характеризации, заключающиеся в определении характеристик типа продуктов (но не их значений!). Вы делаете "пустографку", для "всех насосов" или "всех легкоплавких припоев".
-- идентификации, заключающиеся в заполнении значений характеристик типа продуктов для конкретного продукта. То есть вы определяете, что данный вид насосов весит 5кг и качает 80л/мин, при значении "сила воли" 3 мотивационных единицы.
-- классификации, заключающаяся в присвоении класса из какой-то иерархии (таксономии, "дерева", набора "товарных групп" и т.д.).
-- кодификации, заключающаяся в присвоении кода. Это вовсе не классификация, ибо внутри кода могут быть значения от 0 классификаторов (если код, например, сводится к очередному порядковому номеру) до нескольких разных классификаторов.
Обратите внимание, что ни о каких экземплярах тут речь не идет: пока говорим только о каталоге. Если мы будем рассматривать supply chain (всю цепочку поставок), то там речь пойдет и об экземплярах. А пока мы тут говорим только о каталогах, то есть классах. Онтологическое замечание (оговорюсь: мало кто это место понимает, если три раза не ткнуть носом): даже когда вы пишете строчку по итогам идентификации "насос XAYBZC-817263 весом 5кг черный освященный", то это все равно класс (как и "насосы", в которых вес еще не проставлен, а класс представлен "пустографкой" после характеризации). Класс, ибо его членами являются много-много реальных выпущенных насосов указанного типа, веса, цвета и специальных для некоторых категорий клиентов характеристик, различающихся серийными номерами (которые являются уже экземплярами, а не классами). Контрольная шутка: вы хотите летать на самолете, или на классе самолета (т.е. спецификации самолета)?
Вопрос важный, ибо путаница этих терминов и определений идет даже в некоторых специализированных стандартах, а реализаторам каталога все эти операции и договорки нужно поддерживать конкретными программными кодами, текстами регламентов и путаницу желательно устранить.