А чем, например, семья или оркестр отличаются от велосипеда? Почему семья — это множество людей? А велосипед — это не множество велосипедных деталей? На мой взгляд, ничем. Некоторый атом является частью семьи точно так же как и некоторый другой атом является частью велосипеда :) Ну, т.е. в моём понимании не является ни первый, ни второй.
У меня идея следующая… Отношения "элемент — множество" и "часть — целое" нельзя разделить по наличию или отсутствию транзитивности. "Элемент — множество" видимо нетранзитивно. Но и отношения "часть — целое" могут быть нетранзитивными.
Система — это совокупность связанных элементов, обладающая некоторым новым качеством, которым не обладают элементы в отдельности. В этом плане биосфера, семья или оркестр — системы ничуть не хуже органа или молекулы. Зайцы едят траву, волки едят зайцев, волков после смерти едят черви и создают питательные вещества для растений, которые едят зайцы… Всё это не просто бессвязное множество растений, зайцев, волков,… А достаточно сложная система, из которой так просто что-то не выкинешь. Система не чуть не хуже автомобиля или чего-то подобного.
С точки зрения биологов эти уровни равнозначны. А с точки зрения 4D онтологии до какого-то уровня будет отношение часть-целое, а, например, начиная с популяционно-видового — элемент-множество?
Например,
клетка — часть органа
орган — часть организма
клетка — часть организма
клетка — это часть популяции?
клетка — это часть биосферы?
Я думаю, что нет, также как клетка не является часть организма. Т.е. я думаю, что все отношения "часть-целое" между уровнями тут не транзитивные. "Клетка — часть популяции" или "молекула — часть популяции" — по-моему это звучит очень похоже "на рука музыканта — часть оркестра".
При 4D интерпретации "дверная ручка — это часть дома", а "клеточное ядро — часть органа"? Тогда атом углерода — это тоже часть органа? Меня что-то в этом смущает… Тогда и рука музыканта может быть частью оркестра. Не могу сформулировать что именно меня смущает, но что-то тут не так.
По-моему это не плохие примеры не транзитивных отношений "часть-целое":
1) дверная ручка — часть двери, дверь — часть дома, но ручка — не часть дома
2) ядро — часть клетки, клетка — часть органа, но ядро — не часть органа
Я читал книгу "Business Objects: Re-Engineering for Re-Use", но на практике никогда не применял...
Даже если исключить отношение "элемент — множество", всё-равно отношения "часть — целое" слишком разные. Например, в стакан налита вода, мы можем взять любую часть этой воды, часть всё-равно будет водой. А дерево (часть леса) сильно отличается от леса. Или, если с машины снять колеса, она всё-равно останется машиной. А разложить машину на железо, кремний и т.п. уже проблематично и после этого она перестанет быть машиной.
Нашёл более адекватные примеры (Achille C. Varzi. A Note on the Transitivity of Parthood):
1) дверная ручка — часть двери, дверь — часть дома, но ручка — не часть дома
2) ядро — часть клетки, клетка — часть органа, но ядро — не часть органа
3) и снова про руку, на этот раз музыканта, которая не является частью оркестра
Тут приводится пример:
холодильник — это часть кухни (вид отношения: component — integral object)
кухня — это часть дома (вид отношения: place — area)
но холодильник — это не часть дома
Авторы поясняют отсутствие транзитивности тем, что тут разные виды отношений "часть — целое". Хотя пример какой-то не очень очевидный.
Также там приводится пример "рука — часть Боба, Боб — член кафедры, но рука Боба — не является частью кафедры". Не думаю, что кафедру можно рассматривать как множество сотрудников...
Кстати тут приводится пример
(11) The goalie is part of the team (вратарь — это часть команды)
и далее говорится, что нет согласия среди исследователей считать это мереологическим отношением или нет:
As for cases such as (11), there is disagreement concerning whether teams and other groups should be regarded as genuine mereological wholes, and while there are philosophers who do think so (from Oppenheim and Putnam 1958 to Quinton 1976, Copp 1984, Martin 1988, and Sheehy 2006), many are inclined to regard groups as entities of a different sort and to construe the relation of group membership as distinct from parthood (see e.g. Simons 1980, Ruben 1983, Gilbert 1989, Meixner 1997, Uzquiano 2004, Effingham 2010b, and Ritchie 2013 for different proposals).
Некоторые в принципе говорят, что мереологические отношения должны быть транзитивными, а если это не так, значит это какой-то другой вид отношения. Но единственно правильной классификации мереологических и не мереологических отношений я не видел.
В общем-то я со многим согласен. Буквально на днях сравнивал два документа по разным стандартам. Пересечение было на 1/4, не хватало примерно 800 элементов, а пара тысяч элементов наоборот была избыточной. С разработкой и внедрением стандартов связано действительно очень много проблем и сложностей. Но тем интересней эта задача!
Лично я гораздо больше занимался самими стандартами, чем их внедрением (невозможно заниматься всем). К последнему относился как к сугубо технической задаче. Мне конечно и раньше были знакомы все эти проблемы 1) гигантских суперструктур, с кучей лишних полей 2) чрезмерная сложность некоторых стандартов 3) сложность настройки под конкретные процессы. Но сейчас они проявились совершенно отчетливо. Об этом не принято что ли говорить, обычно говорят о том сколько денег сэкономит внедрение стандарта и на сколько он упростит жизнь. Спасибо за статью и обсуждение.
Согласен, если взаимодействуют две организации, то им не нужна 3-я организация, которая будет разрабатывать какие-то стандарты и т.п. Но если речь идёт о большом количестве участников, об отраслях, то без стандартов никак. Для примера, вот, XML-схемы ISO 20022. Вы действительно считаете, что этот стандарт — пустая трата денег и 2 банка как-нибудь сами между собой договорятся, сами сделают WSDL+XSD какие им нужны и всё?
Допустим, тот же пример с банком и налоговой. Налоговая запилила WSDL, в котором описана служба TransactionAckReceiver, которая может принимать уведомления об оплате с определенной XML-схемой.
Банковая ИС смотрит этот WSDL. Она не сможет автоматически понять, что уведомление об оплате нужно отправлять именно службе TransactionAckReceiver, а не какой-то другой. Банку и налоговой нужно предварительно договориться, что эта служба должна называться именно так. Это не происходит автоматически без участия человека.
Затем, налоговая в XML-схеме уведомления сделала обязательный элемент «код бюджетной классификации платежа», а ФИО плательщика описала в виде 3-х отдельных элементов: фамилия, имя и отчество. Причем, фамилия — обязательный элемент.
Какой-нибудь исландский банк пытается отправить в нашу налоговую уведомление об оплате. У него есть WSDL, XSD. Но это никак не поможет ему заполнить поле «код бюджетной классификации», ну, потому что в их ИС это поле просто не предусмотрено, не откуда взять этот код. И никак не поможет ему заполнить обязательное поле «фамилия», потому что у исландцев нет фамилий.
Эти согласования не могут быть сделаны автоматически. Сначала должны договориться чиновники о том, что в принципе такое взаимодействие между банками и налоговой должно быть. На реализацию всего этого должны быть выделены деньги. Потом аналитики, предметники (банковские и налоговики) читают нормативные документы, плотно общаются друг с другом. Пока не договорятся о том должна быть фамилия обязательным элементом или нет. Фиксируют все свои договоренности в виде документов, которые утверждаются чиновниками. И только после этого программисты начинают пилить свои WSDL, XSD и т.п. Причём, набор элементов данных, правила их именования, заполнения и т.п. программисты воспринимают как само собой разумеющееся. Хотя на это-то как-раз и ушла основная часть времени и денег. Реализовать теперь всё это теперь в синтаксисе EDI, XML, JSON или чём-то ещё — это дело техники.
Ценность EDI как-раз в том, что там уже пройден весь этот путь для разных видов сообщений. Чиновники, крупный бизнес договорились о том, что сообщения должны быть такие-то. В них должно передаваться то-то. То, что синтаксис EDI не очень, ну, это печально, но не на столько, чтобы тратить деньги на переход на XML. Синтаксис — это уже незначительные технические детали. Которые конечно нужно совершенствовать, и это делается, но медленно, потому что затраты на этот переход очевидны, а существенный положительный эффект не очень очевиден.
А как банк и налоговая договорятся о формате сообщения? Налоговая будет договариваться с каждым банком отдельно? А если банкам нужно передавать сведения о платежах не только в налоговую, но и в ГИБДД или таможню? Банкам придется договариваться с ними тоже о формате уведомления?
Т.е. классификаторы должны кому-то принадлежать. И уж точно не EDI (или подобному) комитету. Коды химич.составов — организациям, лицензирующим эти составы. Коды лекарств — тем, кто лицензирует лекарства (т.е. поддерживает базы кодов).
Ну, да, а если эти организации по какой-то причине не сделали нужный классификатор, то напишем им гневное письмо: ну-ка быстро запилили нам классификатор, это ваша обязанность :) Например, 19 или 21 рекомендации (виды транспорта, упаковок).
единые наборы элементов данных и — единые структуры сообщений: вещь бесполезная
Допустим, вы передаёте сведения о какой-нибудь товарной партии. Как вы назовёте эту сущность «Партия товаров», «Товарная партия» или ещё как-то? А её содержимое: «Единица товарной партии», «Товар», «Товарная позиция», «Сведения о товаре»? Отправителя: «Отправитель», «Грузоотправитель», «Отправитель груза»? Сведения об отправителе вы вложите внутрь сведений о товарной партии или на тот же уровень? Какие сведения об отправителе будете передавать: полное и краткое наименование организации или достаточно только полного. А какая максимальная длина для наименования? 100, 200, 300, 500 символов? А если отправитель — это физическое лицо, то его ФИО вы будете передавать в поле «Полное наименование» или в отдельных полях «Фамилия», «Имя», «Отчество»? А какие из этих полей вы сделаете обязательными? А что если в некоторых странах нет фамилий и т.п.
Таких вопросов миллион.
Допустим, в вашей организации есть какие-то нормативные документы, в которых описано как всё это должно называться, структурироваться и т.п. Ну, а в другой организации свои нормативные документы, и, вообще, она находится в другой стране с другим законодательством. Вы представляете сколько нужно человековеков, чтобы создать единый реестр элементов данных?
Да, EDI включал в себя очень много всего: протоколы, форматы и т.п. Сейчас появились лучшие протоколы, лучшие форматы. Но EDI этим не ограничивается. В первую очередь — это единые наборы элементов данных, единые структуры сообщений, единые классификаторы. Я по своему опыту знаю какая это титаническая работа. К тому же, они не дураки и давно есть XML-решения: CCTS, CCL, UBL и т.п.
Это всё техника. Например, есть модель данных Всемирной таможенной организации. В ней гигантские информационные пакеты с кучей полей на все случаи в жизни, как вы пишите. Есть, скажем, странные вещи. Но использовать её или нет — это не технический вопрос, а политический. 99% времени и денег уходит на работу аналитиков, а 1% — работа программистов. Не нравится эта модель? Ну, попробуйте сделать свою, попробуйте утвердить её в виде стандарта, попробуйте убедить перейти всех на вашу модель. В итоге вы придёте к тому, что нафиг весь этот геморой, нужен EDI значит будем использовать EDI.
Основная цель всех этих стандартов — это гармонизация данных. Чтобы какие-нибудь организации в Гондурасе и Австралии одинаково именовали элементы данных, одинаково понимали что за данные передаются или требуется передать. Это ради чего всё это делается. А то, что программист потратит 10 часов вместо 5 часов на реализацию какой-то фичи — это второстепенно и не играет особой роли. Основное время и деньги тут тратятся на совершенно другие вещи.
Согласен, не имея спецификацию сообщения, в нём не возможно ничего понять. В отличие от XML-документов, структура которых понятна даже без схемы и спецификации. И в целом с XML конечно проще работать, тут сложно поспорить. А есть же вроде всякие XMI/EDI или ASC X12 Context Inspired Component Architecture? Я с EDI дело особо не имел. В нашей области стандарты в основном уже более или менее синтаксически нейтральные или с уклоном в XML (CCTS, WCO DM, NIEM, ISO 20022 и т.п.).
Судя по номеру 835, похоже на Health Care Claim Payment/Advice. Нашёл только спецификацию, модель не нашёл. Остаётся видимо только вручную делать объектную модель. Или брать такие таблички из спецификации
переводить их в Excel, csv, xml,… формат.
И запилить генератор, который будет делать из них объектную модель. Чтобы вручную не писать весь этот код, наверное, так было бы проще.
У меня идея следующая… Отношения "элемент — множество" и "часть — целое" нельзя разделить по наличию или отсутствию транзитивности. "Элемент — множество" видимо нетранзитивно. Но и отношения "часть — целое" могут быть нетранзитивными.
Если ядро клетки, входящей в колониальный организм — это часть организма. То почему рука не может быть частью семьи?
С точки зрения биологов эти уровни равнозначны. А с точки зрения 4D онтологии до какого-то уровня будет отношение часть-целое, а, например, начиная с популяционно-видового — элемент-множество?
Например,
клетка — часть органа
орган — часть организма
клетка — часть организма
клетка — это часть популяции?
клетка — это часть биосферы?
Я думаю, что нет, также как клетка не является часть организма. Т.е. я думаю, что все отношения "часть-целое" между уровнями тут не транзитивные. "Клетка — часть популяции" или "молекула — часть популяции" — по-моему это звучит очень похоже "на рука музыканта — часть оркестра".
1) дверная ручка — часть двери, дверь — часть дома, но ручка — не часть дома
2) ядро — часть клетки, клетка — часть органа, но ядро — не часть органа
Даже если исключить отношение "элемент — множество", всё-равно отношения "часть — целое" слишком разные. Например, в стакан налита вода, мы можем взять любую часть этой воды, часть всё-равно будет водой. А дерево (часть леса) сильно отличается от леса. Или, если с машины снять колеса, она всё-равно останется машиной. А разложить машину на железо, кремний и т.п. уже проблематично и после этого она перестанет быть машиной.
1) дверная ручка — часть двери, дверь — часть дома, но ручка — не часть дома
2) ядро — часть клетки, клетка — часть органа, но ядро — не часть органа
3) и снова про руку, на этот раз музыканта, которая не является частью оркестра
холодильник — это часть кухни (вид отношения: component — integral object)
кухня — это часть дома (вид отношения: place — area)
но холодильник — это не часть дома
Авторы поясняют отсутствие транзитивности тем, что тут разные виды отношений "часть — целое". Хотя пример какой-то не очень очевидный.
Также там приводится пример "рука — часть Боба, Боб — член кафедры, но рука Боба — не является частью кафедры". Не думаю, что кафедру можно рассматривать как множество сотрудников...
Кстати тут приводится пример
(11) The goalie is part of the team (вратарь — это часть команды)
и далее говорится, что нет согласия среди исследователей считать это мереологическим отношением или нет:
Некоторые в принципе говорят, что мереологические отношения должны быть транзитивными, а если это не так, значит это какой-то другой вид отношения. Но единственно правильной классификации мереологических и не мереологических отношений я не видел.
Лично я гораздо больше занимался самими стандартами, чем их внедрением (невозможно заниматься всем). К последнему относился как к сугубо технической задаче. Мне конечно и раньше были знакомы все эти проблемы 1) гигантских суперструктур, с кучей лишних полей 2) чрезмерная сложность некоторых стандартов 3) сложность настройки под конкретные процессы. Но сейчас они проявились совершенно отчетливо. Об этом не принято что ли говорить, обычно говорят о том сколько денег сэкономит внедрение стандарта и на сколько он упростит жизнь. Спасибо за статью и обсуждение.
Банковая ИС смотрит этот WSDL. Она не сможет автоматически понять, что уведомление об оплате нужно отправлять именно службе TransactionAckReceiver, а не какой-то другой. Банку и налоговой нужно предварительно договориться, что эта служба должна называться именно так. Это не происходит автоматически без участия человека.
Затем, налоговая в XML-схеме уведомления сделала обязательный элемент «код бюджетной классификации платежа», а ФИО плательщика описала в виде 3-х отдельных элементов: фамилия, имя и отчество. Причем, фамилия — обязательный элемент.
Какой-нибудь исландский банк пытается отправить в нашу налоговую уведомление об оплате. У него есть WSDL, XSD. Но это никак не поможет ему заполнить поле «код бюджетной классификации», ну, потому что в их ИС это поле просто не предусмотрено, не откуда взять этот код. И никак не поможет ему заполнить обязательное поле «фамилия», потому что у исландцев нет фамилий.
Эти согласования не могут быть сделаны автоматически. Сначала должны договориться чиновники о том, что в принципе такое взаимодействие между банками и налоговой должно быть. На реализацию всего этого должны быть выделены деньги. Потом аналитики, предметники (банковские и налоговики) читают нормативные документы, плотно общаются друг с другом. Пока не договорятся о том должна быть фамилия обязательным элементом или нет. Фиксируют все свои договоренности в виде документов, которые утверждаются чиновниками. И только после этого программисты начинают пилить свои WSDL, XSD и т.п. Причём, набор элементов данных, правила их именования, заполнения и т.п. программисты воспринимают как само собой разумеющееся. Хотя на это-то как-раз и ушла основная часть времени и денег. Реализовать теперь всё это теперь в синтаксисе EDI, XML, JSON или чём-то ещё — это дело техники.
Ценность EDI как-раз в том, что там уже пройден весь этот путь для разных видов сообщений. Чиновники, крупный бизнес договорились о том, что сообщения должны быть такие-то. В них должно передаваться то-то. То, что синтаксис EDI не очень, ну, это печально, но не на столько, чтобы тратить деньги на переход на XML. Синтаксис — это уже незначительные технические детали. Которые конечно нужно совершенствовать, и это делается, но медленно, потому что затраты на этот переход очевидны, а существенный положительный эффект не очень очевиден.
Допустим, вы передаёте сведения о какой-нибудь товарной партии. Как вы назовёте эту сущность «Партия товаров», «Товарная партия» или ещё как-то? А её содержимое: «Единица товарной партии», «Товар», «Товарная позиция», «Сведения о товаре»? Отправителя: «Отправитель», «Грузоотправитель», «Отправитель груза»? Сведения об отправителе вы вложите внутрь сведений о товарной партии или на тот же уровень? Какие сведения об отправителе будете передавать: полное и краткое наименование организации или достаточно только полного. А какая максимальная длина для наименования? 100, 200, 300, 500 символов? А если отправитель — это физическое лицо, то его ФИО вы будете передавать в поле «Полное наименование» или в отдельных полях «Фамилия», «Имя», «Отчество»? А какие из этих полей вы сделаете обязательными? А что если в некоторых странах нет фамилий и т.п.
Таких вопросов миллион.
Допустим, в вашей организации есть какие-то нормативные документы, в которых описано как всё это должно называться, структурироваться и т.п. Ну, а в другой организации свои нормативные документы, и, вообще, она находится в другой стране с другим законодательством. Вы представляете сколько нужно человековеков, чтобы создать единый реестр элементов данных?
переводить их в Excel, csv, xml,… формат.
И запилить генератор, который будет делать из них объектную модель. Чтобы вручную не писать весь этот код, наверное, так было бы проще.