Обсуждение

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

А почему Вами нигде не упоминается связка Protege+OWL? Или она больше для онтологий, а не тезаурусов?

Коль скоро одним из основных источников расхождений в терминологии является перевод документации, мне кажется, не стоит обходить вниманием инструменты, которые используются в индустрии локализации (например, Multiterm) и интегрируются с переводческим ПО. Здесь же рядом находится стандарт ISO 30042 (Systems to manage terminology, knowledge and content -- TermBase eXchange (TBX)), который не так уж и стар (2008 г.), а соответствующий формат TBX де-факто является отраслевым стандартом хранения многоязычных глоссариев.

Это декстопная связка, и её долго нужно допрограммировать до коллективной работы через веб, плюс настраивать модель данных именно на тезаурусную. Хотя всех остальных тоже нужно, но у них значительная часть нужных в корпоративном масштабе функций доступна сразу "из коробки".

Обратите внимание: вы сказали "отраслевой стандарт", но не указали отрасль. И привели перевод документации, как основной источник расхождений -- опять же, это в какой отрасли? Не знаю, какая отрасль у вас, но в других отраслях ведь по-другому :-)

Да уж, с терминологией шутки плохи. Стоило употребить синоним, и уже терминологический конфуз:) Я сказал "в индустрии локализации". Соответственно и стандарт относится к той же отрасли (индустрии) - переводческой (локализационной) :)

Я понимаю :-) Но я писал про такие отрасли, как космическая, атомная энергетика, судостроение и т.д.. В таких масштабах "локализация" -- это совсем не "отрасль", хотя и industry :-)

Соответственно речь идет не о практиках управления терминологией в какой-то отдельной отрасли, а о стандарте, принятом именно в области управления терминологией и близкой к ней области перевода.

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

Ой, мы такими штуками лет 15 назад всерьез занимались! Тогда к сожалению современных стандартов и инструментов в помине не было. Началось с того, что одни и те же слова/термины интерпретировались разными ЛПР по разному. Это удалось победить написав свой внутрифирменный язык, который описал организацию в виде объектов и их взаимодействий между собой. Надо сказать удачно получилось, большинство проблем как рукой сняло. Правда потом другая задача появилась - организационная картина мира меняется, и поддерживать согласованность большой модели оказалось сложнее, чем я предполагал вначале. Эта задержка между изменением реальности и отражением в модели была заметна. Плюс внутренняя политика - так как шла борьба за замалчивание каких то одних терминов и продвижение других, то тезаурус становился скажем так не совсем беспристрастным.

Я читал, что первая экспертная система MYCIN загнулась именно потому, что её не смогли поддерживать: с трудом отладили до сравнимого с врачами уровня на какой-то момент, а через очень быстрое время оказалось, что поддерживать её дороже, чем разрабатывать с нуля (ибо она стала чрезвычайно сложна и запутанна), и знания системы стремительно оказались неадекватными текущему состоянию медицины. Плюнули, и забыли. Многие другие системы загнулись по похожему сценарию: отладка на бровях ночами, а потом загиб по потери актуальности, ибо ночью всем хочется спать. Конечно, к терминологической поддержке (а также управлению требованиями и любому другому конфигурационному менеджменту) это также относится в полной мере. Кстати, одну из атомных станций в США закрыли ровно потому, что они потеряли контроль конфигурации, и дальшейшая эксплуатация станции "вслепую" (когда нет уверенности, соответствуют ли чертежи реально установленному оборудованию) была сочтена опасной.

Я встречал у америкосов одно интересное решение построения и согласования объектной модели на основе анализа корпуса текстов -- то есть практически автоматически. Правда оно по моему так и не дошло до масс

У нас это тут: http://dot15926.livejournal.com/33691.html

Есть подвижки?

Конечно :-)

Ничего не знаю о корпоративных нуждах, но все же: почему же Protege+OWL — десктопная связка? OWL (web ontology language) сам по себе никак не привязан к десктопу, и Protege с вебом дружит. Кроме WebProtege для совместной работы над OWL онтологиями есть еще как минимум http://knoodl.com/ui/home.html, это навскидку.

А почему вы сразу не предлагаете какой-нибудь drupal использовать, или alfresco, или вообще с уровня PHP всё написать? Известно же, что в программировании любую программу можно на любой платформе (и даже на любом языке, хоть на ассемблере) написать, а свои запросы инженеры и менеджеры пусть на SPARQL пишут, или на SQL -- разберутся, не маленькие... Я несколько раз смотрел глазками, как люди пробуют в больших компаниях работать с Protege, даже и не с терминологиями. Ничего хорошего не увидел. Это как суп из топора: к этому топору нужно ещё добавить столько морковки, капусты, лука, картошки, мяса и т.д., чтобы получить какой-то удобоваримый продукт...