УДК 681.3 Документальная информационная система организационно-правовой защиты интеллектуальной собcтвенности в высшей школе "ПраЗИС"В целях осуществления принятой Комитетом по высшей школе Российской Федерации программы "Интеллектуальная собственность высшей школы" группой сотрудников кафедры "Электронные вычислительные машины и системы" МГТУ им. Н.Э. Баумана выполнены работы по разработке экспертной системы по организационно-правовой защите интеллектуальной собственности в высшей школе "ПраЗИС". Из назначения проектируемой системы вытекают некоторые общие требования к ней. С одной стороны, она должна содержать полные тексты правовых актов, регулирующих отношения в области защиты интеллектуальной собственности, что сближает ее с документальными информационно-справочными системами. Обеспечения только хранения текстов и просто их просмотра недостаточно. Правовые документы содержат большое количество ссылок на другие документы или разделы того же документа, а также насыщены специальными понятиями и терминами. Для эффективной работы с текстами требуется механизм перехода по ссылкам и возможность обращения к словарю понятий, что свойственно гипертекстовым системам. С другой стороны, вся существенная информация, содержащаяся в текстах этих актов, должна быть извлечена, надлежащим образом препарирована и представлена в виде знаний, пригодных для хранения в компьютерной системе, что характерно для экспертных систем [1,2]. Таким образом, в проектируемой системе требуется сочетание возможностей систем трех разных классов: документальных информационно-справочных систем (ИСС), гипертекстовых систем и экспертных систем. На сегодняшний день нам не известны готовые прототипы таких систем. Сочетание в одной системе свойств систем трех разных классов не позволяют использовать при разработке готовые инструментальные пакеты ни информационных и гипертекстовых, ни экспертных систем [3 - 5]. Требуется создание оригинального программного продукта, а это значительно увеличивает трудоемкость разработки и превращает ее в серьезную техническую задачу. Исходя из изложенного, была разработана общая структура системы организационно-правовой защиты интеллектуальной собственности ПраЗИС и концепция разработки, включающие следующие положения.
Рис. 1. Организационные уровни и основные фунциональные подсистемы ЭС ПраЗИС
Рис. 2. Организация информации в ЭС ПраЗИС В соответствии со схемой на рис.1. разработка системы естественным образом отражает этапы, соответствующие организационным уровням:
На данном этапе разработки основные усилия были направлены на:
Целевая направленность разрабатываемой системы определила содержание информационной базы законодательных документов и нормативных актов. Наполнение базы велось по трем основным разделам:
Первый раздел включает Закон РФ "Об образовании", нормативные акты, регламентирующие деятельность Комитета по высшему образованию, высших учебных заведений России. Второй раздел включает законодательные акты Российской Федерации о защите интеллектуальной собственности, а также "Основы гражданского законодательства Союза ССР и Республик" с набором нормативных актов, вносящих в этот документ изменения и дополнения. Такой состав второго раздела позволит пользователю системы получать информацию как об общих принципах авторского права, так и о конкретных правовых нормах. Введение третьего раздела и его состав продиктованы тем, что, по-нашему мнению, реализация тех или иных норм авторского права невозможна без того, чтобы в той или иной степени не были бы затронуты смежные вопросы законодательства. Следовательно, у пользователя системы неизбежно будут возникать вопросы, связанные с созданием и деятельностью различных организационно-правовых форм, бухгалтерским учетом объектов интеллектуальной собственности и т.д. Поэтому раздел составлен так, чтобы пользователь получил ответы на все эти вопросы. Система "ПраЗИС" поддерживает следующие основные функции:
Таким образом, использование разработанной системы "ПраЗИС" позволит решить задачу создания единой информационной базы по разработкам высшей школы, основанным на объектах интеллектуальной собственности. Имеющийся задел в области полнотекстовых баз данных, сложной обработки информации и созданный в настоящее время сетевой вариант экспертной системы позволяют сделать вывод о том, что задачи создания Банка интеллектуальной собственности и Фонда интеллектуальной собственности высшей школы могут быть успешно решены в рамках дальнейшего развития системы. Ниже изложены некоторые результаты исследования и разработки подсистем "ПраЗИС", отразившие опыт членов авторского коллектива. Принципы построения экспертной части Документальной информационной СистемыДокументы, хранящиеся в системе, представляют собой сложные информационные объекты, ориентироваться в которых пользователю весьма непросто. Существенную помощь в этом должна оказать экспертная часть системы. На экспертную часть (подсистему) возлагаются две основные задачи:
Как известно, экспертные системы (ЭС) - это системы, основанные на компьютерном представлении знаний. К настоящему времени технология ЭС прошла уже немалый путь развития. Созданы и успешно используются ЭС первого поколения; на основе осмысления присущих им недостатков и ограничений сформированы представления об ЭС второго поколения, которые начали появляться в последние годы [6]. Классическая ЭС состоит из двух основных компонентов: базы знаний и механизма ("машины") логического вывода. Важнейшим вопросом проектирования экспертной подсистемы является выбор способа представления знаний и структур их хранения в компьютерной памяти. От этого в значительной степени зависят возможности системы в целом. В ЭС первого поколения выработаны три основные модели представления знаний: продукции, семантические сети, фреймы. Каждая из них имеет свои ограничения, что обусловило появление гибридных моделей в системах второго поколения. В результате анализа особенностей предметной области Документальной Информационной Системы, содержащей нормативные и правовые документы, была выбрана модель представления знаний в экспертной подсистеме. Эта модель представляет собой синтез семантической сети и прологоподобных средств логического вывода. Кроме того, в модели нашли отражение идеи объектно-ориентированного программирования. Основой модели представления знаний в экспертной подсистеме служит понятие абстрактного объекта, или класса. Класс - это описание совокупности элементов данных, объединенных под общим именем. Элементы данных, называемые "свойствами" класса, в свою очередь характеризуются именами, типами и значениями. В вырожденном случае класс может вовсе не иметь свойств, а описываться только именем. Если множества свойств нескольких классов вложены друг в друга, то можно говорить об иерархии классов. В этом случае между классами устанавливается отношение наследования: базовый класс - производный класс. Объект, или экземпляр (представитель) класса, - это совокупность элементов данных с заданными значениями; объект можно уподобить записи базы данных соответствующей структуры. В частном случае некоторые свойства отдельного объекта могут быть не заданы. На множестве объектов, представителей своих классов, могут быть заданы отношения трех видов: факты, правила, следствия. Факт - это отношение между экземплярами классов, которое представляет сведения об объектах, заданные извне, своего рода исходные данные для системы, или первичные знания. Правило - это отношение между классами или внутри класса, которое распространяется на все объекты. На основании фактов и правил с помощью механизма вывода системой могут быть получены выводимые знания. Следствие - это разновидность правила, с помощью которого системой устанавливаются "вторичные факты"; следствия используются для проверки непротиворечивости знаний. Итак, в терминах введенной модели знания о предметной области представляются в виде совокупности объектов с набором свойств, определяемых классом каждого объекта, и совокупности отношений между отдельными объектами и целыми классами. Для описания классов, объектов и отношений разработан специальный язык описания знаний, который вобрал в себя черты языка Пролог в части описания отношений и языка Си++ в части описания классов и объектов. Не приводя полного формального определения языка описания знаний, рассмотрим некоторые примеры, дающие представление о нем. Класс "Человек" мог бы иметь следующее описание.
/* Пример 1 (Это комментарий)
Описание класса "Человек"
*/ class Человек {
string Фамилия;
character Пол = 'М', 'Ж';
date Дата_рождения = 01.01.01 : 31.12.99;
integer Рост = 50 : 250;
integer Вес = 2 : 300;
}
Пояснения: class - ключевое слово языка, с которого начинается описание класса; Возможные типы свойств: integer - целое число // Пример 2 (Это тоже комментарий) // // Определение объектов класса "Человек" Человек Иван_Иванович (Фамилия = "Иванов", Пол = 'М'); Человек Марья_Петровна (Фамилия = "Петрова", Пол = 'Ж'); Пояснения: Иван_Иванович, Марья_Петровна - имена объектов класса Человек, далее в круглых скобках указан список значений свойств; Последние две строки примера 2 можно рассматривать как конструкторы объектов Иван_Иванович и Марья_Петровна.
/* Пример 3
Описание класса "Сотрудник" и определение объектов
*/
class Сотрудник : Человек {
string Подразделение;
string Должность;
date Дата_поступления;
integer Зарплата;
}
Сотрудник Сотрудник_Иванов (
Подразделение = "бухгалтерия",
Должность = "главный бухгалтер") : Иван_Иванович;
Сотрудник Сотрудник_Петрова (
Подразделение = "бухгалтерия",
Должность = "кассир") : Марья_Петровна;
Пояснения: Класс Сотрудник определяется как производный от класса Человек;класс Сотрудник включает все свойства класса Человек плюс те свойства, что определены в его теле; объект Сотрудник_Иванов определен как производный от объекта Иван_Иванович, а Сотрудник_Петрова как производный от объекта Марья_Петровна. Отношения описываются в стиле Пролога в виде функтора и аргументов. Функтор - это имя отношения, после которого в скобках указывается список аргументов. Отношение характеризуется арностью (числом аргументов), а также последовательностью и классом аргументов. По числу аргументов отношения могут быть унарными, бинарными, тернарными и т.д. В зависимости от вида отношения его аргументами могут быть имена классов или объектов. Ниже даны примеры описания отношений.
/* Пример 4
Описание различных видов отношений
*/
// Унарные отношения - правила:
Мужчина (Человек X) <- X.Пол == 'М';
Женщина (Человек X) <- X.Пол == 'Ж';
// Бинарные отношения:
Состоят_в_браке (Y, X); /* правило, утверждающее
симметрию аргументов */
Состоят_в_браке (Иван_Иванович, Марья_Петровна); // факт
Пояснения: Унарное отношение Мужчина (Человек X) представляет собой правило, которое гласит: "Отношению Мужчина удовлетворяет любой объект класса Человек, у которого значение свойства Пол равно "М". На русский язык это можно перевести как "Человек мужского пола является мужчиной". На основании этого правила механизм логического вывода, например, установит, что Иван_Иванович - мужчина. На основании знаний, представленных отношением Состоят_в_браке, механизм логического вывода установит выводимый факт Состоят_в_браке (Марья_Петровна, Иван_Иванович). Совокупность описаний классов, объектов и отношений образует "программу" на языке описания знаний, которая представляет собой не что иное как исходную форму записи знаний экспертной подсистемы. Исходная форма, или внешнее представление знаний появляется как результат кропотливой работы эксперта и инженера знаний. Совместными усилиями они препарируют предметную область, формируя систему понятий и перекладывая их на язык классов, объектов и отношений. Выполнение этой работы конечно же требует соответствующей технологии и инструментальной поддержки, разработка которых должна рассматриваться как самостоятельный этап создания Документальной Информационной Системы. Полученное так или иначе внешнее представление знаний в виде программы на языке описания знаний обрабатывается специальным компилятором, который помимо формального контроля программы проверяет и непротиворечивость всей совокупности фактов, правил и следствий. Выявление и устранение ошибок всех видов составляют содержание этапа отладки. Результатом работы компилятора является формирование внутреннего представления знаний: соответствующих структур данных в компьютерной памяти. Можно считать, что компилятор выполняет загрузку базы знаний и отображает внешнее представление знаний на внутренние структуры данных. Реализация компилятора требует подходящих средств для размещения внутреннего представления знаний в компьютерной памяти. При выборе этих средств нужно исходить из тех особенностей, которые присущи структурам данных внутреннего представления знаний. Главная из них - это большая неоднородность данных, отсутствие даже намека на регулярную структуру вроде записей реляционной базы данных. Наиболее подходящими структурами данных для хранения знаний могут быть деревья и списки, размещаемые в динамической памяти, так называемой "куче". Из этого следует, что для реализации нижнего уровня базы знаний не слишком подходят такие системы общего применения как dBase, FoxBase, Paradox и т.п. Поэтому были выполнены работы по созданию инструментальной системы конечного пользователя базы данных. Среда разработки систем обработки документов MultiBaseТерминология Система обработки документов (СОД) - информационно-поисковая система для работы с информацией, представленной в виде различных документов, анкет, таблиц, меню, диаграмм и т.п. Что такое MultiBase ? MultiBase представляет собой платформу вида "клиент\сервер",предназначенную для разработки прикладных программ (приложений), относящихся к классу СОД. Эти приложения позволяют повысить производительность труда коллективов пользователей за счет использования новой информационной технологии. Они могут автоматизировать основные потоки документооборота, обрабатывать сложные документы с разнородным содержанием, позволить работать над одним документом нескольким пользователям одновременно, распределять информацию по нескольким узлам локальной сети. Кроме того, эти приложения могут существенно помочь в реорганизации трудового процесса. MultiBase разрешает пользователям совместно использовать информацию, предназначенную для документов. Эта информация может поступать в различных форматах: текст, изображение, звук; соответственно документы могут иметь текстовые, графические и звуковые поля. Состав системы MultiBase состоит из комплекса "Сервер MultiBase" и набора динамических библиотек - Dinamic Linkage Library (DLL) для создания приложений пользователя. "Сервер MultiBase" содержит в себе собственно СУБД и управляет доступом ко всем созданным базам данных. Архитектура системы MultiBase изначально разрабатывалась как сетевая. На настоящий момент времени MultiBase функционирует в одноранговой сетевой среде Windous for Workgroups 3.1 и выше. Протокол обмена данными - Dinamic Data Exchange (DDE); механизм обмена - "клиент\сервер" [7]. На каждом узле сети может располагаться несколько баз данных. Если узел сети содержит базы данных, то на нем должен быть инсталлирован "Сервер MultiBase" . Последний занимается обеспечением доступа к базам данных, расположенным на этом узле сети . Запуск "Сервера MultiBase" происходит автоматически при первом обращении от какого-нибудь приложения к какой-нибудь базе данных на этом узле. Таким образом приложения пользователей являются клиентами, а "Сервер MultiBase" - сервером. На каждом узле сети может быть одновременно запущен и "Сервер MultiBase" и приложение-клиент, причем "Сервер MultiBase" может быть только один, а приложений-клиентов несколько. База данных системы MultiBase База данных в системе MultiBase представляет собой средство хранения документов, при помощи которого пользователи могут добавлять, изменять и искать требуемую информацию в своих документах. Каждая база данных может хранить документы различных форматов. Документы MultiBase Документы, которые обрабатываются в приложениях MultiBase, могут иметь любую сложную структуру: их полями могут быть тексты, изображения, звук, таблицы, другие базы данных и т.д. В рамках одной базы данных MultiBase между документами можно задавать связи наследования, создавая таким образом некоторую иерархию документов. Предоставляемые возможности Приложения MultiBase предоставляют пользователю ряд совершенно новых возможностей:
Место MultiBase в системе классификации СУБД MultiBase предназначена для работы с неструктурированной информацией и не является реляционной базой данных по определению. В любой реляционной БД информация структурирована в виде таблиц фиксированной формы, с помощью которых выполняется координированный доступ, хранение и поиск данных. Поскольку информация в этих таблицах жестко фиксирована, то связи между двумя или несколькими таблицами, необходимые для выполнения этих функций, зафиксированы и четко определены. С этой точки зрения разработанная СУБД является объектной СУБД. Приложения MultiBase по своему назначению должны быть гибкими, чтобы поддерживать обработку разнообразных текстовых данных, которые по своей сути должны быть не структурированы, представлены в различных форматах и доступны с нескольких рабочих мест одновременно. С научной точки зрения очень привлекательной особенностью MultiBase является поддержка документов с разнородным содержанием (в иностранной специальной литературе употребляют термин Compound Document). Здесь MultiBase выгодно отличается от существующих СУБД типа dBase ,Paradox, Clipper, Foxbase и им подобным, которые имеют жестко фиксированный набор полей, из которых можно строить документ. Сама БД имеет в этих системах жестко фиксированную структуру, изменение которой сопряжено с очень большими затратами (требуется реорганизация записей БД). БД MultiBase вообще не имеет структуры и работает с документами, ничего не зная о их структуре. Она является просто " хранилищем документов ". Структуру имеет конкретный документ, который может содержать поля с графическими изображениями, большими текстами, звуковыми мелодиями, таблицами и т.д. Существует уже реализованный набор типов полей, но вся суть в том, что можно создавать новые типы объектов, которые могут входить в состав документов и, соответственно, храниться в БД MultiBase. Такими возможностями обладают, из всех известных на сегодняшний день СУБД, только современные объектные СУБД, такие как, например, Jasmine, фирмы Computer Associates International, Inc. [8], которые лишь недавно были анонсированы на западе и практически не представлены на российском рынке. Однако, их появление на рынке и большой интерес к ним со стороны специалистов позволяет считать выбранное направление развития технологии СУБД очень перспективным. Исходя из вышесказанного, наиболее интересными с научной точки зрения, будут применения MultiBase в системах multimedia и в качестве систем управления базами данных и знаний в экспертных системах. Для систем multimedia существенно важным является возможность в одной базе хранить как текстовую, так и графическую, звуковую, табличную информацию. Для СУБД экспертной системы важна возможность хранить в одной БД знания, представляемые рядом различных документов. В большинстве случаев информация, обрабатываемая экспертной системой, является неформализованной и для ее учета в БД очень помогут документы переменного формата. В существующих экспертных системах отдельно ведутся словари понятий, списки правил и базы знаний. При использовании БД MultiBase всю эту информацию можно держать в одном месте, что снижает затраты на реализацию экспертной системы и уменьшает время при ее реорганизациях. СПИСОК ЛИТЕРАТУРЫ
|
