Re[23]: Неужели?
От: Mamut Швеция http://dmitriid.com
Дата: 10.04.08 07:02
Оценка:
M>>Это справедливо только для русского языка

PD>Не думаю. Сказав Nickson, мы тем самым уже установили ассоциацию (в уме) с президентом США. Сказав "Richard" — мы не установили.



Я, сказав Nickson, устанавливаю ассоциацию с кем угодно, только не с Никсоном
Потому что президент будет все же Nixon, но тот же Гугл возможность неправильного написания учитывает

Более того, Nixon вполне может означать Nixon Watches, а вот Richard Nixon — с большой долей верятности указывает на президента

>>>>Что делть с национальными правилами предоставления информации?


PD>>>Сайт обычно делается либо на одном языке, либо отдельные части для разных языков.


M>>Нет, отдельные части в виде собственно отдельных частей не делаются.


PD>Собственно или не собственно, но страниц на двух языках одновременно я не видел.


Аааа, в этом смысле...


PD>>>Структура одна. Граф с выделенным узлом (home page)


M>>Зато граф очень разный Причем точек входа может быть несколько, и каждая из этих точек может быть равнозначной


PD>Это не принципиально. В крайнем случае я готов на несколько несвязных графов с выделенной вершиной у каждого.


В случае last.fm — это (потенциально) бесконечное количество таких графов потому что, повторюсь, граф

Bjork -> Mamut -> Glory Box -> Jaropolk

абсолютно равноначен графу

Jaropolk -> Glory Box -> Mamut -> Bjork

При этом граф

Mamut -> Jaropolk

также абсолютно равнозначен. Или графы
       Jazz - Jan Garbarek
     /
Bjork - Electronic - Miles Davies
     \ 
       Classical - Wolfgang Amadeus Mozart


Абсолютно равнозначны между собой. Причем Bjork я вообще наугад выбрал. Я мог выбрать "вершиной" абсолютно любой из "узлов" сайта — тэг, пользователя, жанр, исполнителя, произведение, радиостанцию. О каких графах мы говорим? Их здесь бесконечное количество

M>>Какого из графов? Как узнать, что


M>>- Павел — Дворкин — отель

M>>важнее, чем
M>>- отель — Павел — Дворкин

PD>Никак. Я еще раз говорю — это вручную наполнители сайта должны решить. Если сайт по отелям, то важнее отель, потому что мои ФИО — это отзыв об отеле. А вот если я — владелец сети отелей — то важнее ФИО.


А если сайт — last.fm?
А если сайт — блог?

M>>Что делать с циклическими ссылками? Или равнозначными путями?


PD>Ну ты от меня многого хочешь. Алгоритмы на графах есть, и обход возможен по-разному. А дать прописи немедленно я не хочу и не могу.


Потому что это в общем случае просто невозможно


M>>Хочу дешевый отель в турции, в анталии, с описанием. Под "описание" попадет и вот это и вот это и вообще чье-то описание в стиле "были на море". Как тот же ЖЖ сможет выдать на это иерархическую структуру? Как ЖЖ вообще сможет выавать хоть какую-то иерархическую структуру?


M>>А с гуглем уже сейчас можно попытаться это найти


PD>А я вообще-то Гугл не предлагаю закрыть


Хорошо, как тогда создать граф для, например, вот этого текста. Вот пришел uberGoogle и Универсальным Языком Запросов молвил нечеловечиским голосом: "а дай ка, uberLJ, граф по своим страницам, да так, чтобы понял я, что такая-то и такая-то страница релевантны для поиска 'отдых в Анталии', а такая-то и такая-то нерелевантны"

... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>


dmitriid.comGitHubLinkedIn
Re[24]: Неужели?
От: Sinclair Россия https://github.com/evilguest/
Дата: 10.04.08 11:34
Оценка: 19 (2)
Здравствуйте, Mamut, Вы писали:

Да это всё очередной утопический проект по Созданию Классификатора Для Всего. Отличный стеб на эту тему можно найти в Quicksilver Стивенсона:

Если будем держаться подальше от политики, то уже через несколько поколений сможем запускать крылатые колесницы на Луну. Надо устранить лишь некоторые преграды на пути прогресса.
– Какие же именно?
– Латынь.
– Латынь?! Но она…
– Да, она универсальный язык учёных, богословов и прочих. А как звучна! Скажешь на ней любую галиматью, и ваш брат университетский выученик придёт в восторг или по крайней мере сконфузится. Вот так Папам и удавалось столько веков впаривать людям дурную религию – они просто говорили на латыни. Зато если перевести их замысловатые фразы на философский язык, сразу проявятся противоречия и размытость.
– М м м… я бы сказал даже, что на правильном философском языке, когда бы такой существовал, нельзя было бы, не преступая законов грамматики, выразить ложное утверждение.
– Вы только что сформулировали самое краткое из его определений, – весело произнёс Уилкинс. – Уж не вздумалось ли вам со мною соперничать?
– Нет, – торопливо отвечал Даниель, со страху не различивший юмора. – Я лишь рассуждал по аналогии с декартовым анализом, в котором, при чёткой терминологии, любое ложное высказывание будет неправомерным.
– При чёткой терминологии! Вот она, загвоздка! – сказал Уилкинс. – Чтобы записать термины, я сочиняю философский язык и всеобщий алфавит – на котором образованные люди всех рас и народов будут выражать свои мысли.
– Я к вашим услугам, сэр, – промолвил Даниель. – Когда можно приступать?
– Прямо сейчас! Пока Гук не покончил с лягушками – если он придёт и застанет вас без дела, то закабалит , как чёрного невольника. Будете разгребать требуху или, что хуже, проверять его часы, стоя перед маятником и считая… колебания… с утра… до самого… вечера.
Подошёл Гук, не только горбатый, но и кособокий, длинные каштановые волосы висели нечёсаными прядями. Он немного выпрямился и задрал голову, так что волосы разошлись, словно занавес, явив бледный лик. Щетина подчеркивала худобу запавших щёк, отчего серые глаза казались ещё больше.
Гук сказал:
– Лягушки тоже.
– Меня уже ничто не удивляет, мистер Гук.
– Я заключаю, что из них состоят все живые существа.
– А вас не посещает мысль что нибудь из этого записать? Мистер Гук? Мистер Гук?
Однако Гук уже ушёл на конюшню, ставить какой то новый эксперимент.
– Из чего состоят??? – спросил Даниель.
– В последнее время, всякий раз, глядя на что либо через свой микроскоп, мистер Гук обнаруживает, что оно сложено из крохотных ячеек, как стена – из кирпичей, – сообщил Уилкинс.
– И на что же походят эти кирпичи?
– Он не зовет их кирпичами. Не забывайте, они полые. Он решил назвать их клетками… Впрочем, в эту чепуху вам встревать незачем. Идёмте со мной, любезный Даниель. Выбросьте клетки из головы. Чтобы постичь философский язык, вы должны усвоить, что всё на Земле и на Небе можно разделить на сорок различных родов… в каждом из которых, разумеется, есть свои более мелкие категории.
Уилкинс провел его в помещение для слуг, где стояла конторка, а книги и бумаги громоздились бессистемно, словно пчелиные соты. Уилкинс двигался так стремительно, что от поднятого им ветра по комнате запорхали листки. Даниель поймал один и прочёл:
– «Петушье просо, листовник сколопендровый, кандык, гроздовик, взморник, кукушкины слёзы, заразиха, петров крест, ложечница лекарственная, цикламен, камнеломка, заячья капуста, подмаренник, плаун вонючий, цикорий, осот, одуванчик, пастушья сумка, икотник, вербейник, вика».
Уилкинс нетерпеливо кивал.
– Коробочкообразующие травы, не колокольчатые, и ягодоносные вечнозелёные кустарники. Каким то образом они затесались среди желуденосных и орехоносных деревьев.
– Так философский язык – своего рода ботанический…
– Гляньте на меня – я содрогаюсь! Содрогаюсь от одной мысли. Даниель, умоляю вас, сосредоточьтесь и вникните. В этом списке у нас все животные от глиста до тигра. Здесь – классификация хворей: от гнойников, чирьев, нарывов, жировиков и коросты до ипохондрической болезни, заворота кишок и удушья.
– Удушье – хворь?
– Превосходный вопрос. За дело – и разрешите его! – прогремел Уилкинс.
Даниель тем временем поднял с пола ещё листок.
– «Палка, женило, ствол…»
– Синонимы слов «срамной уд», – нетерпеливо произнёс Уилкинс.
– «Побирушка, голоштанник, христарадник…»
– Синонимы к слову «нищий». В философском языке будет лишь одно слово для срамных удов, одно слово для нищих. Быстро: Даниель, есть ли разница между тем, чтобы стонать и сетовать?
– Я бы сказал, да, но…
– С другой стороны, можно ли объединить под общим названием коленопреклонение и реверанс?
– Я… я не знаю, доктор!
– Тогда, как я говорю, за работу! Сам же я сейчас увяз в бесконечном отступлении по поводу ковчега.
– Который Завета? Или…
– Другой.
– А он здесь при чём?
– Очевидно, в философском языке должно быть по одному и только одному слову для каждого типа животных. Каждое обязано отражать классификацию; как названия жерди и бруса должны быть заметно схожи, так и наименования малиновки и дрозда. При этом птичьи термины не должны походить на рыбьи.
– Замысел представляется мне… э… дерзким.
– Пол Оксфорда шлёт мне нудные перечни. Мое – наше – дело их упорядочить, составить таблицу всех птиц и зверей в мире. В таблицу уже занесены животные, которые досаждают другим животным: блоха, вошь. Предназначенные к дальнейшим метаморфозам: гусеница, личинка. Однорогие панцирные крылатые насекомые. Скорлупчатые конусообразные бескровные твари, и (предвосхищая ваш вопрос) я разделил их на спиральнозавитых и всех прочих. Чешуйчатые речные рыбы, травоядные длиннокрылые птицы, плотоядные котообразные звери – так или иначе, когда я составил все перечни и таблицы, мне стало ясно (возвращаясь к «Книге Бытия», глава шестая, стихи пятнадцатый – двадцать второй), что Ной каким то образом затолкал этих тварей в посудину из дерева гофер длиной триста локтей! Я испугался, что некоторые континентальные учёные, склонные к афеизму , способны злоупотребить моими словами и обратить их в доказательство того, что события, описанные в Книге Бытия, якобы не могли произойти.
– Рискну даже предположить, что некие иезуиты направят их против вас – как свидетельство ваших будто бы афеистических воззрений, доктор Уилкинс.
– Истинная правда, Даниель! Посему совершенно необходимо приложить, отдельной главою, полный план Ноева Ковчега и показать не только, где размещалось каждое животное, но и где хранился фураж для травоядных, где стоял скот для хищников и где хранился фураж, которым кормили жвачных, пока их не съедят хищники.
– Еще нужна была пресная вода, – задумчиво произнёс Даниель.
Уилкинс, который имел обыкновение, говоря, наступать на собеседника, покуда тот не начинал пятиться, схватил кипу бумаг и огрел Даниеля по голове.
– Читайте Библию, неуч! Дождь шёл без остановки!
– Конечно, конечно, они могли пить дождевую воду, – проговорил совершенно раздавленный Даниель.
– Мне пришлось несколько вольно обойтись с мерой «локоть», – заговорщицки поведал Уилкинс, – но я думаю, Ною должно было хватить восьмисот двадцати пяти овец. Я имею в виду, чтобы кормить хищников.
– Овцы занимали целую палубу?!
– Дело не в пространстве, которое они занимали, а в навозе, который надо было выгребать за борт – представьте, какая это работа!… Так или иначе, вы понимаете, что история с Ковчегом надолго застопорила создание философского языка. А вас я попрошу перейти к оскорбительным выражениям.
– Сэр!
– Не задевает ли вас, Даниель, когда ваш брат лондонец бросается такими словами, как «гнусный подлец», «жалкое ничтожество», «хитрый пройдоха», «праздный бездельник» или «льстивый угодник»?
– Смотря кто кого так обозвал…
– Попробую проще: «развратная шлюха».
– Это тавтология и потому оскорбляет просвещённый слух.
– «Безмозглый фат».
– Тоже тавтология, как «льстивый угодник» и всё прочее.
– Итак, очевидно, что в философском языке не потребуются отдельные имена прилагательные и существительные для подобных понятий.
– Как вам «грязный неряха»?
– Превосходно! Запишите это, Даниель!
– «Беспутный повеса», «язвительный зубоскал», «вероломный предатель»… – Покуда Даниель продолжал в том же духе, Уилкинс подскочил к конторке, вынул из чернильницы перо, стряхнул избыток чернил и, вложив перо в руку Даниеля, подвёл того к чистому листу.
Итак, за работу. В несколько коротких часов Даниель исчерпал оскорбительные выражения и перешёл к добродетелям (умственным, естественным и христианским), цветам, звукам, вкусам и запахам, занятиям (например, плотничеству, шитью, алхимии) и так далее. Дни проходили за днями. Уилкинсу надоедало, когда Даниель (или кто то ещё) слишком много работает, поэтому они часто устраивали «семинары» и «симпозиумы» на кухне – варили флип из мёда, которым учёных исправно снабжал готический апиарий Рена. Чарльз Комсток, пятнадцатилетний сын их высокородного хозяина, заходил послушать Уилкинса и Гука. Как правило, он приносил с собой письма Королевскому обществу от Гюйгенса, Левенгука, Сваммердама, Спинозы. Нередко в письмах содержались новые понятия, и Даниелю приходилось втискивать их в таблицы философского языка.
Даниель прилежно составлял перечень предметов, которыми человек может владеть (акведуки, дворцы, тележные оси, дверные петли и так далее), когда Уилкинс срочно позвал его вниз. Юноша спустился на первый этаж и увидел, что преподобный держит в руках внушительного вида письмо, а Чарльз Комсток расчищает стол: скатывает в рулоны чертежи Ковчега и расписания кормлений для восьмисот двадцати пяти овец, освобождая место для более важных занятий. Карл II, милостью Божьей король Англии, прислал им письмо.

... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: Неужели?
От: Pavel Dvorkin Россия  
Дата: 11.04.08 11:11
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>>Это справедливо только для русского языка


PD>>Не думаю. Сказав Nickson, мы тем самым уже установили ассоциацию (в уме) с президентом США. Сказав "Richard" — мы не установили.

M>В случае last.fm — это (потенциально) бесконечное количество таких графов потому что, повторюсь, граф
M>

M>Bjork -> Mamut -> Glory Box -> Jaropolk

M>абсолютно равноначен графу
M>[q]
M>Jaropolk -> Glory Box -> Mamut -> Bjork

Ну во-первых, насчет бесконечного числа — это вряд ли возможно. А во-вторых, напомню, речь все же шла о создании АПИ для сайта. А на конкретном сайте иерархия довольно четко прослеживается.

Дело не в равнозначности графов. Теоретически они все равнозначны. А практически всегда есть более важное, и менее важное. Точно так же, как в организации теоретически есть тоже граф сотрудников, а практически есть корень в виде президента и далее по иерархии.

M>Абсолютно равнозначны между собой. Причем Bjork я вообще наугад выбрал. Я мог выбрать "вершиной" абсолютно любой из "узлов" сайта — тэг, пользователя, жанр, исполнителя, произведение, радиостанцию.


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

>О каких графах мы говорим? Их здесь бесконечное количество


Граф один для сайта. Путей много в нем.

M>А если сайт — last.fm?


Честно говоря, не знаю, что это такое.

M>А если сайт — блог?


И что ? Там нет иерархии никакой ? По авторам хоть есть ?

M>Потому что это в общем случае просто невозможно


Я не думаю, что обход дерева (графа) невозможен.


M>Хорошо, как тогда создать граф для, например, вот этого текста. Вот пришел uberGoogle и Универсальным Языком Запросов молвил нечеловечиским голосом: "а дай ка, uberLJ, граф по своим страницам, да так, чтобы понял я, что такая-то и такая-то страница релевантны для поиска 'отдых в Анталии', а такая-то и такая-то нерелевантны"


Еще раз — граф строится для сайта, а не для страниц. Если для этой страницы будет ключевое слово "Анталия", если для родителя будет ключевое слово "отдых" (или у этой будет отдых Анталия — 2 слова), то и найдется.
With best regards
Pavel Dvorkin
Re[25]: Неужели?
От: Mamut Швеция http://dmitriid.com
Дата: 11.04.08 11:43
Оценка:
PD>Ну во-первых, насчет бесконечного числа — это вряд ли возможно. А во-вторых, напомню, речь все же шла о создании АПИ для сайта. А на конкретном сайте иерархия довольно четко прослеживается.

PD>Дело не в равнозначности графов. Теоретически они все равнозначны. А практически всегда есть более важное, и менее важное. Точно так же, как в организации теоретически есть тоже граф сотрудников, а практически есть корень в виде президента и далее по иерархии.



Хорошо. У нас будет граф:
                 last.fm____________________________________________________
                       /       |                 \               \          \
         ________users       artists             songs           tags       genres
         |     |              |    \              |              /   \       |    \
       Mamut Jaropolk      Bjork Portishead     "Glory Box"    best worst   jazz electronica



И между каждым из узлов будут связи с (потенциально) каждым из других узлов. Как это нам поможет?

M>>Абсолютно равнозначны между собой. Причем Bjork я вообще наугад выбрал. Я мог выбрать "вершиной" абсолютно любой из "узлов" сайта — тэг, пользователя, жанр, исполнителя, произведение, радиостанцию.


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


И как он нам поможет?

M>>А если сайт — last.fm?

PD>Честно говоря, не знаю, что это такое.

Советую посмотреть


M>>А если сайт — блог?

PD>И что ? Там нет иерархии никакой ? По авторам хоть есть ?

И как иерархия по авторам позволит нам найти описание отеля в Анталии?

M>>Потому что это в общем случае просто невозможно

PD>Я не думаю, что обход дерева (графа) невозможен.

21 миллион пользователей (потенциально — между каждым из них есть связь)
предположим, что исполнителей на порядок меньше и песен тоже, ну и тэгов. Сотня жанров
Между каждым из этих узлов (потенциально) есть связь. Причем связи часто меняются.

Сколько ресурсов надо будет потратить на генерацию такого графа?


M>>Хорошо, как тогда создать граф для, например, вот этого текста. Вот пришел uberGoogle и Универсальным Языком Запросов молвил нечеловечиским голосом: "а дай ка, uberLJ, граф по своим страницам, да так, чтобы понял я, что такая-то и такая-то страница релевантны для поиска 'отдых в Анталии', а такая-то и такая-то нерелевантны"


PD>Еще раз — граф строится для сайта, а не для страниц. Если для этой страницы будет ключевое слово "Анталия", если для родителя будет ключевое слово "отдых" (или у этой будет отдых Анталия — 2 слова), то и найдется.


Откуда у этих страниц найдутся такие ключевые слова и такие родители?
... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>


dmitriid.comGitHubLinkedIn
Re[26]: Неужели?
От: Pavel Dvorkin Россия  
Дата: 14.04.08 04:40
Оценка: -1
Здравствуйте, Mamut, Вы писали:

PD>>Ну во-первых, насчет бесконечного числа — это вряд ли возможно. А во-вторых, напомню, речь все же шла о создании АПИ для сайта. А на конкретном сайте иерархия довольно четко прослеживается.


PD>>Дело не в равнозначности графов. Теоретически они все равнозначны. А практически всегда есть более важное, и менее важное. Точно так же, как в организации теоретически есть тоже граф сотрудников, а практически есть корень в виде президента и далее по иерархии.



M>Хорошо. У нас будет граф:

M>
M>                 last.fm____________________________________________________
M>                       /       |                 \               \          \
M>         ________users       artists             songs           tags       genres
M>         |     |              |    \              |              /   \       |    \
M>       Mamut Jaropolk      Bjork Portishead     "Glory Box"    best worst   jazz electronica

M>



M>И между каждым из узлов будут связи с (потенциально) каждым из других узлов. Как это нам поможет?


Как нам это поможет для данного случая — не знаю, давай другой пример рассмотрим

www.samsung.ru. Компания довольно приличная по размерам, на ее примере и разберем. Почему на ее примере — просто я недавно купил их микроволновую печь

Идем на Home page (A) Там, увы, flash, ну да ладно.

Продукты Бизнес Поддержка ...

Если подсветить "Продукты " — появляется "Телевизоры" "Аудио" "Видео"...
Если подсветить "Бизнес " — появляется "Системы связи" "Полупроводники" ...

И другие аналогично

Пойдем в "Продукты" (B)

Там Телевизоры
Жидкокристаллические
Плазменные
SlimFit

Бытовая техника
Холодильники
Стиральные машины
Микроволновые печи (C)
...

Пойдем в Микроволновые печи
Соло
Гриль
Супергриль
Конвекция

Пойдем в Гриль (D)
Там модели

Ну все, хватит. Естественно, на других путях будет аналогичное

Итак, страница A, т.е home page. Помещаем туда ключевые слова

продукты товары ... (в общем, все синонимы для продукты)
бизнес промышленность решения ... (все синонимы для бизнес)

и т.д. Под словом "синонимы" я имею в виду не синонимы русского языка в точном смысле этого слова, а просто все и всяческие сходные слова, которые кому бы то ни было придет в голову задать при поиске

Страница B

Телевизоры телики теле "ящики для идиотов"
аудио плееры музцентры "музыкальные центры" хрюкалки
"бытовая техника" быт "домашняя техника"

Страница C

"микроволновая печь" "микроволновка" "духовка"

Страница D

Гриль Спираль

Ну и т.д.

Теперь запрос

Продукты — быт — духовка

ведет нас прямым образом на

http://www.samsung.ru/products/home/microwave/

а запрос

Продукты — быт — духовка — спираль

на

http://www.samsung.ru/products/home/microwave/grille/

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

Продукты — дача — духовка

ввиду отсутствия "дача" приведет к сообщению следующего рода

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

(Шел поиск, споткнулся на "дача". Сделана попытка проверить, не удастся ли найти продолжение поиска, если вместо "дача" подставить что-то из того, что есть. Оказалось успешно. Вот если бы запрос был

Продукты — дача — культиватор

то был бы просто отказ — ну нет у нас культиваторов)

Ну и т.д. Другие варианты сам можешь продумать.

Что здесь нереального ?

Кстати. Не помню где я читал, и не поручусь за точность этого высказывания, но якобы средний человек имеет лексикон всего в 2000 слов (разумеется, знает он больше, но употребляет обычно не более 2000). И какой процент от них имеет смысл в применении к этому сайту ? Сомневаюсь, что более 500-1000 на все страницы, скорее меньше.

О "горизонтальных" ссылках. Конечно, они есть. Но сейчас их можно либо

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

Продукты — дача — духовка — мобила

приведет вас на эту печь, и в ответе будет информация о встроенном мобильнике


А теперь пару слов о LJ и FM.

Напомню, с чего вся эта дискуссия началась. Речь шла о получении чего-то от сайта, размеров, веса и цены. Цены тут точно нет, вместо размера для микровольновки возьмем объем, веса, увы, нет. Так что только объем. Ладно

Если сейчас попытаться получить объем,, то остается только найти не знаю каким способом страницу, например

http://www.samsung.ru/products/home/microwave/grille/ce287mnr/

и парсить ее в надежде, что после слова "Объем" и тире за ним стоит именно объем. Вообще говоря, в этом не больше логики, чем в утверждении, что если на вешалке висит пальто, то его хозяин — тот, кто сейчас ближе всего к этому пальто расположен Если же реализовать то, о чем я говорю, то этот запрос будет выглядеть вполне осмысленно.

Что касется LJ — да, скорее всего там это работать не будет. Во-первых, там иерархия верхнего уровня сделана не на страницах, а на именах сайтов, что за пределами моих рассуждений. Во-вторых, иерархической структуры там нет — блог он и есть блог.

Насчет last.fm — затрудняюсь сказать. Иерархическая структура там просматривается, но удастся ли что-то сделать — сказать не берусь.

Я не утверждаю, что то, что я предлагаю — панацея от всех бед и после этого обычный поиск надо выбросить в корзину. Но этот подход позволил бы организовать этот поиск более "интеллектуальным способом", и, кроме того, делать машинные запросы к сайту, что сейчас практически нереально.

Если кто-то с последним утверждением не согласен — OK, предлагаю построить такой запрос

Дайте объем микроволновой печи ce287mnr.

Сайт как он сейчас есть. Делать может что хотите. Решение должно работать до тех пор, пока эту печь не снимут с производства. Дизайн страницы фирма Самсунг может изменить в любой момент как ей захочется, ни я, ни Вы этого запретить ей не можем.
With best regards
Pavel Dvorkin
Re[27]: Неужели?
От: Mamut Швеция http://dmitriid.com
Дата: 14.04.08 07:51
Оценка:
PD>Напомню, с чего вся эта дискуссия началась. Речь шла о получении чего-то от сайта, размеров, веса и цены. Цены тут точно нет, вместо размера для микровольновки возьмем объем, веса, увы, нет. Так что только объем. Ладно

PD>Если сейчас попытаться получить объем,, то остается только найти не знаю каким способом страницу, например


PD>http://www.samsung.ru/products/home/microwave/grille/ce287mnr/


PD>и парсить ее в надежде, что после слова "Объем" и тире за ним стоит именно объем.


Откуда этот вывод? Кто парсит ссылку? Откуда возникла необходимость парсить ссылку?


PD>Вообще говоря, в этом не больше логики, чем в утверждении, что если на вешалке висит пальто, то его хозяин — тот, кто сейчас ближе всего к этому пальто расположен Если же реализовать то, о чем я говорю, то этот запрос будет выглядеть вполне осмысленно.


Не будет. Ниже.

PD>Я не утверждаю, что то, что я предлагаю — панацея от всех бед и после этого обычный поиск надо выбросить в корзину. Но этот подход позволил бы организовать этот поиск более "интеллектуальным способом", и, кроме того, делать машинные запросы к сайту, что сейчас практически нереально.


Еще раз советую внимательно посмотреть на такую вещь, как API, которая уже давно существует.

Например:
EBay API
Amazon API
Google APIs

Предположения об Универсальном Языке Запросов строятся на неправильных предпосылках:

1. Что граф запросов возможно составить для произвольных данных для любого сайта

Обработка любого запроса — это нетривиальная задача. ПОтому что этот самый Универсальный Язык Запросов кто-то где-то должен обработать. А там, по ту сторону баррикад, у него окажется поисковое пространство порядка 5000 x 5000 x 10000 и все, приплыли.

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

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

Есть сайты, для которых графы создать невозможно (блоги) или слишком сложно, чтобы этим кто-то занимался (last.fm)

3. Что запросы к сайтам сейчас ограничиваются запросами GET, парсингом HTML и URI

Помимо GET есть еще и POST, в котором можно спокойно передавать запрос хоть в таком виде:
<request>
    <primaryRequest>
        elephant
    </primaryRequest>
    <secondaryRequest>
        <prioritizeKey>
            <color>pink</color>
        </prioritizeKey>
    </secondaryReqest>
</request>


и если сайт понимает такой вопрос, то он выведет доступных слонов, отдавая предпочтение розовым. Что, вобщем, ничем не отличается от Универсального Языка Запросов.


Потому что УЯЗ упирается ровно в одно: предастление данныз на сайте. Одно — в виде сайта, а одно — в виде графа. Большинство веб-программистов не знают, что такое MVC, а тут еще графы какие-то



PD>Если кто-то с последним утверждением не согласен — OK, предлагаю построить такой запрос


PD>Дайте объем микроволновой печи ce287mnr.


PD>Сайт как он сейчас есть. Делать может что хотите. Решение должно работать до тех пор, пока эту печь не снимут с производства. Дизайн страницы фирма Самсунг может изменить в любой момент как ей захочется, ни я, ни Вы этого запретить ей не можем.


То, что Самсунг не представляет возможноти сделать такой запрос к своему сайту, никак не изменится с УЯЗ
... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>


dmitriid.comGitHubLinkedIn
Re[28]: Неужели?
От: Pavel Dvorkin Россия  
Дата: 14.04.08 09:16
Оценка:
Здравствуйте, Mamut, Вы писали:

PD>>и парсить ее в надежде, что после слова "Объем" и тире за ним стоит именно объем.


M>Откуда этот вывод? Кто парсит ссылку? Откуда возникла необходимость парсить ссылку?


Парсить не ссылку, конечно, а HTML, полученный по ссылке. Делать так предложил Синклер, к нему и все вопросы.

http://www.rsdn.ru/forum/message/2901089.1.aspx
Автор: Sinclair
Дата: 03.04.08


M>Еще раз советую внимательно посмотреть на такую вещь, как API, которая уже давно существует.


M>Например:

M>EBay API
M>Amazon API
M>Google APIs

Посмотрю, когда будет время.

M>Предположения об Универсальном Языке Запросов строятся на неправильных предпосылках:


M>1. Что граф запросов возможно составить для произвольных данных для любого сайта


Либо ты меня не хочешь понять, либо мы о разном говорим. Я тебе пример с samsung привел. Нет там произвольных данных. Какие именно данные я предложил внести — я указал конкретно. Там сотни 2-3 слов будет, ну пусть 5

M>Обработка любого запроса — это нетривиальная задача. ПОтому что этот самый Универсальный Язык Запросов кто-то где-то должен обработать. А там, по ту сторону баррикад, у него окажется поисковое пространство порядка 5000 x 5000 x 10000 и все, приплыли.


Чего ? Это с какой стати-то ? Там сидит дерево, которое я описал, в деталях. Высота этого дерева 5-6. Ширина 6-8. В каждом узле пусть будет 30-50 синонимов. Что за проблема пройти один путь в этом дереве, какие тут миллиарды. ?

Вот возьми и нарисуй то дерево, что я привел. И сразу все поймешь.

M>В итоге любой неправильный запрос бдет программистом сайта просто отсекаться и никаких "вот для дачи у нас нет, посмотрите вот такие" не будет.


Хорошо. Я привел примеры того, что будет давать результат. Приведи пример запроса, на который ответа не будет. Просьба остаться в пределах микроволновых печей, так как времени изучать весь сайт у меня нет.

M>2. Что любой сайт с легкостью сможет построить и предоставить граф для произвольного запроса для своих данных


А чего тут строить-то ? Я же сказал — это ключевые слова. А запрос идет по внутренней логической структуре сайта. Она тут вполне очевидна и я ее описал.

M>Есть сайты, для которых графы создать невозможно (блоги) или слишком сложно, чтобы этим кто-то занимался (last.fm)


Есть! Я не панацею предложил, уже сказал. Но по совести — что ты там за запросы к блогу устраивать собираешься ?

M>3. Что запросы к сайтам сейчас ограничиваются запросами GET, парсингом HTML и URI

M>Помимо GET есть еще и POST, в котором можно спокойно передавать запрос хоть в таком виде:
M>
M><request>
M>    <primaryRequest>
M>        elephant
M>    </primaryRequest>
M>    <secondaryRequest>
M>        <prioritizeKey>
M>            <color>pink</color>
M>        </prioritizeKey>
M>    </secondaryReqest>
M></request>
M>


Ну и прекрасно. Только объясни, как такой запрос из броузера послать. Как с помощью какого-нибудь WebClient — я понимаю, а вот как с помощью броузера — нет.

Дано — запущен IE, в нем about:blank
Надо — послать на сайт a.com такой вот POST запрос (см выше твой XML). Просто послать на сайт по 80. Кто и как там ответит — неважно.
Решение ?

M>и если сайт понимает такой вопрос, то он выведет доступных слонов, отдавая предпочтение розовым. Что, вобщем, ничем не отличается от Универсального Языка Запросов.


Это и будет УЯЗ. За термины я драться не буду. Фактически мы пришли к согласию, остается только конретизировать правила написания этого XML !


M>Потому что УЯЗ упирается ровно в одно: предастление данныз на сайте. Одно — в виде сайта, а одно — в виде графа. Большинство веб-программистов не знают, что такое MVC, а тут еще графы какие-то


Вот в это могу поверить. Не обижайся, но действительно для многих web-программистов MVC и т.д. — вершина того, что они в состоянии освоить. Не хочу обсуждать, почему это так. Само по себе это действительно серьезно, потому что идет какая-то волна примитивизации программирования, отчего мне порой и забавно смотреть, как люди серьезно обсуждают проблемы, яйца выеденного не стоящие. Но это не причина, чтобы отвергать идею.

M>То, что Самсунг не представляет возможноти сделать такой запрос к своему сайту, никак не изменится с УЯЗ


Если бы то, о чем я писал, было реализовано, это было бы легко возможно.
With best regards
Pavel Dvorkin
Re[29]: Неужели?
От: Mamut Швеция http://dmitriid.com
Дата: 14.04.08 09:47
Оценка:
M>>Откуда этот вывод? Кто парсит ссылку? Откуда возникла необходимость парсить ссылку?

PD>Парсить не ссылку, конечно, а HTML, полученный по ссылке. Делать так предложил Синклер, к нему и все вопросы.


PD>http://www.rsdn.ru/forum/message/2901089.1.aspx
Автор: Sinclair
Дата: 03.04.08


Много раз было сказано, что это — крайний случай.

M>>Предположения об Универсальном Языке Запросов строятся на неправильных предпосылках:


M>>1. Что граф запросов возможно составить для произвольных данных для любого сайта


PD>Либо ты меня не хочешь понять, либо мы о разном говорим. Я тебе пример с samsung привел. Нет там произвольных данных. Какие именно данные я предложил внести — я указал конкретно. Там сотни 2-3 слов будет, ну пусть 5


Я же привел контрпример — блоги и last.fm. В одном случае дерева просто не будет, во втором постройка дерева — слишком накладно.

M>>Обработка любого запроса — это нетривиальная задача. ПОтому что этот самый Универсальный Язык Запросов кто-то где-то должен обработать. А там, по ту сторону баррикад, у него окажется поисковое пространство порядка 5000 x 5000 x 10000 и все, приплыли.


PD>Чего ? Это с какой стати-то ? Там сидит дерево, которое я описал, в деталях. Высота этого дерева 5-6. Ширина 6-8. В каждом узле пусть будет 30-50 синонимов. Что за проблема пройти один путь в этом дереве, какие тут миллиарды. ?


PD>Вот возьми и нарисуй то дерево, что я привел. И сразу все поймешь.


Какое дерево?

Если вы хотите слетать из BOS в LAX и обратно через две недели с возвратом через три, так, чтобы было окно в 24 часа перед вылетом в обе стороны, то ограничение возможных полетов (максимум 3 вылета в течение 10 часов) состоит в выборке из примерно 5000 вариантов полета туда и 5000 вариантов полета оттуда. Список этих полетов достигается простым поиском по графу, которые кто угодно может сделать в долб секунды.

Сама проблема состоит в том, что один фиксированный план полета с только двумя вылетами туда/обратно может содерждать более 10 000 комбинаций стоимости, каждая из которых содержит строгие ограничения, которые должны быть сопоставлены с другими стоимостями и полетами. Таким образом область поиска на одно путешествие — 5000 x 5000 x 10000, и наивной программе придется совершать множество вычислений для тго, чтобы проверить все возможности


Все ключевое — во втором абзаце. orbitz.com, о котором идет речь просто не даст никому гулять ни по какому графу.

M>>В итоге любой неправильный запрос бдет программистом сайта просто отсекаться и никаких "вот для дачи у нас нет, посмотрите вот такие" не будет.


PD>Хорошо. Я привел примеры того, что будет давать результат. Приведи пример запроса, на который ответа не будет. Просьба остаться в пределах микроволновых печей, так как времени изучать весь сайт у меня нет.


Цитирую:

Продукты — дача — духовка

ввиду отсутствия "дача" приведет к сообщению следующего рода

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

(Шел поиск, споткнулся на "дача". Сделана попытка проверить, не удастся ли найти продолжение поиска, если вместо "дача" подставить что-то из того, что есть)


В реальном мире все остановится на слове дача.


M>>2. Что любой сайт с легкостью сможет построить и предоставить граф для произвольного запроса для своих данных


PD>А чего тут строить-то ? Я же сказал — это ключевые слова. А запрос идет по внутренней логической структуре сайта. Она тут вполне очевидна и я ее описал.


Нет такого понятия, как "внутренняя логическая структура". Она есть только для сайтов, которые можно уложить в рамки какого-то каталога (оно же дерево оно же граф). Пусть таких сайтов и большинство


M>>Есть сайты, для которых графы создать невозможно (блоги) или слишком сложно, чтобы этим кто-то занимался (last.fm)


PD>Есть! Я не панацею предложил, уже сказал. Но по совести — что ты там за запросы к блогу устраивать собираешься ?



Описание отдыха в Анталии. А что, с точки зрения УЯЗ все хорошо: лето — отдых — анталия. А низзя. Потому-что графа нет. И не может быть

M>>3. Что запросы к сайтам сейчас ограничиваются запросами GET, парсингом HTML и URI

M>>Помимо GET есть еще и POST, в котором можно спокойно передавать запрос хоть в таком виде:
M>>
M>><request>
M>>    <primaryRequest>
M>>        elephant
M>>    </primaryRequest>
M>>    <secondaryRequest>
M>>        <prioritizeKey>
M>>            <color>pink</color>
M>>        </prioritizeKey>
M>>    </secondaryReqest>
M>></request>
M>>


PD>Ну и прекрасно. Только объясни, как такой запрос из броузера послать. Как с помощью какого-нибудь WebClient — я понимаю, а вот как с помощью броузера — нет.


PD>Дано — запущен IE, в нем about:blank

PD>Надо — послать на сайт a.com такой вот POST запрос (см выше твой XML). Просто послать на сайт по 80. Кто и как там ответит — неважно.
PD>Решение ?

Заходим на http://orbitz.com/ и внимательно вдумываемся в то, что происходит при нажатии кнопки Submit.


Некий uberClient так же не сможет с нуля создать какой-либо запрос к чему-либо.


M>>и если сайт понимает такой вопрос, то он выведет доступных слонов, отдавая предпочтение розовым. Что, вобщем, ничем не отличается от Универсального Языка Запросов.


PD>Это и будет УЯЗ. За термины я драться не буду. Фактически мы пришли к согласию, остается только конретизировать правила написания этого XML !


Зачем? Невозможно создать язык, подходящий для всех случаев.


M>>Потому что УЯЗ упирается ровно в одно: предастление данныз на сайте. Одно — в виде сайта, а одно — в виде графа. Большинство веб-программистов не знают, что такое MVC, а тут еще графы какие-то


PD>Вот в это могу поверить. Не обижайся, но действительно для многих web-программистов MVC и т.д. — вершина того, что они в состоянии освоить. Не хочу обсуждать, почему это так. Само по себе это действительно серьезно, потому что идет какая-то волна примитивизации программирования, отчего мне порой и забавно смотреть, как люди серьезно обсуждают проблемы, яйца выеденного не стоящие. Но это не причина, чтобы отвергать идею.



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

Тем более в любом случае любой входящий запрос кто-то как-то должен обрабатывать


M>>То, что Самсунг не представляет возможноти сделать такой запрос к своему сайту, никак не изменится с УЯЗ


PD>Если бы то, о чем я писал, было реализовано, это было бы легко возможно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>


dmitriid.comGitHubLinkedIn
Re[29]: Неужели?
От: Sinclair Россия https://github.com/evilguest/
Дата: 14.04.08 10:54
Оценка: 5 (1) +1
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Парсить не ссылку, конечно, а HTML, полученный по ссылке. Делать так предложил Синклер, к нему и все вопросы.
Павел, я еще раз напоминаю, что это — от безысходности. Если автор веб-приложения не удосужился сделать к нему веб-сервис, то всё, привет, приплыли.
Задача в сделанной тобой постановке неразрешима.
И это никак не связано с вебностью приложений.
Ну вот ты видел когда-нибудь десктопные аналоги сайта самсунга? Сходи в ближайший магазин типа Планета Электрика, возьми компакт-диск с каталогом светильников. И попробуй представить себе приложение, которое вынимает из него, скажем, мощность светильника такой-то модели. Точно так же ты ничего не сможешь сделать, потому что этот каталог скорее всего представляет собой тупо набор картинок, на которых все ТТХ нарисованы. И даже такой тупой и ненадежный анализ, как регексп по html, тебе там будет вовсе недоступен. И точно так же, как и для сайта самсунга, нет никаких шансов, что приложение написанное для каталога 2007 года продолжит работать с каталогом 2008го.

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

PD>Посмотрю, когда будет время.

Ок, давай сменим постановку вопроса. Предположим, что мы с тобой и Мамутом как раз представляем компанию Самсунг, и мы хотим предоставить программный доступ к каталогу товаров нашей компании. Тебя это интересует? Как должен выглядеть API самсунга? Ну так я вроде давал ссылку на книжку про RESTful Web Services.
Там всё написано очень подробно.

M>>3. Что запросы к сайтам сейчас ограничиваются запросами GET, парсингом HTML и URI

M>>Помимо GET есть еще и POST, в котором можно спокойно передавать запрос хоть в таком виде:
M>>
M>><request>
M>>    <primaryRequest>
M>>        elephant
M>>    </primaryRequest>
M>>    <secondaryRequest>
M>>        <prioritizeKey>
M>>            <color>pink</color>
M>>        </prioritizeKey>
M>>    </secondaryReqest>
M>></request>
M>>


PD>Ну и прекрасно. Только объясни, как такой запрос из броузера послать. Как с помощью какого-нибудь WebClient — я понимаю, а вот как с помощью броузера — нет.

Павел, никакой нужды посылать такие запросы из браузера нету. Браузером пользуется человек. Неужели ты не смог найти на сайте самсунга объем выбранной микроволновки? Значит для человека всё уже сделано. Ну, не всё, если почитать книжки Якоба Нильсена, то видно, что хороших сайтов по-прежнему мало. Но все необходимые принципы уже давно сформулированы, все необходимые технические средства есть, остается только применить их на практике.

PD>Дано — запущен IE, в нем about:blank

PD>Надо — послать на сайт a.com такой вот POST запрос (см выше твой XML). Просто послать на сайт по 80. Кто и как там ответит — неважно.
PD>Решение ?
Павел, прекрати заниматься херней. Нет вот этого "надо". Есть две разные задачи:
1. Найти объем микроволновки такой-то модели. Прекрасно решается существующими веб приложениями. Смотреть также: google.com, yandex.ru.

PD>Это и будет УЯЗ. За термины я драться не буду. Фактически мы пришли к согласию, остается только конретизировать правила написания этого XML !

Павел, а вот тут начинается невозможная утопия. Потому, что для самсунга запросы будут одни, а для орбитза — совсем другие. Неужели так трудно понять, что невозможно придумать один язык запросов, который бы подходил и тем и тем?
Еше раз поясняю: для конкретной задачи придется изобретать свой конкретный язык запросов. Есть определенные соображения о том, как этот язык должен быть реализован. В частности, делать один endpoint, в который пихается разнообразный XML, и который возвращает произвольный XML — плохая идея. Математически это, конечно, полностью эквивалентно любому другому API, но с точки зрения практики есть масса соображений, по которым RPC-style сосет, а Resource-oriented style рулит.

M>>То, что Самсунг не представляет возможноти сделать такой запрос к своему сайту, никак не изменится с УЯЗ

PD>Если бы то, о чем я писал, было реализовано, это было бы легко возможно.
Рекомендую посмотреть на то, что уже есть. Ссылки на API тебе давали. Самсунг — не очень хороший пример. Посмотри Амазон.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[30]: Неужели?
От: Pavel Dvorkin Россия  
Дата: 14.04.08 12:30
Оценка:
Здравствуйте, Mamut, Вы писали:

PD>>Вот возьми и нарисуй то дерево, что я привел. И сразу все поймешь.


M>Какое дерево?


Дерево сайта samsung.


PD>>Хорошо. Я привел примеры того, что будет давать результат. Приведи пример запроса, на который ответа не будет. Просьба остаться в пределах микроволновых печей, так как времени изучать весь сайт у меня нет.


M>Цитирую:

M>

M>Продукты — дача — духовка

M>ввиду отсутствия "дача" приведет к сообщению следующего рода

M>"К сожалению, мы не имеем духовок, специально предназначенных для дач. Однако в нашем ассортименте имеется большое количество духовок для бытового применения. Не хотите ли посмотреть имеющийся ассортимент ?"

M>(Шел поиск, споткнулся на "дача". Сделана попытка проверить, не удастся ли найти продолжение поиска, если вместо "дача" подставить что-то из того, что есть)


M>В реальном мире все остановится на слове дача.


Я не знаю, что понимается под реальным миром, но если в программе поиск в одном из узлов на уровне N заканчивается неудачей, а у нас есть еще данные на уровне N+1, то никто не мешает проверить, нельзя ли найти это слово с уровня N+1, если пройти по все вариантам уровня N

Уровень N — бытовая быт домашняя
Уровень N+1 духовка

Ищем на уровне N "дача", N+1 — духовка. Нет дачи на уровне N. Ищем духовку на уровне N+1. Есть она там. Значит, духовка есть, но не для дачи.


M>Нет такого понятия, как "внутренняя логическая структура". Она есть только для сайтов, которые можно уложить в рамки какого-то каталога (оно же дерево оно же граф). Пусть таких сайтов и большинство


Ну и прекрасно. Пусть для большинства это и получится.


M>Описание отдыха в Анталии. А что, с точки зрения УЯЗ все хорошо: лето — отдых — анталия. А низзя. Потому-что графа нет. И не может быть


От лето — скорее всего нет. А вот от страны — есть. Могу попробовать на примере какого-нибудь сайта туроператора прокрутить. Не сегодня.

PD>>Дано — запущен IE, в нем about:blank

PD>>Надо — послать на сайт a.com такой вот POST запрос (см выше твой XML). Просто послать на сайт по 80. Кто и как там ответит — неважно.
PD>>Решение ?

M>Заходим на http://orbitz.com/ и внимательно вдумываемся в то, что происходит при нажатии кнопки Submit.


Еще раз поясняю. Никуда не заходим. Надо просто сделать XML и сразу его послать. И никаких других обращений.


M>Некий uberClient так же не сможет с нуля создать какой-либо запрос к чему-либо.


А вот это неясно почему. Что, так нельзя ?

client.Method = "POST";
client.Text = XMLText;
client.URL = "a.com";
client.Send();



PD>>Это и будет УЯЗ. За термины я драться не буду. Фактически мы пришли к согласию, остается только конретизировать правила написания этого XML !


M>Зачем? Невозможно создать язык, подходящий для всех случаев.


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


M>В этой идее нет особого смысла. Можно как-то автоматизировать создание некоего графа для каких-то простых сайтов. Но только сайт становится чуть сложнее, как все, приплыли


Ну тогда поясни, что такое может измениться на samsung.ru, чтобы мы приплыли.

M>Тем более в любом случае любой входящий запрос кто-то как-то должен обрабатывать


Еще бы!
With best regards
Pavel Dvorkin
Re[30]: Неужели?
От: Pavel Dvorkin Россия  
Дата: 14.04.08 12:45
Оценка: -2
Здравствуйте, Sinclair, Вы писали:

Вообще-то я решил тебе не отвечать, но сделаю здесь исключение.

S>Павел, я еще раз напоминаю, что это — от безысходности. Если автор веб-приложения не удосужился сделать к нему веб-сервис, то всё, привет, приплыли.


Ну тогда приплыли вообще. Можно поинтересоваться насчет web-сервисов www.samsung.com, www.microsoft.com, www.ibm.com и далее, реализующих эту функциональность ? То. что какие-то другие сервисы там могут быть — к делу не относится.

Так что если из этого исходить — приплыли, да


S>Задача в сделанной тобой постановке неразрешима.


Доказательство. Так сказал Синклер, и выделил это жирным шрифтом.

S>Ну вот ты видел когда-нибудь десктопные аналоги сайта самсунга? Сходи в ближайший магазин типа Планета Электрика, возьми компакт-диск с каталогом светильников. И попробуй представить себе приложение, которое вынимает из него, скажем, мощность светильника такой-то модели. Точно так же ты ничего не сможешь сделать, потому что этот каталог скорее всего представляет собой тупо набор картинок, на которых все ТТХ нарисованы. И даже такой тупой и ненадежный анализ, как регексп по html, тебе там будет вовсе недоступен. И точно так же, как и для сайта самсунга, нет никаких шансов, что приложение написанное для каталога 2007 года продолжит работать с каталогом 2008го.


Ну если уж ты к таким аргументам начал прибегать — дело совсем твое плохо. То ты мне битый час доказывал, как прекрасно regex вытащит все данные из страницы. А теперь, оказывается. то, что это все же не получится, мотивируется тем, что и для десктопных приложений этого, мол, нет. Аргументация, однако...

S>Поэтому предлагаю прекратить расход умственной энергии на переливание из пустого в порожнее, связанное с решением вопроса "как мне получить данные вопреки желанию их обладателя" .


Предлагаю всем, кому не нравится обсуждение этой темы, просто не читать эти постинги.

Все остальное поскипано. По одной простой причине. Мамут со мной не согласен, но он пытается меня понять. А ты просто знаешь истину в последней инстанции и вещаешь ее. А понять не хочешь. Чего хотя бы это стоит

S>Павел, а вот тут начинается невозможная утопия. Потому, что для самсунга запросы будут одни, а для орбитза — совсем другие. Неужели так трудно понять, что невозможно придумать один язык запросов, который бы подходил и тем и тем?

Еше раз поясняю: для конкретной задачи придется изобретать свой конкретный язык запросов.

Ты хоть об одном бы подумал. Ведь то, о чем я говорю (черт с ними, с сайтами) есть (упрощая) язык запросов к иерархической БД[/b]. Это ты понимаешь или нет ? Язык запросов к реляционной БД существует и от того, что в БД — не зависит. А ты утверждаешь, что язык запросов к иерархической БД создать невозможно, потому как он будет зависеть, видите ли, от того, что в БД. Действительно приплыли.
With best regards
Pavel Dvorkin
Re[31]: Неужели?
От: Mamut Швеция http://dmitriid.com
Дата: 14.04.08 12:51
Оценка:
PD>>>Хорошо. Я привел примеры того, что будет давать результат. Приведи пример запроса, на который ответа не будет. Просьба остаться в пределах микроволновых печей, так как времени изучать весь сайт у меня нет.

M>>Цитирую:

M>>

M>>Продукты — дача — духовка

M>>ввиду отсутствия "дача" приведет к сообщению следующего рода

M>>"К сожалению, мы не имеем духовок, специально предназначенных для дач. Однако в нашем ассортименте имеется большое количество духовок для бытового применения. Не хотите ли посмотреть имеющийся ассортимент ?"

M>>(Шел поиск, споткнулся на "дача". Сделана попытка проверить, не удастся ли найти продолжение поиска, если вместо "дача" подставить что-то из того, что есть)


M>>В реальном мире все остановится на слове дача.


PD>Я не знаю, что понимается под реальным миром, но если в программе поиск в одном из узлов на уровне N заканчивается неудачей, а у нас есть еще данные на уровне N+1, то никто не мешает проверить, нельзя ли найти это слово с уровня N+1, если пройти по все вариантам уровня N


PD>Уровень N — бытовая быт домашняя

PD>Уровень N+1 духовка

PD>Ищем на уровне N "дача", N+1 — духовка. Нет дачи на уровне N. Ищем духовку на уровне N+1. Есть она там. Значит, духовка есть, но не для дачи.



Это сработает для ограниченного числа сайтов. И то, только тех, кто этот граф предоставит. Причем запрос типа "объем духовки" все равно не получится, если тот же самсунг остановится на уровне N, духовка.


M>>Описание отдыха в Анталии. А что, с точки зрения УЯЗ все хорошо: лето — отдых — анталия. А низзя. Потому-что графа нет. И не может быть


PD>От лето — скорее всего нет. А вот от страны — есть. Могу попробовать на примере какого-нибудь сайта туроператора прокрутить. Не сегодня.


Почему туроператора Мы в этой секции о блогах говорили и о том, какие запросы к ним можно будет задать

PD>>>Дано — запущен IE, в нем about:blank

PD>>>Надо — послать на сайт a.com такой вот POST запрос (см выше твой XML). Просто послать на сайт по 80. Кто и как там ответит — неважно.
PD>>>Решение ?

M>>Заходим на http://orbitz.com/ и внимательно вдумываемся в то, что происходит при нажатии кнопки Submit.


PD>Еще раз поясняю. Никуда не заходим. Надо просто сделать XML и сразу его послать. И никаких других обращений.


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

Кто будет просто делать XML и сразу его отсылать? Гномы с эльфами?

M>>Некий uberClient так же не сможет с нуля создать какой-либо запрос к чему-либо.


PD>А вот это неясно почему. Что, так нельзя ?


PD>client.Method = "POST";

PD>client.Text = XMLText;
PD>client.URL = "a.com";
PD>client.Send();


Кто это будет писать и вбивать? Пользователь? Нет. Тогда пользователю можно пойти на сайт и нажать на кнопочку Submit.

Некий код? Тогда если сайт не пердоставляет АПИ к своим услугам сейчас, что зхаставит его предоставлять граф потом?



PD>>>Это и будет УЯЗ. За термины я драться не буду. Фактически мы пришли к согласию, остается только конретизировать правила написания этого XML !


M>>Зачем? Невозможно создать язык, подходящий для всех случаев.


PD>Ну мы по второму кругу пошли. Если уж на то пошло, есть язык, подходящий для всех случаев, только он не иерархические запросы делает, а реляционные


На самом деле в SQL есть свои проблемы. И панацеей он тоже не является

M>>В этой идее нет особого смысла. Можно как-то автоматизировать создание некоего графа для каких-то простых сайтов. Но только сайт становится чуть сложнее, как все, приплыли


PD>Ну тогда поясни, что такое может измениться на samsung.ru, чтобы мы приплыли.


Ему достаточно стать чем-то вроде youtube/lj/last.fm

С самсунгом легче, унего, в принципе, все каталогизировано. Но!

/продукты/домашние/духовка...

И? Насколько детальный этот граф будет? Что бдет после духовки?
/размер
/объем
/цвет

??


M>>Тем более в любом случае любой входящий запрос кто-то как-то должен обрабатывать


PD>Еще бы!


Ну так как это отличается от существующе ситуации?
... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>


dmitriid.comGitHubLinkedIn
Re[32]: Неужели?
От: Pavel Dvorkin Россия  
Дата: 14.04.08 13:26
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Это сработает для ограниченного числа сайтов. И то, только тех, кто этот граф предоставит.


Ну пусть ограниченного. И конечно, для тех, кто этот запрос будет таким образом обрабатывать. Это само собой.

>Причем запрос типа "объем духовки" все равно не получится, если тот же самсунг остановится на уровне N, духовка.


А пусть не останавливается. Это уже вопрос к администрации сайта — что там должно быть.


M>Почему туроператора Мы в этой секции о блогах говорили и о том, какие запросы к ним можно будет задать


К блогам — я уже сказал, скорее всего ничего. Но к сайтам компаний — очень даже может быть.

PD>>Еще раз поясняю. Никуда не заходим. Надо просто сделать XML и сразу его послать. И никаких других обращений.


M>Ага, в том самом абстрактном клиенте, которые с этим мегаязыком будет работать тоже никакого интерфейса и кнопочек не бдет?

M>Кто будет просто делать XML и сразу его отсылать? Гномы с эльфами?

Нет, почему. Делаем клиент с URL строкой, XML редактором (для начала, потом лучше с построителем дерева) и кнопкой Submit . В URL набираем имя сайта, а редакторе XML. И нажимаем Submit. Это возможно ?


M>Кто это будет писать и вбивать? Пользователь? Нет. Тогда пользователю можно пойти на сайт и нажать на кнопочку Submit.


См. выше.

M>Некий код? Тогда если сайт не пердоставляет АПИ к своим услугам сейчас, что зхаставит его предоставлять граф потом?


Дмитрий, ну сколько же можно ? Конечно, этого нет. Конечно, это делать придется. Никто не заставляет. Равно как никто не заставляет делать поиск и т.д. Если бы такое принято было бы — делали бы, хоть и не заставляют.

PD>>Ну мы по второму кругу пошли. Если уж на то пошло, есть язык, подходящий для всех случаев, только он не иерархические запросы делает, а реляционные


M>На самом деле в SQL есть свои проблемы. И панацеей он тоже не является


Ну и на здоровье. Пусть и у этого подхода будут проблемы. А насчет того. что он не панацея — я уже раза 3 повторил.

PD>>Ну тогда поясни, что такое может измениться на samsung.ru, чтобы мы приплыли.


M>Ему достаточно стать чем-то вроде youtube/lj/last.fm


Я так думаю, что он им никогда не станет, посколько в фирме Самсунг все же здравомыслящие люди сидят.

M>С самсунгом легче, унего, в принципе, все каталогизировано. Но!


M>/продукты/домашние/духовка...


M>И? Насколько детальный этот граф будет? Что бдет после духовки?

M>/размер
M>/объем
M>/цвет

Да. Объем там есть. Могли бы быть цвет, размер, цена и т.д.

M>>>Тем более в любом случае любой входящий запрос кто-то как-то должен обрабатывать


PD>>Еще бы!


M>Ну так как это отличается от существующе ситуации?


Отличается только одним — таких иерархических запросов сайты не поддерживают
With best regards
Pavel Dvorkin
Re[33]: Неужели?
От: Mamut Швеция http://dmitriid.com
Дата: 14.04.08 14:37
Оценка: 10 (1) +3
>>Причем запрос типа "объем духовки" все равно не получится, если тот же самсунг остановится на уровне N, духовка.

PD>А пусть не останавливается. Это уже вопрос к администрации сайта — что там должно быть.


То есть в принципе, ровным счетом ничего не изменилось Ну, по сравнению с текущей ситуацией

Более того, граф люьбого сайта может сильно изменяться от того, что мы думае о сайте. То есть мы думаем так:
Samsung - домашние товары - духовка
                          - стиралка
                          
        - промышленные товары - морозилка
                              - печь

А у Самсунга это на самом деле может быть
Samsung - духовка - домашняя
                  - промышленная
                  
        - морозилка - домашняя
                    - промышленная

или даже (по моделям продуктов)
Samsung - D - K - 500
                - 600
                
            - S - 400
                - 200
                
        - A - P - 620


И никто в жизни не сможет создать нормальный запрос к этому сайту Ну если только не заниматься его reverse enginerring'ом

Это при том, что мы даже еще не поределили, где здесь объем духовки — нам бы саму духовку найти!

Samsung - D - K - 500 - 100
                      - 200
                      - 300
                      - 1300


Предположим, что этот граф — это граф домашней духовки, в которой ширина x длина х глубина — 100 x 200 x 300 (в миллиметрах) и объем — 1300 (в кубических сантиметрах)

Но почему именно миллиметры? Почему именно кубические сантиметры? ПОчему все это — не стоимость различных моделей?

Придется вводить ключевые универсальные слова? На все области человеческой деятельности не напасешься. И никто в здравом уме не будет делать реализацию, поддерживающую этот словарь полностью.

А как с единицами измерения? Их много. Или ограничится какими-то основными и переизобрести XML-RPC?

PD>>>Еще раз поясняю. Никуда не заходим. Надо просто сделать XML и сразу его послать. И никаких других обращений.


M>>Ага, в том самом абстрактном клиенте, которые с этим мегаязыком будет работать тоже никакого интерфейса и кнопочек не бдет?

M>>Кто будет просто делать XML и сразу его отсылать? Гномы с эльфами?

PD>Нет, почему. Делаем клиент с URL строкой, XML редактором (для начала, потом лучше с построителем дерева) и кнопкой Submit . В URL набираем имя сайта, а редакторе XML. И нажимаем Submit. Это возможно ?


Зачем? Чем это будет отличаться от веб-страницы с точно таким же УРЛ и точно такой же кнопочкой?

Кстати, кто будет редактировать этот XML? Пользователь. Нет, увольте Интерфейс построения запросов это вообзе отдельная интересная песня. Причем для большинства задач решеная как на десктопе так и на вебе:

У нас есть форма, которую пользователь заполняет, нажимает на кнопку, а что дальше с данными происходит его не волнует.

Более того, автоматически этот интерфейс сделать просто невозможно. Потому что
Samsung - D - K - 500 - 100
                      - 200
                      - 300
                      - 1300


это совсем не то, что
Daewoo - Appliances - Home - Microwaves - M-100 - 1000 cm3
                                                - 1200 cm3
                                          M-200 - 1250 cm3
                                          M-250 - 1250 cm3
                                                - 1300 cm3


Но при этом и то и другое ведут нас к тому, что нужно — домашней микроволновке объемом 1300 кубических сантиметров


M>>Некий код? Тогда если сайт не пердоставляет АПИ к своим услугам сейчас, что зхаставит его предоставлять граф потом?


PD>Дмитрий, ну сколько же можно ? Конечно, этого нет. Конечно, это делать придется. Никто не заставляет. Равно как никто не заставляет делать поиск и т.д. Если бы такое принято было бы — делали бы, хоть и не заставляют.


Так оно давно принято, да никто не делает

Это и различные микроформаты, и протоколы, и спецификации. А все равно никто ничего не делает

Хотя RDF, насколько я знаю, где-то теплится (во всяком случае FOAF упоминается в LiveJournal'е)

M>>>>Тем более в любом случае любой входящий запрос кто-то как-то должен обрабатывать


PD>>>Еще бы!


M>>Ну так как это отличается от существующе ситуации?


PD>Отличается только одним — таких иерархических запросов сайты не поддерживают


Иерархические запросы, теоретически, это, навреное, неплохо. Но реверс инжинирить каждый сайт? Да и зачем, если есть Гугл
... << RSDN@Home 1.2.0 alpha 4 rev. 1064>>


dmitriid.comGitHubLinkedIn
Re[31]: Неужели?
От: WFrag США  
Дата: 14.04.08 15:51
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Все остальное поскипано. По одной простой причине. Мамут со мной не согласен, но он пытается меня понять. А ты просто знаешь истину в последней инстанции и вещаешь ее. А понять не хочешь. Чего хотя бы это стоит


Что-то мне подсказывает, что ты даже оглавление книжки не посмотрел, на которую Sinclair ссылался. Это к слову об аргументации и воспринятии оной.
Re[31]: Неужели?
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.04.08 03:58
Оценка: 26 (4) +1
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Вообще-то я решил тебе не отвечать, но сделаю здесь исключение.
Спасибо.
PD>Ну тогда приплыли вообще. Можно поинтересоваться насчет web-сервисов www.samsung.com, www.microsoft.com, www.ibm.com и далее, реализующих эту функциональность ? То. что какие-то другие сервисы там могут быть — к делу не относится.
"Эту" — я полагаю, что речь идет о каталоге товаров? Нет, у этих товарищей ничего похожего нет. Надо полагать, не считают нужным публиковать такую функциональность. В связи, скорее всего, с отсутствием платежеспособного спроса.
PD>Так что если из этого исходить — приплыли, да
Совершенно верно.
S>>Задача в сделанной тобой постановке неразрешима.
PD>Доказательство. Так сказал Синклер, и выделил это жирным шрифтом.
Гм. А что тут нужно доказывать? Ты попросил решение, которое будет надежно работать несмотря ни на какие изменения структуры сайта. Теорема 1: для любого решения можно придумать такое изменение структуры, которое сделает решение неработоспособным. Доказательство полностью приводить, или и так понятно?


PD>Ну если уж ты к таким аргументам начал прибегать — дело совсем твое плохо. То ты мне битый час доказывал, как прекрасно regex вытащит все данные из страницы. А теперь, оказывается. то, что это все же не получится, мотивируется тем, что и для десктопных приложений этого, мол, нет. Аргументация, однако...

Павел, постарайся читать то, что я пишу. Напомню еще раз утверждение, которое я иллюстрировал десктопным приложением:

И это никак не связано с вебностью приложений.

Что здесь непонятно?

S>>Поэтому предлагаю прекратить расход умственной энергии на переливание из пустого в порожнее, связанное с решением вопроса "как мне получить данные вопреки желанию их обладателя" .

PD>Предлагаю всем, кому не нравится обсуждение этой темы, просто не читать эти постинги.

PD>Все остальное поскипано. По одной простой причине. Мамут со мной не согласен, но он пытается меня понять. А ты просто знаешь истину в последней инстанции и вещаешь ее.

PD>А понять не хочешь.
Оффтоп
Я хочу понять. Но ты максимально затрудняешь эту задачу. Вместо того, чтобы внятно описать весь workflow в виде, не допускающем разночтения, ты всё время ставишь какие-то непонятные задания. Это, наверное, привычка преподавателя — ничего не рассказывать, а заставлять всех самих догадываться?
Я не знаю истину в последней инстанции. Я просто пишу то, что думаю. Ок, я мог бы везде отвечать вопросом на вопрос.
Но вопросы ты тоже не любишь — когда я спрашиваю банальные вещи вроде поддержки кэширования (которая обеспечивает масштабируемость системы и определяет пригодность архитектуры к реальной работе в распределенной среде), ты начинаешь обижаться и убегать.

Я вообще достаточно хорошо всё понимаю. У меня специфика работы такая: значительную часть последних десяти лет я провел, пытаясь понять вопросы и утверждения, сформулированные в самых разнообразных видах, начиная от скана карандашного рисунка салфетки, и заканчивая детальной спецификацией веб-сервиса на бразильском португальском.

А вот ты почему-то предпочитаешь просто игнорировать всё, что тебе непонятно. Конец оффтопа.

PD> Чего хотя бы это стоит


S>>Павел, а вот тут начинается невозможная утопия. Потому, что для самсунга запросы будут одни, а для орбитза — совсем другие. Неужели так трудно понять, что невозможно придумать один язык запросов, который бы подходил и тем и тем?

PD>Еше раз поясняю: для конкретной задачи придется изобретать свой конкретный язык запросов.
Ну ты только что согласился с разработкой универсального языка запросов. Если бы ты меньше усилий тратил на критику моей манеры изложения очевидных истин и непрозрачные намеки непонятно на что, а больше тратил на внятное изложение своей позиции, то всем участникам дискуссии было бы легче.

PD>Ты хоть об одном бы подумал. Ведь то, о чем я говорю (черт с ними, с сайтами) есть (упрощая) язык запросов к иерархической БД[/b]. Это ты понимаешь или нет ?

Это я понимаю.
PD>Язык запросов к реляционной БД существует и от того, что в БД — не зависит.
Ок, движемся в конструктивную сторону. Педантично уточню, что
а) сам по себе язык запросов недостаточен для построения запросов. Для того, чтобы сделать запрос, нужно знать структуру и семантику конкретной БД. Банальное переименование колонки способно сделать твой запрос невалидным, и ни одна СУБД не станет заниматься "исправлением" ошибок.

б) если ты про SQL, то речь идет не об одном языке, а о целом семействе языков, объединенных похожим синтаксисом. Каждая СУБД использует свой диалект, который отличается от других в достаточной степени, чтобы запрос к одной не подошел к другой. И это не второстепенные детали, а суровая реальность, в которой приходится жить разработчикам.

в) язык SQL не является вычислительно полным. Особенности диалектов как раз и касаются расширений в различных областях:
— в скалярной математике. Банального возведения в степень в ANSI SQL нет
— в реляционных операциях. Классическая реляционная алгебра не позволяет, к примеру, описывать запросы с "бесконечным" количеством Join, что необходимо для некоторых алгоритмов на графах
Без этих расширений невозможно реализовать определенные запросы даже к тем данным, которые вообще удалось разместить в реляционной БД.

г) реляционная модель не является полной. Существует огромный класс приложений, данные которых невозможно адекватно отразить в БД.

Это так, к вопросу о всеобщей применимости SQL.

PD>А ты утверждаешь, что язык запросов к иерархической БД создать невозможно, потому как он будет зависеть, видите ли, от того, что в БД. Действительно приплыли.


Нет. Я утверждаю, что такой язык не будет иметь практической применимости. Это разные вещи.

Ну вот тебя не смущает то, что почему-то никто не делает веб-сервисов, которые бы принимали, к примеру, SQL, и возвращали таблицы? Ведь язык есть, и существует очень давно.
Лично меня смущает, и я полагаю, что причина в том, что SQL плохо подходит для распределенной среды, когда у нас нет гарантии одновременного обновления клиента и сервера.
Может быть, структура реальных корпоративных данных плохо ложится на таблицы, а на самом деле используются деревья?
Ок, есть XPath, на котором проще описывать запросы к древовидным данным. Тем не менее, почему-то не принято делать веб-сервисы, которые бы давали исполнить XPath и возвращали NodeSet.

Есть определенные причины, по которым такие модели не добились успеха. Вместо них успеха добиваются совсем другие модели. Грубо говоря, язык запросов сейчас — HTTP.
Точно так же, как с SQL, клиенту нужно откуда-то получить знания о том, какие запросы на этом языке можно делать к данному сервису, а какие — нельзя.
Понятно, что сам по себе HTTP чрезмерно выразителен для того, чтобы как-то применять его на практике. Авторы реальных веб-сервисов принимают множество решений о том, насколько широким будет класс поддерживаемых ими запросов, и какими техническими подробностями он будет обеспечен.

Сейчас на практике набор поддерживаемых запросов искусственно сужен. К примеру, сайты, посвященные авиаперелетам, не пытаются дать тебе полный язык запросов к направленным графам. Конечно, на таком языке можно было бы сформулировать запрос "дайте мне самый дешевый перелет Омск-Мехико-Омск на такие-то даты", а также еще очень много запросов. Вместо этого они позволяют тебе выполнить, грубо говоря, ровно один запрос с параметрами: дайте мне самый дешевый перелет <А>-<B>-<A> на даты <С> и <D>.
(Я намеренно упрощаю. Под "ровно 1" имеется в виду О(1) типов запросов")

Казалось бы, это несправедливо, прямо-таки апартеид. Почему эти запросы лучше, чем другие?
Да потому, что
а) эти запросы наиболее востребованы.
Значит, заставлять клиента писать полное выражение на расширенном языке реляционной алгебры, рискуя сделать ошибку, будет не очень хорошо. Клиенту удобнее сообщить системе необходимый минимум информации.
Значит, если мы поддерживаем, допустим, четыре типа запросов, то они покрывают 92% всех потребностей. Ок, добавим пятый, и получим покрытие 99%. Остальные миллионы потенциальных запросов не принесут нам пользы, потому что нужны только редким отморозкам.
б) Эти запросы мы внимательно изучаем и оптимизируем систему так, чтобы она их эффективно выполняла.
Это очень серъезная штука. Современные веб-приложения ворочают большими объемами данных, и работают с нагрузкой, которую трудно представить программисту семидесятых.
Науке неизвестны техники оптимизации, которые бы могли дать достаточно приемлемую верхнюю оценку для стоимости произвольного запроса.
Дай мне доступ к любой базе на СУБД из первой десятки tpc-c — и я положу ее в DoS банальным select запросом.

Итого: вместо того, чтобы придумывать 1 язык, который позволяет сделать, скажем, 100 типов запросов и применять его на 10 сервисах, люди делают 10 разных языков, каждый из которых заточен на конкретные десять запросов. Это снижает затраты как клиента, так и сервиса.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[34]: Неужели?
От: Pavel Dvorkin Россия  
Дата: 15.04.08 04:25
Оценка:
Здравствуйте, Mamut, Вы писали:

M>Более того, граф люьбого сайта может сильно изменяться от того, что мы думае о сайте. То есть мы думаем так:


<skipped>

То, что ты написал, и верно, и нет. Верно — в том плане, что путей может быть много и пути, заложенные Самсунгом , могут отличаться от того, что мы думаем. Но вот тут уже вопрос к разработчикам Самсунга — они должны просто предусмотреть те пути, которые пользователь может придумать. Не все, это невозможно. Но основные можно.


M>Но почему именно миллиметры? Почему именно кубические сантиметры? ПОчему все это — не стоимость различных моделей?


Что за проблема, не понимаю. В запросе указывается value="1000" unit="mm" и все.

M>Придется вводить ключевые универсальные слова? На все области человеческой деятельности не напасешься. И никто в здравом уме не будет делать реализацию, поддерживающую этот словарь полностью.


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

M>А как с единицами измерения? Их много.


См. выше. Что-то я не пойму — зачем ты на ровном месте проблемы создаешь. Достаточно указать единицу измерения и все.

PD>>Нет, почему. Делаем клиент с URL строкой, XML редактором (для начала, потом лучше с построителем дерева) и кнопкой Submit . В URL набираем имя сайта, а редакторе XML. И нажимаем Submit. Это возможно ?


M>Зачем? Чем это будет отличаться от веб-страницы с точно таким же УРЛ и точно такой же кнопочкой?


Тогда пошли этот запрос с web-страницы. Я же тебя просил дать мне способ из броузера c about:blank набрать и послать по POST некий XML на некий URL.

M>Иерархические запросы, теоретически, это, навреное, неплохо. Но реверс инжинирить каждый сайт? Да и зачем, если есть Гугл


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

Ладно, давай заканчивать. В общем, ситуация ясная — кое с чем ты согласен, но убедить тебя я в целом не смог. Некоторые твои аргументы меня не убеждают, к другим стоит отнестись более серьезно.

В заключение пару слов на тему о том "этого нет и потому не нужно". Лично мое мнение на этот счет таково. Идея web , в тот момент, когда она была сформулирована, исходила из состояния дел на тот момент. ИМХО это была идея всемирной паутины, не более. Но начав жить своей жтзнью (а идея оказалась очень плодотворной), она начала утверждать законы, исходя из своей собственной модели. Грубо говоря, она начала отвергать все, что в эту модель плохо укладывается и продвигать то, что укладывается хорошо.
With best regards
Pavel Dvorkin
Re[35]: Неужели?
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.04.08 05:12
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Тогда пошли этот запрос с web-страницы. Я же тебя просил дать мне способ из броузера c about:blank набрать и послать по POST некий XML на некий URL.
Павел, ты почему-то всё время подменяешь фундаментальные вопросы, касающиеся этого языка, на какие-то несущественные подробности вроде "послать по POST некий XML на некий URL", причем непременно с about:blank.

Вопросы о том, какой будет транспорт для запросов и ответов на этом языке, вообще говоря вторичен.

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

Вот, например, XPath вводит кучу понятий: node, element, attribute, value, node-set.

У тебя какая структура модели, по которой выполняются запросы? Остовное дерево? Произвольный граф? Что в вершинах этого графа? Что в листьях этого дерева?
Какие предикаты предполагается вычислять?
Какие будут типы данных? Скаляры/кортежи/множества скаляров/множества кортежей/упорядоченные множества/графы?
Какие операции предполагается поддерживать над этими типами данных? Какова алгебра этих операций?
Чем этот язык будет лучше, чем SQL, OCL, OQL, XPath, CSS?

Вот это — важные вещи. А ты сразу — POST, XML... К чему они, если непонятно, куда POST и какой XML?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[36]: Неужели?
От: Pavel Dvorkin Россия  
Дата: 15.04.08 07:07
Оценка:
Здравствуйте, Sinclair, Вы писали:

S>У тебя какая структура модели, по которой выполняются запросы? Остовное дерево? Произвольный граф? Что в вершинах этого графа? Что в листьях этого дерева?

S>Какие предикаты предполагается вычислять?
S>Какие будут типы данных? Скаляры/кортежи/множества скаляров/множества кортежей/упорядоченные множества/графы?
S>Какие операции предполагается поддерживать над этими типами данных? Какова алгебра этих операций?

Вот это уже вопросы по существу. Итак, сам принцип уже не осуждается, а задается конкретный вопрос о том, как будет выглядет запрос и т.д.

Ответа дать не могу. Потому что для того, чтобы его дать, я должен потратить не меньше времени, чем, к примеру, потребовалось разработчикам SQL или XML. Потому что это не проще, а скорее сложнее. Может, тут действительно что-то из XPath можно будет взять, может, что-то иное. Вообще-то языки запросов к иерархическим БД существовали еще в 70-е годы, см, например

http://en.wikipedia.org/wiki/Data_Language/1


S>Чем этот язык будет лучше, чем SQL, OCL, OQL, XPath, CSS?


Вообще говоря, язык меня интересует, но во вторую очередь. Если будут иерархические запросы (а их нет) — будет и язык.

S>Вот это — важные вещи. А ты сразу — POST, XML... К чему они, если непонятно, куда POST и какой XML?


Куда POST — вполне понятно. Какой XML — пусть и непонятно. Но послать-то можно или нет ? Пусть безотносительно к тому, что я писал, просто так вопрос сформулируем — можно ли из броузера послать сразу POST запрос на некий URL ? GET — элементарно, а вот POST ? Кто его там примет — сейчас не важно. И, пожалуйста, без разговоров о том, зачем. Просто — можно или нет ?
With best regards
Pavel Dvorkin
Re[37]: Неужели?
От: Sinclair Россия https://github.com/evilguest/
Дата: 15.04.08 07:29
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Вот это уже вопросы по существу. Итак, сам принцип уже не осуждается, а задается конкретный вопрос о том, как будет выглядет запрос и т.д.


PD>Ответа дать не могу.

Ну тогда что мы здесь обсуждаем? "У меня идея: давайте что-нибудь придумаем"?
PD>Потому что для того, чтобы его дать, я должен потратить не меньше времени, чем, к примеру, потребовалось разработчикам SQL или XML.
Вообще-то определиться с базовыми понятиями можно за день-другой.

PD>Потому что это не проще, а скорее сложнее. Может, тут действительно что-то из XPath можно будет взять, может, что-то иное. Вообще-то языки запросов к иерархическим БД существовали еще в 70-е годы, см, например

PD>http://en.wikipedia.org/wiki/Data_Language/1
Я в курсе. Я вообще задавался вопросом о языках запросов — когда еще собирался писать дисер.

S>>Чем этот язык будет лучше, чем SQL, OCL, OQL, XPath, CSS?

PD>Вообще говоря, язык меня интересует, но во вторую очередь. Если будут иерархические запросы (а их нет) — будет и язык.

Жан Марк Натюр, известный французский художник-портретист, долгое время не мог схватить сходство с португальским послом, которого как раз рисовал. Расстроенный неудачей, он уже собирался бросить работу, но перспектива высокого гонорара склонила его к дальнейшим попыткам добиться сходства. Когда портрет близился к завершению и сходство было уже почти достигнуто, португальский посол покинул Францию, и портрет остался с несхваченным сходством.

Натюр продал его очень выгодно, но с этого времени решил сначала схватывать сходство и только потом приступать к написанию портрета

Ты тоже сначала хочешь запросы, а потом — язык? Как это? Если ты про конкретный синтаксис — я тебя о нем пока и не спрашивал. Рано пока придумывать синтаксис — нужно сначала определиться с семантикой. Если у тебя нет представления о семантике запросов — то говорить в этой ветке как бы не о чем.

S>>Вот это — важные вещи. А ты сразу — POST, XML... К чему они, если непонятно, куда POST и какой XML?


PD>Куда POST — вполне понятно. Какой XML — пусть и непонятно. Но послать-то можно или нет ? Пусть безотносительно к тому, что я писал, просто так вопрос сформулируем — можно ли из броузера послать сразу POST запрос на некий URL ? GET — элементарно, а вот POST ? Кто его там примет — сейчас не важно. И, пожалуйста, без разговоров о том, зачем. Просто — можно или нет ?

Можно. Читать про тег <form>, а также про XmlHttpRequest.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.