Открытое письмо по универсальному обменному астрологическому формату.
Всем добрый день.
Причины побудившие меня поднять данный вопрос.
1. В настоящее время существует достаточное количество астрологических программ. Все они оперируют примерно одним набором данных для построения и анализа карт.
2. Между этими программами, как переходный слой, существуют конверторы для экспорта и импорта данных из одной программы в другую. Форматов хранения данных карт (событий) и обмена большое множество.
3. В сети (и у астрологов в том числе) существует достаточно много накопленных данных (не приватных и закрытых, а тех, которые публичны или которые можно отдать в общее пользование). И, как правило, они представлены в форматах, которые часто недоступны астрологу (не программисту) без конвертирования для работы.
4. Легче один раз создать и проверить наборы данных, нежели перенося их врукопашную, плодить оЧЕпятки.
В связи с этим возник вопрос: "Почему бы не договориться и не сделать достаточно простой универсальный астрологический обменный формат, который бы позволил без проблем переносить общедоступные базы данных в свою любимую программу?"
И раз уж делать этот обменный формат, хорошо бы было предусмотреть не только хранение и передачу обычных признаков (дата-время, координаты, временная поправка и т.д.), но и те, которые бы позволили выполнять автоматическую (автоматизированную) обработку и анализ этих данных. Например, чтобы понять, а что же общего и какие небесные объекты влияют на тему брака , необходима привязка события темы 7 к его натальной карте, а также точность данного события, ибо нет смысла, например, анализировать аспекты от куспидов в минорной прогрессии, при точности события в несколько часов. Это простой пример, но он даёт возможность понять, что для анализа (если такой потребуется) для автоматизации процесса понадобится прибегнуть к дополнительным признакам. Вместе с тем никто не принуждает наделять этими дополнительными признаками свои данные. Главное, чтобы формат позволял, при необходимости, оперировать ими.
Вот и возникла идея создать такой общий формат обмена астрологическими данными.
Так появился CALIF - (Common AstroLogical Interchange Format) - общий формат обмена астрологическими данными. По этому случаю была создана спецификация, примеры и стартовый набор из 9 банков данных различной направленности (часть этих банков взял из сети и преобразовал в формат CALIF).
Данный формат позволяет:
• Организовать хранение данных в древовидной структуре с любой конфигурацией папок.
• Может оперировать частными признаками, присущими только конкретной программе.
• Позволяет автоматизировать астрологический анализ, поиск карт и событий по ряду признаков (тип карты, точность событий, темы кверента и квезита, связывать события с базовыми натальными картами, анализировать количественные величины (например, изменение курса валюты для конкретной биржи) и т.д.).
• Не зависит от форматов хранения данных (дата-время, координаты, знак временной поправки и т.д.), присущих конкретной стране или сообществу астрологов.
• Расширяем, что позволяет легко вводить иные, используемые только конкретной программой, расширения данных.
• Поддерживает любые языки и не зависит от национальной кодировки (использует UNICODE).
• Открыт и прост в реализации, так как представляет собой XML-файл.
Предлагаю обсудить, доработать (если потребуется) и внедрить в своих программах этот формат во благо Астрологии и на радость Астрологам :)
Найти всю необходимую информацию по документации, примерам и стартовым наборам данных можно здесь:
А почему нельзя использовать нормальные, читаемые человеком значения для тех же даты, времени, географических координат? Я использовал XML для хранения данных в своем AstroZaur, ИМХО можно сделать все намного проще и прозрачней
Сделать можно всё :)
А если серьёзно то:
- это независимость от языка (например, june-июнь) и его разбора или
- независимость от представления (нотация США месяц-день-год, нотация Германии как и у нас) или
- независимость от разделителя (точка, косая черта, дефис и т.д.).
- и т.д.
Да, позволяет, только:
- не все астрологические программы оперируют развитыми деревьями базы данных;
- существует принципиальное отличие ветки от листьев;
- и.д.
Да-да. Стандартов - пруд пруди. Один из них я и использую, как наиболее бесконфликтный для обмена - ISO 8601 Data elements and interchange formats - Information interchange - Representation of dates and times. И представляю дату-время в сжатом виде без лишних символов, чтобы избавить от дальнейшего недоразумения, которое обязательно бы возникло. Моя специализация - базы данных, в частности RDDMS Oracle. А писать приходится не только для россиян… Поэтому знаком не понаслышке про проблемы обмена данными с дата-время и вещественными типами.
:) Не будем упрощать. Есть БД астрологических программ, где хранение задаётся тремя уровнями (например, SkyWorker). Есть и плоские исполнения, а есть и более продвинутые варианты. А формат - универсальный. Он должен удовлетворять любому варианту.
Отнюдь, сказал граф гремя манжетами и дико заржал... :)
Папка - ветвь, файл - лист. Это Вы и сами знаете, я уверен. Папка отличается от листа тем, что лист (карта или событие) конечен и наделён определёнными признаками, характерными для карты. Можно, конечно, обойтись без признака "папка", например, по пустому значению даты-времени, но это не универсально, так как не все системы поддерживают тип DateTime=null. Есть и ещё проблемы. Но это уже детали, не будем о грустном :). Поэтому здесь явным образом указывается признак "папка". Если хотя бы одна из миллиона (достаточно большое преувеличение) астрологических программ будет нуждаться в этом признаке (а это уже факт) - его обязательно надо вводить.
Вот и начинается… :)
1. Если посмотреть на стандарт, описанный документом RFC3339 (как следствие вышеописанного стандарта), то дата там представляется в виде 1985-04-12, но это так, к слову. К тому же это стандарт для представления в Интернет. Астрологические программы - далеко не интернет-системы… Что говорить про стандарты, когда HTML и тот в расширениях повяз. И мучаются программисты, делая ветки для конкретного браузера…
2. Для временной зоны "до минут" - маловато (но это, конечно же проблема. Просто мелочёвка) и тем не менее:
- до ввода поясного времени жили по солнечному, а кое-где и даже по истинному солнечному и долготы не у всех кратные…;
- среди временнЫх поправок видел и до секунд. Но сейчас не помню в каком пункте..
3. "+" для европейцев это восточнее Гринвича, а для америкосов - наоборот. А вот это уже серьёзнее. Плавали - знаем ;)
Проанализировав множество программ и форматов представления, собственно и пришёл к CALIF. Вероятнее всего он не идеален, ибо существуют же различные стандарты USB-разъёмов и каждый выполняет свою роль.
И, наконец, в любой живой программе можно найти недостатки. Это нормально. Ибо идеальная программа - мёртвая программа, так как по определению лишена недостатков :) И то, что возникают вопросы - это правильно и хорошо. Главное не уходить в сторону.
Когда приходится выбирать, то, как правило, выбираю то, что более "стандартно" (универсально или поддержано). В данном случае XML вне конкуренции. У XML-данных один недостаток - они слишком тяжелы по весу (тегов много, а информации мало). Но с этим приходится мириться. Здесь важнее доступность и простота реализации. Как в анекдоте "Мы кормим быстро, вкусно и дёшево". Выберите 2 из 3-х…
Что же до читабельности данных, то ознакомившись с описанием, уже через 5 минут Астролог будет понимать, о чём речь. Только вот зачем это нужно Астрологу? :) Взял данные, перегнал и забыл, что есть CALIF. На то он и "на час" :)
Главное - чтобы его любимая программа знала, что есть CALIF.
И я что тогда считал это пустой затеей, что сейчас считаю также.
Для передачи коллегам-друзьям использую формат ZET, у него куча недостатков (например кодировка win1251, отсутствие понятий "первообразной" и "производной" карты, отсутствие тематических полей кроме коментария) но ZET у любого найдется Lite версия )
Сам бы пользовался XML, он масштабируем до бесконечности, можно учесть и дерево, и производные карты разного типа, пользовательские поля (см "букмекерские кэфы", "результат матча", "минуты забитых голов", "футболистов забивших" и ссылки на космограммы самих футболистов и кучу ещё всего разного).
Произвольный формат позволяет и произвольные запросы. Из всех известных на сегодня мне форматов, только XML такое может "из коробки". Но не могут астропроцессоры (к счастью или сожалению). Пока вы не замучаете насмерть всех авторов АП написать процедуры экспорта/импорта в ваш формат - он обречен.
Вот Вам задача на засыпку - напишите и опубликуйте программу переноса из CALIF в формат Germes[DOS] 1.84
Жёсткая типизация... Это мне напомнило историю, когда в конце 80-х попёрли наши ПЭВМ и разработчики решили, что шины в 16 бит многовато. Вполне хватит и 12. Сэкономили… :) Да к тому же ПЭВМ - это не только железо, но и программы. Коих у каждого было аж штук по 5! А тем временем ZX-Spectrum на Z-80А давал фору IBM... Я уже в предыдущем посте объяснил, насколько хорош общий вариант и нехорош хороший, но частный :) Извините за тавтологию.
Как "базовик-затейник" (см. пред-предыдущий пост) я в некотором роде понимаю Вас, ибо для меня не существует проблемы преобразования данных. Но я думаю о тех, кто таким "даром" не обладает (это честный альтруизм, ибо знаю себя и свой Гороскоп: как писал в предыдущем форуме, я ещё и маргинал, потому что к тому же достаточно много практикую. Выглядит как хвастовство ("звиняюсь" :) ), но это не "демонстрация мышц", а аргумент в сторону знаний Астрологии).
Да, это выход. Не оптимальный, но тем не менее, выход. Иногда в такой цепочке бывает по нескольку импорт-экспорт. Но это выход для частного решения, но не для системного.
Я склоняюсь больше к "сожалению". Перефразирую Владимира Владимировича: "Я ВЕРЮ - город будет, я знаю - саду цвесть" . :)
Время покажет :)
Не проблема. Даже выделю время в жёстком графике разработки инструментов , но при некоторых условиях.
1. Это не условие, а вопрос, ибо не знаю Гермес (слышал, но не юзал) - в какие форматы экспортирует он свои данные, чтобы не "гнать волну" :). Вопрос не праздный, так как поддерживает априори, а импортирует из следующих программ:
- SkyWorker (cat)
- SkyWorker (txt)
- Sotis (sbn)
- ZET (zbs)
- Quick Charts (qck)
- Janus (jie)
- Uranus (bod)
И если окажется, что есть пересечение множества, то вопрос решится банальным вариантом, который Вы описали выше. А про экспорт париться не стоит, ибо автор должен знать свою программу лучше, чем "кул-хацкер".
Иначе - идут условия (надеюсь, простые):
Вы предоставите мне несколько баз данных Гермес с множеством вариантов для отработки и тестирования конвертора, чтобы я смог оттестировать конвертор (вернее "импортёр" в CALIF, ибо "экспортёр" делать не буду - я не автор Гермес (см. выше)).
Очень-очень желательно, чтобы среди этих баз были полезные для астрологического сообщества. Работа - работой, но волонтёрство должно быть полезно для других.
Думаю, что условия достаточно простые, чтобы их выполнить.
Нет, все будет немного не так. Базы данных Гермес несколько странные (хотя я не понимаю зачем). Автор решил ограничить выдачу дополнений к Гермесу, в том числе и для работы с базами только зарегистрированным пользователям (хотя я тоже не понимаю зачем, ведь регистрация бесплатна). У меня не хватило времени разбираться файлами, которые он предлагает, хотя я регулярно страдаю от невозможности переноса баз именно в Гермес.
Давайте пойдем стандартным путём (для начала).
Вы скачаете Гермес, заполните регистрационную анкету, отправите Константину, а он Вам выдаст доступ к дополнениям.
Или после двухнедельной паузы эти файлы я дам Вам сам, потому что на своём форуме Константин не появляется уже год, форум заспамлен.
Как мы знаем, на "родине астропроцессоров" - Украине происходят не слишком веселые события, я надеюсь с ним всё в порядке, но мало ли.
Файлы БД Гермеса весьма сложночитаемые (двоичный формат), поэтому анализировать их дело неблагодарное.
Не буду здесь описывать, почему старое досовое приложение мне так ценно, но там действительно реализован ряд вещей, до которых Зайцеву ещё расти и расти :)
Странные потому, что бинарные? Да просто так проще было сериализовать, очевидно.
Я загрузил и установил программу. Она работает без регистрации. Незарегистрированная версия не имеет таблиц временных поправок. Да это и не важно, ибо судя по тому, как они нерегулярно обновляются, пользоваться ими нельзя. Посмотрел библиотеки карт - их всего 5 в общей сумме порядка 120 карт. Маловато, однако :(
Что Вы имеете в ввиду под дополнениями? Это ресурсы, которые у Вас на картинке? Если Да, то для Вас там будет интересен только один архив - DAT2GLB.ZIP (об этом ниже)
Если же Вы имеете в виду это базы населённых пунктов (PLACES.DBP) и исходный файлы поправок (pop_s.rar и tz_source.zip), то их кромсать я не буду по той причине, что это:
1. устаревшие данные (я в (см. GalaxyLocator) содержу несколько альтернативных таблиц изменения времени из разных источников и регулярно обновляю временнЫе поправки, да и база координат у меня более 3 млн. записей);
2. это не этично…
Если же базы данных карт (в программе называются Библиотеки. Например, Американские президенты USPRES.GLB), то это другое дело. Сделать конвертор из Гермес в - можно. Правда из-за скудности библиотек (см. выше) делать это не очень хочется. Но насколько я понял, Вас интересует обратный процесс (см. ниже)?
Это бинарные файлы и, конечно же, они не для простого глаза. Но для этого есть специальные программы типа HEX-редакторов или IDA - интерактивный дизассемблер.
А вот это уже обратный процесс. Про конвертор вида из сторонней программы в Гермес - это дело автора. Я об этом писал в предыдущем посте. Всё дело в том, что каждый автор пишет конверторы (импортёры) с целью помочь пользователям перетащить накопленные ими данные из ранее использованной программы в программу автора (в данном случае - Гермес). И это дело исключительно каждого автора. Ну зачем же сторонний программист будет тратить время на чужую программу? Это не логично со всех сторон. Иное дело - написать экспортёр из Гермес в . Т.е. помочь астрологам взять накопленные данные в Гермес и перенести их в другую программу.
Судя по картинке, которую Вы указываете, последним пунктом идет импортёр из CSV в Гермес. CSV - простой текстовый формат с разделителем в виде запятой, символа табуляции или какого-либо другого. Его легко создать. Он понимается Excel. Вот из него Вы можете спокойно перегнать свои данные в Гермес.
Что я могу сделать для Вас, не создавая конвертор в Гермес, так это вот что:
1. В Galaxy есть импорт из программ, список которых я написал в предыдущем посте.
2. С помощь GalaxyDataWorker (она входит в бесплатный пакет программ ) Вы импортируете свои данные в формат Galaxy и после экспортируете в формат Excel
3. Открываете в Excel и сохраняете в CSV формат.
4. Далее импортируете конвертором DAT2GLB в Гермес.
В этом методе единственное узкое место - так как у меня нет примеров CSV-файла, то я не знаю, в каком формате в CSV должны храниться дата-время, координаты, временные поправки и их порядок следования. Если будет формат этих данных и пример CSV-файла, то я смогу Вам помочь преобразовать Ваши данные. Только так.
Общий формат (хоть какой-нибудь) конечно нужен, но вряд ли в обозримом будущем удастся это дело реализовать на практике.
Для это нужно в этом заинтересовать хотя бы несколько крупных производителей астрософта (Zet, SF) в надежде на то, что другие за ними потянутся, а для этого нужно как минимум:
1. предоставить им API (простое, платформо-независимое и вообще идатое), которое можно бы было без проблем прикрутить к их софту. А без проблем не получится, хотя бы потому что разные программы хранят в файлах данных разную, зачастую неожиданную информацию.
2. Крупные производители софта явно не заинтересованны в общем формате. Например, в составе ZET когда-то был конвектор, который позволял конвертировать базы из старых версий SF в формат ZET, но не обратно. Зайцев одно время явно пытался сделать формат ЗЕТ стандартом, у него даже на форуме была возможность копировать карты в формате csv в буфер и она вставлялась в программу, но что-то стандартом этот формат не стал, даже несмотря на свою простоту и кучу API для работы с csv. Хотя на мой ИМХ - в смысле не изобретения велосипеда - это самое оптимальное SF в свою очередь вообще выкладывать формат своих баз в открытый доступ, с такой политикой они вряд ли станут заморачиваться вашим форматом. А без привлечения как минимум этих 2х игроков на рынке астрософта у вас точно не получится никаких "стандартов"
3. единственный стандарт в мире астрософта, который прижился - это швейцарские эфемериды, но это потому что они экономят кучу времени и сил и избавляют от почти всех проблем с астрономическими расчетами. Ваша же идея хорошая, но не дает никаких конкурентных преимуществ и скорей создает новые проблемы для разработчиков, чем решает старые. Поэтому на мой ИМХ - это мертворожденный ребенок
Как человек имевший дело с астрологической статистикой - скажу, что у Вас весьма наивное виденье проблемы
Веду работу с пока нашими производителями, ибо меня больше интересуют не программы, а Астрологи, которые бы могли использовать накопленные данные. И конечно же я понимаю, что эти пользователи зависят от программистов. Вода камень точит :)
API - уж точно утопия, ибо Вы сами на это предложение и ответили про хранимые форматы. С API будет больше работы, чем без него...
Я ещё не видел ни одного разработчика, который бы делал конвертор-экспортёр из своего формата в формат конкретной программы - это правильно и естественно. В лучшем случае, как например, , есть конвертор в общие, если так можно назвать, "форматы" (csv, txt). Это для того, чтобы облегчить работу тем, кто хотел бы без труда перетащить данные в другую программу.
Вся беда в том, что в мире существую различные представления дата-время, координат, знаков временнЫх поправок, разделителей в датах и т.д. Я об этом писал в предыдущих постах. А Анатолий Зайцев пошёл по пути наименьшего сопротивления - как отображаю, так и вывожу-ввожу - это путь не только не универсальный, но и тупиковый. Для одной программо-страны - это прокатывает и уже затыкаестя на той же программе, но при использовании данных из другой страны (это не только кодировка Win1251, но и формат представления даты, например, у америкосов месяц-день-год. Я об этом уже писал.
Универсальность подразумевает некоторую избыточную работу и это нормально.
CSV - простой, но не самый оптимальный. Тем более, что если говорить про CSV - то это всего лишь разделители, а не формат. Ибо в него всё же надо будет засовывать те же дату-время, координаты и тыды. В этом всё дело. К тому же в CSV существуют серьёзные ограничения. Ну, например, он строго типизирован - последовательность колонок (полей), он плоский и т.д. Всего этого лишён XML - практически сплошные достоинства кроме:
объёма полезной информации
отсутствия ссылочной целостности (и индексов).
Но как промежуточный формат - он очень хорош. Поэтому только XML.
Вода камень точит :)
Надо начать с малого - сделать конвертор SF-> - не проблема.
Для этого требуется:
Несколько примеров баз
Есть для демка SF чтобы я смог эти базы увидеть в программе.
Я бы сказал - один из стандартов, ибо некоторые программы используют другой интерфейс. Но SwisEph - это хорошо и правильно. Швейцарцы молодцы.
Часто (практически все в том или ином виде) разработчики всё же пишут конверторы из других форматов в свой.
Будет - будет один конвертор. И те разработчики, которые смотрят вперёд, а не себе под ноги - поймут.
Рынок динамичен и появляются новые интересные астрологические программы, а старые, как правило, "наворачиваются", загружаются и коллапсируют :) если разработчики не держат нос по ветру.
В отрасли IT (и у программистов в частности) есть очень меткое выражение - приходится бежать вперёд, чтобы оставаться на месте. Так что время пкажет.
:) Полностью согласен. Этот пример тривиален и приведён только лишь для того, чтобы "земные" Астрологи вникли в суть проблемы. Так что не судите строго :)
Вы абсолютно правы, когда рассуждаете с позиций производителя софта (импорт в МОЮ программу из чужих нужен, экспорт в чужие - не нужен). Хорошо укладывается в тренд Embrace, Extend, and Extinguish. Но мне в первую очередь интересен обмен с коммюнити, как мне передать данные одной или сотен карт людям?
Мне категорически не нравятся картинки с картой, которые регулярно постят на астрологических форумах. Восприятие карты у каждого сугубо индивидуальное, лучшее понимание будет когда карта будет построена в своём астропроцессоре, настроенным под те символы, цвета, направления колеса, орбисы и т.п. Я привык видеть карту не такой :)
Я пытаюсь себе представить, как реализовать это. Наверное идеальным был бы вариант нового протокола типа astro://json_xml_csv_file где как в mailto: открывался бы с картой либо локальный десктопный или (черт с вами) мобильный астропроцессор, либо какой-то веб-сервис, где карта строится с учетом персональных предпочтений. А далее я бы мог сохранить или не сохранить эту карту (или эти карты) в свою БД не задумываясь о форматах вообще. Но это все не в сегодняшних астропроцессорах, ессно.
"Приходится бежать со всех ног, чтобы только остаться на том же месте! Если хочешь попасть в другое место, тогда нужно бежать по меньшей мере вдвое быстрее!" это цитата Кэрролла к ИТ сфере... ну не знаю.
Да, и я не планирую пользоваться вашим "вдвойневкуснеем" просто потому что для меня это будет слишком трудоёмкий процесс, плюс аццкое неприятие ваших кислотных скриншотов. :)
Даже запариваться не надо - для одной карты можно и ручками...
Здесь есть и плюсы и минусы, но главный плюс картинки - ты видишь карту глазами Астролога, ибо здесь важны не только натальные данные, например, но и те орбисы и объекты карты, которые использовал Астрлолог. Иначе можно говорить о том, чего в Вашей карте не будет: кто-то использует узкие орбисы, а кто-то такие, что ни в одни ворота не лезет.
Правильнее бы было посылать и данные и картинку.
Это правильно. Каждый выбирает для себя то, к чему душа лежит. Я об этом не устаю говорить. Что же касательно цветовых схем, то в любой достаточно серьёзно программе они настраиваемы.
Прошу не обижаться, но эта тема о совершенно другом - об универсальном обменном формате . Если не цепляет, то лучше не говорить, ибо среди постов можно потерять суть вопроса.
А если серъезно. Если придерживаться сабж - то формат просто обязан быть читаем и записываемый человеком. И по аналогии с Эсперанто - "ни для кого не быть родным языком"
Последний раз редактировалось Strijar, 11.08.2014 в 13:18.
Общий формат обмена астрологическими данными
SF в свою очередь вообще выкладывать формат своих баз в открытый доступ, с такой политикой они вряд ли станут заморачиваться вашим форматом. А без привлечения как минимум этих 2х игроков на рынке астрософта у вас точно не получится никаких "стандартов" 
Линейный вид
