Так, все, этот ответ последний.
>Теорема 1: для любого решения можно придумать такое изменение структуры, которое сделает решение неработоспособным. Доказательство полностью приводить, или и так понятно?
Подменяем понятия, что для тебя характерно. Твоя теорема 1 безупречна, так как она ни о чем. Естественно, если сайт о микроволновках стал сайтом о космических ракетах, то тут уж точно, что ни делай, решение станет неработоспособным.
А вот такую теорему берешься доказать
Теорема 2: для любого решения можно придумать такое изменение внутренней структуры, не влияющее на внешний интерфейс, которое сделает решение неработоспособным.
Если готов согласиться с теоремой 2 — приведи доказательства. Но не думаю, что согласишься, ибо этим половину принципов ООП похоронишь.
А ведь об этом речь и шла.
S>Я вообще достаточно хорошо всё понимаю. У меня специфика работы такая: значительную часть последних десяти лет я провел, пытаясь понять вопросы и утверждения, сформулированные в самых разнообразных видах, начиная от скана карандашного рисунка салфетки, и заканчивая детальной спецификацией веб-сервиса на бразильском португальском.
И что из этого следует ? Я последние десять лет занимался примерно тем же, правда без бразильского португальского и без салфеток. Но из этого я не стану делать выводы, что я хорошо все понимаю. К примеру, в банаховых пространствах я так-таки ничего и не понимаю. Ты уверен почему-то, что все понимаешь хорошо. Бога ради, но почему я должен этому верить ?
S>Ну ты только что согласился с разработкой универсального языка запросов.
Мамуту захотелось так его назвать, я не стал спорить. Называй его УЯЗ или как-то иначе — мне это все равно. Если угодно, можешь назвать SQL УЯЗ/РБД, и это будет верно.
PD>>Ты хоть об одном бы подумал. Ведь то, о чем я говорю (черт с ними, с сайтами) есть (упрощая) язык запросов к иерархической БД[/b]. Это ты понимаешь или нет ? S>Это я понимаю. PD>>Язык запросов к реляционной БД существует и от того, что в БД — не зависит. S>Ок, движемся в конструктивную сторону. Педантично уточню, что S>а) сам по себе язык запросов недостаточен для построения запросов. Для того, чтобы сделать запрос, нужно знать структуру и семантику конкретной БД. Банальное переименование колонки способно сделать твой запрос невалидным, и ни одна СУБД не станет заниматься "исправлением" ошибок.
Естественно. Для этого есть запрос схемы БД, я об этом писал. По схеме можно граф построить. А семантика — да, за кадром, как всегда, об этом я тоже писал.
S>б) если ты про SQL, то речь идет не об одном языке, а о целом семействе языков, объединенных похожим синтаксисом. Каждая СУБД использует свой диалект, который отличается от других в достаточной степени, чтобы запрос к одной не подошел к другой. И это не второстепенные детали, а суровая реальность, в которой приходится жить разработчикам.
Ну это уже совсем бог знает что началось. Какое мне дело до различных реализации SQL и при чем это тут вообще ?
S>в) язык SQL не является вычислительно полным. Особенности диалектов как раз и касаются расширений в различных областях: S> — в скалярной математике. Банального возведения в степень в ANSI SQL нет S> — в реляционных операциях. Классическая реляционная алгебра не позволяет, к примеру, описывать запросы с "бесконечным" количеством Join, что необходимо для некоторых алгоритмов на графах S>Без этих расширений невозможно реализовать определенные запросы даже к тем данным, которые вообще удалось разместить в реляционной БД.
Это все в Recycled Bin как не имеющее к делу отношения.
S>г) реляционная модель не является полной. Существует огромный класс приложений, данные которых невозможно адекватно отразить в БД.
Туда же.
S>Это так, к вопросу о всеобщей применимости SQL.
S>Ну вот тебя не смущает то, что почему-то никто не делает веб-сервисов, которые бы принимали, к примеру, SQL, и возвращали таблицы? Ведь язык есть, и существует очень давно.
S>Лично меня смущает, и я полагаю, что причина в том, что SQL плохо подходит для распределенной среды, когда у нас нет гарантии одновременного обновления клиента и сервера.
Совершенно верно. Но я и не предлагаю в своей модели ничего вставлять или изменять с клиента, еще этого не хватало . А если бы РБД была констатной и из SQL можно было бы только SELECT использовать — почему бы и нет ?
Ладно, все, хватит, нет у меня уже времени обсуждать все с начала
Здравствуйте, Sinclair, Вы писали:
S>Ты тоже сначала хочешь запросы, а потом — язык? Как это? Если ты про конкретный синтаксис — я тебя о нем пока и не спрашивал. Рано пока придумывать синтаксис — нужно сначала определиться с семантикой. Если у тебя нет представления о семантике запросов — то говорить в этой ветке как бы не о чем.
Ну и слава богу.
S>>>Вот это — важные вещи. А ты сразу — POST, XML... К чему они, если непонятно, куда POST и какой XML?
PD>>Куда POST — вполне понятно. Какой XML — пусть и непонятно. Но послать-то можно или нет ? Пусть безотносительно к тому, что я писал, просто так вопрос сформулируем — можно ли из броузера послать сразу POST запрос на некий URL ? GET — элементарно, а вот POST ? Кто его там примет — сейчас не важно. И, пожалуйста, без разговоров о том, зачем. Просто — можно или нет ? S>Можно. Читать про тег <form>, а также про XmlHttpRequest.
Опять та же песня. Я тебя спрашиваю — как из броузера пользователю послать запрос , а ты меня к классам отсылаешь и к HTML. Ну как с тобой говорить после этого!
Еще раз точно определяю задачу. Я — юзер. Я HTML не знаю, тем более какие-то классы.
Я запустил IE7. В окне about:blank
Я имею некий файл, в котором XML (а впрочем, все равно, что там)
Я хочу послать этот файл на сервер a.com (с помощью POST).
Что там с ним сделают — не имеет сейчас значения.
Все.
Решение
1. Ты должен сделать следующее
1.1 Нажать то-то и то-то и т.д.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Sinclair, Вы писали:
S>>У тебя какая структура модели, по которой выполняются запросы? Остовное дерево? Произвольный граф? Что в вершинах этого графа? Что в листьях этого дерева? S>>Какие предикаты предполагается вычислять? S>>Какие будут типы данных? Скаляры/кортежи/множества скаляров/множества кортежей/упорядоченные множества/графы? S>>Какие операции предполагается поддерживать над этими типами данных? Какова алгебра этих операций?
PD>Вот это уже вопросы по существу. Итак, сам принцип уже не осуждается, а задается конкретный вопрос о том, как будет выглядет запрос и т.д. PD>Ответа дать не могу.
Жили были мыши. И все их обижали. И лисы, и кошки, и совы и даже собаки. И тогда они пошли к мудрому филину за помощью и попросились:
— Мудрый филин, помоги нам — нас все обижают — и лисы, и кошки, и совы и даже собаки. Жить невозможно, скажи, что нам сделать?
Подумал мудрый филин и сказал:
— Интересная проблема. Но я могу ее решить — вы просто станьте ежиками. У ежиков иголки, вас никто обижать и не будет!
Обрадовались мыши, поблагодарили мудрого филина и побежали радостные домой. И вот бегут, бегут, и вдруг одна мышь и говорит:
— Постойте, постойте, а КАК мы сможем стать ежиками?
Задумались мыши и побежали опять к мудрому филину:
— Мудрый филин, а скажи, КАК нам стать ежиками?
— Мыши, вот только грузите меня херней — я стратегией занимаюсь!
З.Ы. Павел, ассоциация с этим анекдотом у меня выстроилась в целом по прочтении многих твоих постов. Очень хорошо, когда строится универсальный суперязык и такая система, которая сразу все найдет и поймет вопрос от любого пользователя. Интересная тема, головокружительные перспективы. Но как только встают вопросы хотя бы примерной практической реализации, с указанием слабых мест, например такая мелочь как бесконечные (с практической точки зрения) варианты для перебора — это все несущественная тактика, как нибудь само решится...
Здравствуйте, Pavel Dvorkin, Вы писали: PD>Опять та же песня. Я тебя спрашиваю — как из броузера пользователю послать запрос
PD>, а ты меня к классам отсылаешь и к HTML. Ну как с тобой говорить после этого!
Нормально говорить. Задавать вопросы, если что-то непонятно. Рассказывать, если что-то понятно.
PD>Еще раз точно определяю задачу. Я — юзер. Я HTML не знаю, тем более какие-то классы. PD>Я запустил IE7. В окне about:blank PD>Я имею некий файл, в котором XML (а впрочем, все равно, что там) PD>Я хочу послать этот файл на сервер a.com (с помощью POST). PD>Что там с ним сделают — не имеет сейчас значения. PD>Все.
PD>Решение
PD>1. Ты должен сделать следующее
1. Набрать в адресной строке браузера a.com
2. Найти на сайте (при помощи прочтения документов глазами, понимания их мозгом, и манипуляций мышкой) форму, в которой будет предусмотрен интерфейс по запросу от тебя файлв
3. Воспользоваться кнопочкой browse для выбора файла
4. Воспользоваться кнопочкой submit для отправки файла.
Всё? Или есть какие-то еще ограничения, которые ты забыл упомянуть, чтобы уж с гарантией сделать задачу неразрешимой?
З.Ы. Павел, пытаясь формулировать вот такие идиотские задания, ты не получишь ни славы на форумах, ни понимания того, как правильно проектировать веб-приложения и веб-сервисы.
Если тебе почему-то неочевидно, что твое задание — это верх идиотизма, то я поясню.
Дело в том, что ты выступаешь от имени юзера, который не знает HTML. Так? Ну тогда откуда у тебя желание отправить файл при помощи POST? Откуда ты вообще узнал про протокол HTTP и метод POST в нем? Откуда ты такой взялся, что знаешь, что такое XML, но не знаешь HTML?
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Подменяем понятия, что для тебя характерно. Твоя теорема 1 безупречна, так как она ни о чем.
Павел, ни о чем — это твоя задача. Цитирую:
предлагаю построить такой запрос
Дайте объем микроволновой печи ce287mnr.
Сайт как он сейчас есть. Делать может что хотите. Решение должно работать до тех пор, пока эту печь не снимут с производства. Дизайн страницы фирма Самсунг может изменить в любой момент как ей захочется, ни я, ни Вы этого запретить ей не можем.
PD>Естественно, если сайт о микроволновках стал сайтом о космических ракетах, то тут уж точно, что ни делай, решение станет неработоспособным.
Нет, Павел, сайт не стал о космических ракетах. Компания Самсунг всего лишь выделила микроволновки для россии в отдельную линейку, которая теперь доступна по-другому, а вместо HTML стала отдавать Flash. Плита с производства всё еще не снята, но данные о ней устроены совершенно другим образом. Вполне, впрочем, читаемым для человека.
PD>А вот такую теорему берешься доказать
PD>Теорема 2: для любого решения можно придумать такое изменение внутренней структуры, не влияющее на внешний интерфейс, которое сделает решение неработоспособным.
Нет, не берусь. Я ее и сформулировать не берусь, потому что она оперирует таким неуловимым понятием, как "внутренняя структура", и таким неопределенным, как "внешний интерфейс".
И потому, что к твоей задаче (см. выше) эта теорема никакого отношения не имеет. Если мы запретили самсунгу менять внешний интерфейс, то всё сразу приходит в порядок.
Но мы этого сделать не можем. PD>А ведь об этом речь и шла.
Нет, Павел, речь уже о чем только ни шла.
PD>И что из этого следует ? Я последние десять лет занимался примерно тем же, правда без бразильского португальского и без салфеток. Но из этого я не стану делать выводы, что я хорошо все понимаю. К примеру, в банаховых пространствах я так-таки ничего и не понимаю.
Зачем заниматься передергиванием? Я имел в виду способность понять объяснение, а не заранее полученное знание. Или ты имеешь в виду, что ты в принципе не способен понять банаховы пространства, как бы тебе их ни объясняли? (Кстати, ничего особенного в банаховых пространствах нет. Что именно тебе непонятно — полнота, нормированность, или тебе сам термин векторное пространство непонятен?)
PD>Ты уверен почему-то, что все понимаешь хорошо. Бога ради, но почему я должен этому верить ?
Ну, например потому, что существует большое количество ситуаций, когда я сумел на практике понять достаточно смутную аргументацию. В том числе и в пределах этого форума.
S>>Ок, движемся в конструктивную сторону. Педантично уточню, что S>>а) сам по себе язык запросов недостаточен для построения запросов. Для того, чтобы сделать запрос, нужно знать структуру и семантику конкретной БД. Банальное переименование колонки способно сделать твой запрос невалидным, и ни одна СУБД не станет заниматься "исправлением" ошибок.
PD>Естественно. Для этого есть запрос схемы БД, я об этом писал.
Вообще-то об этом писал
А теперь рассмотрим SQL-сервер. Это тоже сервер , но с несколько иными правилами игры. Он не экспонирует свою внутреннюю структуру и не дает список методов
Поэтому SQL сервер в качестве своего АПИ выдает не коллекцию методов, а, по существу, один- единственный метод ExecSQL, которому передается запрос на языке, понимаемом этим SQL сервером. Это и есть его АПИ.
PD>Ну это уже совсем бог знает что началось. Какое мне дело до различных реализации SQL и при чем это тут вообще ?
При том, Павел, что не удается придумать один SQL на все случаи жизни. Мы имеем дело с большим количеством разных SQL.
PD>Туда же.
Отлично. Вот сразу видно, где проходит граница понимания. То, что не укладывается в твою голову, ты смело отправляешь в dev/null. И при этом у тебя хватает наглости обвинять меня в том, что я как-то неправильно спорю.
S>>Лично меня смущает, и я полагаю, что причина в том, что SQL плохо подходит для распределенной среды, когда у нас нет гарантии одновременного обновления клиента и сервера.
PD>Совершенно верно. Но я и не предлагаю в своей модели ничего вставлять или изменять с клиента, еще этого не хватало .
Павел, я имел в виду не изменение данных. Я имел в виду изменение структуры данных. В RDBMS Достаточно добавить в неудачную таблицу одну колонку, чтобы все клиенты тут же перестали работать.
PD>А если бы РБД была констатной и из SQL можно было бы только SELECT использовать — почему бы и нет ?
Если бы сайт Самсунга был константным, мы бы вернулись к решению с парсингом HTML. Но он меняется во времени — это условие задачи.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
M>>Более того, граф люьбого сайта может сильно изменяться от того, что мы думае о сайте. То есть мы думаем так:
PD><skipped>
PD>То, что ты написал, и верно, и нет. Верно — в том плане, что путей может быть много и пути, заложенные Самсунгом , могут отличаться от того, что мы думаем. Но вот тут уже вопрос к разработчикам Самсунга — они должны просто предусмотреть те пути, которые пользователь может придумать. Не все, это невозможно. Но основные можно.
Угу, и кто этим будет заниматься, этим представлением? Я вот не напрягаясь придумал три способа предсатвления товаров для самсунга. Это при том, что ни одна из этих моделей даже близко может быть не похожа на то, как эта информация хранится на сервере/серверах самсунга.
И что такое "основные"? Для Самсунга может быть только одно основное — разделение по моделям товара. Кто их заставит предоставлять N графов?
M>>Но почему именно миллиметры? Почему именно кубические сантиметры? ПОчему все это — не стоимость различных моделей?
PD>Что за проблема, не понимаю. В запросе указывается value="1000" unit="mm" и все.
То есть мы все равно собираемся ограничить количество ключевых слов?
M>>Придется вводить ключевые универсальные слова? На все области человеческой деятельности не напасешься. И никто в здравом уме не будет делать реализацию, поддерживающую этот словарь полностью.
PD>Ты все время исходишь из того, что эта схема должна быть универсальной и общечеловеческой (по крайне мере национальной). Я же исхожу из того, что здесь весьма небольшой словарный запас.
Неьольшой словарный запас, который подходит для чего?
Для того же Самсунга это моет быть:
— размеры (в миллиметрах для мелких деталей, в сантиметрах — для больших)
— объем (микроволновки)
— вместимость (стиральные машины)
— разрешение (мониторы, телевизоры)
— вес (для всего кроме миксеров, например)
— грузоподъемность (для тракторов)
— тоннаж (для кораблей)
— водоизмещение (для кораблей)
— предельное давление на грунт (для машин)
и т.д. и т.п.
M>>А как с единицами измерения? Их много.
PD>См. выше. Что-то я не пойму — зачем ты на ровном месте проблемы создаешь. Достаточно указать единицу измерения и все.
Какую единицу и для чего? В чем будем измерять водоизмещение яхты и объем микроволновки? Как мы будем указывать, что то или иное значение — это именно водоизмещение, а не объем?
PD>>>Нет, почему. Делаем клиент с URL строкой, XML редактором (для начала, потом лучше с построителем дерева) и кнопкой Submit . В URL набираем имя сайта, а редакторе XML. И нажимаем Submit. Это возможно ?
M>>Зачем? Чем это будет отличаться от веб-страницы с точно таким же УРЛ и точно такой же кнопочкой?
PD>Тогда пошли этот запрос с web-страницы. Я же тебя просил дать мне способ из броузера c about:blank набрать и послать по POST некий XML на некий URL.
Еще раз:
Делаем клиент с URL строкой, XML редактором (для начала, потом лучше с построителем дерева) и кнопкой Submit . В URL набираем имя сайта, а редакторе XML. И нажимаем Submit. Это возможно ?
Чем это отличается от
Заходим на http://orbitz.com/ , заполняем форму и нажимаем на кнопку Submit.
?????
M>>Иерархические запросы, теоретически, это, навреное, неплохо. Но реверс инжинирить каждый сайт? Да и зачем, если есть Гугл
PD>Не совсем понял, зачем тут реверс инжениринг. Я все же исхожу из того, что это должны разработчики сайта делать.
Должны делать что? Граф? И? Этот граф — он же не универсален. Для того, чтобы смочь сделать к нему запрос, надо знать, что значит каждый из элементов этого графа, нет?
Конечный пользователь
Форма составления запроса
Запрос в неком формате
Граф сайта 1
Граф сайта 2
Ответ в неком формате
Форма ответа
Конечный пользователь
— Откуда пользователь знает, что D-K-500-1300 и Daewoo-Appliances-Home-Microwaves-M-250-1300 — это два графа для аналогичных товаров. А он обязан это знать, иначе он никогда не сможет создать запрос к этим двум сайтам
Да никак. Ему придется выкачать весь граф сайта, вручную его проанализировать (ревер-инжинирнуть), понять, что к чему, и только потом составить какой-то запрос. Запрос ему уже не придется составлять, потому что после анализа графа он и так будет знать, что к чему
никуда не приведет. Потому что такие понятия, как быт и духовка у самсунга будут просто отсутствовать, а присутствовать только в описании товара, которое (по аналогии с блогами) в графе не участвует, потмоу что это просто текст.
По аналогии с базами данных. Мы не можем составить произвольный запрос к произвольной базе данных, потому что:
— мы не знаем структуры базы
— если мы знаем структуру, то
-- мы не знаем назначение таблиц и взаимоотношения между ними
-- мы не знаем назначение полей в таблицах и взаимоотношения между ними
Только проанализировав базу мы можем создавать специфические запросы, предназначенные только для этой базы и ни для кого более.
То же и с гипотетическим языком запросов к сайтам.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Mamut, Вы писали:
PD>Дело в том. что Гугл ищет не иерархично, а просто по словам. Есть три слова — Дворкин Павел Лазаревич — показывает. Хотя Дворкин тут вовсе Владимир, Лазаревич — Ефим, а Павел, видимо, не показали.
PD>А вот если бы на сайте была иерархия, то она явно выглядела бы так Дворкин — Павел — Лазаревич. А не Лазаревич — Дворкин — Павел или еще как-то. И весь этот мусор бы не возвращали. Или
PD>точный поиск — только те страницы, для которых есть иерархия Дворкин — Павел — Лазаревич PD>неточный — еще и те, для которых Дворкин — Павел . Тоже неплохо, вернут те страницы, где мое отчество отсутствует. Может , я, может, не я
PD>Но никаких Дворкиных Владимиров, и никаких Ефимов Лазаревичей!
То, о чем идет спор, уже давно реализовано — RDF + OWL. Только одно дело реализовать, другое — заставить применять + реализовать тысячи сервисов для поддержки. Речь ведь идет не просто о том, чтобы заставить гугль переписать свою поисковую машину и не в том, чтобы внедрить в firefox средство для быстрого построения семантических запросов. Есть миллионы сайтов, которые нужно будет переделывать, сотни миллионов пользователей, которых надо заново учить пользоваться поисковиками и т д.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Социализм — это власть трудящихся и централизованная плановая экономика.
ГВ>Я сейчас отнюдь не возражаю против того, чтобы сервер предоставлял описание доступных на нём сведений в том или ином виде. Проблема в том, что словарь самого этого описания должен быть согласован всеми высокими договаривающимися сторонами. Словарь, возможная структура и прочие системные аспекты. То есть, например, список товаров должен называться GoodItemsList и никак иначе, потому что в противном случае никакой привязки не получится.
Дык, миллион стандартов из области EDI, HIPPA и т.д., как раз чтобы знать, где там что. Полно свежих этих же стандартов для XML (собсно, чего я тебе говорю, сам знаешь ).
ГВ>Вот когда вы решите саму по себе задачу самоописаний, то есть попросту разберётесь — какой набор данных и когда должен или может передаваться, тогда отпадут и неоднозначности в оценке XML, Web и всех-всех-всех. Уверен, что можно будет даже и бинарным протоколом воспользоваться без особых неприятностей. Только так и никак иначе.
Здравствуйте, LaPerouse, Вы писали:
LP>То, о чем идет спор, уже давно реализовано — RDF + OWL.
М-да. А мне тут доказывают. что это невозможно. А это, оказывается, от w3c. Что же ты раньше не сказал ?
>Только одно дело реализовать, другое — заставить применять + реализовать тысячи сервисов для поддержки. Речь ведь идет не просто о том, чтобы заставить гугль переписать свою поисковую машину и не в том, чтобы внедрить в firefox средство для быстрого построения семантических запросов. Есть миллионы сайтов, которые нужно будет переделывать, сотни миллионов пользователей, которых надо заново учить пользоваться поисковиками и т д.
А это просто очевидно. Естественно, никто сейчас такое делать не будет, пока нынешнее развитие не дойдет до точки, когда станут существенными его проблемы. А они есть, и это уже сейчас ясно. То, что Гугл выдает сотни тысяч ссылок по поиску — это, может быть, хороший PR-ход (смотрите, сколько у нас есть, мы все знаем ), но пользы от этих сотен тысяч нет , так как их невозможно ни вручную, ни автоматически проанализировать. Модель, увы, не лучшая. Кстати, даже модель с некорректными исходными посылками вполне может давать приемлемые результаты — до поры до времени. В конце концов как-то предсказывали положение планет на базе системы Птолемея с какими-то эпициклами 1500 лет ! Но только до поры до времени. Подождем
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, LaPerouse, Вы писали:
LP>>То, о чем идет спор, уже давно реализовано — RDF + OWL.
PD>М-да. А мне тут доказывают. что это невозможно.
Возможно, возможно. Более того, это очень просто. Правда, они правы в том, что подвести все это под общий гребень сложно. Но например использовать формализацию такого рода для описания некоторой достаточно ограниченной области — это пожалуйста. Для того RDF и создавался. Если взять пример с продукцией samsung, о которой идет речь, то скажем, разработать модель метаданных, чтобы делать запросы типа "дайте мне XXX марки YYY, а если его не будет, то любую другую марку, но не позже 2000 года выпуска" — не проблема. Заходишь например на сайт самсунга и в разделе "расширенный поиск" вбиваешь соотв. запрос. Более того, не проблема даже сделать предметно-ориентированный поисковик, предназначенный, например, для поиска изделий электронной промышленности. "Дайте мне телевизор с диагональю не менее X такого-то года выпуска фирмы Samsung или Philips". В этом случае разные фирмы-изготовители могут договориться об общих URI и предоставляют семантические сервисы, основанные на представлении своих изделий в формате RDF.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали: LP>Возможно, возможно. Более того, это очень просто. Правда, они правы в том, что подвести все это под общий гребень сложно. Но например использовать формализацию такого рода для описания некоторой достаточно ограниченной области — это пожалуйста. Для того RDF и создавался. Если взять пример с продукцией samsung, о которой идет речь, то скажем, разработать модель метаданных, чтобы делать запросы типа "дайте мне XXX марки YYY, а если его не будет, то любую другую марку, но не позже 2000 года выпуска" — не проблема. Заходишь например на сайт самсунга и в разделе "расширенный поиск" вбиваешь соотв. запрос. Более того, не проблема даже сделать предметно-ориентированный поисковик, предназначенный, например, для поиска изделий электронной промышленности. "Дайте мне телевизор с диагональю не менее X такого-то года выпуска фирмы Samsung или Philips". В этом случае разные фирмы-изготовители могут договориться об общих URI и предоставляют семантические сервисы, основанные на представлении своих изделий в формате RDF.
Или, более реалистично, продавцы регулярно читают интернет и постят свои прайс листы в google base: products. Что характерно, всё вышеописанное работает уже сейчас, без изобретения ненужных технологий, и не требует даже RDF. Банальный RSS справляется на отлично, и даже старомодный CSV вполне еще на коне.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, LaPerouse, Вы писали: S>Или, более реалистично, продавцы регулярно читают интернет и постят свои прайс листы в google base: products. Что характерно, всё вышеописанное работает уже сейчас, без изобретения ненужных технологий, и не требует даже RDF. Банальный RSS справляется на отлично, и даже старомодный CSV вполне еще на коне.
RDF в обед сто лет. К слову, "банальный rss" на нем же и построен. Так что ничего изобретать не нужно.
К счастью, неандерталец в свое время, увидев топор, не сказал: "банальная дубинка справляется на отлично".
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, LaPerouse, Вы писали: LP>RDF в обед сто лет. LP>К слову, "банальный rss" на нем же и построен.
А можно пояснить, каким боком RSS построен на RDF? Я что-то не смог сходу найти ссылки в гугле. LP>Так что ничего изобретать не нужно. LP>К счастью, неандерталец в свое время, увидев топор, не сказал: "банальная дубинка справляется на отлично".
Надо полагать, у него были основания увидеть преимущества топора. В этой ветке, я погляжу, модно предлагать решения, которые не лучше существующих, и при этом обвинять собеседников в противостоянии прогрессу.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, LaPerouse, Вы писали: LP>>RDF в обед сто лет. LP>>К слову, "банальный rss" на нем же и построен. S>А можно пояснить, каким боком RSS построен на RDF? Я что-то не смог сходу найти ссылки в гугле.
Здравствуйте, WFrag, Вы писали: WF>http://en.wikipedia.org/wiki/RSS WF>Версии 0.9 и 1.0.
Да, спасибо, уже нашел. Как-то выпало у меня из головы, что была еще одна ветка.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Или, более реалистично, продавцы регулярно читают интернет и постят свои прайс листы в google base: products. Что характерно, всё вышеописанное работает уже сейчас, без изобретения ненужных технологий, и не требует даже RDF. Банальный RSS справляется на отлично, и даже старомодный CSV вполне еще на коне.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Дискуссия, которая развернулась на эту тему, несколько не в том направлении пошла. В значительной мере началось обсуждение пустяков, вроде того, один или два линка нужно и нужно ли выделять мышкой и сохранять. Подумал я и решил начать второй тур, отбросив все пустяки и сосредоточив внимание на сущности.
Прошу прощения за некропостинг, но Джоель опять написал статью, крайне уместную в данной теме.
Цитирую:
The hallmark of an architecture astronaut is that they don't solve an actual problem... they solve something that appears to be the template of a lot of problems. Or at least, they try.
... << RSDN@Home 1.2.0 alpha rev. 677>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, AndrewVK, Вы писали:
F>>Еще есть подтип "веб" приложений, которые на самом деле являются интранет приложениями, работающими только в корпоративной сети заказчика (данная подветка растет из моей истории о таких приложениях). F>>Для них вполне нормальным является требование качественно поддерживать только один браузер (обычно ИЕ), закрепленный корпоративным стандартом. Поддержка остальных — только как бонус.
AVK>На это у меня тоже есть пример. Новая платформа Паруса будет с несколькими клиентами, причем, скорее всего, среди них будет и веб-клиент. Прототип онного имеется в продакшене как раз таки с поддержкой IE-only (под названием веб-интерфейс к КОР, если интересно). Так вот, разработка веб-клиента значительно сложнее смарт-клиента, при том что функционал его меньше.
Гыгы, насколько я слышал, эту "новую платформу" уже 6 лет делают...
Чем это будет отличаться от веб-страницы с точно таким же УРЛ и точно такой же кнопочкой?
