Чтобы судьям это понять, следовало до Презиума ВАС дойти? Меня это просто поражает. Мне после однократного прочтения соответствующей статьи ГК стало сразу ясно, что подразумевается под использованием, а судьям...
Hypocriz, Вам главное понять, что законодатель подразумевает под термином "использование" товарного знака (ТЗ), для чего он нужен. Под "использованием" понимается маркировка производителем своей продукции товарным знаком.
Если вы например упоминая название группы Pink Floyd будете описывать именно эту группу, а не другую, то это не является "использованием" вами их ТЗ, так как они сами так себя назвали, они и "использовали" знак, а вы этот порядок не нарушаете.
Но если под этим названием будет описание и фотки другой группы, то тогда возможно нарушение прав на ТЗ. Вы это вряд ли будете делать, но такая ситуация возможна при неправильном размещении рекламы например.
Нет, просто дор использует копипаст с моего сайта (с небольшой разбавкой с других сайтов), в этом копипасте везде упоминается домен моего сайта.
Сейчас копнул... Оказалось, что там доров на поддоменах сотни (если не тысячи), целевым является очень старый крупный авторитетный высокопосещаемый сайт.
Не ожидал, честно говоря именно от этого сайта такой подставы... ведь они подводят под санкции сайты-источники, с которых инфу парсят, а использование в копипасте доменных имен указывает на намеренность их действий.
Ну, что ж... вызов принят! Посмотрим реакцию поисковиков. Но меня не доры интересуют, их скорей всего забанят, т.к. нарушения там налицо. Больше интересует, может ли быть наказан целевой сайт, принимающий этот трафик?
Может быть их тоже таким образом кто-то глушит, но уж больно дорогое удовольствие получается.
Да, тематика очень конкурентная.
Ну, если тошнота завышена (заголовок многократно дублируется), есть некоторые опасения и стоит задача ее уменьшить, то тогда наверно конечную крошку вообще не показывать.
Вообще не стоит, чтобы поисковики не нервировать. Но мне иногда такие ссылки удобны - когда например надо новую вкладку с этой же страницей в браузере открыть (кликаю по ней средней кнопкой мыши).
И страница выпала из индекса и из топа... если реальный товар сам является витриной.
Если сама чашка по сути та же, а отличается мелочью, то не надо "эти те же самые" чашки плодить в виде множества одинаковых страниц-дублей, надо все эти чашки показывать в одной карточке товаров, тогда реальные товары можно тасовать как угодно и даже если в карточке не останется ни одного реального товара, страница останется в индексе и топе.
Тогда надо свою привязку к своей системе идентификации так или иначе создавать. В противном случае не хорошо будет.
Лучше параллельным слоем товары накатить. Если всё нормально, новый слой активизировать, а старый слой удалить. Тогда всё бесшовно произойдет и без малейших задержек.
А у меня в текущем проекте выхода нет, приходится импорт автоматизировать... Но я введу проверки, и если всё ОК, то новый слой активизируется, иначе потребуется ручная проверка и активизация.
Я в виде полей запишу (не в SQL) для простоты.
ВАРИАНТ 1:
Дисплейный товар (display_product):
id: 123,
name: "Чашка с обезьяной",
url: "store.ru/chashka-s-obezyanoy/"
description: описание товара здесь...
Реальный товар (product):
id: 2047,
sku: "001-red",
name: "Чашка с обезьяной красная",
color: Красная
price: 199.99,
display_product_id: 123
-------------------
ВАРИАНТ2:
Описание товара (product_description):
id: 123
В первом варианте связь по display_product_id, а во втором варианте - по URL.
Тогда по двум полям: SKU+Producer
Но если артикулы меняются, то в любом случае в системе нужен будет свой внутренний уникальный артикул. Тогда надо будет вводить еще одну сущность с таблицей соответствия уникального внутреннего артикула с конкретным товаром.
Это опять таки стандартная задача, которая легко решается например в друпале или тем более в самописе. Не только артикулы могут быть у одного товара разные, партии одного товара по некоторым параметрам могут отличатся, например сроком годности. В друпал коммерс это реализуется легко, т.к. там уже нативно реальные товары отделены от товарных представлений. Т.е. у вас есть дисплейный товар, с ним вы связываете описания и пр., потом связываете с ним реальные товары - из разных поставок, с разными ценами, сроком годности и даже артикулами. Связь "реальный товар - дисплейный товар" вам в любом случае придется создавать по тем или иным критериям. При такой реализации описания можно включить в дисплейные товары, т.к. они импортом затрагиваться не будут. В любом случае полезно отделять реальные товар от его представления на сайте.---------- Добавлено 15.06.2017 в 00:55 ----------
Те, кто импортом занимаются, удалят все товары и зальют все товары по новой. Вся работа по созданию описаний пойдет насмарку.
Простой пример: если описания отделены от товаров, то я могу спокойно удалить целиком базу товаров и импортировать её из файлов поставщиков заново. Все описания товаров останутся на месте. А если описания находятся в самих товарах, то вы уже будете связаны по рукам и ногам при импорте.
Сейчас так не умеет. А в бета (или даже альфа) версиях (более 10 лет назад) она так умела - просто подцепляла sql-файл и генерила из таблиц модели. А дамп был из какого то самописного движка на пхп. Возможно я как-то случайно инициализировал этот процесс, когда игрался. А в стабильных версиях я уже этой фичи не видел.---------- Добавлено 14.06.2017 в 23:15 ----------
Описания нужны возможно не для всех товаров. Для ведения каталога описаний нужен свой функционал работы с описаниями, права доступа и пр., описаниями скорей всего будут заниматься другие люди, которым незачем иметь доступ к ценам, сео-полям и пр. Плюс к тому источник информации в идеале должен быть один - это файл импорта, а лезть в логику автоматического имопрта еще и с логикой ручной работы с описаниями - это плохо. Импорт работает нормально - не надо туда лезть. А описания - это самостоятельная сущность, лучше ее изолировать в самостоятельном каталоге.
Я честно говоря, всегда так делаю, когда необходимо добавить новый функционал в уже работающий проект. Я не добавляю новые поля и логику в существующие оттестированные модели, я лучше создам дополнительную модель с необходимой логикой и сделаю привязку к существующей модели например по артикулу, а потом соединю их где-нибудь, например в шаблоне в виде кастомного тэга. В этом случае я буду уверен, что не нарушу работоспособность нормально работающего проекта, плюс к тому я смогу легко перенести такой каталог в другой проект. Таким образом можно безопасно много чего дополнительного навешать.
