About construction of digital library models
The paper is concerned with creation of digital library models. Several wellknown connected projects are discussed, those are CIDOC CRM, FRBR, FRBRoo,DELOS DLRM and 5S. The study can be used as the basis for creating your own original model DL, which possible should use their strengths and avoid its...
Gespeichert in:
| Datum: | 2026 |
|---|---|
| Hauptverfasser: | , , , |
| Format: | Artikel |
| Sprache: | Russisch |
| Veröffentlicht: |
PROBLEMS IN PROGRAMMING
2026
|
| Schlagworte: | |
| Online Zugang: | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/972 |
| Tags: |
Tag hinzufügen
Keine Tags, Fügen Sie den ersten Tag hinzu!
|
| Назва журналу: | Problems in programming |
| Завантажити файл: |  |
Institution
Problems in programming| _version_ | 1866845000867774464 |
|---|---|
| author | Reznichenko, V.A. Proskudina, G.Yu Kudim, K.A. Ovdiy, О.М. |
| author_facet | Reznichenko, V.A. Proskudina, G.Yu Kudim, K.A. Ovdiy, О.М. |
| author_institution_txt_mv | [
{
"author": "V.A. Reznichenko",
"institution": "Institute of Software Systems NAS of Ukraine"
},
{
"author": "G.Yu Proskudina",
"institution": "Institute of Software Systems NAS of Ukraine"
},
{
"author": "K.A. Kudim",
"institution": "Institute of Software Systems NAS of Ukraine"
},
{
"author": "О.М. Ovdiy",
"institution": "Institute of Software Systems NAS of Ukraine"
}
] |
| author_sort | Reznichenko, V.A. |
| baseUrl_str | https://pp.isofts.kiev.ua/index.php/ojs1/oai |
| collection | OJS |
| datestamp_date | 2026-06-01T21:28:34Z |
| description | The paper is concerned with creation of digital library models. Several wellknown connected projects are discussed, those are CIDOC CRM, FRBR, FRBRoo,DELOS DLRM and 5S. The study can be used as the basis for creating your own original model DL, which possible should use their strengths and avoid its shortcomings.Problems in programming 2010; 4: 60-74 |
| first_indexed | 2026-06-02T01:02:10Z |
| format | Article |
| fulltext |
Експертні та інтелектуальні інформаційні системи
60
УДК 004.415
В.А. Резниченко, Г.Ю. Проскудина, К.А. Кудим, О.М. Овдий
О ПОСТРОЕНИИ МОДЕЛЕЙ ЭЛЕКТРОННЫХ БИБЛИОТЕК
Работа посвящена задаче создания моделей электронных библиотек. Обсуждаются некоторые извест-
ные связанные проекты – СIDOC CRM, FRBR, FRBRoo, DELOS DLRM и 5S. Исследование может быть
положено в основу создания собственной оригинальной модели ЭБ, которая должна по-возможности
использовать их сильные стороны и избежать имеющиеся недостатки.
Введение
Появление новых электронных биб-
лиотек (ЭБ), увеличение числа хранимых в
них документов и повышение качества
предоставляемых ими услуг способствует
развитию науки, облегчая, а иногда и про-
сто открывая единственно возможный дос-
туп к источникам информации для учено-
го, предоставляя ему замечательное сред-
ство донести плоды своей деятельности до
широчайшей аудитории. В последние не-
сколько лет при нашем непосредственном
участии научное сообщество Украины
продвинулось в этом направлении. В част-
ности, в прошлом году создан портал пе-
риодических изданий НАН Украины1. Два
года назад создана ЭБ Института про-
граммных систем НАН Украины2. В пер-
вом случае использовалось программное
обеспечение DSpace, во втором − EPrints.
Обе системы были полностью украинизи-
рованы. Были отработаны основные сце-
нарии использования, создан ряд методик
и рекомендаций по созданию и использо-
ванию электронных библиотек на основе
данных программных систем. Были также
изучены программные продукты
Greenstone3 и Fedora4. Этот опыт оказался
очень ценным для понимания современно-
го состояния дел в мире программных сис-
тем ЭБ.
В настоящее время нет какой-либо
универсальной ЭБ, которая отвечала бы
всем требованиям и ожиданиям пользова-
телей. Анализ существующих систем ЭБ
[1−3] показывает их разнородность на не-
скольких уровнях:
1 http://dspace.nbuv.gov.ua:8080/dspace
2 http://eprints.isofts.kiev.ua/
3 http://www.greenstone.org/
4 http://www.fedora-commons.org/
− на уровне информационной модели,
которую они обеспечивают;
− на уровне поддержки пользователей
и групп пользователей;
− на уровне функциональных возмож-
ностей.
Из-за этой гетерогенности ЭБ и игно-
рирования нужд их пользователей возни-
кает ряд проблем:
− интеграция информации из различ-
ных ЭБ;
− сравнение ЭБ по предоставляемой
функциональности;
− оценка и сравнение производитель-
ности различных систем ЭБ;
− добавление новых типов хранимых
объектов;
− добавление новых функциональных
возможностей;
− резервное копирование.
Решить эти и другие возникающие
проблемы на первом этапе поможет акку-
ратное и полное рассмотрение области ЭБ.
Именно для этого создаются различные
модели, обобщающие накопленный опыт в
сфере создания и использования ЭБ.
В последнее время в мире предприни-
маются усилия по полному и всесторонне-
му описанию сферы ЭБ. В данной работе
мы обсуждаем и анализируем следующие
известные модели и стандарты, которые
могут применяться для описания ЭБ в це-
лом и ее частей: СIDOC CRM [4], FRBR
[5], DELOS DLRM [6] и 5S [7]. Это иссле-
дование может быть положено в основу
создания собственной оригинальной моде-
ли ЭБ, которая должна по-возможности
использовать их сильные стороны и избе-
жать имеющиеся недостатки.
© В.А. Резниченко, Г.Ю. Проскудина, К.А. Кудим, О.М. Овдий, 2010
ISSN 1727-4907. Проблеми програмування. 2010. № 4
Експертні та інтелектуальні інформаційні системи
61
1. CIDOC CRM
Концептуальная эталонная модель
(Conceptual Reference Model, CRM)
CIDOC, разработанная Международным
комитетом по документации Международ-
ного совета музеев (The International
Committee for Documentation of the
International Council of Museums, ICOM-
CIDOC), предназначена для интеграции,
посредничества и обмена информацией в
области мирового культурного наследия и
связанных областей.
Четко обозначенные цели определили
основные конструкции модели и уровень
ее детализации. CIDOC CRM в терминах
формальной онтологии определяет семан-
тику схем баз данных и структур докумен-
тов, используемых в культурном наследии
и музейной документации. Модель не
определяет терминологию, появляющуюся
в конкретных структурах данных, но имеет
характерные отношения для ее использо-
вания. Она не стремится предлагать то, что
должны документировать учреждения
культуры. Скорее она объясняет логику
того, что они фактически документируют
и таким образом предоставляет семантиче-
скую интероперабельность между музея-
ми, библиотеками, архивами. Представляя
определения и формальную структуру
описания неявных (implicit) и явных
(explicit) cущностей и отношений, модель
CIDOC CRM претендует на общий язык
для экспертов предметной области и спе-
циалистов по информационным техноло-
гиям. Она предназначена для покрытия
контекстной информации исторического,
географического и теоретического харак-
тера об отдельных экспонатах и музейных
коллекциях в целом [8, 9].
До 1994 года разрабатывалась ER-
модель для музейной информации, начи-
ная с 1996 года подход разработки модели
сместился к методологиям объектно-
ориентированного моделирования и при-
вел в 1999 году к появлению первой Кон-
цептуальной эталонной модели CIDOC. С
2000 года начался процесс стандартизации,
который успешно завершился принятием
стандарта ISO 21127:2006 – "Эталонная
онтология для обмена информацией куль-
турного наследия" (A reference ontology for
the interchange of cultural heritage
information). Разработчики CIDOC CRM
поставили своей целью написать стандарт
модели, пригодной как для машинной об-
работки, так и для легкого понимания че-
ловеком. Модель совместима с формализ-
мом RDF.
Версия 5.0.1 модели CIDOC CRM [4]
состоит из 90 классов и 148 свойств (бина-
рных отношений), связывающих классы
между собой и описывающих предметы,
понятия, людей, события, место, время и
их отношения. Все концепты (классы и
свойства) модели можно разделить на три
группы. Первая группа включает классы и
отношения, охватывающие наиболее об-
щие понятия окружающего мира: постоян-
ные и временные сущности, отношения
участия, зависимости, совпадения во вре-
мени. Вторая группа содержит понятия,
частично поддерживающие функции
управления: приобретение и учет единиц
хранения, передача прав собственности на
объекты культуры. К третьей группе отно-
сятся классы и свойства, используемые для
внутренней организации самой онтологии:
средства, необходимые для подключения
внешних источников терминов, например,
тезаурусов по отраслям культуры.
На рис. 1 представлена часть иерархии
классов CIDOC CRM. Все классы, за иск-
лючением класса простое значение
(Primitive Value) и его подклассов (эти
классы являются вспомогательными), пря-
мо или опосредовано являются подкласса-
ми класса сущность CRM, охватывающе-
го все сущности, которые могут быть опи-
саны в CIDOC CRM. Далее иерархия клас-
сов делится на 2 ветви: постоянные сущ-
ности и временные сущности.
На самых нижних уровнях иерархии
классов появляются понятия, характерные
для сферы культуры: хранение, перемеще-
ние (ценностей), проект или процедура (в
том числе техника производства), период
(в том числе художественный стиль). Ие-
рархия классов может быть гибко расши-
рена с применением встроенного класса
тип. Наибольший интерес представляют
свойства. Классы на нижних уровнях ие-
рархии имеют около 10−15 свойств, при-
чем большая часть свойств наследуется от
Експертні та інтелектуальні інформаційні системи
62
Рис. 1. Часть иерархии классов в модели CIDOC CRM
классов-предков. Названия свойств пред-
ставляют собой глагольные фразы, выб-
ранные так, что при последовательном
связывании двух классов свойством полу-
чается осмысленная фраза с субъектом
(первый, если считать слева направо,
класс), предикатом (свойством) и объектом
(второй класс).
1.1. Принципы моделирования CIDOC
CRM
Разработка CIDOC CRM проводится в
соответствии со следующими принципами.
Открытый мир − термин и принцип
систем баз знаний подразумевает, что хра-
нимая в этих системах информация явля-
ется неполной относительно универсума
той предметной области, которую они на-
мереваются описать. Такие проблемы ха-
рактерны для информационных систем в
области культуры. Наши записи о про-
шлом обязательно неполны.
Кроме того, существуют свойства, ко-
торые не могут быть в точности назначены
данному классу. В частности, отсутствие
определенного свойства для описанного в
системе элемента, не означает, что у этого
элемента нет этого свойства. Например,
если один элемент описан как биологиче-
ский объект, а второй как физический объ-
ект, то это не означает, что, второй воз-
можно, не биологический объект также.
Поэтому дополнения класса относительно
суперкласса не могут быть в общем виде
выведены из информационной системы,
используя предположение Открытого мира
(аналогично отсутствию понятия универ-
сума в системах БД). Например, нельзя пе-
речислить “все физические объекты, из-
вестные системе, которые в реальном мире
не являются биологическими объектами”,
но можно конечно перечислить “все эле-
менты, известные системе как физические
объекты, но не известные системе как
биологические объекты”.
Монотонность. Поскольку основная
роль CRM − интеграция информации в От-
крытом мире, то она стремится быть моно-
тонной. Принцип состоит в том, что суще-
ствующие конструкции CRM и выведен-
ные из них дедукции (логические выводы)
всегда остаются достоверными и правиль-
но построенными, после добавления новых
конструкций, расширяющих CRM. На-
пример, если было уже описано, что ка-
кой-то объект является экземпляром фи-
зического объекта, а потом его охаракте-
Експертні та інтелектуальні інформаційні системи
63
ризовали как экземпляр биологического
объекта, то в дальнейшем система не
прекращает его рассматривать как экземп-
ляр физического объекта. Для того чтобы
формально сохранять монотонность для
частых случаев альтернативных мнений,
все формально определенные свойства
должны быть реализованы как неограни-
ченные (типа многие-ко-многим) и тогда,
противоречивые экземпляры просто будут
накапливаться. Такое интегрированное
знание на основе CRM, представляющее
совокупность релевантно альтернативных
вариантов для четко определенных объек-
тов, является основой исследования, а за-
ключение об истине − задача науки.
Например, Эль Греко и Король Артур
должны всегда оставаться экземплярами
сущности персона. И как только мы ввели
эти экземпляры в нашу базу знаний, эта
сущность (персона) всегда подразумевает-
ся. Альтернативные мнения о их свойст-
вах, например, место их рождения и жизни
должны накапливаться без решения о том
верны они или нет.
Минимальность. Хотя возможности
CRM очень широки, сама модель построе-
на экономно. Класс не объявлен до тех
пор, пока область определения или об-
ласть значений его свойств не соответст-
вуют его суперклассу или пока он не явля-
ется ключевым понятием в рассматривае-
мой области. По умолчанию классы и
свойства CRM, которые имеют общий су-
перкласс, не являются взаимно исклю-
чающими. Например, объект может быть
экземпляром как биологического объекта,
так и искусственного объекта.
Классы и свойства CRM являются ли-
бо примитивами, либо они – ключевые по-
нятия в рассматриваемой области. Допол-
нения классов CRM не декларируются
(поскольку нет универсума), т. е. модель
фиксирует только то, что реально имеется.
Сокращения. Некоторые свойства
декларируются как сокращения более
длинных свойств. Например, свойство
сущности E19 физический объект P52
имеет владельца E39 актор является со-
кращением от более полного пути: физи-
ческий объект через сущность приобре-
тение до сущности актор. Экземпляр
полного пути всегда подразумевает экзем-
пляр сокращенного свойства. Однако, ин-
версия, возможно, не верна; экземпляр
полного пути может не всегда быть выве-
ден из экземпляра сокращенного свойства.
Непересекаемость. Классы не пересе-
каются, когда у них нет общих экземпля-
ров. Например, не пересекаются пары
классов временной объект и постоянный
объект; физический предмет и концеп-
туальный объект, тем самым различаю-
тися материальные и нематериальные объ-
екты. Экземпляры физического предмета
и концептуального объекта имеют прин-
ципиальное отличие; например, изготов-
ление экземпляров физического предмета
подразумевает использование физического
материала, тогда как изготовление экземп-
ляров концептуального объекта нет. Точ-
но так же экземпляры физического пред-
мета прекращают существовать когда они
разрушаются, тогда как экземпляр кон-
цептуального объекта погибает, когда о
нем забывают, или когда разрушается его
последний физический носитель.
Тип. Фактически все структурирован-
ные описания музейных объектов начина-
ются с уникального идентификатора объ-
екта и информации о типе объекта, кото-
рый часто заносятся в поля, названные как
тип объекта, название объекта, катего-
рия, классификация и т. д. Все эти поля ис-
пользуются для терминов, которые объяв-
ляют, что объект – член специфического
класса или категории объектов и описан в
CRM экземплярами класса тип. Поскольку
экземпляры этого класса в свою очередь
являются самостоятельными классами,
класс тип – фактически метакласс.
Класс сущность CRM является доме-
ном свойства P2 имеет тип (тип чего-то),
который имеет область значения класс
тип. Следовательно, каждый класс в CRM,
за исключением класса простое значение,
наследует свойство P2 имеет тип (тип че-
го-то). Это обеспечивает общий механизм
уточнения классификации экземпляров
CRM до любого уровня детализации, свя-
зываясь с внешними словарями-
источниками, тезаурусами, схемой клас-
сификации или онтологиями, которые
функционируют как расширение к иерар-
Експертні та інтелектуальні інформаційні системи
64
хиям классов и свойств CRM. Внешние
словари не входят в CRM.
Расширения. Поскольку предполагае-
мые возможности CRM – подмножество
реального мира, а значит, потенциально
бесконечны, модель разрабатывалась так,
чтобы быть расширяемой через соедине-
ния с совместимыми внешними иерархия-
ми типов.
Охват. Некоторые понятия CRM раз-
работаны неполно, например: актор и
право. Это – естественное следствие пре-
бывания в пределах ясно сформулирован-
ной практической сфере CRM.
Резюмируя рассмотрение данной мо-
дели, отметим, что для наших целей это –
нужный и полезный стандарт. Важным
преимуществом стандарта является его
формальный подход. Обобщая все много-
образие музейных коллекций и задач, мо-
дель содержит широкий набор универ-
сальных понятий. Важную роль здесь иг-
рают временные сущности, так как они
связывают объекты (концептуальные или
физические) с временным диапазоном, ме-
стом и субъектами. Этот стандарт вполне
может служить основой для информаци-
онной составлящей концептуальной моде-
ли ЭБ. Конечно, он нуждается в расшире-
нии более конкретными сущностями, ко-
торые часто используются во многих ЭБ.
Кроме того, CIDOC CRM не охватывает
пользовательского и функционального ас-
пектов ЭБ.
2. FRBR и FRBRoo
Независимо от CIDOC CRM в 1991–
1997 годах Международной федерацией
библиотечных ассоциаций и учреждений
(International Federation of Library
Associations and Institutions, IFLA) была
разработана ER-модель "Функциональные
требования к библиографическим записям"
(Functional Requirements for Bibliographic
Records, FRBR) как обобщенное представ-
ление библиографического универсума,
независимого от какого-либо кода катало-
гизации или реализации.
В 1998 году модель была опубликова-
на [5]. В настоящее время IFLA продолжа-
ет контролировать приложения модели
FRBR и поддерживает ее использование и
развитие.
FRBR включает описание концептуа-
льной модели (сущности, их отношения и
атрибуты), предлагает универсальные биб-
лиографические записи для всех типов ма-
териалов и пользовательских задач, свя-
занных с библиографическими ресурсами,
описанными в каталогах, библиографиях и
других библиографических инструментах
[10, 11].
Модель FRBR различает три группы
сущностей (рис. 2):
− для описываемых объектов: произ-
ведение (work), выражение (expression),
воплощение (manifestation), экземпляр
(item);
− для описателей-субъектов: человек
(person) и организация (corporate body);
− для описателей-объектов: концепт,
объект, событие и место (concept, object,
event, place).
Далее приведен пример [12] экземпля-
ров сущностей произведения (w1) и его
выражений (e1-e2):
w1 Tennis-bis zum Turnierspieler Элль-
вангера:
− e1 оригинальный текст на немецком
языке;
− e2 перевод на английский язык Вен-
ди Джилл.
Большое внимание в модели уделено
отношениям между сущностями.
Отношения могут быть отражены в
библиографических записях многими спо-
собами. Те, что изображены на ER-
диаграмме FRBR (рис. 2), описывают ло-
гические связи между сущностями и часто
реализуются простой конкатенацией одной
сущности с атрибутами связанной сущнос-
ти в одной записи.
Помимо логических связей в модели
выделена группа так называемых контент-
ных связей (для первой группы сущнос-
тей). Они идентифицируют основные типы
отношений, которые существуют между
экземплярами сущности одного типа (на-
пример, сущности произведения) или ме-
жду экземплярами разных типов сущнос-
тей (например, сущностей произведение и
воплощение). Например, в группе отноше-
ний произведение-произведение выделены
Експертні та інтелектуальні інформаційні системи
65
Рис. 2. Модель FRBR
такие типы отношений: имеет адаптацию
(свободный перевод); имеет приложение
(сходство, соответствие), имеет продол-
жение; имеет резюме (обзор, аннотацию);
имеет преобразование (стихотворную фо-
рму); имеет имитацию (пародию). В гру-
ппе отношений выражение-выражение
перечислены следующие типы отношений:
имеет сокращение (корректировку, уплот-
нение); имеет пересмотр (исправленную
редакцию, расширенную редакцию); име-
ет перевод (буквальный перевод) и неко-
торые другие типы отношений, касающие-
ся музыкальных произведений. И наконец,
отношения часть/целое и часть в части
также представлены в модели FRBR.
Следует отметить, что в FRBR грани-
цы между различными типами основных
сущностей (произведение и выражение)
размыты и окончательное решение по то-
му, к какому типу отнести тот или иной
объект, отдается на откуп каталогизатору.
Кроме того, сущностей этих совсем немно-
го и явно недостаточно для большинства
конкретных библиотечных приложений.
Для нас основной интерес представляет
очень богатый набор атрибутов и отноше-
ний в этой модели. Как и в случае CIDOC
CRM, в соответствии с решаемыми зада-
чами, FRBR применима только для описа-
ния информационной составляющей кон-
цептуальной модели.
Мысль о том, что и библиотечное, и
музейное сообщество могут выиграть от
гармонизации вышерассмотренных двух
моделей, впервые прозвучала в Париже на
24-м Семинаре библиотечных систем
ELAG (Европейской группы автоматиза-
ции библиотек). Однако реальная работа
началась после 2003 года, когда была об-
разована группа по пересмотру FRBR спе-
циально для гармонизации этих двух кон-
цептуальных моделей. В 2008 году рабочая
группа по гармонизации FRBR и CIDOC
CRM завершила важный этап работы: пол-
ная версия 0.9 draft объектно-
ориентированной формулировки FRBR
(FRBRoo) была представлена для обсуж-
дения.
FRBR моделирует результаты (произ-
ведение, выражение…) процессов (таких
как создание, реализация, планирование),
но не сами процессы. FRBRoo, используя
подход CRM, фокусируется на процессах.
Такой подход позволяет принимать во
внимание обстоятельства, при которых,
например, конкретные произведения были
задуманы или реализованы. Подобные об-
Експертні та інтелектуальні інформаційні системи
66
стоятельства могут быть предметом иссле-
дования (например, в теории литературы),
но существующие библиографические ин-
струменты не могут достаточно хорошо
обеспечить данное исследование. Хотя
можно возразить, что большинству биб-
лиотек не требуется выполнять подобные
специализированные исследования, но это
важно для общей модели, чтобы поддер-
живать как можно больше запросов. В ка-
ждом конкретном случае уровень сложно-
сти должен определяться с учетом всей
имеющейся информации.
В результате в FRBRoo объекты произ-
ведение, выражение и воплощение были
разбиты на несколько классов со специфи-
ческими свойствами. Так, в FRBRoo при-
сутствует класс произведение, но также
декларированы подклассы индивидуальное
произведение (Individual Work), составное
произведение (Complex Work), сопроводи-
тельное произведение (Container Work),
совокупность произведений (Aggregation
Work), серийное произведение (Serial
Work), издательское произведение
(Publication Work), исполнительское про-
изведение (Performance Work), записанное
произведение (Recording Work). Класс про-
изведение является суперклассом, объеди-
няющим подклассы как частные случаи,
каждый из которых имеет свою специфику
создания или составления. Данный анализ
– это шаг к пониманию вопросов, связан-
ных с совокупностями произведений (аг-
регатами).
FRBRoo следует рассматривать как ин-
терпретацию FRBR, а не ее новую версию
или замену. Главное новшество FRBRoo –
реалистичная, явная модель процесса ин-
теллектуального творчества, которая еще
должна получить свое дальнейшее разви-
тие для библиотекарей и ученых [13].
3. DELOS DLRM
Группа специалистов ассоциации в
сфере ЭБ DELOS в 2006–2007 гг., основы-
ваясь на анализе имеющихся библиотеч-
ных систем [3], где большое внимание бы-
ло уделено функциональным возможнос-
тям современных ЭБ, начали разработку
эталонной модели ЭБ (Digital Library
Reference Model, DLRM) [6]. Цель проекта
– разобраться с фундаментальными поня-
тиями, существенными объектами и их от-
ношениями, стандартными функциональ-
ными и структурными блоками и процес-
сами, из которых состоит универсум ЭБ.
Эталонная модель предназначена для раз-
работки более узких моделей с конкретной
архитектурой для последующей реализа-
ции программных систем.
Прежде всего, в модели было выделено
три понятия для разграничения того, что
обычно называется ЭБ:
− ЭБ – конкретная ЭБ с ее пользова-
телями, правилами, содержимым, интер-
нет-сайтом и ведущей организацией. На-
пример, библиотека Института программ-
ных систем http://eprints.isofts.kiev.ua;
− система ЭБ – программное обеспе-
чение, на основе которого создаются ЭБ.
Например, EPrints 3.0.
− система управления ЭБ – программ-
ное обеспечение для создания и управле-
ния системами ЭБ. Например, система
OpenDLib5.
Далее модель DELOS DLRM рассмат-
ривается в ролевом аспекте, т. е. с точки
зрения разных категорий пользователей:
− конечный пользователь ЭБ;
− разработчик ЭБ;
− системный администратор ЭБ;
− разработчик приложений для ЭБ.
Соответственно DELOS DLRM имеет че-
тыре уровня пользовательских представ-
лений.
Весь универсум ЭБ разбит на шесть
высокоуровневых ключевых областей
(рис. 3):
− контент;
− пользователь;
− функциональные возможности;
− качество;
− политики;
− архитектура
и несколько дополнительных. Эти
шесть областей объединены в одну
область ресурса. В каждой из них вводятся
и определяются свои сущности и их
свойства.
Теперь вкратце рассмотрим наиболее
важные области ЭБ и их структуру.
5 http://www.opendlib.com
Експертні та інтелектуальні інформаційні системи
67
Рис. 3. Иерархия областей ЭБ в модели
DELOS DLRM
Область ресурса ЭБ – наиболее об-
щая область в данной модели, представля-
ет все сущности и связи, населяющие уни-
версум ЭБ. Ресурс – наиболее общее поня-
тие, включающее любую сущность ЭБ. По
аналогии с ресурсом в Веб, ресурс – это
все то, что может быть идентифицировано,
названо или адресовано. Представленная
здесь модель ресурса исходит из веб-
архитектуры, но дополнена некоторыми
аспектами, специфичными для предмет-
ной области ЭБ.
Ресурс – абстрактное понятие, в том
смысле, что непосредсвенно не имеет эк-
земпляров, он только выражен экземпля-
рами одной из своих специализаций. В ча-
стности, экземплярами понятия ресурс в
универсуме ЭБ являются экземпляры ин-
формационного объекта любого типа (на-
пример, документы, изображения, видео,
мультимедийные объекты, наборы мета-
данных и аннотаций, потоки, базы даных,
коллекции, запросы и результаты запро-
сов), акторы (как одушевленные так и не-
одушевленные сущности), функции, поли-
тики, параметры качества ЭБ и архите-
ктурные компоненты. Каждый из этих эк-
земпляров представляет главное понятие в
своей области, таким образом в представ-
ленной модели ЭБ каждая область состоит
из ресурсов, а ресурсы – строительные
блоки всех областей ЭБ. Каждый ресурс:
− имеет идентификатор;
− организован в соответствии с фор-
матом ресурса. Формат здесь выражен
онтологией. Ресурс может быть сложным
и структурированным, поскольку он, в
свою очередь, может состоять из меньших
ресурсов и иметь связи с другими ресур-
сами;
− может характеризоваться парамет-
рами качества;
− может регулироваться политиками,
управляющими его жизненным циклом;
− выражается через информационный
объект;
− может быть описан или дополнен
информационным объектом, обычно – ме-
таданными и аннотациями.
С организационной точки зрения, ре-
сурсы могут группироваться в наборы ре-
сурсов, которые рассматриваются как еди-
ная сущность. Например, коллекции в об-
ласти контента или группы в области поль-
зователя.
Область контента (рис. 4) представ-
ляет все объекты, связанные с информаци-
ей, которой управляет ЭБ. Информацион-
ный объект – наиболее общее понятие в
этой области, представляет произвольную
единицу информации, управляемую в уни-
версуме ЭБ. В DELOS DLRM различают
информационный объект по уровню абст-
ракции, где заимствуются типы объектов
из модели FRBR (произведение, выраже-
ние, воплощение) и информационный объ-
ект по связи – "абстрактный концептуаль-
ный контейнер для классов, которые по-
рождают эти объекты", а именно:
− первичный информационный объект
– информационный объект, который ис-
пользуется самостоятельно, например, тек-
стовые документы, изображения;
− метаданные – информационный
объект, главная цель которого состоит в
том, чтобы дать информацию о целевом
ресурсе (как правило о первичном инфор-
мационном объекте);
− аннотация – информационный объ-
ект, главная цель которого состоит в том,
чтобы аннотировать целевой ресурс или
его часть (на рис. 4 части ресурса соответ-
ствует сущность регион). Примеры таких
аннотаций включают примечания, струк-
турированные комментарии и связи. Объ-
екты аннотации помогают интерпретиро-
вать целевой ресурс, содержат либо
Експертні та інтелектуальні інформаційні системи
68
Рис. 4. Область контента ЭБ в модели DELOS DLRM
поддержку, либо возражения, либо более
детальные объяснения.
Поскольку информационный объект
является ресурсом, то он наследует все
вышеперечисленные свойства ресурса.
Информационные объекты также мо-
гут быть сложными объектами и могут
быть сгруппированы в коллекции инфор-
мационных объектов. Коллекции, в свою
очередь, тоже являются информационны-
ми объектами, они наследуют все аспекты
моделирования информационных объектов
и средства их обслуживания, например
они могут аннотироваться. Кроме того,
коллекция – специализация понятия набо-
ра ресурсов. Коллекции определяются
критерием отбора (hasIntension) либо пе-
речислением элементов (hasExtension).
Другая специализация понятия набор ре-
сурсов в данной модели – результирующий
набор. В традиционных ЭБ он представ-
ляет собой набор документов, которые из-
влекаются в ответ на запрос.
Область пользователя в DELOS
DLRM содержит все объекты, которые яв-
ляются "внешними по отношению к сис-
теме ЭБ и с ней взаимодействуют: люди и
неодушевленные объекты, например, про-
граммы или физические инструменты…
или даже другая ЭБ может быть среди
пользователей ЭБ".
Поскольку главная сущность в этой
области – актор является ресурсом и сле-
довательно, наследует все его свойства, а
именно:
− имеет уникальный идентификатор
(идентификатор пользователя);
− организован в соответствие с фор-
матом (модель пользователя);
− благодаря свойствам ресурса компо-
зиции и соединения может быть составлен
в различные сложные и структурирован-
ные группы например, сотрудничество
пользователей или cоавторов;
− описан или дополнен метаданными
и аннотациями.
Область функций представляет наи-
более объемную и наиболее открытую
часть модели DELOS DLRM, поскольку
охватывает всю обработку ресурсов, а
также действия пользователей в ЭБ. Здесь
наиболее общим понятием является сущ-
ность функция. Функция – специфическая
задача обработки, которая может быть
реализована на наборе ресурсов или одном
ресурсе в результате действий отдельного
пользователя. Описание функций основано
на пользовательском аспекте и ресурсе,
представляющем все объекты, вовлечен-
ные в ЭБ. Хотя функции в традиционных
моделях ЭБ обычно связываются с кон-
тентом в ЭБ и выполняются людьми,
Експертні та інтелектуальні інформаційні системи
69
здесь, в данной модели, функции могут
выполняться неодушевленными пользова-
телями на любом типе ресурсов.
В данной модели ЭБ каждая функция
также является ресурсом и потому насле-
дует все его характеристики.
Функции разделены на пять классов:
− доступ к ресурсам;
− управление ресурсами;
− совместная работа;
− управление ЭБ;
− настройка ЭБ.
Внимательное изучение данной моде-
ли помогло не только обозреть всю сферу
ЭБ, но и найти некоторые пробелы в самой
модели. Вот некоторые из них:
− недостаточно формализованные оп-
ределения, оставляющие размытыми гра-
ницы многих сущностей (например, сущ-
ности, заимствованные из FRBR, или гра-
ница между метаданными и аннотацией);
− в некоторых местах остаются не яс-
ными критерии выделения сущностей (в
частности, область качества наименее убе-
дительна в этом отношении);
− неоднородность описания различ-
ных областей ЭБ, скрытая за внешне одно-
образным описанием (достаточно сравнить
простую иерархию области функций со
сложной структурой области контента).
К преимуществам DELOS DLRM сле-
дует отнести наибольшую полноту охвата
среди существующих концептуальных мо-
делей ЭБ.
4. Модель 5S
Goncalves и другие предложили и фо-
рмализовали модель 5S – Streams,
Structures, Spaces, Scenarios and Societies
(Потоки, Структуры, Пространства, Сце-
нарии и Сообщества) [7]. Целью авторов
было не только разработать структуру для
проектирования и разработки ЭБ, но также
для того чтобы пользователям было проще
понять данные технологии. В частности,
5S ориентирована на описание информа-
ционных систем как таковых. В рамках
данной модели ЭБ – это комплексная сис-
тема, которая помогает: удовлетворить
информационные потребности пользова-
телей (Сообществ), предоставить инфор-
мационные сервисы (Сценарии), организо-
вать информацию в удобном виде (Струк-
туры), предоставить полезную информа-
цию (Пространства) и связать информа-
цию с пользователями (Потоки) [14]. 5S
позволяет определить ЭБ, используя эти 5
взаимодополняющих элементов. В табл. 1.
приведены примитивы, формализмы и це-
ли элементов [15].
С помощью формальной модели 5S,
абстракции, такие как электронные объек-
ты, метаданные, коллекции, сервисы и т.д.
могут быть описаны посредством компо-
зиции базовых и высокоуровневых мате-
матических объектов.
Например,
− Сообщества + Сценарии = Пользо-
вательская модель.
− Сообщества + Сценарии + Про-
странства + Потоки = Пользовательский
интерфейс.
− Потоки + Структуры = Разметка.
− Потоки + Структуры + Сценарии =
= Объект.
− Структуры + Сценарии = СУБД.
Рассмотрим подробнее, что же из себя
представляют элементы модели 5S.
Потоки (Streams) – последовательно-
сти элементов произвольных типов, ис-
пользуемых для описания как статического
(например, текст) так и динамического
(например, видео) контента. Динамиче-
ский поток может представить поток ин-
формации или последовательность сооб-
щений, таким образом, являясь важным
элементом для представления любых ком-
муникаций в ЭБ.
Как правило, динамический поток вос-
принимается посредством его временной
природы. Тогда динамический поток мо-
жет быть интерпретирован как конечная
последовательность показателей времени и
связанных значений, которые могут ис-
пользоваться для определения потоковой
алгебры, позволяющей выполнять опера-
ции на разнообразных видах мультимедиа
потоков. В статической интерпретации
временная природа обычно не использует-
ся, и поток соответствует некоторому ин-
формационному наполнению, которое ин-
терпретируется как последовательность
Експертні та інтелектуальні інформаційні системи
70
Таблица 1. Примитивы, формализмы и цели элементов 5S
Измерение Примитивы Формализм Цели
Потоки
Текст, видео, аудио, программа
Последовательности,
типы
Описывает свойства контента ЭБ, такие
как система кодировки и язык для тек-
стовых материальных или специфиче-
ских форм мультимедиа данных
Структуры
Коллекция, каталог, гипертекст,
документ, метаданные, органи-
зационные инструментальные
средства
Графы, узлы, ссылки,
метки, иерархии
Определяет организационные аспекты
контента ЭБ
Пространства Пользовательский интерфейс,
индекс; модель поиска
Наборы, операции, век-
торное пространство,
пространство с мерой,
пространство вероятно-
сти
Определяет логические и презентацион-
ные представления некоторых компо-
нентов ЭБ
Сценарии
Сервис, событие, условие, дей-
ствие
Диаграммы последова-
тельностей, диаграммы
сотрудничества
Детализирует поведение сервисов ЭБ
Сообщества
Содружество, менеджеры, ак-
теры, классы; отношения, атри-
буты, операции
Объектно-
ориентированные конст-
рукции моделирования,
шаблоны
Определяет менеджеров; ответственных
за выполнение сервисов ЭБ; актеров,
которые используют эти службы; и от-
ношения между ними
базовых элементов, обычно одного и того
же типа. Примером статического потока
является текст (последовательность сим-
волов). Тип потока определяет его семан-
тику и область применения. Например,
любое текстовое представление можно
рассматривать как поток символов, таким
образом, текстовые документы, такие как
научные статьи и книги, можно рассмат-
ривать как структурированные потоки.
Структуры (Structures) определяют
способ, которым части целого упорядоче-
ны или организованы. В ЭБ структуры
представляют гипертексты, таксономии,
взаимосвязи пользователей и т. д. Книги,
например, можно логически структуриро-
вать в главы, разделы, подразделы или фи-
зически в страницы и строки. Электронные
документы обычно структурированы с по-
мощью языков разметки (например,
HTML, XML). В реляционных базах дан-
ных данные структурированы с помощью
схем, используя таблицы. В модели 5S
структура определяется как помеченный
ориентированный граф.
Пространство (Spaces) – любой набор
объектов вместе с операциями над этими
объектами, которые удовлетворяют опре-
деленным правилам. Объединение опера-
ций и объектов отличает пространства от
потоков и структур. Они зачастую приме-
няются, когда нельзя с помощью других
измерений определить часть ЭБ, которую
могут моделировать традиционные биб-
лиотеки, используя пространства вирту-
ального мира. Также пространства для
поддержки совместной работы обеспечи-
вают контекст, для виртуальных встреч и
сотрудничества. Пространства отличаются
операциями над своими объектами. ЭБ мо-
гут использовать много типов пространств,
для того чтобы индексировать, визуализи-
ровать и выполнять другие операции. Са-
мыми значимыми для ЭБ являются изме-
римые пространства, пространства с ме-
рой, пространства вероятности, векторные
пространства и топологические простран-
ства.
Сценарии (Scenarios) состоят из по-
следовательностей событий или действий,
которые изменяют состояния, для дости-
жения функциональных требований. Од-
ним из важных типов сценария является
текст, который описывает возможные спо-
собы использования системы, для дости-
жения функции, необходимой пользовате-
лю. Сценарии полезны как часть процесса
проектирования информационных систем.
Они помогают визуализировать простран-
ства, организовав потоки в соответствии со
структурой. Таким образом, набор сцена-
риев описывают сервисы, действия, задачи
и операции, а они, в конечном счете, опре-
деляют функциональные возможности ЭБ.
Понятия состояния и события фунда-
ментальны для понимания сценариев. Не-
Експертні та інтелектуальні інформаційні системи
71
формально, состояние определяется тем,
какой информационный контент находятся
в указанных местах (например, в машин-
ной памяти). Событие обозначает переход
или изменение между состояниями (на-
пример, выполнение команды в програм-
ме). Сценарии определяют последователь-
ности событий, которые вовлекают дейст-
вия, которые изменяют состояния и влия-
ют на возникновение и результаты буду-
щих событий. В ЭБ сценарии моделируют
потоки данных и рабочие процессы.
Сообщество (Societies) это ряд объек-
тов и действий и отношений между ними.
Объекты включают людей, а так же аппа-
ратные и программные компоненты так
или иначе связанные с ЭБ. Действия со-
стоят в том, что объекты сделали, делают и
будут делать друг с другом. Отношения
определяют связи между объектами и дей-
ствиями сообщества. Сообщества необхо-
димы, чтобы описать контекст использо-
вания ЭБ. Сообщество - компонент высше-
го уровня библиотеки, поскольку ЭБ воз-
никла, для того чтобы удовлетворить ин-
формационные потребности ее сообществ.
В электронных библиотеках опреде-
ленные человеческие сообщества включа-
ют авторов, издателей, редакторов, разра-
ботчиков и библиотечный штат. В челове-
ческом сообществе у людей есть роли, це-
ли и отношения. Сообщества следуют оп-
ределенным правилам, и их участники иг-
рают роли менеджеров, участников или
пользователей. В участников есть действия
и взаимосвязи. Во время их действий уча-
стники сообщества создают информацион-
ные артефакты, которыми может управ-
лять ЭБ.
Рассмотренные измерения наряду с
другими фундаментальными теоретиче-
скими определениями, используются для
определения других конструкции ЭБ, та-
ких как цифровые объекты, спецификации
метаданных, коллекции, репозитории и
сервисы.
На основе модели 5S было определено
"ядро" ЭБ или "минимальную" ЭБ, т. е.,
минимальный набор компонентов, кото-
рые ее составляют и без которых прило-
жение нельзя считать ЭБ. Каждый компо-
нент (например, коллекции, сервисы) фор-
мально определяются с точки зрения кон-
струкций 5S или как комбинация, или ком-
позиция двух, или более из них. На рис. 5
показаны различные уровни определений:
математические основы (графы, последо-
вательности и функции), измерения 5S и
ключевые концепты (цифровой объект,
коллекция) [16]. Стрелки представляют
зависимости, указывая, что понятие фор-
мально определено ранее с точки зрения
понятий, которые указывают на него.
Сервисы, предоставляемые ЭБ, можно
классифицировать как элементарные или
составные [6]. Элементарные сервисы
обеспечивают базовую инфраструктуру
ЭБ. К таким сервисам относятся сбор, ин-
дексация, оценка и привязки. Составные
сервисы могут быть составлены из других
элементарных или составных сервисов,
путем их многократного использования
или их расширения. Например, сервисы
поиска и просмотра используют сервисы
индексирования и привязки.
Рис. 5. Минимальная ЭБ в 5S
Експертні та інтелектуальні інформаційні системи
72
Таблица 2. Таксономия сервисов ЭБ онтологии 5S
Инфраструктурные сервисы
Построение репозитория
Создание Хранение
Добавление
значений
Сервисы предоставле-
ния информации
Сбор данных Сохранение Аннотация Присвоение
Авторство Конвертация Классификация Просмотр
Каталогизация Копировании/Репликация Кластеризация Распространение
Краулинг Эмуляция Настройка Расширение (запрос)
Описание Восстановление Оценка Фильтрация
Оцифровка Преобразование (формата) Извлечение Рекомендация
Харвестиг Индексирование Запрашивание
Снабжение Привязка Поиск
Внесение Протоколирование Визуализация
Измерение
Ранжирование
Рецензирование
Обзор
Обучение (классификатор)
Перевод (язык/формат)
В табл. 2 приведена таксономия серви-
сов ЭБ [17]. В этой таксономии определя-
ются фундаментальные сервисы (обозна-
ченные полужирным шрифтом) такие как:
− те, которые помогают создавать
элементы базовых понятий, входящих в
минимальное определение ЭБ, такие как
цифровые объекты, спецификации мета-
данных, коллекции и каталоги;
− те, которые принадлежат минималь-
ному набору сервисов ЭБ (например, по-
иск и просмотр);
− те, которые поддерживают преды-
дущие сервисы с точки зрения расширения
и многократного использования.
Подчеркиванием обозначены состав-
ные сервисы. В рамках данного проекта
была разработана, на наш взгляд наиболее
полная и проработанная, онтология ЭБ
[17]. Кроме того на основе модели 5S было
разработано ряд инструментов: Деклара-
тивный язык 5SL [15] на основе XML, для
определения и генерации ЭБ; 5SQual [18] –
инструмент для автоматической проверки
качества ЭБ, ее объектов, метаданных и
сервисов; 5SGen, осуществляющий гене-
рацию кода для реализации ЭБ, используя
ее определение на языке 5SL; 5SGraph –
инструмент для моделирования ЭБ;
5SSuite – набор инструментов для под-
держки генерации объединения ЭБ, вклю-
чающий 5SGraph, 5SGen и SchemaMapper
(который отображает отдельные схемы ЭБ,
в общую схему объединенной ЭБ) [19].
Достоинством 5S является то, что это
формальная модель с четкими математиче-
скими определениями, правилами и ак-
сиомами. С другой стороны, на наш
взгляд, модель слишком оторвана от ре-
альности и слишком универсальна, хотя и
позиционируется как модель ЭБ. Приме-
нение или "наложение" ее на реальную
систему ЭБ неочевидно, хотя авторы при-
водят соответствующие примеры. Учиты-
вая то, что модель развивается "снизу
вверх" от минимальной модели, она охва-
тывает меньше аспектов ЭБ по сравнению
с моделью DELOS.
Заключение
В мире электронных библиотек суще-
ствуют задачи, которые могут быть реше-
ны с помощью качественного концепту-
ального описания таких систем. На сего-
дняшний день не существует всеохваты-
вающей модели ЭБ, которую можно было
бы с полным правом назвать эталонной.
Построение хорошей модели, учитываю-
щей мировой опыт подобных разработок,
является нашей целью.
В работе представлен подробный ана-
лиз ряда известных проектов из этой об-
ласти: CIDOC CRM, FRBR, FRBRoo,
DELOS DLRM, 5S. На основновании ко-
торого в настоящий момент проводится
разработка оригинальной модели научной
электронной библиотеки.
Експертні та інтелектуальні інформаційні системи
73
1. Когаловский М.Р., Паринов С.И. Информа-
ционные ресурсы, наукометрические пока-
затели и показатели качества метаданных
системы Соционет // Тр. IX Всероссийской
конф. "Электронные библиотеки: перспек-
тивные методы и технологии, электронные
коллекции". − RCDL’2007, г. Переславль-
Залесский, Россия. − 2007. − С. 45−54.
2. А Guide to Institutional Repository Software.
3rd Edition. Open Society Institute. 2004.
http://www.soros.org/openaccess/
pdf/OSI_Guide_to_IR_Software_v3.pdf
3. Candela L., Castelli D., Fuhr N., Ioannidis Y.,
Klas C.-P., Pagano P., Ross S., Saidis C.,
Schek H.-J., Schuldt H., Springmann M. Cur-
rent Digital Library Systems: User Require-
ments vs Provided Functionality. IST-2002-
2.3.1.12. Technology-enhanced Learning and
Access to Cultural Heritage. March 2006.
4. Crofts N., Doerr M., Gill T., Stead S.,, Stiff M.
(editors), Definition of the CIDOC Concep-
tual Reference Model, January 2008. Version
4.2.4.
5. Functional Requirements for Bibliographic
Records, Final Report / IFLA Study Group on
the Functional Requirements for Biblio-
graphic Records. – München: K.G. Saur,
1998. (UBCIM Publications, New Series;
v.19).http://archive.ifla.org/VII/s13/frbr/frbr.h
tm
6. Candela L., Castelli D., Dobreva M., Ferro
N., Ioannidis Y., Katifori H., Koutrika G.,
Meghini C., Pagano P., Ross S., Agosti M.,
Schuldt H., Soergel D. The DELOS Digital
Library Reference Model Foundations for
Digital Libraries. IST-2002-2.3.1.12. Tech-
nology-enhanced Learning and Access to Cul-
tural Heritage. Version 0.98, December 2007.
http://www.delos.info/files/pdf/ReferenceMod
el/DELOS_DLReferenceModel_0.98.pdf
7. Goncalves M.A.., Fox E.A.., Watson L.T. and
Kipp N.A. Streams, structures, spaces, scenar-
ios, societies (5s): A formal model for digital
libraries // ACM Trans. Inf. Syst. 22(2). −
2004. − Р. 270–312.
8. The CIDOC Conceptual Reference Model.
http://cidoc.ics.forth.gr
9. Doerr M., Iorizzo D. The Dream of a Global
Knowledge Network − A New Approach //
ACM J. on Computing and Cultural Heritage,
June 2008. − Vol. 1, N. 1, Article 5.
10. Tillett, Barbara B. “Bibliographic Relation-
ships.” In: Relationships in the Organization
of Knowledge, edited by Carol A. Bean and
Rebecca Green. − Dordrecht: Kluwer Aca-
demic Publishers, 2001. − Р. 19−35.
11. Barbara Tillett What is FRBR? A Conceptual
Model for the Bibliographic Universe.
http://www.loc.gov/cds/downloads/FRBR.pdf
12. Функциональные требования к библиогра-
фическим записям : окончат. отчет / Рос.
библ. ассоц., Рос. гос. б-ка ; пер. с англ.
[В.В. Арефьев ; науч. ред. пер.: Т.А. Бахту-
рина, Н.Н. Каспарова, Н.Ю. Кулыгина]. −
М.: РГБ, 2006. − 150 с.
13. Doerr M., Leboeuf P. Modelling intellectual
processes: The FRBR−CRM harmonization //
In Conf. Proc. of ICOM-CIDOC Annual
Meeting. Gothenburg, Sweden. − 2006. −
Р. 10–14.
14. Fox E.A. From Theory to Practice in Digital
Libraries: 5S and Educational. Applications
(NDLTD, CSTC) // Workshop on Digital Li-
braries, Albuquerque NM. − 1999.
15. http://www.dlib.vt.edu/projects/5S-Model/
16. Murthy U., Gorton D., Torres R., Goncalves
M.A, Fox E.A., Delcambre L. Extending the
5S Digital Library (DL) Framework: from a
minimal DL towards a DL Reference Model //
ACM IEEE J. Conf. on Digital Libraries. −
2007.
http://fox.cs.vt.edu/talks/2007/20070623JCDL
dlfWkshpMurthy-5S.ppt
17. Goncalves M.A., Fox E.A., Watson L.T. To-
wards a digital library theory: a formal digital
library ontology // Int. J. Conf. on Digital Li-
braries, 8(2). − 2008. − Р. 91−114.
18. Moreira B.L., Goncalves M.A., Laender
A.H.F., Fox E.A. 5SQual: a quality assess-
ment tool for digital libraries // JCDL ’07:
Proc. of the ACM/IEEE-CS J. Conf. on Digi-
tal Libraries. − 2007. − Р. 513−513.
19. Shen R. Applying the 5S Framework To Inte-
grating Digital Libraries. Ph.D. Dissertation.
Department of Computer Science, Virginia
Tech. − 2006.
http://scholar.lib.vt.edu/theses/available/etd04
212006-135018/unrestricted /Rao_final De-
fense_final5.pdf
Получено 17.03.2010
Експертні та інтелектуальні інформаційні системи
74
Об авторах:
Резниченко Валерий Анатольевич,
ведущий научный сотрудник,
Проскудина Галина Юрьевна,
научный сотрудник,
Кудим Кузьма Алексеевич,
младний научный сотрудник,
Овдий Ольга Михайловна,
младший научный сотрудник.
Место работы авторов:
Институт программных систем
НАН Украины,
03187, Киев-187,
Проспект Академика Глушкова, 40.
Тел. +38(044)526 6033
е-mail: reznich@isofts.kiev.ua
gupros@isofts.kiev.ua
kuzma@isofts.kiev.ua
olga.ovdiy@gmail.com
|
| id | pp_isofts_kiev_ua-article-972 |
| institution | Problems in programming |
| keywords_txt_mv | keywords |
| language | Russian |
| last_indexed | 2026-06-02T01:02:10Z |
| publishDate | 2026 |
| publisher | PROBLEMS IN PROGRAMMING |
| record_format | ojs |
| resource_txt_mv | ppisoftskievua/f7/942e572949c96cdc8d0004f995a826f7.pdf |
| spelling | pp_isofts_kiev_ua-article-9722026-06-01T21:28:34Z About construction of digital library models О построении моделей электронных библиотек Про побудову моделей електронних бібліотек Reznichenko, V.A. Proskudina, G.Yu Kudim, K.A. Ovdiy, О.М. UDC 004.415 УДК 004.415 УДК 004.415 The paper is concerned with creation of digital library models. Several wellknown connected projects are discussed, those are CIDOC CRM, FRBR, FRBRoo,DELOS DLRM and 5S. The study can be used as the basis for creating your own original model DL, which possible should use their strengths and avoid its shortcomings.Problems in programming 2010; 4: 60-74 Работа посвящена задаче создания моделей электронных библиотек. Обсуждаются некоторые известные связанные проекты – СIDOC CRM, FRBR, FRBRoo, DELOS DLRM и 5S. Исследование может быть положено в основу создания собственной оригинальной модели ЭБ, которая должна по-возможности использовать их сильные стороны и избежать имеющиеся недостатки.Problems in programming 2010; 4: 60-74 Робота присвячена задачі створення моделей електронних бібліотек. Обговорюються деякі відомі зв’язані проекти – СIDOC CRM, FRBR, FRBRoo, DELOS DLRM и 5S. Дослідження може бути покладено в основу ство-рення власної оригінальної моделі ЕБ, яка має по-можливості врахувати їх сильні сторони й уникнути їх недоліків.Problems in programming 2010; 4: 60-74 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2026-06-01 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/972 PROBLEMS IN PROGRAMMING; No 4 (2010); 60-74 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 4 (2010); 60-74 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 4 (2010); 60-74 1727-4907 ru https://pp.isofts.kiev.ua/index.php/ojs1/article/view/972/1040 Copyright (c) 2026 PROBLEMS IN PROGRAMMING |
| spellingShingle | UDC 004.415 Reznichenko, V.A. Proskudina, G.Yu Kudim, K.A. Ovdiy, О.М. About construction of digital library models |
| title | About construction of digital library models |
| title_alt | О построении моделей электронных библиотек Про побудову моделей електронних бібліотек |
| title_full | About construction of digital library models |
| title_fullStr | About construction of digital library models |
| title_full_unstemmed | About construction of digital library models |
| title_short | About construction of digital library models |
| title_sort | about construction of digital library models |
| topic | UDC 004.415 |
| topic_facet | UDC 004.415 УДК 004.415 УДК 004.415 |
| url | https://pp.isofts.kiev.ua/index.php/ojs1/article/view/972 |
| work_keys_str_mv | AT reznichenkova aboutconstructionofdigitallibrarymodels AT proskudinagyu aboutconstructionofdigitallibrarymodels AT kudimka aboutconstructionofdigitallibrarymodels AT ovdiyom aboutconstructionofdigitallibrarymodels AT reznichenkova opostroeniimodelejélektronnyhbibliotek AT proskudinagyu opostroeniimodelejélektronnyhbibliotek AT kudimka opostroeniimodelejélektronnyhbibliotek AT ovdiyom opostroeniimodelejélektronnyhbibliotek AT reznichenkova propobudovumodelejelektronnihbíblíotek AT proskudinagyu propobudovumodelejelektronnihbíblíotek AT kudimka propobudovumodelejelektronnihbíblíotek AT ovdiyom propobudovumodelejelektronnihbíblíotek |