1

Тема: мысли

Всем здравствуйте.

Хочу озвучить свою задумку проект и услышать критические комментарии.


смысл: создать удобный интерфейс для быстрого доступа к поступающей в процессе жизни человека информации


описание:
1)  используется многомерная система координат
   оси ( в скобках буду приводить соответствие декартовым)
   время ( X ), масштабность события / социальная общность ( Y ), чувства / разум ( Z )
2) используется связность объектов на уровне предопределенных онтологий и отношений
3) система динамическая
4) объекты создаются как пользователем так и внешними источниками ( например агрегаторы  новостных сайтов создают объекты новостей с учетом индекса доверия пользователя к этим сайтам)
4) объекты могут быть "расшарены" с другими участниками-пользователями подобного интерфейса ( зависит от "масштабности" объекта
5) для удобной навигации используется цвет объектов. ( к сожалению 3D демонстрация пока не готова в приемлемом виде  smile выглядит как планетарная модель с фиксированной точкой взгляда )

поясняющие картинки по ссылке http://blindguns.tumblr.com/
на картинке overview есть более развернутое описание

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

Thumbs up Thumbs down

Re: мысли

картинки красивые:)
ось X это неплохо, насчет осей  Y  Z  я бы посомневался. В принципе можно предоставить выбирать пользователю по какой оси что проецируется.

вы еще

и интерфейс это хорошо, а в чем обьекты вы будете хранить? имхо всего три варианта: mysql rdf view, virtuoso, sesame.
rdf view на основе mysql ограничит возможности,
если хранить триплеты прямо в mysql, то даже при среднем обьеме базы запросы будут выполняться очень долго.

не могли бы вы поподробнее описать предполагаемую логику работы. И собственно что это будет? приложение под windows?

Thumbs up +1 Thumbs down

3

Re: мысли

Евгений, во-первых спасибо
думал сразу скажут бред и закроют smile

теперь по существу.
на сегодня уже есть примерные наработки движков вот например продукт VUE
обратите внимание на раздел "Semantic Mapping Tools"
подумываю о прологе , но визуализировать на нем что либо самоубийство
можно разбить задачу на 2 части:
1) быстрая и легкая визуализация ( с увеличением времени обработки запросов по мере углубления в "объекты" и характер работы с ними)
2) собственно качество обработки семантических связей.
в качестве примера лёгкого интерфейса посмотрите на  bubbl.us

про оси согласен. жесткое навязывание отпугнёт.  с другой стороны отдавать заполнение основных "справочников" на откуп пользователям... мы получим "spore" во всем великолепии и нелепости.

ниже жосткое видео с ютуба smile начало smile 10 секунд превратили в 3 и качество уничтожили просто совсем
как то так

Thumbs up Thumbs down

4

Re: мысли

Наличие некой упорядоченности в виде осей --- почти единственное, чего не хватает продуктам от http://www.thebrain.com/ . Тут вы правы совершенно.

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

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

Вот как-то так.

5

Re: мысли

Иван, спасибо что присоединились.
смысл подобного представления как раз и состоит в частичной разгрузке от прорисовки связей графов
опишу логику работы с точки зрения пользователя:

на первом уровне мы видим только разнесенные объекты и ориентируясь на их размер и положение в пространстве определяем важность для себя.

при выборе объекта мы попадаем " как бы " внутрь где обычная плоская форма,  на которой шапка объекта с пользовательскими данными + смысловое содержание + панель взаимосвязей ( здесь хранятся  связующие теги и обеспечивается возможность перехода по ним ) + "подвал числовых итогов" где вы видите характеристики "проекций" объектов в системе и прочую статическую информацию например о "глобальном" уровне интереса к этой информации

объекты-вехи на осях это  внутренние агрегаторы  по своим зонам ( пример как раз картинка "планета") там собирается в табличный вид всё что есть с тегом планета .

объект "важно" - агрегатор по времени и значимости для пользователя ... что то вроде современных dashboard.

таким образом взаимосвязи пользователь видит только при переходах из объекта
да и то видит он только " красивую картинку" чтобы не испугаться ...
...
для тех "кто понимает" можно и альтернативный режим классических графов ввести ( тот же VUE ) smile

Thumbs up Thumbs down

6

Re: мысли

Доброе время суток,

если позволите, у меня есть два вида комментариев smile - по визуализации и по семантике.

Визуализация 1. Допустим, всё оставлять, так как есть, т.е. идея семантически-помеченных осей, планетарная модель, детализация вершин при необходимости.
(название теории я не знаю) если учесть, что движения глаз человека в разных ситуациях примерно стандартны (когда вспоминаем что-то, то смотрим влево вверх, когда придумываем что-то, то смотрим вправо вверх, и.т.п.), то направления соответствующих осей могли бы отражать эти движения, чтобы не искать глазами по экрану в поисках нужной ветки.
Например, календарные и прочие планы на будущее - вправо вверх, сделанные работы - соответственно влево вниз, и т.д.

Визуализация 2. 
картинка с "тумблера" (планетарная модель, та, которая без детализации) проявила ассоциацию:
Node-Link and Containment Methods in Ontology Visualization, Dmitrieva J., Verbeek F.J., http://www.liacs.nl/~jdmitrie/ontVis/No … nt1.5.jnlp. Онтология там являлась субъектом изучения и визуализации, так вот, там предлагается тип визуализации "semantical zoom" - красиво, хочется посмотреть, покрутить, а там - и погрузиться в детали. Т.е. осей нет вовсе, есть смысловые "материки" - корни соответствующих онтологий, размеры территорий - соответствуют объему понятия, а вложенность территорий - иерархии, т.е. Эверестом будет самое детальное понятие раздела.


Семантика 1.

blind пишет:

про оси согласен. жесткое навязывание отпугнёт.  с другой стороны отдавать заполнение основных "справочников" на откуп пользователям... мы получим "spore" во всем великолепии и нелепости.

Однозначно, отдавать пользователю создание онтологий "под свои интересы" - получится второй del.isio.us, да еще и неиерархичный.
Но вот если прислушаться к теории (см. выше), то может быть, стандартные оси уже как бы и есть? И, как в продвинутых погодных информерах, их можно включать.
Хотя возможность добавления "своих" осей нужна!

Далее,

blind пишет:

2) используется связность объектов на уровне предопределенных онтологий и отношений

т.е. онтологии могут быть и общими, стандартными. Но онтологий на "все случаи жизни" ещё нет, их надо создавать. Значит, задача крепко завязывается с задачами составления/извлечения онтологий, если мы хотим не просто словари терминов, а ещё и отношений между ними.
Или ограничить возможные отношения шкалами: нравится - не нравится, важно - не важно, срочно - не срочно, и т.п.

Thumbs up Thumbs down

7

Re: мысли

Я бы для начала озадачился другой проблемой.

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

Только после досконального разбирательста с этой проблемой можно заниматься остальными гуёвыми примбабасами. И на мой взгляд, добавление ещё одной визуализации совершенно не делает погоды на фоне десятков и десятков визуализаций уже известных. Если будет некая достаточно разумная и универсальная система назначений ролей объектам, то можно будет просто брать любое нужное количество студентов и грузить их написанием взаимно независимых модулей отрисовки, в идеале --- по одному модулю на каждую клеточку "периодической таблицы" http://www.visual-literacy.org/periodic … table.html

Можете, кстати, сразу на Виртуозу смотреть, с учётом того, что и она легко встраивается в сишные программы как модуль, и сишные плагины к ней пишутся легко, и есть хостинг кучи скриптовых языков.

Re: мысли

Имхо для каждого класса должно быть жестко прописано свое отображение. Навряд ли удастся как то унифицировать представление.

И у меня возник вопрос - по всей видимости будет зум. И при максимальном обзоре пользователь будет видеть всю базу?
Тут ведь непонятно как определять что показывать. У классов ведь нет параметра типа вложенность или аналогичного.
Если показывать скажем все наследуемые напрямую от Thing, так их весьма много от него наследуется. Если что то придумаете напишите, будет любопытно узнать Ваши мысли на этот счет:)

Thumbs up Thumbs down

9

Re: мысли

> Имхо для каждого класса должно быть жестко прописано свое отображение. Навряд ли удастся как то унифицировать представление.

Удастся или нет --- вопрос сроков и бюджета, а вот с жёсткостью не согласен. Предположу, что отображение каждого кусочка данных будет описываться как "суперпозиция" описания объекта/отношения/свойства в роли и описания отрисовки роли в визуализации. И описания эти будут интенсивно редартироваться в процессе резработки каждого конкретного приложения на вашей платформе. Посмотрите на CSS --- ещё ни один файлик на моей памяти не дожил от черновика до открытия сайта без серьёзных правок.

При описании такой "суперпозицией" будут возникать многочисленые пары правило/и исключение", так как правила будут задаваться в виде "для свойства P объекта типа T, показываемого визуализацией V в роли R пользователю U при выполнении работы W, делать то-то и то-то", и каждый из параметров P,T,V,R,U,W может быть конкретным значением, списком значений или '*', то есть области действия неизбежно будут пересекаться. Так что список правил придётся упорядочивать, явно убирая произвол. Самым интересным местом будет автоматизация драки за "недвижимость" --- экранные пиксели, которых всегда не хватает, чтобы показать всё, что хочется. Качество автоматизации этой драки в немалой степени определит успех всего продукта.

> И у меня возник вопрос - по всей видимости будет зум. И при максимальном обзоре пользователь будет видеть всю базу?

Не будет, в видеобуфер ограниченного размера (6 мегабайт для труколора 1600x1200) вы все данные большой базы не сможете запихать даже теоретически wink Как и для любой карты, у вас будет конфликт между охватом и детализацией. Но пока я не понимаю необходимость зума для такой визуализации в степени, достаточной для выдачи советов.

10

Re: мысли

iv_an_ru пишет:

>> И у меня возник вопрос - по всей видимости будет зум. И при максимальном обзоре пользователь будет видеть всю базу?

>Не будет, в видеобуфер ограниченного размера (6 мегабайт для труколора 1600x1200) вы все данные большой базы не сможете запихать даже теоретически wink Как и для любой карты, у вас будет конфликт между охватом и детализацией. Но пока я не понимаю необходимость зума для такой визуализации в степени, достаточной для выдачи советов.

ну тут я как раз и имел ввиду "как это будет сделано?". Понятно что все объекты базы пользователь видеть не будет, но какое то представление всей базы вполне возможно. То есть я хотел спросить каково будет это представление.

Насчет остального думаю с такой позиции действительно лучше всего и подходить.

Thumbs up Thumbs down

11

Re: мысли

Я бы при крайнем удалении показывал вообще совершенно отдельную вещь --- "рукописную" страничку с самыми ходовыми "закладками" и ещё чем-нибудь отличным от просто отрисовки вида с ещё на единичку большим значением параметра "охват".

Утрированно, если в географическом атласе на страницах 4 и 5 --- карта полушарий, на страницах с 6 по 27 карты отдельных материков и океанов, дальше 100 страниц карт стран и ещё 300 --- регионов, то при этом на страницах 1-3 дан не вид Земли из дальнего космоса, как можно было бы предположить, а титульный лист и оглавление.

12

Re: мысли

iv_an_ru пишет:

Я бы при крайнем удалении показывал вообще совершенно отдельную вещь --- "рукописную" страничку с самыми ходовыми "закладками" и ещё чем-нибудь отличным от просто отрисовки вида с ещё на единичку большим значением параметра "охват".

Утрированно, если в географическом атласе на страницах 4 и 5 --- карта полушарий, на страницах с 6 по 27 карты отдельных материков и океанов, дальше 100 страниц карт стран и ещё 300 --- регионов, то при этом на страницах 1-3 дан не вид Земли из дальнего космоса, как можно было бы предположить, а титульный лист и оглавление.

Логично:)

Thumbs up Thumbs down