Обсуждение

> Контрольная шутка: вы хотите летать на самолете, или на классе самолета (т.е. спецификации самолета)? эээ... ответ скорее всего будет "я хочу летать на Боинге-737, безотносительно его серийного номера". это как, на самолёте или на классе?

эээ, всё равно не помогает. у спецификации тоже есть серийный номер.

ну да, я как бы это и хотел. самое обидное, что в ОО дизайне есть своя устоявшаяся терминология (класс, инстанс экземпляр класса), в entity-relationship modeling - своя, а в онтологии опять своя, и всегда надо чётко понимать, каким "языком" мы говорим.

У меня вопрос лишь относительно по теме. Мы сейчас делаем стартап, одной из функций которого является примитивная база знаний. Соответственно, эти знания нужно каким-то образом систематизировать. Большинство существующих сервисов обходятся для этого фолксономией, таксономией или их смешением. Но недостатки этих подходов очень велики. Придумало ли человечество что-то новое в этом направлении? Стартап у нас для обычных людей, поэтому понятно, что подход должен быть супер простым и понятным для пользователей, а уже во вторую очередь эффективным (но эффективнее, чем распространенные подходы). Пока лучшее что у нас получается в прототипах -- плоская структура данных, но небольшие иерархии в тегах. Куда можно еще двинуться?

ISO 15926? На первый взгляд он все-таки об обмене данными, а не об их классификации, нет? Ну и это все-таки для промышленных систем. У нас достаточно неформальный формат данных. Можно сказать, что задача сводится к классификации небольших текстовых заметок и созданию удобного инструмента для их выборки. А намекать не бойтесь, я потому Вам и написал, что знаю что можете подкинуть пищи для мозгов за счет широкого кругозора - готового решения и не жду.

Вы здесь, ИМХО, обосновали "инфраструктурную" значимость онтологизации\таксономизации коммуникационных процессов в больших системах. А именно, если брать в расчет корпоративную систему - это все не имеет смысла (за редкими исключениями в виде сверхбольших систем вроде Росатома или РЖД), а вот если уже национальную - то имеет (даст эффект экономии) (если я правильно понимаю размерность на графике). И именно отсюда выводится стандартизуемость - целесообразность развития системы национальных стандартов, фиксирующих "договорки". Пойдем дальше (не зацикливаясь на стандартах), и спросим, если издержки на создание этих "умных" каталогов несоразмерны по отношению к отдельным компаниям, но хороши по отношению к национальному уровню, не гоже ли посоветовать СРО (как минимум) или государству (в лице ответственных ведомств, как максимум) провести данную работу и предоставить предприятиям "сервис" - этот самый Промнет? Интересно ваше мнение в разрезе - правильно\не правильно, реализуемо\утопично?

Я там в личку написал про свой интерес к вашему стартапу. Простите за назойливость :-)

Вы хотите летать на самолете, у которого есть серийный номер, но вам неважно его значение. "Неважно" -- это не значит, что его нет. "Головой залез в буфет, говорит, что дома нет" у онтологов не проходит.

Серийный номер спецификации -- это не серийный номер самолета. Есть class, есть class-of-class, в конце концов, есть powertypes (metaclass). Вы правильно демонстрируете, что легко запутаться, если вестись на внешние признаки, а не суть (онтология -- это вопрошание о сути!). Я призываю тут быть осторожным, у новичков много тут ошибок. Скоро будет много-много модельеров, которые пришли из инженеров, и мне пока непонятно, как им все это объяснять.

Это, увы, такие вещи, что "по телефону не лечатся". Выбор представления данных как внутреннего (хранение), так и внешнего (нотация) существеннейшим образом зависит от того, какие у вас предполагаются операции с данными. Так что боюсь даже намекать на ответ, ибо для таких намеков нужно хорошо изучить предметную область вашего приложения и сам замысел. Мы сами тупо ориентируемся на ISO 15926, ибо надеемся на появление большого количества поддерживающих этот стандарт промышленных движков.

А еще онтологи говорят, что легче научить инженера, нежели переучить объект-ориентированного программиста... Вспомниается пошлая шутка, что женщин не берут в армию, потому как они неверно выполняют команду "ложись"...

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

Сайта еще нет. Мы взялись за этот проект совсем недавно. Изначально мы собирались сделать инструмент для управления задачами, который был бы удобен нам. За основу взяли банальный GTD к которому до сих пор нет ни одной адекватной веб-реализации. Все делают какие-то костыльные реализации таскинга из GTD, но ни у кого нет не менее важных частей -- базы знаний, обзора с большей высоты, инструментов для структуризации офлайновой инфы. Это нас бесило. В процессе работы мы выяснили, что было бы круто автоматом класть в инбокс всю инфу, которая только поступает к человеку, чтобы организовать разбор в одном месте. Тут естественно возникла проблема как эту инфу представить. Мы пришли к выводу, что человек все равно идентифицирует объекты не по сложным формальным структурам, а по их простому строчному описанию. То есть любой, даже сильно формализованный объект можно преобразовать к строке по которой будет понятно о чем идет речь. Этим мы и решили заняться. Построить агрегатор метаинформации. Свести все к чему-то вроде дублинского ядра (его я нашел уже после того, как эта идея нас посетила). А как ложатся на это задачи? Да очень просто. По сути система таск-менеджмента это тоже система, оперирующая мета-информацией. Реальное же описание хранится где-то еще, или у вас в голове. В принципе все стало выстраиваться в стройную систему, если бы не одно но -- объем данных настолько велик, что пока слабо представляются способы их систематизации и поиска, а без этого система не жилец, так как это основная ее функция. Вот почему мы и озадачились поиском подходящих механизмов. В частности механизм тегов здесь применим весьма условно -- их будет настолько много, что работа с ними превратится в ад. А если у человека недостаточно развита культура тегования, то система станет для него и вовсе бесполезной. Поэтому мы и ищем какие-то альтернативы. Есть идеи?

Идей масса, т.к. в этом ключе я и сам изрядное количество лет уже думаю. А Вы вообще где обитаетесь? Если в Москве или Питере - можно было бы пересечься и обсудить...

Не-а, мы в Череповце. Но есть же скайп: proxiper :)

Ну тогда коротко здесь (скайп возможен - но я в офисе, поэтому не очень удобно говорить). GTD сам по себе (как подход) основан на том, что необходимо первым делом идентифицировать задачу (или если правильнее - объект\возможность воздействия - с точки зрения того, какие результаты вообще возможны). Результат этой идентификации - модель объекта, над которым Вы совершаете воздействие. Поэтому последовательный (глубокий) GTD неизбежно моделецентричен - зря Вы ушли от графических способов изложения - сильно упрощают навигацию внутри модели. Ну да ладно. Расскажу Вам мое видение. Так вот, если на вопрос идентификации отвечать моделью (самой простой - признаки, активность, связи), то само сабой - категории лучше брать из справочника. Каждая категория увязывается с другими фолксономией и семантикой совместного использования. Т.е. выбирать ее лучше не из списка или иерархии, а тыкаясь мышкой в "кружочек", или пролистывая "карту" связанных кружочков. Синтаксисов может быть превеликое множество. Самое главное - результат "тыканий" - это должна быть сущность, которая влияет на веса и отображаемые взаимосвязи (близость) категорий. И эта же сущность превращается в задачу, под которую собираются другие сущности (также классифицируемые, иногда делают несколько "срезов" - для разных стадий жц задачи). В моих экспериментах получалось использовать не просто категории, а категории, указывая отношение к ним. Например, в пространстве целей, указание тега "Семья" используется в отношении "членOf", а тега - "Дети" с отношением "поОтношениюК" и указание субъекта (например, мои). И тогда можно например, запланировать подарок на день рождения любимой племянницы, автомтаически попадая в контекст ее интересов или линкуя задачу с ней. Удобным тут как правило является 3-4 ходовое уточнение контекста. Т.е. в блок Теги вначале вводится ключевое слово, для него дается контекст (уточнения\близкие значения) с частотами употребления, из контекста выбирается одно (а может быть два-три) наиболее близких, для которых снова строится контекст, уже с возможностью уточнить отношения к этим понятиям. Если тут давать снизу подсказку (что и зачем стоит выбирать), то пользователи научатся работать с инструментом (которые научатся, получат более удобный инструмент, что повысит их интерес к системе). Налицо - возможность создать правильное осмотическое давление для культурных внутрь - для безкультурных и не желающих учиться - в туман. Все это, кстати, можно сделать чисто текстовым (потеряете всего лишь одно измерение), просто надо думать над интерфейсом, чтобы в поле зрения попадало то, что нужно, и не надо было бы листать.

Спасибо за идеи. Штука, конечно, мощная, но я не думаю, что удастся обречь ее в какой-то понятный большинству людей инструмент. Собственно мощный букс семантик веба это подтверждает -- никто не хочет заносить кучу метаинформации при сомнительных выгодах. Тот же GTD подразумевает быстрый разбор - лениво будет людям выходить на категорию по наводкам, да потом еще и отношения задавать. Может быть удастся, конечно, как-то нэтивно это сделать, например тот же "членOf" через привычную иерархию, но тогда не очень понятно чем оно будет отличатся от того, что сейчас уже есть.

> Финансовые модели поставщиков каталогов сложны ... > Не будем пока обсуждать "кому выгодны эти ваши каталоги" или "кто будет этими вашими каталогами пользоваться". Тут проблемы, которые решаются не только технологически, но и организационно. А можно попросить как-нибудь с оказией вернуться к этим вопросам? Потому как про капиталистических ежиков, плачущих взбираясь на кактусы, прикольно читать, но потихоньку появляются валентности и точки, к которым можно было бы эти вопросы прицеплять, но дорожных карт у инициаторов как правило нет, а воззрения наивны до невозможности. Или же, что бы Вы могли посоветовать некоторому абстрактному EPC-подрядчику, у которого есть возможность договориться о коллаборации, и есть даже понимание, что так дальше жить нельзя, но "простой и понятной" картинки светлого будущего (кто и за что платит, кто и как поддерживает штаны, и на что эти штаны можно было бы надеть) не имеется.

Для того же ISO 15926 существует весьма много применений в рамках EPC-подрядчиков. Это и handover между стадиями жизненного цикла, и handover между субподрядчиками, и интеграция разных САПР для создания мегамодели сооружения, и промышленные каталоги комплектующих. Сейчас в США идет семинар по ISO 15926, где как раз компании обмениваются опытом. Некоторые из моих клиентов послали туда представителей, а некоторые слушают этот семинар в Москве в онлайне (хотя отнюдь не всё слышно). Так что я бы посоветовал подрядчику выделять людей на full time, закупать софт и делать конкретные проекты, двигаясь в понимании со всем миром. Как я понял из упомянутого мной семинара, выделенный человек за год профессионализируется. За год, не за неделю или за месяц. Так что сначала получаем в вашем EPC-подрядчике профессионала (за год занятий каким-то из конкретных проектов), а потом уже продолжаем разговор...

Для выделения ресурсов (человеко-год неглупого человека стоит с учетом командировок и накладных пару миллионов рублей), нужна понятная конечная цель и дорожная карта к тому, чтобы туда дойти. Цель - создать пром.каталог, который бы облегчил взаимодействие между строительными подрядчиками и поставщиками - довольно таки интересна. И для того, чтобы на этот процесс выйти, таковое решение можно было бы и получить. В противном случае объяснить, зачем нужен такой профессионал - довольно-таки сложно. Почему я и спрашиваю, есть ли у Вас видение, к чему (ценному для EPC-подрядчика) можно было бы дойти, чтобы выбивать под это ресурсы. Кстати, если есть возможность слушать таковые семинары онлайн, то как и где?