На все, что ты пометил как тему для обдумывания — не отвечаю.
ГВ>Ошибочна тут исходная посылка — представление сайта в виде набора агрегатов и приклеивание к этому представлению поисковых запросов.
Ну во-первых, определение агрегата в студию . Пока его нет — будем считать агрегат == класс в моем понимании. А насчет поисковых запросов попробую объяснить. На аналогии.
Вот представь себе DLL. Импорта нет. Но есть .pdb или .sym. Можно пытаться на этой основе вызывать функции. В общем, работает, пока не перекомпилировали.
А теперь допустим, что и .sym нет
Но вдруг стало известно (не важно откуда), что если управление передать по RVA 0x1234 и до этого в стек заслать пару int, то будет хороший результат — экран разрисуют серо-буро-малиновым. Эту информацию ты мне сообщил. Я ее записал.
А потом мне Вася Пупкин еще про аналогичный вызов сообщил. Если по RVA 0x2353 вызывать, предварительно заслав 3 int,то на экране сферического коня нарисуют.
И т.д. И т.п. И все это я собрал. А еще я научился сам такие пробы делать и их собирать.
И вот теперь я FAQ делаю. Чтобы серо-буро-малиновым — по 0x1234. Чтобы коня — 0x2353. И т.д.
А ты мне запрос делаешь — как, мол, коня нарисовать ? А я тебе в ответ — 0x2353.
Дурацким делом все мы, конечно, занимались, но разве от этого DLL не перестала быть некоторым АПИ ?
PD>>Нет у меня спецификации, где я ее возьму ? Но от противного — докажи, что современные поисковые системы как-то учитываают приоритет входных параметров запроса!
ГВ>Ни в коем случае не собираюсь этого доказывать. Они не расставляют, а следовательно и не учитывают приоритеты параметров запросов. Здесь вопрос именно в том, на какую модель мы хотим натянуть описание запросов.
Именно! Обычная модель — все же AND (ну не совсем). Я хочу — иерархию.
ГВ>Я думаю, что проще предполагать, что ссылка на .aspx — это ссылка на элемент второстепенной структуры. В прочем, это тема N3 для того же таймаута.
А все же — что тут делает .aspx ? Зачем мне, пользователю, знать, кто там скрывается ? К тому же и врут безбожно. Синклер приводил пример с .php, за которвм может что угодно скрываться. Я могу еще пример с .html привести — за ним такой Tapestry слой может стоять вместо чистого HTML, что не дай боже. А зачем мне все это знать ? Зачем вы мне эту структуру показали ? Чтобы я вместо asmx asm набрал и удивлялся, с чего это я не получил в ответ mov eax, 0 ?
PD>>>>А теперь возвращаемся к сайтам. В некотором упрощенном виде сайт — это иерархическая база данных. ГВ>>>Тщ-щ-щ! После слов "...упрощенном..." резко принимаем охотничью стойку — ща начнётся! PD>>Ну-ну. А ты хотел, чтобы я тебе полную сетевую модель Интернета выложил ?
ГВ>Нет, разумеется. Просто это и в самом деле очень важно: упрощения должны быть корректными.
Упрощения могут быть любыми при условии, что в результате получается модель, которая позволяет описать реальность более или менее успешно. Потому что корректность или некорректность упрощения определяется соотвтетсвием модели и реальности. Я на этих делах две собаки съел. Диссертация моя была по расчетам в химической термодинамике, и на определенном этапе я получал в качестве промежуточных данных отрицательные объемы . Но результаты всегда были более или менее соответсвующими экспериментальным данным, поэтому всех, кто мне задавал вопрос о физической осмысленности промежуточных данных, я посылал подальше. Есть модель. Есть то, что она дает. С результатами не согласны — будем обсуждать. Если сумеете ее применимость опровергнуть, показать, что она дает неправильные результаты — признАю свою неправоту. А до тех пор — до свидания.
ГВ>Совершенно согласен про эффект второго порядка. Не согласен с тем, что интернет можно рассматривать как иерархическую БД.
Я разве такое говорил ? Но сетевая модель на порядок сложнее. В конце концов, и реляционные БД есть тоже упрощение — нет в реальности никаких реляционных схем, там скорее иерархия или сеть. Однако же работают.
>Скорее, тут сетевая модель, да и то — если мы говорим только о поиске. Google, если уж продолжать начатую тобой аналогию, пытается стать корнем дерева поисковых запросов. Но ведь ими функциональность Сети не ограничивается.
Здравствуйте, Pavel Dvorkin, Вы писали:
ГВ>>Стойка обретает суровую стабильность...
PD>Зря ты эту стойку принял. Такое моделирование совершенно обычно в научных исследованиях.
Только вот разработка архитектуры ПО это исключительно инженерная деятельность.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1074 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Иными словами, ты считаешь, что аналогия некорректна ? Почему ? Есть сайт, я его представляю как объект.
Ок. Что есть объект в твоем понимании? Некая сущность обладающая identity и state, который меняется под воздействием приходящих messages в cоответствии с некоторым behavior этого объекта, так? PD>Это мое желание создать некую модель, больше ничего. У этого объекта есть набор страниц (HTML). Я их рассматриваю как подобъекты объекта. Что тут неверно ?
Не то чтобы неверно. Пока что ты не указал никакого критерия относительно того, что ты считаешь подобъектомобъекта. PD> Если бы я класс всерьез начал бы писать (не для сайта, а вообще), ты бы не возразил, надеюсь ? Почему же в этой модели неверно ?
Так, только что никакой речи о классах не было. Я отношу себя не к ученым, а к тупым инженерам, поэтому меня всегда настораживает, когда термины начинают произвольно взаимозаменяться, типа класс<->объект, формат<->протокол, и так далее. PD>Почему это ? Имеем a.com/product.html. Тем самым сайт говорит. что у него есть подобъект product. Мне нет дела, что за код там стоит, но что сам объект есть — в чем ошибка ?
Гм. Следует ли из этого, что a.com/product.html?productId=188 — это другой подобъект сайта a.com?
Является ли он подобъектом объекта a.com/product.html PD> product есть, а вот products, положим, нет, а поэтому a.com/products.html — ClassNotFound или 404.
Ну вот, опять класс. PD>Вот тут наше с тобой расхождение. То, что это в Интернете поисковые (и даже не поисковые, а просто линк в URL броузера) запросы — никакого сомнения. Но почему я не могу их рассматривать как вызовы методов класса — обоснуй. PD>Я думаю, ты понимаешь, что я не предлагаю садиться и эти классы писать. Это только модель для рассуждений. Но если она неверна — объясни, почему.
Ну, например потому, что класс подразумевает множество объектов.
Предположим, ты предлагаешь рассматривать HTTP-реквесты как вызовы методов некоторого объекта. Ок, не проблема.
Не очень правда понятно, каким образом ты разделяешь объекты и методы.
Вот a.com/product.html?productId=188 — это что? Вызов a_com.product(188), или a_com.product.productId(188)? PD>И что ? А для обычных, классических функций всегда гарантировано сохранение результата во времени ?
Если мы говорим о вызовах методов в распределенной системе, то для достижения успеха крайне полезно с самого начала озаботиться разделением методов на консервативные, идемпотентные, и все остальные. Потому что от этого крайне зависят возможности оптимизации в среде, где накладные расходы на вызов как правило превышают оные на его обработку. PD>Нет у меня спецификации, где я ее возьму ? Но от противного — докажи, что современные поисковые системы как-то учитываают приоритет входных параметров запроса!
Гм. Я не очень понимаю, что такое "приоритет входных параметров запроса". Ты про какой запрос?
PD>Не пойдет. Именно произвольного (т.е не обязательно броузера, а что захотим, то и напишем, и какими средствами захотим , такими и напишем, и будет он десктопным или нет — как захотим), но для данной цели. Если я писал в свое время такой клиент для задач оптимизации финансовых расчетов (реализуемых сервисом), то для задач предсказания погоды он не пойдет. Но мы этот клиент делали как десктопное приложение (для отладки), как код, вызываемый их Excel и т.д.
PD>А вот если бы этот сервис вернул мне javascript, то пришлось бы либо исполнять это только из броузера, либо писать свой интерпретатор javascript и надеяться, что в ответе будет только часть, относящаяся к задаче, а не window.open(...), в противном случае придется свой броузер писать. Вот и все, что я хотел здесь сказать.
Ну, именно поэтому сервисов, которые бы возвращали джаваскрипт (в том виде, в котором ты его здесь понимаешь), в природе не существует. Есть сервисы, которые возвращают JSON, но в нем не будет привязки к environment браузера, а парсеры JSON есть уже для всех популярных языков программирования.
А веб-приложения, которые ориентированы на исполнение в браузере, могут как раз исполняться в браузере. Что, впрочем, ничему не мешает. См. например Google AJAX Search API для сравнения с google.com.
PD>WSDL не имеет. Ссылка имеет. Вот тот факт. что в ссылке указана страница (.asmx или что-то еще) — это и есть экспонирование.
Экспонирование чего? Ссылка ничего не говорит о структуре. Со ссылкой можно сделать только одно: разыменовать. Есть желание расширить модель и придать некую иерархическую семантику интернету? Ок, можно попробовать и так. Что будет листьями этого дерева?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
AVK>>Только вот разработка архитектуры ПО это исключительно инженерная деятельность.
PD>То-то в Америке этим в основном университеты и занимались.
И что? Университеты, тем более технологгические, тем более в штатах, вполне могут заниматься инженерно-конструкторской деятельностью.
... <<RSDN@Home 1.2.0 alpha 4 rev. 1074 on Windows Vista 6.0.6001.65536>>
Собрал здесь то, над чем подумал дополнительно. Мои возражения оказались не во всём состоятельными.
PD>Иными словами, ты считаешь, что аналогия некорректна ? Почему ? Есть сайт, я его представляю как объект. Это мое желание создать некую модель, больше ничего. У этого объекта есть набор страниц (HTML). Я их рассматриваю как подобъекты объекта. Что тут неверно ? Если бы я класс всерьез начал бы писать (не для сайта, а вообще), ты бы не возразил, надеюсь ? Почему же в этой модели неверно ?
Прежде всего, что вот это:
com.a.html.product(type=elephant,color=rose)
вовсе не внутренняя структура сайта. Это некоторый URL и только. Про внутреннюю структуру мы ничего не знаем, поскольку URL попадает на соответствующий сайт и там уже может быть трансформирован во всё, что угодно.
PD>Почему это ? Имеем a.com/product.html. Тем самым сайт говорит. что у него есть подобъект product. Мне нет дела, что за код там стоит, но что сам объект есть — в чем ошибка ? product есть, а вот products, положим, нет, а поэтому a.com/products.html — ClassNotFound или 404.
Не забывай, что этот URL (a.com/product.html) выдан нам самим этим сайтом, соответственно, он может воообще никак не соотноситься с внутренней структурой самого сайта. Вот в таком вот интересном виде разработчики договорились выдавать ссылки на какие-то элементы своей программы, открытой внешнему миру под маской web-сервера.
Безусловно, мы сами можем интерпретировать текст этого URL как набор некоторых объектов. Скажем, объектов типа CDomainName, CSiteDirectory, CSitePage, etc. Но это уже наше личное, внутреннее дело. К внутренней структуре сайта сие никакого отношения не имеет. Всё, что мы знаем об этом сайте, это то, что если ему послать вот этот URL:
com.a.html.product(type=elephant,color=rose)
то обратно нам раньше или позже прилетит какое-нибудь:
<html>Бамбарбиа! Кергуду!</html>
PD>Вот тут наше с тобой расхождение. То, что это в Интернете поисковые (и даже не поисковые, а просто линк в URL броузера) запросы — никакого сомнения. Но почему я не могу их рассматривать как вызовы методов класса — обоснуй.
Можно. Можно рассмотреть поисковый URL как вызов метода экземпляра некоторого класса. Я просто смысла в этом не вижу. Получается, что есть класс Internet с методом GetData(url), или класс TGoogle с аналогичным методом и т.п. Ну да, некая обобщённая модель, которая вполне может быть реализована на клиенте... А дальше что?
PD>>>Да и результат существенно меньше требует наличия естественного интеллекта для его анализа. Но экспонирование внутренней струкруы осталось и гарантий по сохранности интерфейса по-прежнему нет ГВ>>Павел, это уже не смешно. У меня ни коньяку не хватит, ни здоровья на здоровый смех. Во-первых, WSDL-description, так же, как и API, не имеет никакого отношения к внутренней структуре системы, накрываемой этим API. PD>WSDL не имеет. Ссылка имеет. Вот тот факт. что в ссылке указана страница (.asmx или что-то еще) — это и есть экспонирование.
Не совсем так. WSDL-описуемый вызов, как и URL — птицы одного полёта. И тот и другой можно абстрагировать от внутренней структуры сайта. Web-сервер может весь URL дополнительно парсить/анализировать/перенаправлять, и тот факт, что там указана какая-то mypage.jsp, не может быть гарантией того, что такая страница существует в действительности в виде отдельного .jsp-файла. Это вполне может быть, например, ключом к каким-то внутренним базам данных, скрытым web-сервером. На вскидку не скажу, какие серверы умеют именно так делать, но ничего невозможного тут не вижу. Соответственно, ссылка — это не более, чем навигационное приспособление, т.е., артефакт уровня репрезентации. Как она в действительности интерпретируется сайтом — отдельный вопрос.
Мы достатчно уверенно можем сказать только то, что например, в таком URL: http://www.a.com/mypages/mypage.htm?a=1&b=2 только "a.com" представляет собой имя некоторого узла, которое превратится DNS-ом в некоторый IP-адрес. Но и всё. Дальше — ведомство уже этого самого узла.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Pavel Dvorkin, Вы писали:
ГВ>>Ошибочна тут исходная посылка — представление сайта в виде набора агрегатов и приклеивание к этому представлению поисковых запросов. PD>Ну во-первых, определение агрегата в студию . Пока его нет — будем считать агрегат == класс в моем понимании.
Встречное пожелание: что такое класс в твоём понимании?
PD>А насчет поисковых запросов попробую объяснить. На аналогии.
PD>Вот представь себе DLL. Импорта нет. [...] PD>А ты мне запрос делаешь — как, мол, коня нарисовать ? А я тебе в ответ — 0x2353. PD>Дурацким делом все мы, конечно, занимались, но разве от этого DLL не перестала быть некоторым АПИ ?
Ограниченный контекст... Всем всё заранее известно... Осталось только найти точку входа в известно, какую функцию. Что-то я не понимаю, что ты хочешь до меня донести.
PD>>>Нет у меня спецификации, где я ее возьму ? Но от противного — докажи, что современные поисковые системы как-то учитываают приоритет входных параметров запроса! ГВ>>Ни в коем случае не собираюсь этого доказывать. Они не расставляют, а следовательно и не учитывают приоритеты параметров запросов. Здесь вопрос именно в том, на какую модель мы хотим натянуть описание запросов. PD>Именно! Обычная модель — все же AND (ну не совсем). Я хочу — иерархию.
Понятно.
ГВ>>Я думаю, что проще предполагать, что ссылка на .aspx — это ссылка на элемент второстепенной структуры. В прочем, это тема N3 для того же таймаута.
PD>А все же — что тут делает .aspx ? Зачем мне, пользователю, знать, кто там скрывается ? К тому же и врут безбожно. Синклер приводил пример с .php, за которвм может что угодно скрываться. Я могу еще пример с .html привести — за ним такой Tapestry слой может стоять вместо чистого HTML, что не дай боже. А зачем мне все это знать ? Зачем вы мне эту структуру показали ? Чтобы я вместо asmx asm набрал и удивлялся, с чего это я не получил в ответ mov eax, 0 ?
Так ты сам всё время говоришь про какую-то "внутреннюю структуру" сайта. А в URL в общем случае её нет ни разу. Не обязан URL отражать внутреннюю структуру, следовательно, нельзя и апеллировать к этому. Может, но не обязан.
PD>>>>>А теперь возвращаемся к сайтам. В некотором упрощенном виде сайт — это иерархическая база данных. ГВ>>>>Тщ-щ-щ! После слов "...упрощенном..." резко принимаем охотничью стойку — ща начнётся! PD>>>Ну-ну. А ты хотел, чтобы я тебе полную сетевую модель Интернета выложил ? ГВ>>Нет, разумеется. Просто это и в самом деле очень важно: упрощения должны быть корректными. PD>Упрощения могут быть любыми при условии, что в результате получается модель, которая позволяет описать реальность более или менее успешно.
Ага. Складываем 2 и 2. Ты хочешь любой сайт приводить к некоей иерархической интерпретации, так? Или к набору таких интерпретаций. Верно? Почему говорю "хочешь", — потому что никакой имманентно присущей им структуры у сайтов нет. Это может быть вообще плоская как доска таблица SQL, где лежит содержимое всех страниц, доступных извне через систему разделов, подразделов и т.п.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Кажется, я наконец-то сам понял, чего я добиваюсь
Кажется, и я наконец-то понял, чего ты добиваешься. Ты хочешь искать информацию по её семантике, правильно?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>А вот теперь представь, что этот клиент (C) — лишь часть клиента, а надклиент (SC) эту строку как-то сооружает и этому C передает. Так вот, эта строка и будет АПИ этого C! У C есть АПИ для SC, и он заключается в текстовой строке! Мы такое не сделали, просто потому, что не надо было. А вот сейчас я как раз такого SC и написал, заказчик его тестирует. Но это уже другая задача.
Я так думаю, что правила, по которым SC сооружает строку для C вполне точно определены, потому здесь нет ничего необычного. Это вопрос кодирования информации, ничего более.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Pavel Dvorkin, Вы писали:
PD>>Кажется, я наконец-то сам понял, чего я добиваюсь
ГВ>Кажется, и я наконец-то понял, чего ты добиваешься. Ты хочешь искать информацию по её семантике, правильно?
Ответ здесь на все твои постинги.
Искать информацию по семантике ? Хорошо бы, но вряд ли получится. Потому что семантика за кадром, как я уже писал, и, как ты верно отметил, есть просто соглашение. Почему tiff — это обычно графический файл ? Потому что большинство с этим согласилось. Это не формализуемо. Почему ++ — это инкремент ? Тоже согласились. Можно вполне язык предложить, где это иначе делается, да и предлагать не нало — Inc в Паскале. Ничего тут ИМХО сделать нельзя.
А вот с иерархичными запросами — можно. Более того, вполне реально. Но сначала отвечу на твои замечания
ГВ>Прежде всего, что вот это:
com.a.html.product(type=elephant,color=rose)
вовсе не внутренняя структура сайта. Это некоторый URL и только. Про внутреннюю структуру мы ничего не знаем, поскольку URL попадает на соответствующий сайт и там уже может быть трансформирован во всё, что угодно.
Может. Но далеко не всегда это делается. Точнее, чаще всего не делается. Обращение по линку
a.com/goods/product.html?type=elephant,color=rose
есть все же обращение к странице product.html из виртуального каталога goods. Да, оно может быть потом трансформировано во что угодно, но в большинстве случаев при отсутствии вирт. каталога goods ты получишь либо 404, либо редирект куда-нибудь, может, и разумный, может, на улучшенный 404.
А вот с тем, что сайт не есть иерархическая структура — не согласен. В точном понимании он, конечно, не есть иерархия, но все же остовное дерево в нем обычно есть. Это следует просто из того, что во внутренней структуре сайта часто имеется parent для каждой страницы. Я не утверждаю, что всегда, но чаще всего все же есть. Иерархичность просто следует из логики представления информации. Есть компания, у нее есть товары, услуги, документы, товары в свою очередь подразделяются на ..., услуги на... и т.д. Да, конечно, потом это сто раз перевязано гиперлинками, но основа сохраняется.
Кстати, если эту компанию как таковую рассмотреть, то это очень хорошо заметно. Есть руководство, есть отдел кадров, есть бухгалтерия, отдел производства, отдел торговли и т.д. Конечно, все это переплетено массой горизонтальных связей, формальных и неформальных, но это не отменяет базовой структуры.
Вернусь сюда
a.com/goods/product.html?type=elephant,color=rose
Ну а если goods решено переименовать в products ? Или просто пользователь неправильно набрал линк
a.com/good/product.html?type=elephant,color=rose
Обычно из этого следует в той или иной форме 404. Ты можешь мне 100 раз говорить, что внутренняя структура сайта в действительности может быть скрытой и все эти линки поведут на
Если же остовное дерево сайта более или менее определено, то сайт мог бы его экспонировать. Не прямо, конечно. Но это остовное дерево есть гораздо более перманентная вещь, нежели структура виртуальных каталогов. Потому что она отражает реально, чем компания занимается и меняется слабо. Конечно, если компания Рога и Копыта начнет производить сверхзвуковые самолеты, то от дерева останутся рожки и ножки . Но если она решила расширить ассортимент рогов, добавив рог носорога, то дерево сильно не пострадает.
А дерево это уже есть, между прочим. Если со страницами ассоциированы ключевые слова, то они и образуют это дерево. Никакого другого не надо. Но сейчас поиск идет по ключевым словам обычно в пределах страниц. Надо этот поиск сделать иерархичным.
Вот смотри
http://a.com XML (я оставлю XML, но понимай что хочешь под ним).
На XML описывается запрос. Он иерархинчный, то есть мне в первую очередь нужен слон, а уж потом розовый, при отсутствии розового я готов на любого слона, а при отсутствии слона в запросе есть ветка else, которая выдаст мне мамонта, если он есть.
Этот запрос парсится в соответствии со структурой сайта, описанной деревом ключевых слов. Вместо того, чтобы
a.com/goods/product.html?type=elephant,color=rose
обращаться к вирт. каталогу goods, идет сравнение дерева запроса с деревом сайта. В запросе, скажем, присутствует слово "товар" Именно так, по русски. На верхнем уровне сайта идет разбор этого запроса с привлечением ключевых слов, которых может быть довольно много , синонимов в некотором смысле — products, товар, товары, goods, prod (да-да, почему бы и не сокращения). И если в запросе присутствует "товар", то направление дальнейшего прохода дерева сайта определилось. И если prod — тоже, или goods. Дальше на следующем уровне в запросе есть "elephant", а может , "слон", а может, "хоботное". В любом случае соотнесение произведено.
В результате возможно одно из двух. Либо запрос реализуется точно, и тогда мы попадаем на Response для продаваемого розового слона. Либо он точно не реализуется, тогда начинает работать приближенный поиск, который, впрочем, в отличие от полнотекстового не вернет мне ни розовое небо, ни розовые обои. Потому что тут иерархия, а не AND, а на верхнем уровне иерархии розового нет. Вот если бы это был сайт для живописцев, то может быть, выше было бы розовое, а потом уж что.
Если запрос был успешным и точным, его можно сохранить. В дальнейшем, если его повторить, возможно одно из 3. Либо он останется точным и приведет к точному Response, хотя , возможно, совсем другому, так как изменился ассортимент розовых слонов и было решено их из товаров отправить в раздел "животные". Это изменения во внутренней структуре, они никого не касаются. Либо запрос перестал быть точным (фирма все еще торгует слонами, но только не розовыми), в этом случае возвращается приближенный Response. Либо запрос реализовать совсем нельзя, так как фирма перепрофилировалась не реактивные лайнеры. Ну, тут ничего не поделаешь.
Кстати, если вернуться к "живой" компании, то здесь может быть то же самое. Приходит письмо от неизвестной до сих пор личности (если известной, алгоритм может быть иной). Его кладут на стол директору, который отправляет его кому-то из заместителей. По каким критериям ? Да по списку ключевых слов. Читать ему это письмо некогда, поэтому он пробегает его по диагонали и видит там слова, на основании которых решает, что это в компетенции заместителя по маркетингу. Тот, в свою очередь, сделает то же, отправив этот запрос помощнику по копытам. И т.д.
Такой иерархичный поиск, в отличие от полнотекстового, мало того, что более конкретен, но еще и более "машинизируем". Его можно автоматически генерировать. Например, обнаружен сайт, новый. Обшарим его , начиная с home page, потом устроим , например, анализ частот встречаемых слов и определим предметную область (нет-нет, никакой семантики пока, просто набор наиболее часто встречаемых терминов безотносительно к смыслу). Теперь этот сайт можно "попытать". На основе этого набора терминов шлем ему сгенерированные иерархические запросы. Например, отобрали мы 2 термина — слон и розовый. Шлем ему запрос со словом слон наверху, а розовый — ниже. Он дает Response, точный (можно, кстати, некий Confidence завести), а поэтому мы этот запрос сохраняем. На запрос, в котором выше розовый, а ниже — слон, Response будет нулевой, а поэтому мы его просто отбросим. И т.д. В результате мы имеем набор запросов, на которые этот сайт дает вразумительные ответы. Если теперь это все проанализировать, то в итоге может получиться Google2 , который будет по некоторому запросу (его, конечно, придется иерархичным делать пользователю или его софту) подбирать более или менее похожие запросы их возвращать. Вместо 100,000 ссылок.
Резюмируя, скажу следующее. Делая запрос к сайту, я вообще не интересуюсь его внутренней структурой. Рассматривай ее как хочешь, хоть как истину, хоть как сокрытие и перенаправление, мне она все равно не нужна. Меня не интересует, php там, aspx или html. Меня не интересует набор каталогов в строке URL, что бы они не означали. Это вообще не мое дело. Меня интересует только запрос и ответ. А структура запроса должна быть приближена к его "естественной" структуре. Формального определения последней я не дам
Тогда получается, что в целом всё выглядит достаточно просто. Поисковый запрос сопоставляется с иерархическим "справочником" ключевых слов, котрый уже определяет множества страниц, содержимое которых следует отсматривать. Проблем я вижу две:
1. Построение этого самого справочника.
2. Синтаксис языка запросов, он получается слегка нетривиальным.
По первому пункту.
Насколько я понял, ты предлагаешь воспользоваться некоей разновидностью "естественной" упорядоченности данных сайта, определяемой, например по длине "пути" в URL. Соответственно, ключевые слова, встречающиеся в "верхних" страницах имеют, в некотором смысле, больший вес, чем такие же слова в "нижних". Оставлю пока за скобками вопрос о надёжности такого метода, перейду к главному. Здесь есть очень большая проблема определения словаря этих ключевых слов. Что считать ключевыми словами? Нужно ли для этого вводить какой-то предопределённый словарь или воспользоваться каким-то ещё формальными критериями выделения ключевых слов из содержимого сайта?
По второму пункту ответ кажется простым. Можно использовать тот же синтаксис S-expression, тогда, например, запрос на поиск розового слона с предпочтением слонов, а не "розовости" может выглядеть так:
(elephant (rose))
В принципе, ничего необыкновенного.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, Pavel Dvorkin, Вы писали:
ГВ>Тогда получается, что в целом всё выглядит достаточно просто. Поисковый запрос сопоставляется с иерархическим "справочником" ключевых слов, котрый уже определяет множества страниц, содержимое которых следует отсматривать. Проблем я вижу две:
ГВ>1. Построение этого самого справочника. ГВ>2. Синтаксис языка запросов, он получается слегка нетривиальным.
ГВ>По первому пункту.
ГВ>Насколько я понял, ты предлагаешь воспользоваться некоей разновидностью "естественной" упорядоченности данных сайта, определяемой, например по длине "пути" в URL. Соответственно, ключевые слова, встречающиеся в "верхних" страницах имеют, в некотором смысле, больший вес, чем такие же слова в "нижних".
Не совсем так просто. Тут в принципе можно любую логику реализовать. Например, при неудачном точном поиске устроить приближенный или вообще перейти к другому разделу. Кстати, при этом (сейчас понял) необязательно сайт в качестве дерева рассматривать. Можно и как граф, то есть в истинном виде.
>Оставлю пока за скобками вопрос о надёжности такого метода, перейду к главному. Здесь есть очень большая проблема определения словаря этих ключевых слов. Что считать ключевыми словами? Нужно ли для этого вводить какой-то предопределённый словарь или воспользоваться каким-то ещё формальными критериями выделения ключевых слов из содержимого сайта?
Только вручную. Эта структура должна просто создаваться разработчиком сайта и наполняться по мере надобности. Да, впрочем, эти ключевые слова и так есть , так они и вводятся. Сам не раз в такой разработке участвовал.
А иначе — мы опять к проблеме синтаксис — семантика перейдем.
ГВ>По второму пункту ответ кажется простым. Можно использовать тот же синтаксис S-expression, тогда, например, запрос на поиск розового слона с предпочтением слонов, а не "розовости" может выглядеть так:
Уф-ф-ф!
ГВ>>Насколько я понял, ты предлагаешь воспользоваться некоей разновидностью "естественной" упорядоченности данных сайта, определяемой, например по длине "пути" в URL. Соответственно, ключевые слова, встречающиеся в "верхних" страницах имеют, в некотором смысле, больший вес, чем такие же слова в "нижних".
PD>Не совсем так просто. Тут в принципе можно любую логику реализовать. Например, при неудачном точном поиске устроить приближенный или вообще перейти к другому разделу. Кстати, при этом (сейчас понял) необязательно сайт в качестве дерева рассматривать. Можно и как граф, то есть в истинном виде.
Ну да, структура сайта, — это лишь некоторая предварительная структура. Её можно и совсем проигнорировать.
>>Что считать ключевыми словами? Нужно ли для этого вводить какой-то предопределённый словарь или воспользоваться каким-то ещё формальными критериями выделения ключевых слов из содержимого сайта? PD>Только вручную. Эта структура должна просто создаваться разработчиком сайта и наполняться по мере надобности. Да, впрочем, эти ключевые слова и так есть , так они и вводятся. Сам не раз в такой разработке участвовал. PD>А иначе — мы опять к проблеме синтаксис — семантика перейдем.
Ну тогда здесь остаётся только задача согласования ключевых слов самих по себе.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ну тогда здесь остаётся только задача согласования ключевых слов самих по себе.
О-о, пацаны, еще немного, и вы изобретете Full Text Search и очередную версию алгоритма оценки релевантности.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
ГВ>>Ну тогда здесь остаётся только задача согласования ключевых слов самих по себе. PD>Да хотя бы и без них для начала. Сделали бы хоть иерархию, а слова найдутся
Кто — сделал бы?
В общем, чтобы не разводить лишний флейм, обозначу главную проблему такого подхода: масса народу должна договориться по таким вопросам:
— Какие символы обозначают иерархию;
— Какие слова являются ключевыми.
Этим может заняться специальный комитет...
Иными словами, приехали к сугубо организационной задаче.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>В общем, чтобы не разводить лишний флейм, обозначу главную проблему такого подхода: масса народу должна договориться по таким вопросам:
ГВ>- Какие символы обозначают иерархию; ГВ>- Какие слова являются ключевыми.
ГВ>Этим может заняться специальный комитет...
ГВ>Иными словами, приехали к сугубо организационной задаче.
А это с самого начала ясно было. Любое решение, изменяющее текущее положение дел, требует стандартизации и комитета
ГВ>>В общем, чтобы не разводить лишний флейм, обозначу главную проблему такого подхода: масса народу должна договориться по таким вопросам:
ГВ>>- Какие символы обозначают иерархию; ГВ>>- Какие слова являются ключевыми.
ГВ>>Этим может заняться специальный комитет...
ГВ>>Иными словами, приехали к сугубо организационной задаче.
PD>А это с самого начала ясно было. Любое решение, изменяющее текущее положение дел, требует стандартизации и комитета
PD>Ждем-с
. Пока его нет — будем считать агрегат == класс в моем понимании. А насчет поисковых запросов попробую объяснить. На аналогии.
