![[Home]](/~megera/oddmuse/zen3.gif)
VO с технологической точки зрения - это инфраструктура работы данных, ориентированная на программный доступ, т.е. оперирование данными из программ. Человеческие интерфейсы являются надстройкой над этим и рассматриваться не будут.
Целью VO является обеспечение астронома всей информацией, необходимой для научной работы, независимо от ее расположения, в виде, удобным для анализа существующими и специально созданными инструментами VO.
Данные - неоднородные, распределенные. Человеку требуется немало сил и знаний, чтобы понять как их найти, получить и воспользоваться. Программе очень трудно это сделать, ей нужны стандартные форматы данных, стандартные методы доступа к данным, возможность обнаружения данных по запросу (с привлечением семантики!). Обладая этими возможностями, программы могут сами! находить данные, взаимодействовать с другими программами (которые предоставляют доступ к данным), анализировать и обрабатывать данные.
Примечание: данные - это результаты наблюдений, результаты компьютерных расчетов.
Примечание: данных может быть очень много - много по количеству записей, много по размеру объектов (большие изображения), что накладывает дополнительные требования на методы работы с данными, а именно - на их масштабируемость.
Таким образом, одной из задач VO является однородное представление неоднородных и распределенных данных, а также разработка стандартных методов доступа к данным для автоматизации поиска и обработки данных, что позволит масштабировать анализ данных при том росте количестве данных (data deluge) и их разнородности, который мы уже имеем и который неминуемо ожидает нас в будущем.
Данные необходимо как-то описывать, например, необходимо давать названия различным характеристикам рассматриваемого объекта, явления, события или понятия. Практически любое астрономическое наблюдение имеет пространственные и временные атрибуты - координаты объекта и момент времени наблюдения. Коль скоро с эти данными начинают работать несколько человек, этим атрибутам необходимо давать названия, их надо как-то обозначать. В пределах изолированной рабочей группы можно достаточно легко договориться о семантике этих названий и обозначениях, чтобы "разговаривать" друг с другом на одном языке.
Изолированность рабочих коллективов в прошлом привела к тому, что таких языков оказалось очень много, что очень затрудняло работу на "межколлективном" уровне. Одним из примеров является собственное движение звезд, которое имеет более 300! обозначений в каталогах центра астрономических данных в Страсбурге.
Метаданные - это данные о данных, предоставляющие описание контекста данных. Что можно сказать о вот таких данных 0:42:44.323992, +41:16:8.5299600000036 без их описания ? В данном примере, по формату можно догадаться, что это небесные координаты - прямое восхождение и склонение, но непонятна используемая система координат, эпоха. И если человек все-таки может вспомнить/предположить, что это координаты туманности Андромеды (M31) в экваториальной системе координат, эпоха 2000 года, то компьютеру это будет сделать весьма трудно.
Метаданные используются для описания и управления данными. Наиболее типичный астрономический пример - описания, которые находятся в заголовке FITS файла.
Метаданные бывают разных типов в зависимости от контекста их использования и типов данных:
Метаданные, несущие семантическую нагрузку, называются UCD (Uniform Content Descriptors). Их можно использовать, например, для сравнения данных из разных каталогов - для этого надо быть уверенным, что колонки содержат данные об одинаковых физических величинах.
UCD описывают астрономические величины и используют формальный словарь (список слов), описывающий астрономические данные, который был создан на основе анализа описаний более 5000 каталогов. Этот словарь поддерживается группой Семантики IVOA. UCD состоят из слов этого словаря, разделеных точкой, например, phot.color.excess означает фотометрический избыток цвета. Можно комбинировать несколько UCD, например, pos.eq.ra;meta.main описывает прямое восхождение в экваториальной системе координат. При этом, первое слово в UCD всегда несет основной смысл, в то время как следующие уточняют его. Иерархический формат записи UCD принят только для удобства (не подразумевается никакой модели), он понятен и человеку и компьютеру.
UCD используются для семантического описания данных в VOTable, ресурсов в реестрах данных, параметров пакетов VOEvent.
Феноменологическая природа UCD, сам способ их составления снизу-вверх, не позволяют детально описать данные, a только указать на их присутствие и их семантику. Например, возвращаясь к координатам туманности Андромеды, каким образом можно узнать, что величина 0:42:44.323992, имеющее UCD pos.eq.ra, требует другую астрономическую величину - склонение, чтобы вместе пределить позицию объекта на небе. UCD pos.eq.ra говорит нам только то, что эта величина есть прямое восхождение в экваториальной системе координат. Для того, чтобы ответить на вопрос нужно иметь модель данных, которая описывает элементы данных и их связи, в данном случае - модель позиционных данных, которая помимо координат может включать и ошибки их измерения. Вот модель человека от Юлия Кима:
Точка, точка, запятая - Вышла рожица кривая. Ручки, ножки, огуречик,- Получился человечек!
Эта шуточная модель, конечно неполная, но уже она показывает, что в этой модели требуются ручки и ножки, и не в единственном числе.
Современные астрономические данные очень разнообразны как по своей структуре, так и по способам хранения. Это связано, в частности с тем, что современные данные охватывают весь спектр электромагнитного излучения и в каждой области длин волн сложились свои представления о том, каким образом описывать данные (разная физика, разные инструменты). Для эффективной работы астронома необходимо иметь стандартизованные интерфейсы доступа к данным и метаданным, которые скрывают всю эту сложность и специфику. Для этого в VO разрабатываются модели данных, которые стандартизуют структуру и информационное наполнение метаданных.
Модель данных состоит из информации (атрибутов) и структуры, которая организует их (классы). Для описания моделей используются utype (user-defined type), синтаксис которых позволяет однозначно определить роль описываемого атрибута в конкретной модели данных. Например, в модели для описания пространственно-временных метаданных (STC), прямое восхождение имеет utype="stc:AstroCoords.Position2D.Value2.C1", а склонение - utype="stc:AstroCoords.Position2D.Value2.C2". Здесь префикс stc указывает на используемую модель, самый левый элемент AstroCoords обозначает класс, а самый правый C1 (C2) - собственно рассматриваемый атрибут.
<FIELD name="RAJ2000" ucd="pos.eq.ra;meta.main"
utype="stc:AstroCoords.Position2D.Value2.C1"
datatype="float" precision="4" unit="deg"
/>
<FIELD name="DEJ2000" ucd="pos.eq.dec;meta.main"
utype="stc:AstroCoords.Position2D.Value2.C2"
datatype="float" precision="4" unit="deg"
/>
Можно различать универсальные метаданные, которые действительны для любого типа данных, и специфические для описания основных классов астрономических данных (изображение, спектр, временные итд).
Основные универсальные метаданные - это
Кроме того, метаданные могут быть расширены для конкретной коллекции данных, чтобы более подробно описать именно эту коллекцию, например, можно добавить метаданные для описания конфигурацию инструмента, на котором были получены эти данные.
Примечание: UCD описывают только величины, размерности, но не объекты, процессы, понятия.
IVOA (www.ivoa.net) - международный союз национальных обсерваторий, призван координировать деятельность по стандартизации описания, доступа, поиска и публикации данных. Для этого в составе IVOA работают 9 рабочих групп.
Semantic group - группа, которая занималась разработкой UCD (Unified Content Descriptors), используемые для семантического описания каталожных данных и их обменом. UCD - это название атрибута в рамках предопределенной схемы (иерархический глоссарий научных значений астрономических данных), отражающее семантический смысл атрибута. Например, phot.count, phot.flux.density.sb, phys.luminosity. Можно объединять несколько UCD, например, stat.error;phys.temperature означает ошибку измерения температуры. UCD используются в стандартах VOTable, Registry, VOEvent, Cone Search и других. Также, популярные приложения Aladin, TopCat используют UCD. Наличие UCD позволяет автоматизировать обработку данных, например, можно определить какая колонка таблицы в VOTable формате содержит координаты на небе и отобразить источники на картинке. Последний список UCD1+ (версия 1.23, < 500 слов) доступен по адресу http://www.ivoa.net/Documents/latest/UCDlist.html. В настоящее время, помимо поддержки и развития UCD, она занимается обобщением UCD - SV (Standard Vocabulary) для описания астрономических объектов, типов данных, явлений, событий…., а также связями между словами, символами и понятиями.
Data Modeling (DM) - разработка инструментов и соглашений для описания моделей данных, которые описывают наблюдательные и симулированные данные. Группа разрабатывает модели данных:
Для описания моделей данных используются специальные атрибуты метаданных, которые называют utype (user-defined type), которые похожи на UCD, но в отличие от последних, которые описывают семантику значения, utype несут синтаксическую нагрузку и представляет собой иерархическое название атрибута модели данных, тем самым описывая роль атрибута в этой модели.
Data Access Layer (DAL) group - разработка стандартов VO для удаленного доступа к данным. Центры астрономических данных и обзоры могут использовать эти стандарты для разработки интерфейсов, совместимых с VO. С точки зрения архитектуры информационных систем, DAL - это программная прослойка между клиентским приложением и данными, которая обеспечивает независимость от размещения данных (приложению не нужно знать, где именно находятся данные), унифицированный интерфейс к данным ( не надо разрабатывать специализированный интерфейс к каждому центру данных), однородное представление неоднородных данных с помощью определения стандартных метаданных и, в некоторых случаях, стандартных моделей данных для представления реальных данных.
Наиболее важные стандарты:
Resource Registry - группа занимается разработкой документов, регулирующих работу реестров ресурсов и их имплементаций в соответствие с более общим стандартом W3C UDDI (Universal Description, Discovery and Integration), в частности:
Реестр ресурсов - это репозиторий описаний ресурсов, который поддерживает публикацию описаний ресурсов в соответствии с RM (Resource Metadata) и их поиск - справочная служба астрономических ресурсов. Унифицированный интерфейс для работы с реестрами позволяет осуществлять глобальный поиск по всем реестрам в конкурентном режиме. Найденные релевантные ресурсы выдаются в виде таблицы в формате VOTable, так что они могут быть автоматически обработаны клиентским приложением, которое может запросить более детально каждый найденный ресурс (службу). Реестры поддерживают обмен информацией между собой.
VOTable group - группа занимается разработкой и поддержанием VOTable - XML-стандарта для обмена данными, представленные в виде набора таблиц.
Существует много форматов для табулярных данных - обычные отформатированные таблицы, HTML таблицы, электронные таблицы, FITS таблицы (ascii и бинарные), реляционные таблицы в базах данных, но они все не содержат семантические метаданные, которые позволяли бы компьютерным агентам (программам) находить, анализировать и обрабатывать данные. Обычной практикой является сопровождения файлов с данными специальным документом, например, README, в котором содержится описание данных или ссылки на веб-страницы с подробным описанием. Очевидно, что такой формат, будучи вполне понятным человеку, не годится для компьютерной обработки. Кроме того, данные отделены от описания, что с течением времени может привести к потери семантической информации о данных.
FITS формат, принятый в астрономии, был одним из первых, который содержал метаданные вместе с самими данными, однако, FITS стандарт определяет только синтаксис файла, а не семантику. Формат VOTable (самый первый стандарт, принятый IVOA) основан на XML технологии, которая дает гибкость, интероперабельность, при этом поддерживается совместимость с FITS форматом. Метаданные в VOTable могут содержать ссылку на данные, которые могут находиться где-то в другом месте. Немаловажно также и то, что формат VOTable приспособлен для работы с очень большими массивами данных в распределенной инфраструктуре GRID (нет необходимости задавать количество строк в заголовке, как это требуется в FITS формате - NAXIS2).
VOTable таблица является неупорядоченным множеством строк однородной структуры, которая описана в метаданных таблицы, расположенных в заголовке таблицы. Метаданные могут быть семантическими (UCD) для описания колонок таблиц, логистические, описывающие типы данных и статистические для описания статистических свойств данных, содержащихся в таблице, например, количество записей, область неба, агрегаты по данным в колонках и т.д. Для примера приведем список некоторых основных атрибутов для описания одной колонки, которые задаются в поле <FIELD>:
VO Query Language - разработка универсального языка запросов для использования в приложениях, работающие с распределенными данными в рамках VO. VOQL стандарт имеет следующую структуру:
VO Event group занимается выработкой так называемого пакета VOEvent - пакет информации, необходимый для представления, передачи, архивирования и публикации открытия события на небе. Пакет содержит структурированную информацию об авторе открытия, типе, месте и времени события, метаданных инструмента, которая может быть легко обработана автоматическими системами. Для быстрой обработки пакета и его распространения пакет должен быть небольшим. Предполагается использование пакета VOEvent для работы автоматизированных роботов, оповещения астрономического сообщества, для создания интероперабельных архивов. Каждый пакет VOEvent получает уникальный идентификатор и хранится в базах данных и реестрах ресурсов VO, так что пакеты могут ссылаться на другие пакеты. Это позволяет фильтрацию пакетов используя заранее определенные критерии, заданные подписчиком. Для описания астрофизических объектов, процессов и инструментов используется контролируемый словарь, который разрабатывается рабочей группой Semantic. Кроме этого, группа разрабатывает расширение стандарта реестров VO VOEventStream, которое добавляет два новых типа ресурсов - VOEventStream и VOEventServer для описания коллекций событий и интерфейса службы, обслуживающей коллекции (рассылка событий, поиск событий).
Grid and Web Services - группа описывает использование грид-технологии и веб-сервисов в контексте VO, а также специфицирует и разрабатывает требуемые стандарты. Деятельность группы концентрируется в разработке следующих документов:
Applications - деятельность группы сосредоточена в основном на программном обеспечении, которое используют астрономы для доступа к данным и службам VO. Группа предоставляет средства для разработки и реализации VO приложений в соответствии с разработкой стандартов IVOA. Основные задачи группы:
There is still a lot of confusion in understanding of UCD and UTYPE, since they share the same syntax and sometimes have the same look. In my understanding, UCD were developed from bottom trying to classify already existed keywords to the managed structured set of metadata, while UTYPE were developed from scratch (but after UCD and with UCD knowledge) after some data modelling activity trying to create an elegant structured models for describing everything, so UTYPEs are about hierarchy, no semantics.
Ideally, at the beginning there are must be UTYPEs with real physical life incarnation as UCDs.
But, it happens the other way round, plus the same people are after UCD and UTYPE, plus the same syntax, so we now have what we have :) I think this is serious obstacle for adopting VO. I'd prefer to use different syntax, at least !
From 2004 discussion http://www.ivoa.net/forum/dm/0404/0408.htm
This generated from Roy:
> Haven't you just made an alternative set of UCD? No, I don't think so. They do different things. A UCD will tell you "This is a wavelength". A UTYPE will tell you "This is the 2nd axis of an array, and if you look over here I will tell you its UCD, which in this case happens to be wavelength". One is about what physics it is, and the other is about what role it is playing. Having done this and similar exercises recently has convinced me much more strongly that we need both. The fact that the data models need UCDs in various places, such as my example of "is this spectrumor " says to me that UCDs and data models are not the same thing, but in fact desperately need each other in a very interrelated way. The UCDs distinguish between identical data model instances representing different physics, and the data models say whether a particular UCD is being used as a value, an array axis, a table column, etc. as well as (once we define the models down to that level) saying what properties are associated with a UCD (a quantity whose UCD is phot.flux better have some kind of em.{wl,freq,energy} associated with it). I think the latter use case is much closer to having a danger of reinventing UCDs, but as I argue in the previous message, the way to serialize such models is exactly to use the UCD, rather than have separate UTYPEs. Bottom line: once we have a good set of data models and corresponding UTYPEs, if we did not also have UCDs we would have to invent them.
