авторефераты диссертаций БЕСПЛАТНАЯ БИБЛИОТЕКА РОССИИ

КОНФЕРЕНЦИИ, КНИГИ, ПОСОБИЯ, НАУЧНЫЕ ИЗДАНИЯ

<< ГЛАВНАЯ
АГРОИНЖЕНЕРИЯ
АСТРОНОМИЯ
БЕЗОПАСНОСТЬ
БИОЛОГИЯ
ЗЕМЛЯ
ИНФОРМАТИКА
ИСКУССТВОВЕДЕНИЕ
ИСТОРИЯ
КУЛЬТУРОЛОГИЯ
МАШИНОСТРОЕНИЕ
МЕДИЦИНА
МЕТАЛЛУРГИЯ
МЕХАНИКА
ПЕДАГОГИКА
ПОЛИТИКА
ПРИБОРОСТРОЕНИЕ
ПРОДОВОЛЬСТВИЕ
ПСИХОЛОГИЯ
РАДИОТЕХНИКА
СЕЛЬСКОЕ ХОЗЯЙСТВО
СОЦИОЛОГИЯ
СТРОИТЕЛЬСТВО
ТЕХНИЧЕСКИЕ НАУКИ
ТРАНСПОРТ
ФАРМАЦЕВТИКА
ФИЗИКА
ФИЗИОЛОГИЯ
ФИЛОЛОГИЯ
ФИЛОСОФИЯ
ХИМИЯ
ЭКОНОМИКА
ЭЛЕКТРОТЕХНИКА
ЭНЕРГЕТИКА
ЮРИСПРУДЕНЦИЯ
ЯЗЫКОЗНАНИЕ
РАЗНОЕ
КОНТАКТЫ


Pages:     | 1 |   ...   | 24 | 25 ||

«Электронные библиотеки: Перспективные Методы и Технологии, Электронные коллекции English Труды RCDL 2010 ...»

-- [ Страница 26 ] --

большой популярностью пользуется VCS git [11].

3.3 Импорт документов Впрочем, как будет показано в следующем разделе, для нашего проекта более предпочтительной явля- Требуемые для CitCMS возможности обеспечи ется VCS Subversion. ваются за счет создания новых плагинов для ikiwiki.

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

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

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

ются разные модели представления документов.

Литература Проблема усугубляется сложностью и закрытостью формата Word и наличием связанных с этим ошибок [1] Кузнецов С.Д., Сальникова Е.Е., Сальников С.А.

в свободных (и проприетарных!) реализациях. В Управление контентом в крупных научно ряде случаев удается преобразовать документы в технических Internet-библиотеках// Труды XI Все формате Word к формату CitCMS за счет использо- рос. конф. «Электронные библиотеки: перспектив вания средств OpenOffice.org [15] и собственных ные методы и технологии, электронные коллекции», программных средств, но в общем случае без доли Петрозаводск, 17 – 21 сентября 2009 г.

ручного труда обойтись не удается. [2] IEEE Computer Society Digital Library. – В очень многих случаях публикация, которую http://www.computer.org/portal/web/csdl, 2010.

требуется отредактировать и разметить в библиоте- [3] The ACM Digital Library. – http://portal.acm.

ке CITForum, изначально представлена в формате org/dl.cfm, 2010.

HTML. В этом случае CitCMS пытается автомати- [4] Библиотека CITForum. – http://citforum.ru/, 2010.

чески привести исходный формат HTML к своему [5] Wiki проекта CitCMS. – http://citcms.org/, 2010.

внутреннему формату. Общего алгоритма преобра- [6] Web-сайт издательства «Открытые системы». – зования не существует, но поддерживаются наибо- http://www.osp.ru/, 2010.

лее распространенные варианты исходного HTML- [7] Веб-сайт компании «Интерфейс». – http://www.

представления (при отклонении от них опять же interface.ru/, 2010.

требуется вмешательство человека). [8] Wiki проекта ikiwiki. – http://ikiwiki.info/, 2010.

Частным, но важным случаем задачи импорта [9] Веб-сайт проекта Debian. – http://www.debian.

документов, представленных в формате HTML, яв- org/, 2010.

ляется перенос в среду CitCMS текущего контента [10] Веб-сайт проекта Apache Subversion. – http:// библиотеки CITForum. Это объемная и непростая subversion.apache.org/, 2010.

работа, поскольку контент накапливался в течение [11] Веб-сайт проекта git. – http://git-scm.com/, 2010.

долгого времени без точного отслеживания стан- [12] CPAN: Comprehensive Perl Archive Network. – дартов HTML-представления документов, но она http://www.cpan.org/, необходима для CITForum и чрезвычайно полезна [13] Веб-сайт проекта Mercurial. – http://mercurial.

для тестирования CitCMS. selenic.com/, [14] Веб-сайт проекта Bazaar. – http://bazaar. canoni 3.4 Форматирование cal.com/en/, 2010.

Поскольку система ikiwiki в своем исходном ви- [15] Веб-сайт проекта OpenOffice.org. – http://www.

де применяется для публикации документов в стиле openoffice.org/, 2010.

Wiki, в CitCMS требуется добавление средств фор матирования, естественных для Internet-библиотеки. Architecture and implementation of the Такие средства форматирования реализуются в виде Content Management System CitCMS for набора дополнительных плагинов и поддерживают, internet library в частности, возможности разбиения крупных до кументов на страницы, автоматическое оформление E.E. Salnikova, S.A. Salnikov, S.D. Kuznetsov ссылок на используемые литературные источники, обработку крупных изображений и т. д. The paper [1] presented at the RCDL’2009 motivated needs for a new content management system to support 4 Заключение full-text scientific and technological Internet libraries В первой работоспособной версии новой WCMS (Web Content Management System, WCMS), stated CitCMS решен ряд важных задач: requirements to such a system, and discussed technolo • спроектирована общая архитектура системы;

gies that might be used in it’s implementation. During • выбраны основные готовые компоненты, кото- last year several experiments has been conducted, sev eral prototype systems have been implemented and рые можно использовать в реализации;

• проведена первая фаза опытной эксплуатации. tested based on real content. This paper describes re sults and conclusions of our experiments, and discusses Система является естественным образом расши main components used within a resulted WCMS ряемой. Хотя в настоящее время она позволяет ре CitCMS.

шать только наиболее важные задачи управления контентом научно-технической Internet-библиотеки, Работа выполнена при финансовой поддержке РФФИ в дальнейшем возможно наращивание ее возможно (проект 09-07-00282) стей для достижения всех целей, сформулирован ных в [1]. Кроме того, система опирается на исполь зование хорошо поддерживаемых готовых про Особенности построения цифровых библиотек со связанным контентом © А.Г. Марчук, П.А. Марчук Институт систем информатики им. А.П. Ершова СО РАН, г. Новосибирск mag@iis.nsk.su, peter@iis.nsk.su дает рядом недостатков. Во-первых, фиксируется Аннотация адрес (URL) публикуемого файла. Это не так В работе обсуждается подход к построению страшно для библиотечной системы, поскольку при цифровых архивов или библиотек, сущест- ее переносе на другой сервер можно изменить также венной особенностью которых является и адреса связанных документов. Но если речь идет о предоставление доступа не только к запи- других информационных системах, сопряженных с сям базы данных, но и к электронным об- данной, или о поисковых системах интернета, то разам хранимых документов. Файлы, до- при перемещении или реструктуризации публика полнительные к базе данных, будем назы- ционной зоны возникают труднопреодолимые про вать контентом библиотеки. Работа с кон- блемы. Например, в других информационных сис тентом включает хранение, транспортиров- темах могут появиться ссылки на документы нашей ку и обработку файлов, публикацию внеш- электронной библиотеки. Эти ссылки не всегда него образа контента, изменение содержи- можно изменять, а долго поддерживать переадреса мого файлов и др. В статье обсуждаются цию затруднительно.

также структура хранения данных, исполь- Еще одна проблема этого способа публикации зование хранилищ, интеграция данных, контента связана с тем, что может возникнуть по расположенных в разных хранилищах, ми- требность в предоставлении рабочего доступа не к грация данных по мере изменения техноло- исходному, оригинальному файлу, а к некоторому гий и стандартов. Работа выполнена при переработанному варианту, более подходящему для поддержке гранта РГНФ 10-03-12116в и конкретной ситуации его использования. Например, программы РАН р 2/12. оригинал фотодокумента, хранящегося в библиоте ке, может быть слишком большим для оперативного 1 Постановка задачи использования или он может быть защищен правом интеллектуальной собственности, в этом случае Во многих случаях можно сказать, что цифровая следует предоставлять доступ к уменьшенным ва библиотека представляет собой множество метаин риантам фотографии.

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

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

держимому являются прямая публикация докумен При увеличении числа информационных единиц тов в интернет-пространстве и использование URL в электронной библиотеке усложняется доступ к публикации для предоставление доступа к ней. Если каждой из единиц. В серверном приложении прихо URL отражает структуру хранения данных на сер дится переходить на использование базы данных вере, то он же может использоваться и для доступа для быстрого нахождения запрашиваемого доку к файлу со стороны серверного приложения. Такой мента. Это, во-первых, излишне централизует хра способ публикации и предоставления доступа обла нилище, во-вторых, «привязывает» информацион ную систему к конкретной СУБД. Судьба многих Труды 12й Всероссийской научной конференции малых и не очень малых информационных проектов «Электронные библиотеки: перспективные методы и часто плачевна: авторы закончили работу над про технологии, электронные коллекции» – RCDL’2010, ектом и перестали его поддерживать, а ценные дан Казань, Россия, ные «застревали» в недрах какой-то базы данных и тов которого и есть содержимое документа, напри потом уничтожались при очередной реконфигура- мер, для фотодокумента имеется файл графического ции серверного хозяйства. Кроме того, при исполь- формата (TIFF, JPEG), представляющий собственно зовании централизованной базы данных трудно фотографию.

предоставлять доступ к контенту, расположенному Особое внимание обратим на документы, кон в хранилищах, внешних по отношению к ИС. тент которых вовлекается в оперативную работу Популярные ныне системы управления контен- информационной системы, например, фотографии, том (CMS) и системы управления документами имеющиеся в базе данных. Для каждого такого до (DMS) [2, 6], не полностью решают указанные про- кумента, прописанного в базе данных, надо иметь блемы и, кроме того, вовлекают в решение реляци- структуру и набор полей, а также связи с другими онные СУБД, что для малых электронных библио- документами, т. е. «маленькую» базу данных, обес тек имеет свои недостатки. Также активно развива- печивающую доступ к нему и к дополнительной ется направление хранения документов в специали- информации. Такая структура может оказаться из зированных или универсальных сервисных порта- лишне громоздкой, если ее реализовывать на уровне лах [1, 5, 7, 8]. Использование такого способа имеет основной базы данных. В качестве решения предла ограничения в виде необходимости быть подклю- гается информацию группировать, порождать опи ченным к интернету, работы с файлами очень сание для групп элементов и включить ее в кассету, большого размера и сложность в увязывании интер- о которой идет речь в данном разделе. Соответст нет-хранилища с базой данных библиотечной ин- венно, доступ к элементам кассеты будет регламен формационной системы и неопубликованной ча- тирован такой локальной базой данных.

стью контента. Однако перспективность подобных Файловые сборки давно используются для раз интернет-сервисов не вызывает сомнений. ных целей, обычно сочетаясь со сжатием информа ции. Новизной предлагаемого подхода является ис пользование сборок, т. е. кассет для объединенного 2 Механизм кассет в качестве малого хранения базы данных и набора документов элек хранилища данных тронной библиотеки и обеспечения их функциони Предлагается в качестве хранилища данных ис- рования. В качестве модели кассеты можно рас пользовать специальную файловую структуру – сматривать подобие DVD-диска, который обладает кассеты, т. е. группу файлов организовать таким такими свойствами, как перемещаемость, наличие образом, чтобы их структура была удобной для внутренней структуры, множественность хранимых обеспечения базовых возможностей по включе- файлов, наличие дополнительной информации.

нию/исключению файлов, предоставлению доступа к оригиналам и специальным копиям, прямой и кос- 3 Общая структура кассет венной публикации в интернете. Такой формат фай Вернемся к связи записи документа с файлом ловой сборки был разработан и ныне используется в документа. Предлагается использовать для этого разработках ИСИ СО РАН. Структура кассеты яв URI (Universal Resource Identifier). Можно сказать, ляется простой системой файлов и директорий, на что информация, синтаксически оформленная в чинающейся от одного корня, ее можно переносить едином URI, представляет собой четверку {прото или делать резервные копии с помощью обычных кол, имя кассеты, код документа, класс документа}.

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

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

может ссылаться на объекты кассеты, используя В качестве модельного примера рассмотрим URI помещенных туда файлов. Рассмотрим некото простой кассетный протокол simple. В этом прото рые особенности предлагаемого решения.

коле файлы документов упорядочиваем в дерево Предположим, что в базе данных описан некото директорий (папок) в соответствии с обычным рый документ. Это может быть как текстовый, так и строением файловой системы. Тогда именем кассе фото-видео-аудио документ или файл иной приро ты будет имя папки, а кодом документа – относи ды. База данных позволяет увязать документ с дру тельный путь (path) к файлу от папки, корневой для гими сущностями путем установления интуитивно данной кассеты.

понятных отношений типа «авторство», «отраже Поскольку имя кассеты рассматривается в об ние» и др. Кроме этого документ, как правило, яв щем пространстве интернета, нам понадобится еще ляется также носителем информации, представлен пространство имен, в котором определено имя кас ной в виде байтов, конкретной информации, внеш сеты. В итоге общая структура URI для идентифи ней относительно базы данных. Типичным оформ лением этой информации является файл, поток бай кации файла документа строится в соответствии с ментов по определенным критериям. Если эта логи рекомендациями WWW-консорциума: ка предполагает наследование контекста от дирек protocol://cassette-name@domain/document-code. ex- торий к поддиректориям, то это наследование мож tension. но было бы напрямую использовать при формиро Здесь в качестве пространства имен использует- вании базы данных. Однако структуру рабочих (не ся домен, зарегистрированный пользователем. meta и не preview) директорий желательно не иска В случае простого кассетного протокола URI до- жать дополнительной информацией, хотя и не ис кумента может выглядеть следующим образом: ключено, что следует допустить обе возможности.

simple://demo-cassette@iis.nsk.su/dir1/sub-dir11/ pho- Раздел preview также может быть устроен спе to1.jpg. цифическим образом, но общая конструкция этого Вышеуказанная интерпретация простого прото- раздела – хранилище файлов, производных от доку кола предполагает следующий способ нахождения ментных оригиналов, и базы данных для того, что координаты файла: бы ускорить порождение специальных (просмотро координатаКассеты(demo-cassette)/dir1/sub-dir11/ вых или транспортируемых) вариантов некоторых photo1.jpg. видов документов, хранящихся в кассете.

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

митивна и не содержит мета- и предвычисленной Последний вариант рассмотрим на примере.

информации. Рассмотрим более общую сложную Пусть мы имеем дело с фотодокументами и нам структуру кассеты, в настоящее время применяе- требуется предварительно вычислить и поместить в мую в проектах ИСИ СОРАН. preview «маленькие» копии этих фотографий. Мож Сохраним простую структуру хранения файлов в но поступить достаточно просто: по URI документа виде директорий, но добавим две дополнительные – вычислить идентификатор с помощью некоторой meta и preview. В директорию meta будем помещать взаимно однозначной функции и в соответствии с метаинформацию, соответствующую хранимому ним помещать различные по размерам имиджи в массиву файлов, а в preview – дополнительную ин- раздел preview. Имена таких вспомогательных фай формацию, предназначенную, как правило, для бы- лов вычисляются, например, по формуле:

строй визуализации при просмотре. Мы постулиру- ФункцияПреобразования(URI-документа) + “_” ем, что раздел preview может быть вычислен по + спецификатор + “.jpg”, где спецификатор – какой протоколу и массиву файлов. В разделе meta соби- нибудь код, соответствующий размеру имиджа (“s”, рается информация, являющаяся локальной частью “m” и т. д.).

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


мых в meta и preview, зависит от системы соглаше- Использование базы данных для установления ний по каждому конкретному протоколу. Тем не соответствия между документом и дополнительной менее, следует сохранять общие свойства такой ин- информацией обеспечивает большую гибкость. Во формации. Рассмотрим один из возможных подхо- первых, база данных сама может являться хранили дов к размещению мета- и дополнительной инфор- щем дополнительной информации. Во-вторых, с мации в кассете. помощью базы данных можно регулировать нали В раздел meta желательно поместить следую- чие или отсутствие такой информации, значит, не щую информацию: имя протокола, имя кассеты, обходимость ее вычисления в динамике доступа. В комплектация кассеты, имя корневой коллекции, этом случае мы можем организовать дополнитель идентификатор корневой коллекции. Эта информа- ную информацию по принципу кэша и экономить на ция является интерфейсной и не предназначена для вычислениях, выполняя их по необходимости (on прямого включения в базу данных модели. Другой demand). В-третьих, база данных может содержать частью meta-раздела является RDF-документ базы сведения о текущем варианте дополнительной ин данных, которая обычно включает описатели доку- формации к документу. Например, если в качестве ментов кассеты и формирует иерархию вложения предварительно вычисляемой информации для документов в коллекции, соответствующие иерар- (больших) фотодокументов используются их хии директорий хранения документов. Третья часть уменьшенные копии, то размеры этих копий могут meta-раздела определяет контекст документов. Во- быть разными, а требуемый в конкретный момент обще говоря, контекст можно связывать с директо- времени размер может быть динамически вычислен риями, по которым распределены документы. До- не по большому оригиналу, а по близкой по размеру кумент помещается в директорию, исходя из логики копии. Использование базы данных для хранения пользователя, определяющей группирование доку- дополнительной информации полезно, например, в случае, когда часть оригиналов изменяется и требу- вым). Соответственно, все «правильные» решения, ется где-то фиксировать эту ситуацию и синхрони- типа Content-type для HTTP здесь уместны.

зировать дополнительную информацию с оригина- Рассмотрим различные виды запросов к источ лом. нику данных. Первая группа – запрос контента фай ла документа. В эту группу входит запрос оригина ла и запрос специальных копий (preview). Основ 4 Доступ к данным и документам ным параметром запроса является идентификатор Важную роль в фактографических системах иг- или URI документа. Дополнительным параметром рает способ доступа к данным, т. е. к базе данных и является квалификатор вида копии, например, ква контенту документов. Обычное решение этой зада- лификатор размера изображения. В этой группе есть чи заключается в том, что базовое прикладное про- свои особенности. В частности, в ряде случаев URL граммное обеспечение, например, веб-приложение, запроса должен выглядеть как URL прямо опубли имеет внутренние механизмы такого доступа и кованного файла, что связано с особенностями кэ осуществляет его по мере формирования отдельных ширования в прокси-серверах и особенностями ис визуальных образов и обработки данных, посту- пользования данного контента, например, потоково пивших при «нажатии» кнопок и по мере заполне- го видео. Такая постановка требует специального ния форм. Организация такого доступа в виде одно- кодирования запроса и его специальной обработки го или нескольких сервисов, выполняющих запросы интерфейсом сервиса. Для этой группы существен как от простых пользовательских интерфейсов, так но также использование компрессии и декомпрес и от сложно устроенных машинных агентов, высту- сии данных. Например, сжатие данных при запросе пающих в качестве клиентов к таким сервисам, документов формата XML может многократно представляется более интересной. уменьшить объем передаваемой информации.


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

предполагать, что используется протокол однократ- Третья группа запросов – это запросы на изме ного запроса в стиле объектно-ориентированного нение базы данных и клиент-серверная синхрониза программирования. Таким примером и основой для ция по данным. Логика этих запросов диктуется практической реализации является протокол HTTP. общей логикой синхронизации моделей в распреде Подход фирмы Google, реализующей доступы к ленной фактографической системе [3, 4]. В эту своим сервисам [8] средствами API [9], основу ко- группу входят: внесение новых записей в базу дан торого составляет довольно простое использование ных или модификация имеющихся, операторы HTTP, наиболее близок к рассматриваемому здесь. уничтожения записей и замены идентификаторов, Но в этом и сила подхода, поскольку вне зависимо- запросы на обновление клиентской модели в соот сти от платформы, на которой реализована его ин- ветствии с изменениями серверной.

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

зующиеся «поверх» HTTP, такие, как SOAP, WCF и другие. Запрос представляет собой набор парамет 5 Использование кассет в информаци ров, например, идентификатор объекта, операция и онных системах др. Кроме того, HTTP позволяет в режиме POST передавать произвольные последовательности бай- Кассеты могут быть использованы в самых раз тов. Ответ от сервера также может иметь парамет- ных случаях построений информационных систем.

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

Поскольку в наших проектах все существенные ре сурсы отображаются на файлы, кассета может быть new_cloud_data_storage_for_developers.html, единственным носителем всего конкретного проек- 2010.

та. В кассете легко разместить и RDF-базу данных, [8] Create and share your online documents, presenta и OWL-спецификации, различные конфигураторы, tions, and spreadsheets. – http://docs.google.com.

XSLT, CSS, JS файлы для оформления визуального [9] Google Data Protocol. – http://code.google.com/ интерфейса пользователя и обеспечения его функ- intl/ru/apis/gdata/docs/developers-guide.html.

циональности. Такой подход проверялся на проек тах малого и среднего размера, когда количество Special features of the construction of документов не превышало нескольких десятков ты- digital libraries with document content сяч, а количество фактов в базе данных – одного A.G. Marchuk, P.A. Marchuk миллиона.

Оформление данных и документов в кассеты по In the work is discussed the approach to the construc зволяет гибко управлять содержимым различных tion of digital archives or libraries, essential feature of информационных систем, использующих общее which is the granting of access not only to the records информационное поле. Это означает, что под кон of the database, but also to the digital content of docu кретную информационную систему собирается на ments. Files, additional to the data base, we will call бор кассет, содержащих нужные данные, эти кассе content of library. Work with content includes storage, ты загружаются в оперативную зону системы и transportation, publication in the Internet, a change of обеспечивают данными ее функционирование. На files and others. In the article the following questions пример, информационная система может использо are discussed: the structure of storage of data, the use of вать несколько общих кассет, содержащих публич depositories, the integration of data, located in the dif ную информацию о людях, организациях, событиях, ferent depositories, the migration of data in proportion и приватные кассеты с непубличными данными to a change in the technologies and standards.

пользователей.

6 Заключение Предлагаемый подход был реализован и исполь зован в нескольких исследовательских и приклад ных проектах, которые проводятся в ИСИ СО РАН.

В частности, это Фотоархив Сибирского отделения, Электронная энциклопедия ММФ НГУ, База дан ных летних школ юных программистов, информа ционная система кафедры программирования ММФ НГУ.

Литература [1] Бесплатное защищенное паролем интернет хранилище. – http://office.live.com.

[2] Коржов В. Использование сетевой модели дан ных для управления информационным наполне нием// Computerworld Россия. – 2000. – № 21.

[3] Марчук А.Г. Распределенные электронные ар хивы, библиотеки и базы данных // Препринт 122, Институт систем информатики им. А.П. Ер шова СО РАН, Новосибирск, 2004. – 25 с.

[4] Марчук А.Г., Марчук П.А. Платформа интегра ции электронных архивов // Электронные биб лиотеки: перспективные методы и технологии, электронные коллекции. Тр. девятой Всерос.

конф., Переславль, 2007. – С. 89-94.

[5] Парамонов В. Google открывает «облачное»

хранилище данных. – http://www.citforum.ru/ news/23833/, 2010.

[6] Пьянзин К. Универсальные системы управления документами // Lan/Журнал сетевых решений. – Ноябрь 1998. – Т. 4, № 11.

[7] Bradley T. Google unveils new cloud data storage for developers. – http://www.pcworld.com/ busi nesscenter/article/196539/google_unveils_

Pages:     | 1 |   ...   | 24 | 25 ||
 





 
© 2013 www.libed.ru - «Бесплатная библиотека научно-практических конференций»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.