ПО ТЕХНИЧЕСКОМУ РЕГУЛИРОВАНИЮ И МЕТРОЛОГИИ

СИСТЕМЫ УПРАВЛЕНИЯ ТЕРМИНОЛОГИЕЙ, БАЗАМИ ЗНАНИЙ И КОНТЕНТОМ

Проектирование, внедрение и поддержка систем управления терминологией

(ISO 26162:2012, ЮТ)

Издание официальное

Москва

Стандартинформ

2017

Предисловие

1    ПОДГОТОВЛЕН Автономной некоммерческой организацией «Институт безопасности труда» (АНО «ИБТ») на основе собственного перевода на русский язык стандарта, указанного в пункте 4

2    ВНЕСЕН Техническим комитетом по стандартизации ТК 55 «Терминология, элементы данных и документация в бизнес-процессах и электронной торговле»

3    УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 30 ноября 2016 г. № 1905-ст

4    Настоящий стандарт идентичен международному стандарту ИСО 26162:2012 «Системы управления терминологией, знаниями и содержанием. Проектирование, внедрение и поддержка систем менеджмента терминологии» (ISO 26162:2012 «Systems to manage terminology, knowledge and content — Design, implementation and maintenance of terminology management systems», IDT).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА.

5    ВВЕДЕН ВПЕРВЫЕ

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном указателе «Национальные стандарты», а текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ежемесячном информационном указателе «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

© Стандартинформ, 2017

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

ГОСТ Р ИСО 26162-2016

3.3 Моделирование данных

3.3.1 _

data model (модель данных): Графическое и/или лексическое представление данных, определяющее их свойства, структуру и взаимосвязи.

[ИСО/МЭК 11179-1:2004, 3.2.7]

3.3.2    data modelling (моделирование данных): Процесс структурирования и организации данных, как правило для внедрения в системе управления базой данных.

3.3.3    data modelling variance (различие моделирования данных): Изменение в назначении категорий данных (3.2.1) к моделям данных в результате различий в философии относительно заказа информации в терминологическом входе (3.1.4).

3.3.4

metamodel (метамодель): Модель (3.3.1) данных, которая определяет одну или более других моделей данных.

[ИСО/МЭК 11179-1:2004, 3.2.20]

3.3.5

metadata (метаданные): Данные, которые определяют и описывают другие данные.

[ИСО/МЭК 11179-1:2004, 3.2.16]

3.3.6

global information GI (глобальная информация GI): Техническая информация и административная информация, относящаяся к полному сбору данных.

[ИСО 16642:2003, 3.7]

Пример — Название сбора данных, истории пересмотра.

3.3.7

complementary information Cl (дополнительная информация Cl): Информация, дополнительная к описанной в терминологических записях (3.1.4) и разделенная через терминологический сбор данных (3.1.1).

[ИСО 16642:2003, 3.1]

Пример — Иерархии области описания учреждения и библиографические ссылки — типичные примеры дополнительной информации.

3.3.8    shared resource (общий ресурс): Информационный объект, к которому можно получить доступ от любых из терминологических или лексикографических записей в терминологическом или лексикографическом ресурсе.

Пример — Общие ресурсы, как правило, включают библиографические записи, записи ответственности, namespace идентификаторы, часто ссылаются на текстовый материал, списки географического положения и внешние файлы, такие как графические или аудиофайлы.

3.3.9

language section LS (языковая секция LS): Часть терминологического входа (3.1.4), содержащего информацию, имела отношение к одному языку.

[ИСО 16642:2003, 3.9]

3.3.10

term section TS (секция термина TS): Часть языкового раздела (3.3.9), содержащего информацию о термине (3.1.13).

[ИСО 16642:2003, 3.15]

5

3.3.11    class (object class) (класс): Класс объекта.

<UML> Графическое описание ряда объектов, которые разделяют тех же самых участников.

3.3.12    multiplicity (разнообразие): Число случаев одного класса (3.3.11), которое связалось с одним случаем другого класса в установленных отношениях.

Примечание — Например, дата происхождения может быть тем же самым для многих терминологических записей, но у одного терминологического входа может только быть одна дата происхождения.

3.4 Заявления

3.4.1    language planning (языковое планирование): Преднамеренные усилия влиять на поведение человека относительно приобретения, структуры или функционального распределения языка.

Пример — Языковое планирование может включать стандартизацию правописания и грамматических правил, спецификации официальных национальных языков, усилия создать жизнеспособные неологизмы, разработанные, чтобы увеличить способность языка как транспортного средства для научной и коммерческой коммуникации и меры, разработанные, чтобы защитить язык от иностранных влияний.

3.4.2    descriptive terminology (описательная терминология): Подход для руководящей терминологии, которая документирует путь, который называет (3.1.13), используется в контекстах, не указывая на предпочтенное использование.

3.4.3    prescriptive terminology (предписывающая терминология): Подход для руководящей терминологии, которая указывает на предпочтительное использование.

3.4.4    normative terminology (нормативная терминология): Подход для руководящей терминологии, которая используется в работе стандартов или правительственном регулировании.

3.4.5    translation editor (редактор перевода): Программное обеспечение, которое поддерживает процесс создания и пересмотра переводов.

3.4.6    controlled authoring (создание, которым управляют): Создание, которое использует ограниченный словарь и текстовую сложность, чтобы представить четкие документы.

3.4.7 _

localization И On (локализация И On): Процесс взятия продукта и создания его лингвистически и культурно соответствующим целевому месту действия (страна/область и язык), где это будет использоваться и продаваться.

[Ассоциация промышленных стандартов локализации]

4 Системы управления терминологией (TMS)

4.1    Общее описание

TMS программное средство, специально предназначенное для сбора, хранения и предоставления доступа к терминологическим данным. Она используется переводчиками, терминологами, техническими писателями и другими пользователями. TMSs должны быть основаны на принципах терминологической работы, изложенной в ИСО 704, что означает, что терминологические ресурсы, которые созданы при помощи TMS, содержат терминологические записи, разработанные, чтобы зарегистрировать понятия и все условия (синонимы и эквиваленты на других языках), которые обозначают эти понятия.

TMSs, как правило, используются для разработки, поддержания и распространения TDCs в различных организационных структурах, в том числе национальными органами, государственными учреждениями, заинтересованными группами, компаниями и частными лицами. В зависимости от организационной структуры TMS должны будут поддерживать различные функции, задачи и потенциальных пользователей.

Планируя приложение управления терминологией, важно рассмотреть различные возможные типы или категории TMS.

4.2    Коммерческие и некоммерческие TMS

Есть множество инструментов управления терминологией на рынке программного обеспечения; большая часть программного обеспечения коммерческая, но увеличивающееся множество бесплат-

6

ГОСТ Р ИСО 26162-2016

ного программного обеспечения или общедоступного программного обеспечения доступно для управления терминологией. Если организационные, функциональные и методологические потребности соответствующей прикладной окружающей среды удовлетворены системой, она может использоваться с полки. Однако во многих случаях ориентированная на клиента адаптация и регулирование необходимы. Если коммерческое программное обеспечение не может быть адаптировано к определенным потребностям, TMS должны будут быть развиты внутренне. Затраты, обслуживание, поддержка и совместимость — важные параметры, которые должны быть рассмотрены, когда принимается решение между покупкой или арендой TMS.

4.3    Предопределенный или свободно определяемый TMS

Коммерческий TMSs мог предопределить или свободно определить структуры моделирования данных. TMS с фиксированным набором категорий данных, определенным набором языков и/или неизменной модели данных должны только использоваться, если урегулирование будет соответствовать точно потребностям организационной окружающей среды, в которой будут применены TMS. TMS со свободно определимой структурой позволяют пользователям определять свои собственные категории данных и свои собственные структуры входа так, чтобы программное обеспечение могло быть адаптировано, чтобы удовлетворить определенным терминологическим потребностям пользователей и могло быть изменено, когда будущие требования изменяются.

4.4    Настольный, клиент-сервер или Сетевой TMS

Самые простые TMSs установлены на местном компьютере для единственного человека. Иногда основные файлы базы данных хранятся на компьютере LAN и могут быть разделены многократными настольными клиентами. В крупных организациях со многими пользователями (и различными ролями), только TMS с архитектурой клиент-сервер может удовлетворить потребности организации. Эти TMSs требуют установки клиента на каждом местном рабочем столе и установки программного обеспечения сервера, обращающейся с одновременным доступом различных клиентов (с различными задачами).

Если у многочисленных пользователей во всем мире должен быть доступ к терминологическим данным, единственное эффективное решение — Сетевые TMS; пользователи не должны устанавливать программное обеспечение, определенное для ТМ на их местных компьютерах, потому что стандартный веб-браузер позволит все операции с TMS. Выбирая Сетевые TMS, проектировщики также должны решить, принять ли их собственный сервер или использовать сторонние TMS, например, выбирающие между услугами, предложенными крупными поставщиками программного обеспечения TMS или свободной, Резидентской сетью совместной окружающей средой. Прежде чем решить произвести принимающую функцию на стороне, они должны тщательно взвесить факторы — такой, как строится, экспертные знания хозяина и надежная доступность данных, а также защита информации и конфиденциальность.

4.5    Автономный, интегрированный или объединенный TMS

Автономные TMS — автономный пакет программ, разработанный для руководящей терминологии независимо от любого другого применения. Объединение терминологии от автономных TMS в другие заявления, такие как инструменты разработки, которыми управляют, или инструменты Перевода с помощью компьютера (CAT), обычно требует, чтобы терминология была экспортирована otTMS и импортирована в другое применение. Иногда интеграция может быть понята, если развить определенные программные расширения для каждого применения, в котором требуется терминология. Поскольку они не связаны с определенным приложением, эти типы TMS, как правило, предлагают больше гибкости с точки зрения адаптируемости данных для различных заявлений.

Интегрированные TMS — те, которые включают ряд функций управления терминологией непосредственно в рамках другого приложения, такого, как в инструменте CAT. Чтобы использовать интегрированные TMS, пользователь должен установить и использовать пакет TMS вместе с беспрепятственно совместимым номером люкс программного обеспечения. Эти типы TMS разработаны, чтобы предложить функции и особенности, определенно требуемые программным обеспечением, которого они — часть, но как следствие они могли бы забыть включать особенности, требуемые для других заявлений. Например, TMS, объединенные в авторское применение, которым управляют, будут содержать функции и типы данных, требуемые для создания, которым управляют, но оно, вероятно, испытало бы недостаток в особенностях, требуемых процесса перевода.

4.6    Одноязычный, двуязычный или многоязычный TMS

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

4.7    База данных или структурированный текст TMS

Начиная с TMS должны поддержать огромный объем данных, ядро базы данных обычно бежит на заднем плане. Реляционная база данных — идеальная архитектура для обработки типичных терминологических требований, таких как много условий на многих языках, многократных категориях данных и (неограниченной) воспроизводимости определенных типов терминологической информации. Ориентированный на структурированный текст TMS также отвечает многим типичным терминологическим требованиям, помечая различные типы данных, такой как в XML.

4.8    Единственная база данных или многократная база данных TMS

TMS могут сохранить все терминологические записи в одной единственной базе данных. Различные предметные области, обрабатывая стадии, клиентов и другие типы информации, могут быть классифицированы признаками, и фильтры могут использоваться, чтобы создать виртуальное подмножество базы данных. Другие TMSs хранят терминологические данные в различных физических базах данных, такой что касается различных предметных областей или различных клиентов. Или пользователь должен выбрать одну из баз данных прежде, чем искать и отредактировать, или программное обеспечение допускает одновременный поиск и доступ ко всем базам данных, иногда с определимой иерархией, определяющей, с какой базой данных будут консультироваться сначала. Особый случай последнего — объединенные TMS, которые собирают данные от различных внешних баз данных, потенциально с различными структурами данных.

5 Этапы проекта

5.1 Обзор

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

-    Проведите предварительное технико-экономическое обоснование (см. 5.2).

-    Проведите технико-экономическое обоснование (см. 5.3).

-    Проведите анализ случая использования (см. 5.4).

-    Установите системные требования (см. 5.5).

-    Проанализируйте рентабельность (см. 5.6).

-    Проектируйте TMS (см. 5.7).

-    Развейте TMS (см. 5.8).

-    Разверните TMS (см. 5.9).

-    Проверьте TMS (см. 5.10).

-    Населите, используйте и поддержите TMS (см. 5.11).

Подробная работа и график времени должны быть установлены, чтобы установить крайние сроки и распределить задачи вовлеченному персоналу. Промежуточные отчеты должны зарегистрировать результаты. График должен ясно указать, когда решения будут приняты, чтобы возобновить проект (так 8

ГОСТ Р ИСО 26162-2016

называемое go/no-go решение) и построить ли новые TMS, купить или выбрать существующие TMS, или изменяют существующие TMS. Эти решения могут повториться на различных стадиях в процессе, поскольку требования расположены по приоритетам.

Фазы, описанные в этом пункте, могут быть приспособлены согласно объему проекта и типу вовлеченной организации (коммерческие предприятия, правительственные учреждения, учебные заведения, бюро переводов и т. д).

5.2    Предварительное технико-экономическое обоснование

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

Может быть решение сознательно исключить единицы или части процесса, определенного здесь, или отложить их до более поздней стадии проекта. Предварительное технико-экономическое обоснование также предоставляет первоначальное описание процесса создания TMS. Это оправдывает потребность в представлении TMS, включая идентификацию любых альтернатив, и определяет основные требования потенциальных пользователей. Организационная окружающая среда, требуемая для осуществления и управления TMS, должна быть обсуждена.

5.3    Технико-экономическое обоснование

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

5.4    Анализ случая использования

Проведение анализа случая использования важно для обеспечения, что TMS удовлетворят потребности целевой группы пользователей. Эта фаза описана в 6.3.

5.5    Системные требования

Во время этой фазы определенные требования для спроектированных TMS определены как основанные на обратной связи от прямых пользователей и других заинтересованных сторон. Технические требования характеристики программного обеспечения тогда определены, чтобы выполнить те требования. Компоненты аппаратного и программного обеспечения выбраны согласно предпосылкам, обрисованным в общих чертах в технических требованиях характеристики программного обеспечения.

Как правило, требования расположены по приоритетам, основанным на отзывах пользователей, так как может быть невозможно обеспечить все требования (см. 6.6).

В дополнение к сосредоточенным пользователями техническим требованиям, касающимся инфраструктуры программного обеспечения организации, нужно ответить, например, гарантировано ли соответствие стандартам компании, а также меры безопасности и правила технического обслуживания.

Модель данных для TMS должна быть определена, прежде чем она будет развита или куплена.

5.6    Рентабельность

Затраты на осуществление и работу TMS должны быть оценены, так же как ожидаемая выгода системы. Нужно отметить, что финансовый возврат инвестиций не будет понят до окончания TMS. Любое экономическое обоснование ситуации, которое используется, чтобы определить, одобрен ли проект для финансирования, должно включать неосязаемые, нематериальные преимущества (иногда

так называемые «мягкие преимущества») в дополнение к финансовым. Мягкие преимущества включают улучшенное качество и удовлетворенность потребителя, стоят предотвращения через сокращение дублирования работы или другие источники неэффективности и более эффективные процессы (такие как перевод и обслуживание клиентов). Если несколько альтернативных вариантов все еще возможны в этой фазе (такой как строительство новых TMS или покупка коммерчески доступных TMS), затраты и преимущества должны быть оценены и сравнены для каждого выбора.

Другим фактором являются затраты на неосуществление TMS. Факторы предотвращения стоимости, упомянутые выше, вписываются в эту категорию, но есть другие соображения, такие как судебные издержки фирменного нарушения, которого TMS могли бы помочь избежать, упущенные возможности для создания, которым управляют, и дополнительные трудности в осуществлении системы управления контентом без терминологии, которой управляют. Все потенциальные текущие и будущие применения терминологии должны быть приняты во внимание в строительстве экономического обоснования ситуации.

Затраты на импортирование существующих данных могут быть значительными, особенно если существующий набор данных должен быть изменен до импорта. Средства для импортирования существующих данных, предлагаемых различными системами, которые рассматривают, должны быть вычислены в анализе затрат. Может быть возможно просить, чтобы поставщик существующихTMS развил любой необходимый таможенный конверсионный установленный порядок.

5.7    Системное проектирование

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

Любые требования для импортирования существующих терминологических данных нужно рассмотреть в дизайне.

5.8    Развертывание системы

Цель этой стадии состоит в том, чтобы развить необходимые компоненты аппаратного и программного обеспечения. TMS и его подсистемы осуществлены, сочиняя новое программное обеспечение или формируя и/или настраивая существующее программное обеспечение, важно зарегистрировать и проверить компоненты и их функцию в пределах целой системы, поскольку они осуществлены.

5.9    Стадии развертывания системы

Стадия развертывания охватывает несколько подстадий и должна быть идеально объединена со стадией тестирования.

Начальное развертывание, особенно на крупных предприятиях, должно показать системный запуск для небольшой группы отобранных пользователей. Во время этого начального запуска должны быть проверены TMS, и любые недостатки должны быть исправлены. Люди, вовлеченные в это начальное развертывание, должны участвовать в тестировании действий и должны экспериментировать с маленьким набором терминологических записей прежде, чем работать с крупными проектами.

Полное развертывание всего предприятия должно быть предпринято только после завершения фазы тестирования, как описано в 5.10.

5.10    Системный тест

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

ГОСТ Р ИСО 26162-2016

влечь представителей всех пользовательских ролей (терминологи, технические писатели, специалисты по предметной области, переводчики и т.д.). Ручное тестирование может быть увеличено при помощи автоматических методов и установленного порядка и может обеспечить исходные данные, которые могут использоваться позже, чтобы проанализировать выгоду изменений в системе.

Людям нельзя разрешать настраивать их собственную автономную среду тех же самых TMS, пока тестирование не завершено.

5.11 Наполнение TMS, эксплуатация и обслуживание

Как только TMS были развернуты и проверены, система готова к эксплуатации. Полное развертывание вовлекает системных администраторов инструктирования и системных пользователей, установление необходимой инфраструктуры обслуживания и интеграция TMS в полный технологический процесс. Может быть необходимо наполнение TMS первоначально, импортировав существующие терминологические данные. До импорта должны быть рассмотрены данные; модификации в содержании, структуре и формате могут быть необходимыми. Эта задача может занять большое количество времени, таким образом, усилие должно быть оценено, и подходящее время позволено в полном графике. Для получения дополнительной информации об импортировании данных см. 12.2.

6 Пользовательско-ориентированный дизайн

6.1    Основные процедуры

6.1.1    Пользовательско-ориентированный дизайн относится к методологиям и принципам проектирования продукта так, чтобы это удовлетворило потребности пользователей продукта. Цель этого пункта состоит в том, чтобы объяснить, как включать пользователей в процесс проектирования.

В число потенциальных пользователей TMS включаются:

-    люди, такие как терминологи, переводчики, переводчики — специалисты по предметной области, учителя, студенты, технические писатели, рекламодатели, проектировщики СМИ и сценаристы, инженеры знаний и информации, языковые инженеры, разработчики продукта, инженеры и т. д.;

-    машины и инструменты, что доступ и обрабатывает терминологическую информацию, такую как инструменты разработки, которыми управляют, правописание и блоки проверки грамматических ошибок, двигатели машинного перевода, называют инструменты извлечения, инструменты перевода с помощью компьютера, функции соответствия, поисковые системы, текстовые анализаторы и т. д.

У каждой пользовательской категории есть свои особенности и определенные потребности. Если TMS предназначены больше чем для одной пользовательской категории, общий знаменатель или доминирующие потребности всех пользователей должны быть определены, и эти потребности должны быть расположены по приоритетам по всем другим.

6.1.2    Проектировщики должны определить:

-    нормативная ли цель коллекции терминологии, предписывающая, или описательная;

-    должны ли TMS быть общим, покрывающим все области или специализированную, рассматривающую только одну предметную область или ограниченное число предметных областей и, если это — последний, какие предметные области должны быть покрыты.

6.1.3    Возможности для поставки информации пользователям с изменением потребностей включают обеспечение:

-    многократные представления о терминологических данных (частичные взгляды, некоторые области, скрытые, пока не требуется);

-    всей информации, доступной на всех языках или некоторой информации, доступной только на одном языке;

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

-    доступ на местной (внутренней), национальной и/или международной основе;

-    Интерфейс Web или другой тип интерфейса;

-    открытый доступ или доступ, ограниченный определенной окружающей средой.

6.1.4    Проектировщики должны определить, как база данных будет использована. Некоторые типы информации более важны для некоторых пользователей, чем для других. Например, технические писа-

11

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

6.2    Процедуры пользовательско-ориентированного подхода

Принятие ориентированного на пользователя подхода к проектированию TMS позволяет гарантировать то, что созданная система будет проста в использовании и позволит достичь желаемых целей.

Этапы:

-    Определите пользователей и их потребности (см. 6.3).

-    Определите выходную продукцию (см. 6.4).

-    Проанализируйте задачи, которые будут выполнены и создадут случаи использования (см. 6.5).

-    Перечислите требования (см. 6.6).

-    Проведите оценку конкурента (см. 6.7).

-    Подготовьте и оцените дизайн прототипа (см. 6.8).

-    Отрегулируйте дизайн в соответствии с отзывами пользователей (см. 6.9).

-    Выполните бета-оценку (см. 6.10).

6.3    Идентификация пользователей и их потребностей

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

Различные типы пользователей должны быть рассмотрены способом, который пропорционален их использованию. Например, если есть 1 ООО переводчиков и 100 терминологов, которые, как ожидают, получат доступ к TMS в Сети, тогда отношение переводчиков к терминологам, которые опрошены на Сетевых функциях, должно быть 10:1. Однако если терминологи проведут вдвое больше времени, обновляя сбор данных как переводчики, отношение должно быть приспособлено соответственно для вопросов о функциях обновления: 10*1:1*2 = 10:2.

Особое внимание должно быть уделено потребностям, которые, кажется, противоречат друг другу. Иногда, воспринятые потребности одной группы настроены против потребностей другой группы; например, технические писатели и переводчики могут выразить взаимоисключающие требования. Например, предложения контекста (типовые предложения, содержащие термин), могут быть полезны для переводчиков, но не для писателей. В таких случаях может быть возможно удовлетворить и те, и другие потребности, обеспечив определенные для пользователя представления о данных и/или определенные для пользователя технологические процессы.

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

Чтобы утвердить потребности и восприятие, что берущие обзора имеют потребностей, которые они выражают, вопросы должны быть включены, что попытка оценить результаты, которые предполагают берущие обзора, будет получена, осуществляя их предложения. Важно избежать любой двусмысленности в вопросах об обзоре.

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

1. Какова главная цель TMS?

ГОСТ Р ИСО 26162-2016

-    Например, если цель состоит в том, чтобы стандартизировать терминологию на одном или более языках, то сбор данных должен быть нормативным. Это означает, что будет проведено в жизнь использование определенных стандартных условий. В этом случае дизайн и методология, принятые для TMS, должны следовать за стандартами ISO для стандартизации терминологии, такими как ИСО 704, ИСО 1087 и ИСО 10241-1. С другой стороны, если цель состоит в том, чтобы улучшить использование терминологии, то сбор данных должен быть предписывающим. Это означает, что должно указать на предпочтенные условия и непредпочтенные условия и включать рекомендации по использованию. Если цель состоит в том, чтобы описать, как термины использованы (не предписывая, как они должны использоваться), то сбор данных описательный. Этот тип терминологического ресурса не указывает предпочтенные или непредпочтенные условия.

-    Если сбор данных предназначается, чтобы поддержать поставщика услуг локализации, у которого есть много различных клиентов, то целостность терминологии клиента в пределах TMS главная. Поля данных должны быть обеспечены, чтобы определить происхождение условий, клиента и проектов, где термины использованы, и меры безопасности могут быть осуществлены, допуская защиту данных. В некоторых случаях отдельные сборы данных должны быть предоставлены отдельным клиентам.

2.    Все пользователи состоят в компании/организации или некоторые являются внешними?

-    Ответ на этот вопрос повлияет на доставку и каналы доступа для данных. Например, в случае основанных на сети TMS, если некоторые пользователи вне брандмауэра организации, специальные меры должны быть взяты, чтобы предоставить им доступ к TMS. Все ли данные о терминологии подойдут и для внутренних и для внешних пользователей? В противном случае будет необходимо так или иначе дифференцировать данные, которые могут быть распределены внешне, отданных, которые не могут, например с помощью специального поля данных. У внешних групп, таких как клиенты и продавцы, может не быть доступа к тем же самым инструментам для использования терминологии. В этом случае важна совместимость данных, что обеспечивается через поддержку международных стандартов обмена (см. ИСО 12620, ИСО 16642 и ИСО 30042).

-    Каждый раз, когда многократные версии или копии данных существуют внутренне и внешне, управление версиями и глобальное обновление должны составляться в технологическом процессе и планировании. Однако, нежелательно поддержать многократные версии данных.

3.    Все пользователи — опытные профессионалы (писатели, переводчики, терминологи и т. д.) или являются таковыми в других областях, таких как продажи, управление, служба поддержки, обучение, и т. д?

-    TMS, которые служат диапазону пользовательских типов, возможно, должны показать различные типы информации к различным типам пользователей. Если много пользователей могут создать терминологические записи, им также, возможно, понадобятся различные интерфейсы, чтобы создать те записи. Административный персонал не захочет делать запись столько же детализированной информации, как терминологи, и технические специалисты будут нуждаться в информации, представленной из других источников, а не в той, которая требуется переводчикам.

4.    Будут какие-либо другие инструменты, такие как система настольной издательской системы или система Translation Memory, должны получить доступ или взаимодействовать cTMS?

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

5.    Какие языки TMS должны поддержать?

-    Unicode (ISO 10646) является рекомендуемым стандартом кодирования для совместимости с другими системами и поддерживать самый широкий диапазон языков. Все недавно развились, TMSs должен быть Unicode-послушный.

-    Выбор UTF8 или выше зависит от языков, которые будут осуществлены и доступная операционная система.

-    Если TMS будут включать двунаправленные языки (такие как арабский или иврит), то двунаправленные входные методы и форматы показа должны быть поддержаны.

6.    Сколько языков должно поддержать TMS и сточки зрения содержания и сточки зрения интерфейса?

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

13

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

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

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

-    В пределах многоязычные, ориентированные на понятие TMS, проектировщики должны рассмотреть, как обращаться с ситуациями, включающими квазиэквивалентные понятия: термин А можно считать эквивалентным В на одном языке и С в другом, но понятия, лежащие в основе В и С, могут не быть полностью эквивалентными. Решение должно быть принято относительно того, как обращаться с такими случаями неполной эквивалентности понятия, поскольку это решение может повлиять на основной дизайн TMS. Эти частично эквивалентные понятия могут быть включены в тот же самый вход понятия с областью, доступной для комментариев передачи, чтобы объяснить различие, или они могут быть зарегистрированы в отдельных терминологических записях и соединены как кандидаты перевода.

7.    Какие определенные данные делают каждый тип пользовательской потребности?

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

8.    Как пользователи будут искать и восстанавливать информацию?

-    Пользователи должны быть в состоянии искать условия из других приложений, такой как от редактора перевода или текстового процессора? Они будут использовать Интернет или интранет? Им нужен доступ от мобильных устройств? Им будут нужны фильтры расширенного поиска, или действительно простая строка поиска достаточна? Есть ли какие-либо исполнительные проблемы, которые нужно рассмотреть относительно этих СМИ доступа?

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

ГОСТ Р ИСО 26162-2016

Содержание

1    Область применения.................................................................1

2    Нормативные ссылки.................................................................1

3    Термины и определения...............................................................1

3.1    Ресурсы........................................................................1

3.2    Категории данных................................................................3

3.3    Моделирование данных...........................................................5

3.4    Заявления......................................................................6

4    Системы управления терминологией (TMS)..............................................6

4.1    Общее описание.................................................................6

4.2    Коммерческие и некоммерческие TMS...............................................6

4.3    Предопределенный или свободно определяемый TMS..................................7

4.4    Настольный, клиент-сервер или Сетевой TMS.........................................7

4.5    Автономный, интегрированный или объединенный TMS.................................7

4.6    Одноязычный, двуязычный или многоязычный TMS....................................8

4.7    База данных или структурированный текст TMS.......................................8

4.8    Единственная база данных или многократная база данных TMS..........................8

5    Этапы проекта.......................................................................8

5.1    Обзор..........................................................................8

5.2    Предварительное технико-экономическое обоснование.................................9

5.3    Технико-экономическое обоснование................................................9

5.4    Анализ случая использования......................................................9

5.5    Системные требования............................................................9

5.6    Рентабельность..................................................................9

5.7    Системное проектирование.......................................................10

5.8    Развертывание системы..........................................................10

5.9    Стадии развертывания системы...................................................10

5.10    Системный тест................................................................10

5.11    Наполнение TMS, эксплуатация и обслуживание.....................................11

6    Пользовательско-ориентированный дизайн..............................................11

6.1    Основные процедуры............................................................11

6.2    Процедуры пользовательско-ориентированного подхода...............................12

6.3    Идентификация пользователей и их потребностей....................................12

6.4    Идентификация продуктов продукции...............................................15

6.5    Выполнение анализа задачи и подготовка случаев использования.......................15

6.6    Идентификация потребностей и их приоритетов......................................16

6.7    Проведение конкурентоспособной оценки...........................................17

6.8    Проектирование и оценка прототипа................................................17

6.9    Наладка дизайна по отзывам пользователей.........................................17

6.10    Выполнение бета-оценки........................................................18

7    Терминологическая категория данных..................................................18

7.1    Введение в категории данных.....................................................18

7.2    Принципы для отбора и использования категорий данных..............................18

7.3    Типы категорий данных...........................................................21

III

ГОСТ Р ИСО 26162-2016

6.4    Идентификация продуктов продукции

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

Различные продукты продукции также требуют различных экспортных форматов от простых отделенных от запятой списков до подробного повышения XML.

Чтобы приспособить все эти факторы, проектировщики должны сделать инвентарь всех ожидаемых терминологических продуктов продукции и форматов и категорий данных требуемым поддержать те продукты.

6.5    Выполнение анализа задачи и подготовка случаев использования

Эта стадия включает проведение всестороннего анализа задач, которые будущие пользователи TMS в настоящее время выполняют, и затем развивающий случаи использования для того, как пользователи выполнили бы эквивалентные задачи, а также любые недавно необходимые задачи, используя новые TMS.

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

Пример 1 — Типовой анализ задачи, выполненной переводчиком.

Задача: используйте предписанный термин из словаря проекта во время перевода

Актер: удаленный переводчик

Материал использовал: электронная таблица, содержащая определенную для проекта терминологию

Инструменты использовали: редактор перевода

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

Развивая случаи использования для новых TMS, проектировщики должны определить, кто выполняет задачи, каковы предпосылки, какие определенные данные и инструменты включены, последовательные шаги, которые будут сделаны, и любые определенные взаимодействия, которые произойдут между пользователем и TMS.

Пример 2 — Упрощенные случаи использования, показывающие, как переводчик мог бы выполнить эту задачу в новых TMS.

Задача: используйте предписанный термин из словаря проекта во время перевода

Актер: удаленный переводчик

15

7.4    Структуры ввода данных..........................................................24

7.5    Отбор категорий данных..........................................................24

7.6    Определенные для перевода категории данных......................................25

7.7    Предписывающие категории данных................................................25

7.8    Связанные с технологическим процессом категории данных............................25

7.9    Стандартизированные названия категории данных и понятия категории данных............26

8    Моделирование данных..............................................................26

8.1    Терминологическая метамодель...................................................26

8.2    Данные, моделирующие для ориентации понятия.....................................27

8.3    Прикладные подходы............................................................30

8.4    Примеры моделирования данных..................................................31

8.5    Составление устаревших данных..................................................37

9    Разработка TMS....................................................................38

10    Развертывания TMS................................................................39

10.1    Действия развертывания........................................................39

10.2    Подготовка документации, помощи и образовательных материалов.....................40

10.3    Оказание поддержки и обслуживания..............................................40

10.4    Встреча зависимостей заинтересованной стороны...................................40

10.5    Реклама и продвижение TMS.....................................................40

10.6    Поставка TMS.................................................................41

10.7    Обеспечение обучения..........................................................41

10.8    Измерение удовлетворенности пользователей......................................41

11    Пользовательские интерфейсы.......................................................41

11.1    Проектирование пользовательского интерфейса.....................................41

11.2    Показ терминологических категорий данных........................................41

11.3    Показ и подготовка терминологических записей......................................43

12    Ввод и редактирование данных.......................................................44

12.1    Введение данных вручную.......................................................44

12.2    Импортирование данных.........................................................48

12.3    Редактирование данных.........................................................49

12.4    Утверждение данных............................................................49

12.5    Автоматическое воспроизведение или изменение данных.............................50

12.6    Добавление перекрестных ссылок.................................................50

12.7    Добавление мультимедийных файлов..............................................50

13    Функции поиска....................................................................51

13.1    Функции поиска базы данных.....................................................51

13.2    Поиск термина.................................................................51

13.3    Поиск числом понятия или особенностями..........................................52

13.4    Сложная фильтрация и поиск.....................................................52

13.5    Поиск в текстовых полях.........................................................53

13.6    Просмотр.....................................................................53

14    Вывод данных.....................................................................53

14.1    Типы вывода данных............................................................53

14.2    Показ результатов поиска........................................................53

14.3    Сортировка....................................................................54

ГОСТ Р ИСО 26162-2016

14.4    Распечатки....................................................................55

14.5    Экспорт данных в файл.........................................................57

14.6    Экспорт данных для других заявлений.............................................58

15 Организация и управление TMS......................................................58

15.1    Создание плана управления......................................................58

15.2    Важность управления потоком данных.............................................58

15.3    Изменение модели данных.......................................................59

15.4    Обеспечение защиты информации................................................59

15.5    Управление доступом...........................................................60

15.6    Поддержка формата обмена.....................................................60

15.7    Укомплектование персоналом TMS................................................60

15.8    Управление затратами и руководящими ресурсами...................................61

Приложение А (справочное) Тематические исследования: категория данных и моделирование

данных.................................................................62

Приложение ДА (справочное) Сведения о соответствии ссылочных международных стандартов

национальным стандартам Российской Федерации...........................65

Библиография.......................................................................66

V

Введение

Терминологические данные собираются, управляются и хранятся в самых разнообразных системах управления терминологией (TMSs). TMSs используют различные системы управления базами данных, начиная с приложений персонального компьютера для отдельных пользователей, клиент-сервером, приложения или веб-приложения, используемые крупными компаниями и правительственными учреждениями. Терминологические сборники данных (TDCs) основаны на различных видах моделей данных и состоят из различных наборов категорий данных (Выбор категорий данных, DCSs). Чтобы облегчить сотрудничество и предотвратить дублирование, необходимо разработать стандарты и рекомендации для создания и использования TDCs, а также для совместного использования и обмена данными.

В целях содействия обмену терминологическими данными и создания комплексного подхода, который будет использоваться при анализе существующих и проектировании новых TDC, ISO/TC 37 опубликовал следующие стандарты: ИСО 704, ИСО 12620, ИСО 16642.

Было бы полезно ознакомиться с этими документами прежде, чем прочитать настоящий стандарт.

Настоящий стандарт содержит указания по выбору соответствующих категорий данных, а также по проектированию и реализации модели данных и пользовательского интерфейса дляТМБ, принимая во внимание целевую группу пользователей. Рекомендации, описанные в этом стандарте, обязательны для успешного развития TMS и для предотвращения дорогостоящих ошибок. Этот стандарт может использоваться для выбора соответствующих TMS в определенной цели.

VI

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

СИСТЕМЫ УПРАВЛЕНИЯ ТЕРМИНОЛОГИЕЙ, БАЗАМИ ЗНАНИЙ И КОНТЕНТОМ

Проектирование, внедрение и поддержка систем управления терминологией

Systems to manage terminology, knowledge and content.

Design, implementation and maintenance of terminology management systems

Дата введения — 2017—09—01

1    Область применения

Настоящий стандарт устанавливает критерии проектирования, внедрения и поддержания систем управления терминологией (TMSs).

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

Настоящий стандарт предназначен для терминологов, разработчиков программного обеспечения и других лиц, которые вовлечены в процесс разработки или приобретения TMS.

2    Нормативные ссылки

В настоящем стандарте использованы нормативные ссылки на следующие международные стандарты. Для датированных ссылок применяют только указанные издания. Для недатированных ссылок применяют самые последние издания (включая любые изменения и поправки).

ISO 704:2009, Terminology work. Principles and methods (Терминологическая работа. Принципы и методы).

IS012620:2009, Terminology and other language and content resources. Specification of data categories and management of a Data Category Registry for language resources (Терминология, другие языковые ресурсы и ресурсы содержания. Спецификация категорий данных и ведение реестра категорий данных для языковых ресурсов).

ISO 30042:2008, Systems to manage terminology, knowledge and content — TermBase exchange (TBX) (Системы для управления терминологией, знаниями и содержанием. Обмен базами данных (TermBase exchange (TBX)).

3    Термины и определения

В настоящем стандарте применены термины с соответствующими определениями:

3.1    Ресурсы

3.1.1    terminological resource, terminological data collection TDC (терминологический ресурс, терминологический сбор данных TDC): Текст или информационный ресурс, состоящий из терминологических записей (3.1.4).

Примечание —Адаптированный в ИСО 24613:2008.

Издание официальное

3.1.2    terminology management system TMS (системы управления терминологией TMS): Программное средство, специально предназначенное для сбора, поддержания и доступа к терминологическим данным.

3.1.3    terminological database TDB (termbase) (терминологическая база данныхTDB): Терминологическая база, база данных, включающая терминологический ресурс (3.1.1).

3.1.4    terminological entry ТЕ (терминологический вход ТЕ): Часть терминологического ресурса (3.1.1), который содержит терминологические данные, связанные с одним понятием.

Примечание — Адаптированный в ИСО 1087-2, 2.22.

3.1.5    concept orientation (ориентация понятия): Принцип относится к управлению терминологией, посредством чего терминологический вход (3.1.4) описывает одно и только одно понятие или два, или больше квазиэквивалентных понятий (3.1.7).

Примечание — Ориентированный на понятие вход может содержать многократные условия, которые считают семантически эквивалентными.

3.1.6    equivalent concept (эквивалентное понятие): Понятие на одном языке, которое включает те же самые особенности, как покрытый данным понятием на другом языке.

3.1.7    quasi-equivalent concept (nearly equivalent concept) (квазиэквивалентное понятие (почти эквивалентное понятие): Понятие на одном языке, которое разделяет больше всего, но не все особенности с понятием на другом языке, но это, тем не менее, используется в качестве эквивалента для того понятия в некоторых контекстах.

3.1.8    entailed term (вызванный термин): Термин использовался в текстовом поле, таком как / definition/ или /context/, которое определяет понятие, которое определено в другом терминологическом входе (3.1.4) в том же самом терминологическом ресурсе (3.1.1).

3.1.9    doublette (двойной вход): Терминологический вход (3.1.4), который описывает то же самое понятие как другой вход.

Примечание — Двойной вход обычно обнаруживается TMS, определяя два условия, имеющие ту же самую форму; однако, в нем определены основанные на идентичных понятиях, не на идентичных условиях. Двойной вход не должен быть перепутан с омографами.

3.1.10

concept system (система понятия): Набор понятий, структурированных согласно отношениям среди них.

[ИСО 1087-1:2000, 3.2.11]

3.1.11

concept diagram (диаграмма понятия): Графическое представление системы понятия (3.1.10).

[ИСО 1087-1:2000, 3.2.12]

3.1.12    legacy data (устаревшие данные): Терминологические данные, которые доступны в существующем файле или базе данных и которые рассматривают для импорта в TMS (3.1.2).

Примечание — Устаревшие данные могут быть в форме ранее используемых баз данных, файлов обработки текстов, разграниченных запятой текстовых файлов, SGML, HTML или файлов XML, и т. п. Преобразование таких данных к формату, который будет совместим с новыми TMS, может создать серьезные проблемы.

3.1.13    term (термин): Слово или несколько слов, которые обозначают понятие.

Пример — «Олимпийские игры» и «специальные Олимпийские игры» являются двумя условиями в области спортивных состязаний.

Примечание 1 — Когда слово или слова могут обозначать больше чем одно понятие, каждая пара слова/ понятия — отдельный термин. Например, «порт» (приют для лодок) и «порт» (компьютерная точка контакта) являются двумя различными условиями.

Примечание 2 — В теории терминологии термины обозначают понятия в определенных предметных областях, и слова от общего словаря, как полагают, не являются условиями. В TDC, однако, слова от общего словаря иногда регистрируются в терминологических записях, где они все еще упоминаются как «условия».

3.2 Категории данных

3.2.1 _

data category (категория данных): Результат спецификации поля данных.

[ИСО 1087-2:2000, 6.14]

3.2.2

data element (элемент данных): Единица данных, в определенном контексте, считается неделимым.

[ИСО 1087-2:2000, 6.11]

3.2.3    data granularity (степень детализации данных): Степень точности данных.

Примечание — Например, набор отдельных категорий данных (3.2.1) / часть речи/, /грамматический пол/, и/ грамматическое число/ предусматривает большую степень детализации данных, чем делает единственную категорию данных /граматика /.

3.2.4    data elementarily (данные): Принцип, посредством чего единственное поле данных должно содержать только один пункт информации.

Примечание — Например, включение полной формы и включение сокращения в той же самой области было бы нарушением принципа данных elementarily.

3.2.5    term autonomy (автономия термина): Принцип, посредством чего все условия в терминологическом входе (3.1.4) могут быть описаны при помощи того же самого набора категорий данных (3.2.1).

3.2.6

Data Category Registry DCR (Регистрация категории данных DCR): Набор стандартизированных категорий данных (3.2.1), чтобы использоваться в качестве ссылки для определения лингвистических схем аннотации или любых других форматов в области языковых ресурсов.

[ИСО 12620:2009, 3.2.1]

Примечание — 1ЭОЯС 37 DCR содержит технические требования категории данных (3.2.7), которые включают историческую, описательную, и административную информацию и другие метаданные.

3.2.7

data category specification (спецификация категории данных): Набор признаков, используемых, чтобы полностью описать данную категорию данных (3.2.1).

[ИСО 12620:2009, 3.2.2]

Примечание — Сокращение, которое DCS отсылает к Выбору Категории Данных (3.2.8).

3.2.8

Data Category Selection DCS (Выбор категории данных DCS): Набор категорий данных (3.2.1) отобранный из Регистрации категории данных (3.2.6).

[ИСО 12620:2009, 3.2.3]

3.2.9

complex data category (сложная категория данных): Категория данных (3.2.1), у которых есть концептуальная область (3.2.11).

[ИСО 12620:2009, 3.1.7]

3.2.10

open data category (открытая категория данных): Сложная категория данных (3.2.9), чья концептуальная область (3.2.11) не ограничена перечисленным набором ценностей.

[ИСО 12620:2009, 3.1.8]

3

3.2.11    conceptual domain (концептуальная область): Набор действительных значений стоимости (3.2.14).

Примечание 1 — Основанное на ИСО/МЭК 11179-1:2004, 3.3.6.

Примечание 2 — Значения стоимости в концептуальной области могут быть перечислены, далее определены дополнительными ограничениями или выражены через описание. Например, категория данных (3.2.1) / термин/ описан его определением и таким образом ограничен от надлежащего содержания, например, контекстной информации или грамматической информации, но было бы невозможно перечислить все ценности, связанные с этой категорией данных.

3.2.12

closed data category (закрытая категория данных): Сложная категория данных (3.2.9), чья концептуальная область (3.2.11) ограничена рядом определенных простых категорий данных (3.2.13). [ИСО 12620:2009, 3.1.13]

3.2.13

simple data category (простая категория данных): Категория данных (3.2.1) без концептуальной области (3.2.11).

[ИСО 12620:2009, 3.1.12]

3.2.14

value meaning (значение стоимости): Значение или семантическое содержание стоимости. [ИСО/МЭК 11179-1:2004, 3.3.39]

Примечание — ISO/TC 37 перечислили ценности как простые категории данных, то есть как категории данных самостоятельно. Значение стоимости всегда рассматривается в контексте области общей стоимости и закрытой категории данных, с которой это связано и не является просто собственностью области, ценят себя.

3.2.15

value domain (область стоимости): Набор допустимых ценностей (3.2.16)

[ИСО/МЭК 11179-1:2004, 3.3.38]

3.2.16

permissible value (допустимая стоимость): Выражение стоимости, означающей (3.2.14) позволенный в определенной области стоимости (3.2.15).

[ИСО/МЭК 11179-1:2004, 3.3.28]

3.2.17

thematic domain (тематическая область): Класс заявлений, определенных подобием структур данных, они должны управлять.

[ИСО 12620:2009, 3.4.3]

Примеры — Терминология, лексикография, морфосинтаксис.

3.2.18

thematic domain profile profile (тематический профиль профиля области): Представление той в пределах спецификации (3.2.7) категории данных тематической области (3.2.17), с которой эта категория данных (3.2.1) связана.

[ИСО 12620:2009, 3.4.4]

Примечание — У категории данных может быть несколько тематических профилей области, указывая, что она используется несколькими тематическими областями.