Аттрибуты контента

Вот еще одно словоблудие затерялось на просторах моей фантазии (хранил в MyBase Desktop и никому не показывал). Читаем.

1. Аттрибуты:
Attribute: существенный признак, свойство, характеристика чего-либо. Делят на смысловые ценности (назначение, для чего, зачем нужен) и материальные свойства (технические, физические параметры контента). Эти 2 важных типа аттрибутов накладывают определенные условия на построение собственной БД...
Аттрибуты контента можно выловить, например, из его описания.
Управлять контентом можно только сформировав его БД. Это можно сделать с помощью СУБД. Поскольку контент распространяется через веб (electronic) и физические носители (media), необходима нативная онлайн-интеграция СУБД с утилитами исследования, загрузки и файловыми сервисами (Web-Browsers, Offline Browsers, Download Managers, File Sharing, P2P, FTP, Web Search), а также с файловыми и медиа менеджерами (File Managers, About Release, Rippers, Virtual Drives, Screen Capturing and Burning Managers), позволяющая в рамках единой многофункциональной оболочки осуществлять полное управление контентом, независимо от его рода и формата представления. (Думаю, что не последнюю роль здесь играет возможность создания SQL-запросов к БД и поддержка командной строки со стороны соответствующих утилит.) Поскольку (если) требуется, чтобы сама БД была доступна как можно большему числу пользователей, сюда следует приплести и концепцию создания Web-сайта, т.е. такую СУБД можно называть CMS (Content Management System).

2. Формирование записи:
Коротко, что такое запись в БД контента? Это - разложенное по полочкам (аттрибутам) описание контента (позволяет делать то-то, весит столько-то, и пр.), т.е. структура самого описания. Одним из аттрибутов записи является само описание контента (description, текст - может быть RTF, HTML-файл).
Другими важными аттрибутами могут быть:

• формат представления контента: архив; инсталлятор; образ; носитель и т.д.
• общие сведения: размер дистрибутива; список файлов; число [архивных] частей, составляющих релиз; скриншот и др.
• для диска: метка диска; обложка диска (скан); кем и когда записан
• контент как продукт: разработчик; издатель; дата релиза; цена; редакция; версия; рейтинг; копирайт; тип лицензии и пр.
• и еще много чего.

[Тут же отмечу, что некоторые разновидности контента содержат аттрибуты, о которых можно узнать лишь, используя специальные утилиты, например, для воспроизведения файлов (Multimedia), а также внутри самой программы, в разделе About (Software) или на веб-сайте разработчиков (например, Description) и др.]
Заметьте, все аттрибуты "материально-технического" происхождения (компания, дата релиза, распространение, описание+примечания+расположение - как составляющие документа, и собственно сам контент) чаще структурируют из описания в запись. Взять хотя бы любой софтовый сайт (неважно в зоне какой юридической компетенции он находится) - везде: Дата, Название, Описание, Размер, Ссылки. И гемор будет, если вы не выудите эти аттрибуты из описания. Таким образом, данные аттрибуты являются своего рода низкоуровневыми, если хотите фундаментальными структурами по отношению к более высоким структурам.
Каким нахрен еще высоким структурам?
А вот каким. Вы никогда не слышали приблизительно похожую музыку (смотрели фильм, использовали ПО)? Когда по жизни появляются одинаковые вещи, их начинают объединять в группы (работников, например). Или вот раньше о Progressive Rock никто слыхом не слыхивал, а сейчас, гхм, ну в общем вы меня поняли. Мы ведь оставили в описании еще какие-то аттрибуты?
Чтобы раскладывать контент по группам (группировать записи), нужна голова на плечах, структура сложившихся ценностей, так сказать, и много еще чего уметь надо, ИМХО (И не важно, с чем конкретно вы работаете - с БД велосипедов на складе или БД вареза:) Я бы назвал их аттрибутами назначения или смысловыми аттрибутами, т.е. какую роль они играют для конкретного человьека.
Вот возьмем любой компилятор, пусть GCC. Это что? - software. Не понял? - System (системное). А именно? - Tools (инструмент). И только среди Embedded, Installers, Assembers и прочих струментов мы возможно воткнем категорию Compilers. Почему возможно? Не всяк человек имеет светлую память и запросто может запутаться в категориях (или других структурах), так же как и в своих мыслях. И дело здесь не только в чей-то голове...
Поскольку каждый контент характеризуется индивидуальным набором аттрибутов (духовные аттрибуты, как правило, изменяются, ну а физические остаются :), его относят к нескольким структурам одновременно (т.н. рубрикация, на ее основе можно разложить контент по дереву категорий). Даже описание контента и его суть, в силу разных человеческих причин, разнятся. Чем выше степень иерархии контента, тем больше вероятность того, что он окажется в данной иерархической структуре. Чем больше контента имеет выдернутый из описаний одинаковый аттрибут назначения, тем выше уровень этого аттрибута.
Изначально всем категориям (рубрикам) присваивают одинаковый уровень. Затем человек сам выбирает расширенный поиск по категориям, и СУБД должна вывести список записей, удовлетворяющих заданному комплексному условию, например:
Рубрики: Linked Documents - Software - Freeware;
Результат: Выводит все документы со ссылками на бесплатные программы;
и пр.
Категории следует объединять в группы для удобного перемещения по ним. Чтобы избежать путаницы не стоит создавать одноименных категорий в разных группах.
Присваивая смысловым аттрибутам рейтинги в рамках единицы контента (по степени важности), можно приблизительно оценить его "вектор принадлежности".

3. Задача из области графов:
---------------------------------------
Philips (5) SAA7130 WDM (2) Video Capture (3)
Для работы Fly 2000 TV и других аналогичных программ необходим WDM-драйвер(1), обычно он входит в комплект поставки или загружается с сайта производителя тюнера (4). В качестве альтернативы можно воспользоваться драйверами, опубликованными на сайте программы Fly 2000 TV. Это универсальные WDM-драйверы для устройств на базе чипов Philips SAA7130/7133/7134/7135. В список поддерживаемых карт входят Asus, Compro, ECS, LifeView, manli, Terratec, Tevion, Typhoon. Если вашего тюнера нет в списке, обращайте внимание не на производителя, а на номер чипа, используемого в тюнере. Для карт на базе Philips SAA7130 выбирается вариант LifeView FlyVideo 2000, для карт на базе Philips SAA7134 - LifeView FlyVideo 3000.
Условия распространения: Freeware
Загрузка: http://auzol.narod.ru/files/drivers/saa7130.zip (Philips SAA7130)
http://auzol.narod.ru/files/drivers/saa713x.zip (Philips SAA7133-7135)
---------------------------------------
Кратко: драйвер (1) WDM типа (2) для видеозахвата (3), использующий TV-тюнер (4) на чипсетах Philips (5)
Ветвь иерархии: Drivers -> WDM -> Video Capture -> TV-Tuner -> Philips -> Philips SAA7130 WDM Video Capture
Кроме того, в этом описании представлено 2 единицы контента (Philips SAA7130 и Philips SAA7133-7135). А название получила только одна из них. Их следует описать раздельно.
Чем обширнее описание контента, тем больше человек может подметить особенностей. Поначалу главное - не зацикливаться на мелочах. Как только на одном из уровней скопится достаточное количество записей, можно задумываться о структуризации контента. И еще не надо забывать, что путь сверху вниз - самый легкий.
---------------------------------------
Тогда почему на любом сайте эти "низкоуровневые структуры" являются структурами самого высокого уровня? Вот примеры главного меню сформировавшихся сайтов:
Сайт: http://r-i-p.info
- Главная
- Новости
- Софт
- Фильмы
- Игры
- Русификаторы
...
---------------------
Сайт: http://www.3dnews.ru/
Титул 3DNews
Новости:
- Hardware News
- Software News
Обзоры:
- Аналитика
- Процессоры и память
- Материнские платы
- Корпуса и охлаждение
- Видеокарты
--------------------------
Можно приметить некоторые особенности. Вот сайт http://www.wjjsoft.com/:

Назв. тек. страницы | Home | Downloads | Support | Order | Contact | Sitemap |
------------------------------------------------------------------------------
Левая колонка:
Основное меню (записи БД 1-2 уровня)
Тело материала: 
Оригинальный Java, HTML контент, таблицы, картинки, текущее описание контента
Правая колонка: 
Ссылки, Содержание тек. страницы.
------------------------------------------------------------------------------
строка копирайта
------------------------------------------------------------------------------

Тогда в CMS должна иметься панель присвоения (назначения) аттрибутов описанию контента (записи в БД). Узлы же БД (более высокие структуры, ветви записей) должны быть сформированы потом, основываясь на самих записях.

[Этому должна способствовать (или должна быть сформирована) система сопоставления нечетких фраз из описания с четко определенными аттрибутами контента (однословные простые, например, конвертирует -> конвертирование или англ. - Conversion; многословные составные, например, позволяет ковертировать видео -> конвертирование). Таким образом, СУБД должна содержать некий лингвистический анализатор (parser), в т.ч. базирующийся на системах проверки орфографии, словарных БД и грамматики. И естественно, в формировании текстовых связей между фразами и аттрибутами, как и в в создании иерархии контента между аттрибутами и структурами следует использовать механизм нечеткого поиска текстовой информации (как, например, в интеллектуальной поисковой системе "Следопыт" компании МедиаЛингва. Она предназначена для "смыслового" поиска информации в русских и английских текстах по запросам на естественном языке). И не зависимо от языка (ну это я уж слишком загнул)...]

Путь (URL) локального местонахождения контента (как и путь загрузки) должен формироваться автоматически при составлении записи в БД. При изменении местонахождения URL также должен измениться, в том числе и при записи на внешний Media носитель, диск. (Когда скачиваешь - в базе должен сохраниться URL загрузки, а когда скачал - плюс URL инсталляции, запуска)

Тип принадлежности ПО (Package, System) и формат его лицензионного распространения можно косвенно определить по его назначению, размеру и количеству составляющих компонентов.

4. Навигация и просмотр:
Как должна отображаться БД в CMS для захвата и перенаправления контента в конкретный узел БД? Табличный метод будет наглядно отображать постепенно формирующуюся иерархию, заодно позволив значительно ускорить процесс навигации по БД (как, например, календарь ускоряет перемещение по дате). Таблица должна обладать "памятью" состояний открытых записей. Релизы, крэки, локализаторы, обновления, исходники и другие типы одноименного контента должны быть описаны и прогруппированы отдельно и уже затем совмещены в единой БД, например, как ссылки по теме. Все это касается навигации и отображения для пользователя.
При поиске контента по базе, удовлетворяющего определенным требованиям (аттрибутам) найденный контент следует сортировать по его релевантности (т.е. в порядке убывания суммы набранных рейтингов аттрибутов?)

Не путай документы с ссылками на них, также как и другие виды контента с ссылками на них. Запись в БД Mybase - тоже контент (RTF, HTML, Image).

Для каждого релиза - отдельная запись в БД, неважно какой релиз - важно его появление. Если русификатор, плагин или крэк вышел отдельным релизом - пиши отдельную запись и не клади его в папку с другим релизом. Для каждого релиза - отдельная папка с уникальным названием, так как бывает, что в одном релизе идут несколько файлов (например, несколько частей одного архива, или незапакованный инсталляционный директорий с ROM-носителя, но можно обойтись и без директорий, если файлы правильно представлены в БД). Не следует изменять (переименовывать, распаковывать и т.д.) файлы релиза, чтобы при обновлении не перепутались. Можно хранить все в архивах и не создавать директориев, но также нужно помнить, что при создании оригинального, например, загрузочного диска инсталляционные файлы лучше распаковать. И как же это сделать автоматом? Может иметься и файл-образ с несколькими десятками единиц контента - как обращаться с ним? В общем здесь два пути - самостоятельно изменить релиз или уметь правильно настроить и использовать соответствующие утилиты (архиватор, загрузчик файлов-образов и еще...)
[Жаль, но я имею БД Mybase Desktop, ограниченную размером 2ГБ и не поддерживающую виртуальные папки в аттачментах. 1. Если я буду импортировать релизы в запись, пусть папки в архивах - хрен с ними, - то можно будет создать авторан диск в виде части БД с выбранным набором релизов (или HTML - если найдешь зарегенный TreeHTML, а то писать на диск файл большого размера - рисковое дело для массового производства, но для хранения можно:). 2. Если я буду использовать в БД ссылки на релизы - то при записи на болванку возникнут проблемы с вылавливанием нужных релизов, но размер БД - меньше, так что в этом случае лучше выбрать 2-ой вариант, т.к. "Although keeping database file size less than 100MB usually helps obtain better performance and make database more stably and reliably."]
Ничего похожее на это я, к сожалению, не видел... Отзовитесь хоть кто-нибудь! Чтоб и авторан автоматом создать можно было, и часть БД на внешний носитель записать и обратно.

Если программа ContentSaver умеет производить индексируеный поиск по БД, а также обладает свойствами многоуровневой категоризации (рубрикации), то почему бы при добавлении очередной записи не производить бы поиск слов заголовка записи или даже текста документа записи и автоматически присваивать категории (например, первые TOP 5-10 в рейтинге по количеству отдельно набранных аттрибутов в порядке убывания)? Потому что авторубрикация при сохранении на основе записей в существующей БД - это формула еще более быстрого серфинга, т.е. необходим лингвистический анализ текущего контента. Этот анализ должен производиться как можно раньше - во время передачи HTML кода в браузер, чтобы результаты поиска рубрик для текущей (создаваемой) записи выдавались быстрее.
Еще один камень в огород ContentSaver, MyBase. Не думаю, что проприетарный формат информационного архива - оптимальный вариант для хранения записей в БД, пусть даже с возможностью сжатия и прочими прибамбасами. Короче, типичный шароварный недостаток. Необходим открытый формат для самой БД, чтобы сильнее сгладить те неровности перехода от одной СУБД к другой. Таким образом, контент должен быть представлен в таком виде, в котором его размещают в интернет, то есть в его сборе, анализе, систематизации и доступе информации должны быть использованы те же технологии - читай HTML, CSS, Java, PHP, ADODB и другие. Либо должна быть интернет лазейка в саму БД, если она закрытого типа.
Сергей, что вы думаете о системах управления контентом в интернет, (сайт cmsobzor.ru), какие из них вам наиболее известны и, самое главное, - какую роль эти системы играют в процессе DataMining? Может среди этих систем есть лучшее, чем то, что мы нашли - ContentSaver, MyBase? Я, к сожалению, не ас в клиент-серверных технологиях веб-программирования и потому не знаю, что за звери эти CMS. Так что даешь голубятню! :).
Программе DataMining-типа необходима функция кумулятивного наполнения записи контентом - HTML-текстом, картинками, ссылками, причем здесь желателен метод Drag'n'Drop, и как результат - из этих кусочков должна быть "склеена" запись (кусочки можно тусовать, должен быть предусмотрен многоуровневый буфер, быстрый просмотр и т.д.). Стиль HTML документа записи должен определяться отдельно таблицей CSS, чтобы не перегружать код, т.е. этот css-файл должен находиться в temporary files, иначе говоря, быть общим (common file) для всех записей.

Alphabetical - это категория, которая должна также составляться на основе записей, так же как и другие категории. Не привязывай название контента к записи (то бишь к самому контенту). Alphabetical = Name.
Не редактируй, не удаляй, не переименовывай файлы в релизе. Оставь его таким, каким он попал в твои руки.

Мы присвоили набор аттрибутов записи. При просмотре этой записи можно использовать макро шаблоны (на основе SQL запросов к БД?), например: Company %Company%; Name: %Name% и т.д. Такой шаблон отображается в отдельном окне БД.

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

25.11.2006 14:10:31
Итак, я думаю, что если документы являются одним из типов файлов, тогда наряду со множеством других типов (релиз -> отдельный файл) следует организовать БД в виде списка аттрибутов, присвоенных файлам. Основные файловые аттрибуты являются обязательными: имя, тип, размер, дата. Важным аттрибутом является также источник, с которого файл был получен.

23.01.2007 23:40:03
Мне необходимо упорядочить большое количество контекста. У меня много документов, журналов, заметок, советов, проблем по разным темам, программ различного назначения, ссылок, мультимедиа контента. Как не искать название, версию, автора? Как быстро сформировать многокритериальный поисковый запрос к постоянно наполняемой базе данных и получить ссылки на нужные файлы? Для СУБД (коей является CMS) и для нас важно, что любой, даже неэлектронный контент должен иметь свой электронный контекст, текстовое описание, нода. Этот контекст (данные) хранится в файлах, которые, как известно, бывают разного формата (бинарном и тектовом) и типа. Поэтому поисковые алгоритмы должны быть адекватны и поэтому не справляются со всеми типами. Как создать не просто категории контекста, а уровни категорий, не ограничиваемые ни сверху, ни снизу, с перекрестными связями, как ссылки бы, сделанные хорошим веб-программистом, определяли бы удобную навигацию по сайту? Как из перекрестных категорий и словарей сгенерировать локальную карту терминов (тоже многородовое дерево) под конкретный поисковый запрос, и экспортировать дерево найденных решений (новый сайт), ну, например, чтобы отправить другу, то, что бы ему пригодилось из того, что вы уже когда-то прочитали и вам это понравилось? Ну и напоследок, вопрос из области фантастики: как распознать и выудить аттрибуты контекста (те же названия чего-либо), то есть во время ввода текущего контекста произвести его лингвистический разбор (язык, морфология, грамматика) на основе имеющихся словарей и категорий и АВТОМАТИЧЕСКИ просвоить соответствующие категории текущей ноде, а результат присвоения легко редактировать (подсветка найденных текстовых фраз, имеющих отношение к категории, которая возможно была бы присвоена ноде, добавление, изменение, удаление категорий). Также вести словарь обозначенных (банально, выделяемых мышью) пользователем текстовых фраз, в том числе как синонимов, для каждой категории. Постоянное накопление ключевых текстовых фраз в словаре позволит усилить процесс автоматизации присвоения категорий ноде, выстроить категории следующего (высшего/низшего) уровня, установить взаимосвязи между категориями с помощью синонимов, в конечном итоге получить карту сайта, то есть той темы, что вам/нам нравится. А вопрос поиска в любом случае не должен оставаться открытым: это результат применения комплексного фильтра к БД. Еще раз повторюсь, получение электронного контекста из контента и занесение его в базу данных - важная вещь, и, несомненно, Google здесь впереди, но также необходимо стремиться разрабатывать свои или использовать открытые технологии поиска и индексации данных в закрытых проприетарных форматах. Ну а для нецифрового контента без техники не обойтись, сто пудов.