Этой статьей я хочу объявить об опубликовании в открытом доступе для просмотра и обсуждения начальных попыток реализации моей идеи создания общей базы знаний в области информационного моделирования или, если позволите, «Википедии» про BIM ТИМ. Идея, собственно, не нова. База знаний на базе Wiki-движка существует. Созданная Сергеем Волковым Information Modelling Body of Knowledge (IMBOK) предназначена именно для этих целей. Когда я узнал об этом из интервью Сергея Игорю Рогачёву, я подумал, что это послужит достоверным источником развития моей компетенции в качестве BIM-специалиста, так как помимо наличия как таковой информации я всегда искал именно структурированные данные, логически связанные между собой категории и определения, коим и мог бы послужить данный сайт. Но, к огромному сожалению, база знаний не развивается…
Предпосылки создания единой базы знаний BIM
Изучая методы информационного моделирования в Autodesk Revit, я всегда получал некий конечный результат. Давно все уже умеют моделировать красивые семейства. И даже адаптируемые компоненты. Ой, а что это тут? Опять дубликаты в ФОП… А тут параметр по-другому снова назвал. Не туда вписал маркировку. Лень пролистывать BIM-стандарт. К тому же мы договорились недавно по-другому именовать виды с коллегами. До сих пор изменения не внесли в инструкцию! Это семейство мне не нравится. Да и различается оно от вот этого. Лично меня это выбивает из темпа и демотивирует на работу, если хоть немного задача касается однообразности. Пусть это и мой перфекционизм капризничает, хоть и все работает. Говорят, что нечего трогать, если все работает.
Но я знал, что в плане информационной составляющей и соответствия модели прописанным нормам действующей нормативной технической документации, это никуда не годится, ведь я же не трехмерные мультики рисую. Информационная модель преследует цель приближения к реальному объекту. Другими словами, она должна являться цифровым двойником реального объекта и в нашем случае строительного изделия. И не просто на мгновение, а на протяжении периода существования реального объекта. Еще большая «отдача» от таких цифровых данных может быть тогда и только тогда, когда информационная модель будет полна, достоверна, а самое важное конвертируема. Ну а таких объектов много. Ну и разработчиков много. А что мешает прийти к единым правилам? Вот только не говорите мне про нынешние технические нормы, прошу…
Основными проблемами при разработке информационной модели являлись следующие (на примере Autodesk Revit):
- Отсутствие определенных и единых правил именования элементов для компактной структуризации, сортировки и идентификации участниками процесса;
- Разнородность шаблонов, несогласованность внесения изменений, применение различных методов моделирования;
- Проблема с ориентированием в процессе моделирования в применении тех или иных инструментов и методов моделирования, создании контента и инструкций;
- Неполная вовлеченность потенциала программы для решения поставленных задач, применение возможностей программы в ошибочном ключе;
- Наличие негативной и избыточной информативности в экосистеме модели (информационный мусор);
- Отсутствие эффективного поддержания профессиональной компетенции участников процесса, обмена информацией;
- Использование большого количества разнородных программ и сервисов для обеспечения информационного моделирования, в том числе и хранения центральной библиотеки;
- Возникающие сложности в сохранности налаженной совместной работы при расширении круга участников процесса;
- Необходимость конвертируемости всех данных, их универсальности в применении и т.д.
Профессиональное сообщество в течение более десятка лет создало огромную массу контента и накопила знания в форумах Autodesk Community Russia, сайте DWG.ru, большом количестве Telegram-чатов и других социальных сетях. Как высказался коллега, большинство вопросов с предложенными решениями в них буквально увековечены, так как эти веб-страницы посещают специалисты, спустя десяток лет. Далее уже примененные на практике знания и опыт организациями и профессионалами в области информационного моделирования подарили всем заинтересованным шаблоны, скрипты, типовой BIM-стандарт и другие бесценные практические наработки. Не имея в этот период профессионального отношения к BIM-деятельности, просто за интерес, я старался следить за событиями и контентом тех личностей, которые протоптали все эти тернистые тропы по освоению технологии информационного моделирования, знаниями которых пользуются все специалисты. Очень ценю и благодарен за этот безмерный труд этим людям!
Большая часть всех этих знаний заполнила для меня пробелы в знаниях понимания технологии информационного моделирования, в частности основанная на Autodesk Revit. Но лично для меня, дотошного, оставались вопросы, которые были нужны, по всей видимости, только мне. Например, почему я не могу поменять основу размещения у семейства. Вернее, какие есть еще основы. Или чем отличается категория обобщенной модели на основе стены от категории окна. Или почему так много шаблонов семейств, если категория мебели одинакова с обобщенной моделью по функционированию. Или что такое вид в Revit – семейство или совсем другая сущность? На некоторые вопросы подобного рода знатоки мне отвечали, что мне это незачем и какая в этом разница, если все функционирует, как нужно. Поэтому на некоторые из этих вопросов я стал искать ответы самостоятельно, так как ответы было порой сложно, а то и невозможно найти в самом справочнике Revit.
Итак, разбирая BIM-стандарт Autodesk, и дойдя до раздела о семействах, я вдруг остановился на категориях семейств, придавая этому немалое значение. Тогда еще я заметил, что не только назначение категории семейству меняет его поведение в среде проекта: все зависит также и от шаблона, в котором семейство разработано. Но взаимосвязь между параметрами и свойствами всех этих составляющих я не мог закрепить только в памяти и в блокноте. И как оказалось, даже в xls-формате. А дальнейший перенос всего этого недоразумения в SQL-сервер создал еще больше преград для работы с данными.
Кто-то скажет, что это бесполезное молочение воды. Но только таким способом я смог лучше понять устройство среды моделирования в Revit. Далее по моей просьбе в вопросе о категориях в сообществе со мной поделились сводной таблицей этих категорий семейств и вдобавок групп параметров, типов данных. Сначала я не очень понимал, что это. Какие-то названия на латинице. В последствии я обнаружил, что это извлеченные данные из Revit API. Для меня это было чуждо, так как в процессе изучения я не затрагивал программирование и даже Dynamo. Далее я открыл для себя плагин RevitLookup и только тогда для меня начала проясняться картина устройства программы.
Так как Excel очевидным образом являлся, мягко говоря, убогим способом сбора таких разветвленных данных, а изучение языков программирования было не настолько оправдано для решения проблемы. С учетом предопределения удобства планируемой среды сбора данных для других участников, я стал искать другие решения. Мысль о создании сайта требовало специфических знаний, на которые не было времени и мотивации. Но был вариант более простого способа на базе веб-приложений. Среди них я рассматривал MediaWiki, DokuWiki, MediaWiki, WackoWiki, TikiWiki. Даже Вики-хостинг Fandom! Смешно, на первый взгляд. Но смешнее тот факт, что школьники собирают колоссальных масштабов энциклопедии на аниме-сериалы, японскую мангу и культовые игры. Да что там говорить – Луркоморье при всей своей абсурдности содержания имеет огромные массивы иерархических данных из страниц, разделенных на множество категорий.
Но все перечисленные движки были по тем или иным причинам не подходящие. Даже приглядывался к PowerShell, не до конца поняв, что с этим делать. Затем мысль о создании сайта с применением фреймворков, которые позволили бы как-то организовать работу с базами данных с приятной визуализацией (видел подобное на основе Angular, React). Но кроме отсутствия тех же ресурсов, взгляд на перспективу выявлял сложности в поддержке такого сайта. Ну а создание сайта в конструкторах или базы знаний в сервисах Yandex или того же Битрикс24 были очевидным образом не устойчивы помимо прочих минусов.
Совершенно случайно, среди всего того, что мне всегда попадалось при поиске, я обнаружил для себя Notion.
Лучшее решение для базы знаний
Ознакомившись с возможностями Notion, я понял, что это именно то, что я так долго искал, надоедая всем знакомым. Хоть и этот сервис имеет обзоры в сети, в которых тинейджеры рассказывают об использовании сие инструмента для красивого оформления с анимированными иконками перечня задач, которые надо сделать к лету, и ведения мемуаров тленной жизни, остальные обзорщики рассматривали сервис как инструмент эффективного управления командой, начиная от накопления информации до делегирования задач и обсуждения совместных проектов.
Далее я постараюсь выделить все преимущества и недостатки Notion с сопоставлением преследуемых целей:
Преимущества:
1. Универсальный и простой язык разметки Markdown
Имеющийся синтаксис разметки текста с всплывающими окнами инструментов показался намного проще того же Wiki, так как именно дизайн интерфейса позволил легко справляться с созданием контента.
2. Возможность экспорта/импорта данных
Вернее говоря, каждая созданная страница в системе может быть экспортирована в xls-формат, отредактирована по усмотрению, и снова импортирована. Так как в системе нет удобных инструментов для пакетной обработки данных, этот вариант полностью компенсирует данный недостаток. Именно таким способом я создал тысячи наименований, на основе которых были автоматически созданы веб-страницы, что исключило ручную обработку.
3. Универсальные базы данных
Складывается ощущение, что разработчики горели именно этой идеей при создании платформы. Пользователи больше отмечают дизайн в большинстве случаев. Но, на мой взгляд, работа с базами данных тут в десятки раз удобнее и практичнее, чем в других системах (имею ввиду PhpMyAdmin и даже Microsoft Access). Дело в том, что создавая таблицу на странице, ее можно перевести в базу данных. После преобразования образуется также ключевой столбец, ячейки в которых превращаются в веб-страницы. В каждой строке соответственно данные для этих наименований являются атрибутами этих страниц. Такие базы данных можно экспортировать в xls-формат, а также в SQL. Данный факт не испепелил во мне надежду того, что созданные наработки не созданы зря – импорт существующих данных преобразовался в системе, где далее я продолжил их обработку.
В плане дизайна и визуализации данных есть еще один большой плюс, за который любят Notion – базы данных могут быть представлены в виде календарей, канбанов, списков и галерей. Напоминает Revit, в котором можно манипулировать семействами как на видах, так и в спецификациях, в разных представлениях. Как уже можете догадываться, имеет смысл для преобразования в тот же календарь в том случае, если имеется тип данных «Дата». Типы данных знакомы всем – число, дата, текст, список, булево значение, связи и т.д.
4. Создание связей
Следом отмечу данную возможность, что является обязательным условием для создания любой базы знаний. Связи могут быть как типами данных в базах данных, так и создаваться в качестве отдельных гиперссылок в содержаниях страниц. Так можно связывать базы данных и страницы рабочего пространства. Но кроме этого типы данных со связями могут быть формулированы для создания определенных запросов. Мне известно, что некоторые так ведут бухгалтерию в системе, создавая фильтры на определенные данные да еще и привязывая к ним приглашенных пользователей, участников рабочего пространства.
5. Notion API
Notion есть SAAS-платформа для управления документами. Собственно, с перспективой на будущее это дает огромный потенциал для интеграции и синхронизации со сторонними сервисами. Являясь хранилищем данных он может служить источником информации, которая в первую очередь будет структурирована. Помимо возможности создания интеграций, уже имеется синхронизация данных с такими сервисами как Slack, Trello, GitHub, Drive, DropBox и многими другими.
6. Удобство для редакторов и пользователей
И снова отмечу удобный интерфейс и инвентарь. Создаваемые страницы по своему визуальному виду имеют достаточно широкие возможности. Здесь, конечно, нет динамических шаблонных элементов или анимированных блоков, как в некоторых других конструкторах сайтов, как Wix или Tilda, но, надо сказать, что в Notion и нет ничего лишнего. Все предоставляемое пользователю создано оптимальным образом.
Бесплатный тариф позволяет пригласить в роли редакторов несколько пользователей, хоть и имеет ограничения на вложенные файлы в 5 МБайт. Для просмотра и обсуждения для незарегистрированных пользователей после публикации страницы в сети ограничений нет. Каждая страница имеет возможность обсуждения и также может быть настроена по доступности.
Недавно появилась возможность структуризации страниц в режиме Wiki. Преобразование страниц в этот режим позволяет создавать страничную иерархию и вставляет поле для поиска по всей базе знаний, что также создает комфорт в пользовании и ориентировании. Но функционал этого режима состоит больше в удобстве администрирования и контроля актуальности страниц администраторами.
Все перечисленные возможности я видел также в MediaWiki. Но если в Notion все возможности уже встроены в систему и не требуют специфических навыков программирования, то в Wiki для того, чтобы свести пару строк в таблицу с цветными строками, надо было лезть в код (разметку). Естественно, и данная платформа состоит из кода. Но имеющиеся инструменты исключают необходимость редактору разбираться в написании кода, хоть и в Notion есть и такая возможность.
По страницам ведется история изменений и версионность. Имеется также аналитика.
7. Внедренный искусственный интеллект
Кажись, больше всего на это надо надеяться с уже существующим контентом. Notion «дружит» с нашумевшим ChatGPT. Да, на бесплатном тарифе он может высказать свое цифровое мнение о написанном тексте, выдать предложения и идеи. А вот как он сможет собирать из материалов модели, как изображения в MidJourney, я пока не представляю.
Недостатки:
1. Все на английском
Для кого-то это может быть проблемой, так как язык системы не имеет возможности отображения интерфейса на русском языке. Но, я считаю, что это пустяк, с учетом того, что по традиции многие осваивали Adobe Photoshop, Premiere Pro и Autodesk 3ds Max исключительно на английском языке (ну, кроме меня). С моим уровнем А1 английского не так уж и сложно было разобраться в системе.
2. Сторонний сервер
Все, что создано в рабочем пространстве, храниться только на серверах разработчиков Notion. Если Wiki-движок можно развернуть на собственном домене, взяв сам каркас, то собственником данных в Notion стать не удастся. Если только извлечь все в SQL, например, а потом перерабатывать при импорте в свою платформу.
Во-первых, это влияет на быстродействие. На бесплатном тарифе скорость может быть недостаточная, особенно, если тимспейс массивен. Молчу уже о том, что иногда могут происходить и баги. Во избежания этого разработчики предлагают десктоп-версию сервиса (также бесплатно).
Во-вторых, не являясь полностью владельцем своих данных, будучи живущим в нашей стране, по причине «сложившегося отношения» к россиянам, можно столкнуться с ограничениями от администраторов в любой непредвиденный момент. Например, при попытке изменения роли пользователю, локализируемого в России, был выдан отказ, по именно этой причине локализации. Дискриминация и здесь, да. Хорошо хоть не отобрали рабочее пространство!
3. Бесплатный тариф щедр до некоторой поры
Как выше писал, бесплатный тариф позволяет очень многое. Но если нужно больше 5 приглашенных и зарегистрированных в тимспейс пользователей, которым нужно будет давать права редактора, то бесплатный тариф на этом ограничивается. Также есть ограничение на хранение файлов. Тарифы, естественно, оплачиваются в «валюте» посредством иностранных платежных систем. Ну а самый дорогой тариф, помимо того, что дает полную власть над функционалом системы, так еще и заручается технической поддержкой разработчиков с персональным подходом к пользователю. Возможно, по капризу клиента они могут добавить и другие плюшки. Я не пробовал, точно не знаю.
4. Ограничения по пакетной обработке данных
Как и писал выше, инструменты массового редактирования в самой системе не очень удобны. Иногда слетает курсор и ввод значения происходит совсем в другой ячейке. Можно выделить строки и вписать значения во все необходимые ячейки, предварительно отфильтровав таблицу. Но если очень много строк, лучше извлечь и отредактировать в стороннем сервисе или программном обеспечении, потому что манипуляции с большими базами данных приводят к торможениям.
Так а зачем все это?
Пусть я из тех, кто любит изобретать велосипед. Но, в первую очередь, это базу знаний я создаю для себя. Повторюсь, тот же справочник Autodesk Revit не удовлетворял меня по той причине, что там много строчной текстовой информации, а не табличной, которая бы позволила видеть взаимосвязь между элементами. Да, можно было даже найти страницу на определенную категорию семейства, в котором вот так вот таблично расписан каждый параметр. Но, во-первых, поиском мне это обнаружить никак не удавалось. А, во-вторых, если я хотел знать, где еще применен определенный встроенный параметр, то также не мог позволить себе такую радость. Поиск в этом справочнике было странствием с родительской страницы до вложенных вниз по списку до тех пор, пока не найдется то, что нужно. Притом, это нужное было распределено кусками во всех этих страницах. В Notion же я могу все свести к одному знаменателю и связать все между собой.
Если даже и контент во многом будет взят из этого справочника или BIM-стандарта Development Systems, например, он будет структурирован именно так, как нужно для лучшего понимания устройства Revit. Кто-то и говорил, что я глубоко копаю. Но тот же Микеланджело Буонарроти достиг огромных высот в живописном искусстве, получив доступ к моргу, чтобы изучать человеческое тело на трупах. На мой взгляд, только полная картина технического устройства Revit даст место новым идеям и творчеству.
Кроме того, накопленный контент требует систематизации. По моему мнению, это можно будет создать в Notion, убрав все лишнее и оставив конечное и нужное, распределив все по «полочкам».
Заключение
Я не компания… Я не Architectural Bureau… Пока что… SEV KARAP есть мой личный бренд (а назвал так, потому что так захотелось). К чему я это? Я не обладаю достаточными ресурсами для полноценной реализации этой идеи. По крайней мере, именно в данный момент. Если это будет интересно многим, то возможно несколько сценариев развития:
- Среди профессионального сообщества появятся коллеги, которые разделят со мной идею создания общей базы знаний. DATABAZ должна быть открытой и бесплатной в этом случае и ее наполнение и ведение будет на добровольных началах. Я буду только рад обсуждению по этому поводу и того, каким путем должна быть ее реализация. Я не проводил опрос среди сообщества специалистов, но многие говорили, что с охотой бы пользовались контентом, тем более, если так детально были бы расписаны составляющие Revit.
- То, что такая база знаний имеет пользу и нужна, у меня нет сомнений. Но если мне придется остаться одному, что очень вероятно, то я продолжу ведение DATABAZ самостоятельно в закрытой форме до тех пор, пока от его содержания не будет действительной пользы и отдачи для BIM-специалиста. Буду наполнять параллельно с медиаконтентом в целях обучения. Но если и произойдет, что она станет более стоящей, не обещаю, что она будет бесплатна для доступа.
- Идея приглянется хорошей, но заинтересованные создадут что-то подобное на стороне для собственных, возможно, коммерческих целей. Ради Бога, я не против. По праву, это было бы справедливо.
Но, вместе с тем, я делюсь этой идеей потому, что кроме предложений на словах, я могу продемонстрировать инициативу. А еще может возникнуть мысль, что я чужими руками хочу создать себе ресурс. Это исключено, потому что BIM-сообщество очень тесное, а я дорожу репутацией. В том числе, если мой контент как повторение содержит в себе ранее предложенные решения, идеи, я всегда указываю автора или упоминаю, что это не мои мысли. Если не указываю конкретно личность, то прошу прощения заранее – значит я не обнаруживал первоисточник.
Насколько мне известно, Википедия в большей своей части ведется и по сей день на добровольном начале. Поэтому, мое дело в этом случае – предложить.
Пока что публикую и оставляю ссылку на DATABAZ. Актуальную ссылку всегда можно будет взять в моем сообществе (она может быть изменена). Жду реакции.
Удачи, коллега!
#база знаний #bim #цифровизация #информационное моделирование #Notion