Без заголовка

Не вполне согласен с Вашим видением формирования Промнета (Industrial Network - IndiNet :-). Если я правильно понял, Вы полагаете, что он может вырасти из каталогов промышленной продукции или спецификаций услуг (в котором модели могут встречаться или не встречаться). Но ведь этот инструмент (каталоги), если хотите - лишь костыль для того, чтобы было проще очерчивать финансовый контур компании (на котором каждый элемент каталога есть ни что иное, как точка на контуре, от которой можно протянуть стрелочку поставок, заключив определенный контракт). Т.е. если я не имею каталога продукции\услуг - меня просто нет как юр.лица. ИТОГО, мотивация к тому, чтобы это формализовать - очевидна, но тут никто не отменял "использование сникерса в качестве замазки для чума". Таким образом, если отталкиваться от каталогов пром.продукции и сервисов, получающаяся картинка добавленной стоимости (и сборки) начинает запутываться, и для навигации в ней необходим своего рода "браузер", который бы говорил о том, какой элемент можно куда вставить, и имеет ли он вообще хоть какую-то полезность для бизнес- или технологической модели предприятия. Что из этого вытекает? Что ситуация по идее должна быть ровно обратной. Ни где-то в таких сетях должны находиться 3Д модели (как частный случай функциональных моделей), а такие сети могут только и строиться на протоколах, описывающих функциональные модели, причем правильнее всего это делать было бы не в точке (покупки, поставки), а в контексте всего жизненного цикла (что изменяет подход к документированию процесса сборки, обслуживания или демонтажа, делая его также моделецентричным). ИМХО, мастер-данные это как раз функциональные (полные) описания моделей товаров и сервисов. И стандарт, который сможет говорить об их полноте (чтобы соответствующий "браузер" мог инкорпорировать эти данные в "собираемое" устройство, причем тут безразлично, идет ли речь о технической сборке, или о сборке экономической - это просто две разных проекции), фактически и будет новым TCP/IP. А пром.каталоги, как и ERP-компоненты, направленные на организационную синхронизацию (сроки и деньги, ответственность и сервис), должны быть просто выразимы в этом стандарте, чтобы "браузер" мог их понимать.