мысли

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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