Обсуждение

В архиве: 7 комментариев.

Читать и комментировать в ЖЖ ↗

Имя не сохранено · 4 апреля 2011

Комментарий

Хотелось бы чуть поправить. Семантика базовых отношений ISO 15926 таки не совпадает и с RDF, ибо rdf:type уже не ISO 15926-2 classification. И с 4D не всё однозначно, оба подхода одинаково выразительны, но по разному практичны в разных контекстах. Хотя решение не усложнять стандарт схемой взаимодействия 4D и 3D+1 было разумно для той технической/языковой базы (EXPRESS). В остальном согласен. И работы у нас ещё много.

Имя не сохранено · 5 апреля 2011

Комментарий

>> (я всё-таки противлюсь идее, что семантика базовых отношений онтологии ISO 15926 совпадает с семантикой базовых отношений онтологии OWL). видимо, пока это вариант с наибольшей преемственностью и с наименьшими побочными эффектами. но учитывая owl-ловский логотип фраза "натянуть сову на глобус" приобретает неожиданный смысл. :) P.S. у меня маленький практический вопрос: очень интересует - имеется ли гармонизированный перевод на русский понятий (и аннотаций к ним) из списка: http://www.tc184-sc4.org/wg3ndocs/wg3n1328/lifecycle_integration_schema/lifecycle_integration_schema.html мне припоминаются Ваши посты которые касались темы перевода, но целостного списка в выложенных материалах я пока не обнаружил.

Анатолий Левенчук · 5 апреля 2011

Комментарий

Неоднократно обсуждалась идея осмысленности или бессмысленности перевода этого списка (тем более что переводить нужно не только этот список, но и definitions, и notes, и примеры, и диаграммы и вообще пухленький томик Части 2 (а по совокупности -- и Части 7). Пока склонялись к мысли, что переводить даже вредно. Но в последнее время раздаются слабые голоса о том, что для поддержки разговорной речи можно было бы иметь хоть какие-то ориентиры (хотя бы для выбора из "индивида" и "индивидуала" -- сейчас все вразнобой тут говорят ;) Но это явно не в приоритетах: плюс тут самые разные философские традиции вмешиваются, но главное -- непонятно, кто мог бы и для каких целей использовать перевод. Это как спецификацию XML переводить, или HTML 5...

Ответ на комментарий

Имя не сохранено · 6 апреля 2011

Комментарий

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

Ответ на комментарий

Анатолий Левенчук · 6 апреля 2011

Комментарий

Всего не переведёшь, в этом проблема. Более того, эти тексты непрерывно меняются (за последние несколько месяцев Части 7 и 8, например, существенно менялись). Российские RDL разрабатываются сразу по-русски, а вот глобальный RDL нужно принимать таким, как он есть, чтобы не терять возможность обсуждать наши диаграммы с иностранцами. Замечу, что идея переводить операторы языков программирования (Паскаля, Фортрана, Явы и других) на русский была, но от неё отказались -- и с русскоязычными операторами сейчас разве что "школьный алгоритмический язык". То же самое будет и с class_of_class -- будут писать по-английски, это неизбежно. Так зачем тогда переводить, ввязываясь в заведомо безнадёжное мероприятияе? Почему язык ISO 15926, переведенный на русский, ждёт более удачная судьба, нежели переведенный на русский набор тегов много более популярного OWL?

Ответ на комментарий

Имя не сохранено · 6 апреля 2011

Комментарий

>> Замечу, что идея переводить операторы языков программирования (Паскаля, Фортрана, Явы и других) на русский была, но от неё отказались -- и с русскоязычными операторами сейчас разве что "школьный алгоритмический язык". просто операторы" ЯП (которых типично 2-3 десятка штук)- это фактически расширенный набор "знаков пунктуации". действительно, "переводить" их вроде бы как и не осмысленно (хотя в современных продуктах это можно. в том же C#/.NET вполне можно с помощью алиасов переопределить синтаксис на использование ЦЕЛЫХ и ВЕЩЕСТВЕННЫХ и делать прочие кунштюки доступные благодаря использованию UTF). но в случае "15926" имеется 200-штук-сущностей-только-для-начала, которые уже не "пунктуация" никаким боком. конструкционный элемент с серьезной смысловой нагрузкой. который чтобы правильно-применить надо 1) правильно-понять и, не менее важно, 2) не-понять-неправильно. и если между "мысленным формулированием" и "записью решения" в технологическую цепочку внезапно вклинивается еще и "перевод с русского на ангельский" - вероятность пункта два скачком возврастает. >> То же самое будет и с class_of_class -- будут писать по-английски, это неизбежно. так пусть пишут и по английски тоже - если удобно. но зачем лишать возможности писать вместо этого "КлассКлассов"( и перегонять в/из class_of_class при необходимости. преобразование же взаимно однозначное ). > Почему язык ISO 15926, переведенный на русский, ждёт более удачная судьба, нежели переведенный на русский набор тегов много более популярного OWL? у OWL все таки тэги. а у 15926 - все таки литералы-внутри-тегов. субстанция гораздо более лояльная к переводу. а "удачность судьбы" сильно зависит от количества последователей. которое обратно пропорционально величине порога вхождения.

Ответ на комментарий

Анатолий Левенчук · 6 апреля 2011

Комментарий

Про порог вхождения я тоже, конечно, думаю. Но мы совершенно недаром help по софту .15926 сделали на английском языке. Если мы будем тратить силы на важное, то через некоторое время переводчики найдутся, если будет в этом действительная потребность. Пока важнее не столько перевести Часть 2, сколько сделать набор упражнений, который действительно снизит порог вхождения -- сильнее, чем перевод на русский (и неизбежное потом запоминание английских оригиналов). Нам хватает русского языка там, где он неизбежен: например, при создании шаблонов для уникальных советских ГОСТов, которых нигде за пределами бывшего советского лагеря и на других языках не сыщешь. Тем не менее, мы активно обсуждаем полноценный механизм многоязычных labels и механизм namespaces, без которых вся эта деятельность непрактична. Наш софт должен будет поддерживать многоязычность, в том числе в варианте редактора. Так что набор понятий технологически можно перевести, и даже пополнить русскими labels RDL. Но какие от этого пряники будут, я искренне не понимаю. Продолжая полную аналогию с языками программирования, переводить нужно было бы не только немногие ключевые слова языка, но и обширные библиотеки. Но этого опять же никто не делает. ISO 15926 -- это сейчас не только 201 понятие части 2, но и 2млн.700тыс. триплов текущего RDL. Это непереводимо, смысла нет. Нужно создавать русскоязычные классы, по потребности. Технологию для этого мы готовим. Методики на английском делаем (и выверяем терминологию там -- по потребности каждого текста). Но переводить Стандарт не понимаем зачем. Наоборот, вот перевёл бы кто нашу Методику "ISO 15926 Outside" на английский... А то у самих время не доходит. Это точно бы уменьшило входной порог для многих и многих людей...

Ответ на комментарий