Проект ACIS: содержание, old manual.

Автоматическая поддержка Contributions профайла (APS), непринятый вариант

Я написал этот документ примерно год назад, весной/летом 2003-го, однако так и не реализовал то, что в нём написано.  Сейчас, когда я подошёл вплотную к этому вопросу, я решил идти другим путём.

Назовём систему мониторинга, уведомления пользователя и автоматического-обновления Academic Contributions профайла — APS, сокращение от "Academic Profile Support" или от "Automatic Profile Support".

Система APS будет состоять из двух частей.  Первая часть будет модулем, обрабатывающим все новые (и не только) поступления в базу данных о документах.  Этот модуль будет писать потенциальные связи авторства/etc. в relations-таблицу.  Вторая часть будет отрабатывать накопленные «наводки».

Что мы имеем?

Для каждой записи о человеке в ACIS мы имеем:

• полное имя,
• список дополнительных вариантов имён,
• список пар [идентификатор, роль] — по паре для каждого из объектов, к которым человек имеет отношение,
• список идентификаторов документов, к которым человек точно не имеет отношения.

Обрабатывая user-data файл и записи внутри него, мы извлекаем (с помощью ARDB) следующую информацию:

• отношения affiliated-with,
• отношения not-related-to,
• отношения author-of, editor-of, participant-of, contributor-to, … (?)
• Полное имя и варианты имён (name-variations) объединяются в один набор (set). (Набор — это список, в котором не может быть двух одинаковых элементов.  То есть из списка удаляются все дубликаты, если они там есть.) Выполняем операцию replace на таблице names, с двумя полями (и значениями): person handle и список имён как единая строка, где элементы разделяются символом "\n".

Смотри Обработка user-data файлов.

В таблицу relations мы будем писать ещё один тип отношений о человеке: may-be-related.  Эти отношения будут заноситься в таблицу системой полуавтоматического обновления, «сыщиком».  Субъект отношения — человек.

«Сыщик»

Что делает сыщик? Он обрабатывает все входящие данные и ищет там персональную информацию.  Напоминаю, что плагины ARDB получают входящие данные в виде записей ARDB, со своим интерфейсом.

Если сыщик находит в записи упоминание человека, то пытается проверить, нет ли такого человека среди людей, известных ACIS.

Для этого, в частности, он использует таблицу acis.names, в которой есть поля names и handle.  В поле names сыщик ищет совпадения с искомым именем.  Если такое совпадение есть и оно одно, то владелец этого имени становится "конкретным подозреваемым".  Если таких совпадений несколько, то их владельцы становятся "просто подозреваемыми".

Ed.Note: Я так подозреваю, что select handle from acis.names where names regexp "(^|\n)bla bla name from the document(\n|$)" должно сработать, при соответствующем заполнении таблицы acis.names.

Ed.Note: В перспективе возможно, что мы еще и по email-адресам будем пытаться установить гражданина… Аналогичным образом.

Иногда в описании документа может стоять явная ссылка на конкретного автора — его идентификатор (handle).  В этом случае надо проверить, соответствует ли этот идентификатор записи о человеке, и если соответствует, то искать в таблице acis.names не надо.  А надо назначить этого человека «конкретным подозреваемым».

В случае с документами, люди чаще упоминаются как авторы, но могут упоминаться и редакторы (а в будущем — и ещё хрен знает кто…).  Для одного документа может быть несколько подозреваемых, и у каждого из них может быть своя роль: кто-то подозреваемый автор, а кто-то подозреваемый редактор. (Роль важно запомнить.)

Далее, мы проверяем таблицу relations на предмет такой записи:

Такое отношение означало бы, что мы уже спрашивали у человека про этот документ, и он сказал: нет, это не я!.  Значит, если такое отношение есть, то мы выкидываем такого человека из числа подозреваемых. (Хотя вообще-то, мы могли бы на всякий случай запомнить, но сейчас нам не об этом думать.)

Далее, для всех оставшихся подозреваемых мы пишем в таблицу relations отношения типа may-be-author-of, may-be-editor-of, … и так далее.  Если роль нам не известна, то пишем отношение may-be-related-to.

Ed.Note: Должна быть разница между отношениями для «конкретных подозреваемых» и отношениями «просто подозреваемых»… XXX

Получается, что «сыщик» должен будет знать о структуре записей разных типов и о том, какие отношения откуда вытекают.  Вообще, это очень ответственная часть ACIS и в будущем она будет развиваться, то есть — усложняться.  Так что тут есть большое поле для дальнейшей абстракции… …и развития гибкости ARDB.  Ведь именно для таких задач ARDB и предназначен.  Чем больше удасться сделать стандартными средствами ARDB, тем легче будет поддерживать и развивать этот участок.  А пока мне страшно подумать, как мы будем отлаживать изменения в этих алгоритмах…

Довольно лирики.  Вернёмся к ACIS.  Когда человек входит в систему или когда он входит в свой contributions-profile, ACIS будет проверять таблицу relations и будет показывать объекты may-be-related и предлагать человеку определить свою связь с этими объектами.  Причём эти объекты должны быть отсортированы по значимости этих отношений.  Например, отношение may-be-related — неконкретное и самое мало-значимое. Объекты с этим отношением должны идти в конце списка.

Ed.Note: Так когда же всё-таки?: когда входит в систему (в редактирование записи) или когда входит в contributions-profile?

«Репортер»

Периодически запускаемая, вторая программа-часть APS будет проходить по всему списку персональных записей ACIS и делать следующее для каждой персональной записи:

1. загружать запись из user-data (если нету lock файла),
2. загружать пользовательскую запись APS, если такая существует,
3. искать отношения по маске may-be-*, в таблице relations, где субъектом является человек, описываемый записью. Запомнить отношения и идентификаторы документов, на которые эти отношения ссылаются.
4. если таких отношений нет, выходим из обработки текущей записи (т.е. переходим к следующему человеку),
5. подготовить краткую информацию об этих документах,
6. смотреть на параметр "automatic update of the contributions profile":
   • если параметр стоит в значении auto (и этот человек был «конкретным подозреваемым»), то:
     1. снова проверить lock на user-data файле, если он отсутствует, создать
     2. записать в user-data соответствующие идентификаторы,
     3. удалить lock,
     4. отправить запрос контрольному демону RePEc-Index на обработку user-data,
     5. удалить отработанные may-be-… отношения,
   • если параметр стоит в значении semi (или если человек был «просто подозреваемым»), то:
     • проверить, не повторяемся ли мы, если предлагаем пользователю эти отношения.  Смотрим в APS профайл.
     • запомнить свеженайденные отношения в APS профайле, чтобы потом не рапортовать их снова…
7. отправить пользователю уведомительный email с:
   • описанием сделанных добавлений, (если они были)
   • приглашаением зайти в систему и проверить «подозрительные» документы (если такие остались), с их перечислением.

Порядок всех этих действий важен и должен быть точно соблюдён.

(Надо, однако, признать, что использование lock-файлов здесь не гарантирует безопасность и сохранность системы.  Сложно защититься от ситуации, когда система начнёт что-то менять в user-data, а пользователь в это же время зайдёт в систему через Web и будет что-то менять.)

Проблемы

• Можно прогнозировать, что со временем возникнет необходимость усложнять алгоритм отработки «наводок», потому что простой опции auto/semi/off будет недостаточно.  Люди могут захотеть более тонко управлять своим APS-«агентом».  Возможно, они захотят указывать дополнительные условия, при которых профайл будет автоматически пополняться.  Но это не сейчас.

* * *

Путь абстракции: диалог с пользователем

Возникает вопрос об универсальности подхода.  Хорошо было бы, если бы ACIS могла в неизменной, простой манере иметь дело с объектами любого типа, даже если она с ними не знакома.  Мы можем ввести три совершенно универсальных свойства объекта: имя или название, идентификатор, URL.  Этого, в общем, достаточно для простейшего представления объекта на веб-странице.  Этого не достаточно для ведения диалога с пользователем об объекте.  Нужен ещё тип (или, если угодно, класс) объекта.  Класс объекта позволит вывести возможные отношения между ним и человеком, человеком и ним.  Например, если объект имеет тип «проект», то круг возможных отношений включает: «основатель», «участник», «автор идеи».  Если объект — «человек», то возможны отношения: «друг», «со-автор», … Кажется, определить такие вещи значит определить таксономию.  Не посмотреть ли мне чуточку более подробно на DAML, XTM?

В работе ACIS с affiliations и с academic contributions есть общее: мы позволяем пользователю заявлять о его связях или отношениях с другими объектами: организациями или документами.  В дальнейшем нам придётся работать в том-же направлении — например, позволять людям сообщать о цитатах между документами.  Или сообщать о связях между человеком и другим человеком.  Имело бы большой смысл каким-то образом абстрагировать алгоритмы, но мне кажется ясным, что полностью абстрагировать это невозможно: конкретный экран (и алгоритм, стоящий за ним) должен быть разработан специально для каждого типа объектов и, возможно, класса отношений.

И всё-таки, если попробовать?

В ARDB мы уже имеем некоторую простую таксономию (taxonomy): мы идентифицируем и описываем отношения. Отношение related является взаимным и ненаправленым. (<relation-type name="related" undirected="yes" />) Мы могли бы ещё описывать:

• типы объектов и то, какие отношения возможны между объектами описанных типов,
• более подробно взаимоотношения отношений: разновидности (отношение author-of это разновидность отношения related), взаимное исключение (отношение author-of не совместимо с отношением unrelated-ro).
• …

Какие главные моменты у нас в работе с объектами?

• Задаём вопрос;
• Обрабатываем ответ, сохраняем в user-data;
• Обрабатываем user-data, извлекаем отношения;
• Задаём новый вопрос…

Вопрос состоит из формулировки на человеческом языке, краткого описания объекта (и ссылки на его подробное описание), и списка возможных ответов.

Причем, формулировка на человеческом языке может повторяться в большом количестве вопросов, поэтому она, скорее всего, будет показываться один раз.  За формулировкой будут следовать описания объектов с сылками и вариантами ответа.  После всего этого — кнопка [save] или аналогичная.

Каждому варианту ответа соответствует какое-то действие, которым ACIS должно зафиксировать ответ человека (в отношении этого объекта).  Для общей, универсальной обработки этих взаимодействий нужно, чтобы все объекты имели идентификаторы.

Конкретный вопрос можно определить через:

• тип вопроса (идентификатор),
• субъект (для некоторых вопросов, не для всех),
• списка объектов.

Тип вопроса описывается:

• уникальным идентификатором,
• человеко-читаемой формулировкой (предположительно, в xhtml),
• параметр: варианты ответа взаимо-исключительны или нет,
• список вариантов ответа на вопрос.  Для каждого варианта —
  • имя
  • человеческое описание
  • действие
  Действие, в нашем случае, это указатель: где сохранить идентификатор объекта (где внутри user-data) и имя ответа.  Хотя иногда надо сохранять и идентификатор субъекта…

Ed.Note: Я так подозреваю, что подробный пример здесь не помешал бы…

Нет, господа, об этом мы подумаем в будущем.  А пока попробуем решить задачу подручными средствами… (А может зря я так?)