как советский народ изменил ход войны – Москва 24, 05.12.2016

75 лет назад, 5 декабря 1941 года, в рамках одного из самых важных сражений Великой Отечественной войны началось контрнаступление советских войск под Москвой. К этой дате Главное архивное управление города Москвы по просьбе m24.ru подготовило материал о Битве за Москву.

Командир 82-й мотострелковой дивизии 5-й армии, генерал-майор Николай Иванович Орлов (справа) и военком дивизии, полковой комиссар Михаил Андреевич Клименко наблюдают за ходом боя. Автор – Д.А. Минскер. Место съемки – Западный фронт, Можайское направление. Дата съемки – январь 1942 года

Подготовка

Стратегическая обстановка на советско-германском фронте к концу сентября 1941 года оставалась неблагоприятной для СССР. Превосходство в силах и инициатива действий находились на стороне врага. Однако и немецкие войска понесли крупные потери, а их попытка сходу прорваться к Москве была сорвана героической борьбой Красной Армии во время Смоленского сражения.

В итоге 6 сентября 1941 года верховное командование вермахта отдало приказ о переходе войск на московском направлении к временной обороне и приступило к подготовке операции по захвату Москвы под кодовым названием «Тайфун».

Замысел операции предусматривал мощными ударами окружить и уничтожить силы Красной Армии, прикрывавшие столицу в районах Брянска и Вязьмы, а затем обойти Москву с севера и юга. Штаб оперативного руководства Верховного Главнокомандования вермахта считал, что этот удар «сломает спинной хребет русского оборонительного фронта».

Генерал Хайнц Гудериан писал: «Москва — это не только голова и сердце СССР. Это также центр связи, политический центр, самая индустриальная область и узел коммуникаций всей страны. … И если мы в Москве одержим победу над силами врага и выключим центральную сортировочную станцию Советского Союза, тогда перед нами падут и остальные его области».

Выполнение замысла возлагалось на группу армий «Центр» (командующий генерал-фельдмаршал Федор фон Бок). Для удара было сосредоточено 77 дивизий, в том числе 14 танковых и 8 моторизованных, в которых насчитывалось 1,8 миллиона. человец, свыше 14 тысяч орудий и минометов, 1,700 танков, 1390 самолетов. На московском направлении немцы сосредоточили треть имеющейся у них на Восточном фронте артиллерии, почти половину боевых самолетов и три четверти своих танковых соединений.

Группе армий «Центр» противостояли войска Западного (командующий генерал-полковник Иван Конев), Брянского (командующий генерал-полковник Андрей Еременко) и Резервного (командующий Маршал Советского Союза Семен Буденный) фронтов, оборонявшиеся на фронте шириной 800 километров.

В советских войсках насчитывалось около 1,2 миллиона человек, 6800 орудий и минометов, 1044 танка и 545 самолетов. Враг превосходил советские войска по численности людей в 1,2 раза, артиллерии и минометов — в 2,1 раза, танков — в 1,6 раза, боевых самолетов — в 1,7 раза. Многие советские дивизии, особенно Резервного фронта, а также 12 стрелковых дивизий народного ополчения не имели боевого опыта и должного вооружения.

Советское Верховное Главнокомандование намеревалось упорной обороной нанести врагу тяжелые потери и выиграть время для сосредоточения резервов. На подступах к Москве создавалась система мощных оборонительных рубежей, занимавших свыше 300 километров по фронту и 250 километров в глубину. В их подготовке важную роль сыграли дивизии московского народного ополчения, а также трудящиеся Смоленской, Брянской, Тульской, Калининской, Московской областей и Москвы. Однако работы по укреплению обороны не были завершены.

Начало сражения

Наступление врага началось 30 сентября ударом 2-й танковой группы по войскам Брянского фронта. 2 октября перешли в наступление главные силы группы армий «Центр» против войск Западного и Резервного фронтов. На направлении главных ударов они имели превосходство над советскими войсками по численности в 4,5 раза, по артиллерии – в 9 раз, по танкам – в 5,5 раз. В первый же день противник продвинулся на 40—50 км. 3 октября части 2-й танковой группы ворвались в Орел. 4 октября враг захватил Спас-Деменск и Киров, 5 октября — Юхнов и вышел в район Вязьмы. 6 октября пал Брянск.

В окружении оказались 7 советских армий. Упорно сопротивляясь, окруженные войска на неделю сковали 28 дивизий противника, но лишь малой их части удалось прорваться из окружения. В «котлах» под Вязьмой и Брянском советские фронты потеряли 35 процеентов своих дивизий, 85 процентов танков и артиллерии. Создалась прямая угроза Москве.

В этих условиях оставшиеся войска Резервного фронта были 10 октября переданы в состав Западного фронта, командование которым в этот день принял генерал армии Георгий Жуков. На московском направлении был создан новый фронт обороны.

Положение Западного фронта оставалось тяжелым. На фронте от Московского моря до Калуги в составе его четырех армий насчитывалось лишь 90 тысяч человек. В ходе ожесточенных боев на Можайской линии обороны 13 октября пала Калуга, 16 октября – Боровск, 18 октября – Можайск и Малоярославец. Величайшим напряжением сил удалось остановить врага на рубеже рек Протва и Нара. 17 октября был оставлен Калинин. Для прикрытия столицы с северо-запада 17 октября был создан Калининский фронт (командующий генерал-полковник Иван Конев). С 19 октября в Москве и в прилегающих районах было введено осадное положение.

Артиллерийское подразделение гаубиц направляется на новые позиции. Автор – Д.А. Минскер. Место съемки – Дорохово. Дата съемки – январь 1942 года.

К 29 октября, когда наступление гитлеровских войск удалось остановить, бои шли уже в 80–100 километрах от Москвы. Гитлер требовал во что бы то ни стало захватить Москву до начала зимы. Для нового наступления на столицу командование группы армий «Центр» развернуло 51 дивизию, в том числе 13 танковых и 7 моторизованных. Перевес в силах оставался на стороне противника: в людях в 2 раза, в артиллерии – в 2,5 раза, в танках – в 1,5 раза.

Наступление немецко-фашистских войск возобновилось с северо-запада 15–16 ноября, с юго-запада – 18 ноября. Главные удары противник наносил в направлениях Клин – Рогачево и Тула – Кашира. В конце ноября врагу удалось овладеть Клином, Солнечногорском, Истрой, выйти к каналу Москва — Волга в районе Яхромы и занять Красную Поляну (в 27 километраъ от Москвы). Здесь он был остановлен.

В районе Каширы и Тулы советское командование 27 ноября нанесло контрудар по 2-й танковой армии генерала Гудериана, отбросив ее от Каширы. Потерпев поражение под Каширой, 2-я немецкая танковая армия попыталась обойти Тулу с востока и северо-востока, но 2-4 декабря советские войска отбросили врага на исходные позиции. 1 декабря немецкие войска предприняли попытку прорваться к Москве в районе Апрелевки, но и она провалилась.

Контрнаступление

Силы и моральный дух немецкой армии были надломлены, создались предпосылки для перехода советских войск в контрнаступление. Советские войска под Москвой к началу декабря насчитывали около 720 тысяч челов, 5900 орудий и минометов, 670 танков и 760 самолетов. Немецкие войска имели 800 тысяч человек, 10400 орудий и минометов, 1000 танков и около 600 самолетов.

Замысел советского командования заключался в разгроме ударных группировок противника. К контрнаступлению привлекались войска Калининского и Западного фронтов и 2 правофланговые армии Юго-Западного фронта (командующий Маршал Советского Союза С. К. Тимошенко). Главный удар наносил Западный фронт.

Контрнаступление началось 5–6 декабря на фронте от Калинина до Ельца. 9 декабря советские войска освободили Рогачево, Венев, Елец, 11 декабря – Сталиногорск, 12 декабря – Солнечногорск, 13 декабря – Ефремов, 15 декабря – Клин, 16 декабря – Калинин, 20 декабря – Волоколамск…

К началу января 1942 года войска Западного фронта вышли на рубеж рек Лама и Руза. 26 декабря был освобожден Наро-Фоминск, 2 января – Малоярославец, 4 января – Боровск. Успешно развивалось контрнаступление и на левом крыле Западного фронта. 28 декабря был освобожден Козельск, 30 декабря – Калуга, в начале января 1942 года – Мещовск и Мосальск.

Командиры Рабоче-крестьянской Красной армии у немецких гаубий, брошенных противником при отступлении. Автор – Д.А. Минскер. Место съемки – в районе Можайска. Дата съемки – январь 1942 года

7 января 1942 года контрнаступление завершилось. Его результатом стал разгром основных сил 2-й, 3-й и 4-й танковых армий и соединений 9-й полевой армии вермахта . 38 немецких дивизий были разбиты. Гитлер снял с постов главнокомандующего сухопутными войсками генерал-фельдмаршала Вальтер фона Браухича, командующего группой армий «Центр» Бока, командующих 2-й и 4-й танковых и 9-й армиями Гудериана, Эриха Гепнера, Адольфа Штрауса. Всего своих должностей лишились 35 фельдмаршалов и генералов вермахта.

После удачных боев под Москвой. Автор – И.М. Шагин. Место съемки – Московская область Дата съемки – декабрь 1941 года.

Общее наступление

5 января 1942 Ставка Верховного Главнокомандования приняла решение о переходе в общее наступление на всех стратегических направлениях с целью разгрома главных группировок врага. 10 января войска Западного фронта освободили города Можайск, Верею, Медынь, Киров, Людиново и Сухиничи. Войсками Калининского фронта и левого крыла Северо-Западного фронта были освобождены города Пено, Андреаполь, Селижарово, Торопец.

Наступление войск Западного фронта на Вязьму, начавшееся 26 января, успеха не имело. Немецко-фашистское командование подтянуло подкрепления, которые отбили атаки советских войск и нанесли им тяжелые потери. 20 апреля 1942 года советские войска перешли к обороне на рубеже Ржев, Гжатск, Киров, Жиздра.

Вступление войск Красной армии в Можайск после его освобождения от фашистских захватчиков. Автор – М.В. Бачурин. Место съемки – Можайск. Дата съемки – 20 января 1942 года.

Итоги битвы за Москву

В результате контрнаступления и общего наступления противник был отброшен на 100–250 километров. Полностью были освобождены Московская, Тульская и Рязанская области, а также многие районы Калининской, Смоленской и Орловской областей.

Победа под Москвой имела огромное политическое и военное значение. Она знаменовала крах стратегических планов Германии, положила начало развертыванию массового сопротивления на оккупированных территориях СССР, послужила укреплению антигитлеровской коалиции.

Президиум Верховного совета СССР 1 мая 1944 года учредил медаль «За оборону Москвы». Ей награждены более миллиона человек.

Плакаты периода Гражданской войны

Плакат (от франц. placard – объявление, афиша) известен с древнейших времен. Он бытовал в Древнем Египте, Греции и Риме. Первые агитационные плакаты или «летучие листки» − гравюры большого формата – возникли в Германии в 1524-1526 гг.

В России первый революционный плакат появился в начале ХХ в. В период Русско-японской и Первой мировой войн он получил значительное распространение. Но именно в годы Гражданской войны появился и достиг своего расцвета политический плакат. Ясность изобразительных средств, наглядность образов, возможность быстрого отклика на происходящие события и быстрое распространение обусловили применение плакатного искусства как наиболее эффективного средства вовлечения народа в общественную жизнь. Советское правительство нуждалось в пропаганде и агитации своих политических идей и целей.

Язык художника звучал наравне с речью политического оратора. И можно сказать, что речь далеко не всякого оратора обладала такой яркостью и мобилизующей силой, какая была свойственна плакатам Гражданской войны. Вот почему все агитационные поезда: «Октябрьская революция», «Агитпоезд им. В. И. Ленина», «Красный казак», знаменитый агитпароход «Красная звезда» были украшены яркими, убедительными плакатами. Первые советские политические плакаты были выпущены издательством ВЦИК в августе 1918 г. Позднее крупнейшими издателями плакатов стали Центропечать с сетью губернских агентств РОСТА (так называемые «Окна РОСТА»), Всероссийское бюро военных комиссаров, Литературно-издательский отдел Реввоенсовета Республики. Центрами по выпуску советских плакатов были Москва, Петроград, Казань, Киев, Одесса, Смоленск, Харьков.

В процессе создания плакатов участвовали как художники-профессионалы, имевшие опыт работы в живописи, станковой и журнальной графике, иллюстрации, так и любители-самоучки. Основоположниками советского политического плаката были Д. Моор, В. Дени, М. Черемных, А. Апситис (Апсит), Н. Когоут, Н. Кочергин, А. Радаков, художники «Окон РОСТА» В. Маяковский, М. Черемных, А. Левин, И. Малютин в Москве, В. Лебедев, В. Козлинский в Петрограде. Среди графиков можно назвать Н. Купреянова, С. Чехонина, Е. Кругликова, Л. Лисицкого, В. Фидмана и других.

Новый плакат вобрал в себя традиции русской сатирической графики, использовал выразительные средства русского народного лубка, иллюстрации, журнальной карикатуры. При этом определились специфические приемы плакатного искусства: динамизм и лаконичность формы, образная и цветовая символика. Плакатное оружие было настолько действенным, что, несмотря на нехватку оборудования, материалов и кадров в издательствах и типографиях, плакаты печатались в первую очередь. Нередко они сопровождались красноречивыми надписями: «Каждый, кто срывает или заклеивает этот плакат, совершает контрреволюционное дело».

Постепенно были выработаны основные жанры политического плаката: сатирический и героический. Сатирический разоблачал «старый строй» и тех, кто, по мнению советского руководства, его поддерживал − капиталистов, интервентов, белогвардейцев, кулаков, соглашательские партии и церковь. Героический плакат с революционным пафосом призывал к борьбе с врагами советской власти, возвеличивал «нового героя» − рабочего, крестьянина, солдата. На нем крупными буквами помещались лозунги дня, задачи момента, сопровождавшиеся яркими и убедительными рисунками. Вот некоторые наиболее характерные лозунги: «Товарищи, все на Урал!», «На коня, пролетарий!», «Врангель еще жив, добей его без пощады!».

Многие плакаты периода Гражданской войны стали важнейшим средством политико-просветительной работы, классикой советского изобразительного искусства.

Коллекция плакатов музея-заповедника «Сталинградская битва» по тематике Гражданской войны насчитывает 40 единиц хранения. Первые плакаты поступили в фонды тогда еще Музея обороны Царицына имени тов. Сталина вскоре после открытия музея в 1937 г. В дни Великой Отечественной войны, когда в октябре 1941 г. музейные ценности были эвакуированы в Заволжье, учетная документация была почти вся утрачена, поэтому известны не все источники поступления плакатов. По сохранившейся описи музейных ценностей на 1 января 1941 г. в экспозиции музея было четыре плаката: «Граждане! Сдавайте оружие», «Казак, у тебя одна дорога с трудовой Россией», «Сказ про казака Ерему, попавшего в плен к большевикам», «Запись в Красную армию». Все они сохранились. Часть коллекции составляют плакаты, переданные в дар крупнейшими музеями СССР в 1951-1955 гг. Это плакаты из обменных фондов Музея революции СССР, Центрального Музея Советской армии. Отдельные плакаты поступили из Государственного архива Сталинградской области, Астраханского архивного бюро.

Граждане! Сдавайте оружие

Художник А. Апситис (Апсит)
Литературно-издательский отдел
Политуправления Реввоенсовета Республики
Москва, РСФСР
1918 г.
Бумага; типографская печать
103×67 см

МЗСБ КП-5527

---

К концу 1918 г. боевой состав Красной армии насчитывал 285 тыс. штыков и сабель, общая численность армии составляла 800 тыс. человек. С ростом армии остро встала задача снабжения ее оружием. 10 декабря 1918 г. был издан декрет о сдаче оружия, который обязывал «все население и все учреждения гражданского ведомства сдать находящиеся у них все исправные и неисправные винтовки, пулеметы и револьверы всех систем, патроны к ним и шашки военного образца».

Плакат был написан тут же, буквально через несколько дней после публикации декрета. Он ясно и убедительно доносил до каждого гражданина Советской республики, в чем заключается его гражданский долг, его личное участие в классовой битве. И в тексте, и в рисунке плаката ярко выражены призыв, агитация. На плакате только одна фигура красноармейца. Левой рукой он указывает на текст «Граждане! Сдавайте оружие», правую волевым движением обращает к зрителю.

К красноармейцу протянуты руки рабочих, откликнувшихся на призыв. Рабочие сдают винтовки, револьверы, шашки для нужд Красной армии. На втором плане изображение красной звезды – эмблемы Красной армии. В левом нижнем углу подпись автора: «СКИθ» (один из псевдонимов художника).

Год Красной Армии. 1918-1919

Художник А. П. Апситис (Апсит)
Агитационно-просветительный отдел
Всероссийского бюро военных комиссаров
Москва, РСФСР
1919 г.
Бумага; типографская печать
69×52 см
МЗСБ КП-1102

---

Плакат относится к 1918-1919 гг. – периоду построения армии нового типа − Рабоче-Крестьянской Красной Армии. Армия укреплялась организационно. На смену принципу добровольности пришел принцип всеобщей воинской обязанности. Стабилизировалась структура органов военного руководства, которую возглавил Реввоенсовет Республики. Красной армией приобретался боевой опыт, повышалась ударная и огневая мощь, что позволило не только сдерживать противника, но и на ряде направлений наносить успешные контрудары.

Плакат способствовал формированию у населения представления о Красной армии как защитнице интересов граждан республики. На переднем плане – фигура красноармейца с винтовкой наперевес, прикрывающего собой женщину с ребенком. В верхней части плаката изображен символ Красной армии – красная звезда с плугом и молотом в центре, вписанная в силуэт гербового щита. Слева и справа от фигуры красноармейца расположены элементы герба династии Романовых. Разорванная цепь, пораженные двуглавый орел и грифон символизируют разорванные оковы российского самодержавия. Фоном рисунка служит карта Советской Республики, на которой отражены успехи Красной армии. Подпись автора в правом нижнем углу: «СКИθ» (один из псевдонимов художника). Рисунок заключен в рамку, над которой указаны годы: «1918-1919». В нижней части плаката текст: «Я – крестьянский, рабочий сын. Я – солдат Красной Армии. Пока держу ружье в руках – нет воли врагам трудящихся. Год целый бьюсь на всех фронтах. Красная звезда с плугом и молотом, под алым знаменем загорается все дальше и дальше. Вольный пахарь, вольный рабочий под моей защитой строит новое вольное царство труда. За год окреп я, верю в силы свои, верю в правоту свою, верю в победу рабочего и крестьянского люда во всем мире. Рад бы отдохнуть, но клянусь держать крепко винтовку в руках, пока не согласны на мир враги Российской Рабоче-Крестьянской Советской Республики». Под текстом указан издатель: «Издание агитационно-просветительного отдела Всероссийского бюро военных комиссаров».

Деникинская банда

Художник В. Н. Дени (Денисов)
Литературно-издательский отдел
Политуправления Реввовенсовета Республики
Москва, РСФСР
1919 г.
Бумага; типографская печать
100×70 см
МЗСБ КП-1090

---

Генерал А. И. Деникин, с января 1919 г. − Главнокомандующий Вооруженными Силами Юга России, лидер Белого движения на юге России. Главными идеями его программы были борьба с большевиками и восстановление «Великой Единой Неделимой России».

В центре плаката, на фоне темных туч, расположен символ Белого движения – трёхцветный российский флаг с надписью: «Бей рабочих и крестьян». На первом плане карикатурно изображены генерал А. И. Деникин и видный русский политический деятель, монархист В. М. Пуришкевич. Их окружают фигуры, которые для художника ассоциируются с представителями реакционных кругов дореволюционной России: казак, священник, кулак и жандарм. Над рисунком надпись: «Деникинская банда», в центре призыв: «Защищайте Советы! Защищайте свою волю, свою власть». В нижней части плаката стихотворное «Обращение к крестьянам» Демьяна Бедного:

Подходите! Подходите!
На картину посмотрите:
– «Эх, картина… Просто шик»,
– Чешет голову мужик.
Развалившись на картине,
Сам Деникин в середине,
Сам Деникин-генерал,
Всё «правительство» собрал.
А правительство-то, эва
Пуришкевич лысый слева,
Справа бритый важный Туз –
Черносотенный союз.
Черносотенная стая:
Снизу – тройца пресвятая,
А у ней над головой, –
Поп, Кулак, Городовой.
Вот он батя-богомолец,
Возле бати – Доброволец!
Весь избит и зверски пьян, –
Побеждать идет крестьян.
Темный люд на водку падок.
– «Вот вам водка. Дуй из кадок». 

Как допьетеся до дна, 
Станет правда вам видна. 
Пей, ребятушки, из кадок,
За помещичий порядок,
За деникинскую плеть,
Неча спин своих жалеть.
Раньше баре подать брали,
Подать брали – шкуру драли,
Нынче ж власть коль заберут,
С мужиков семь шкур сдерут.
Оберут народ до нитки,
Возместят свои убытки,
Все убытки возместят,
Жир на брюхе отрастят.
Забунтуют деревушки,
Баре схватятся за пушки,
Чтобы бар нам вновь свалить,
Кровь рекой придется лить.
Чем терпеть нам снова муки
От деникинской науки,
Так не лучше ли вам всем
Не знавать ее совсем.  

Ой вы, светы мои, други,
Чай, мозги у вас не туги,
Так возьмите же вы в толк:
Кто вам друг и кто вам волк.
Чем Советов вам лишаться,
А потом за них сражаться,
Не сподручней ли для вас –
Не терять их ни на час.
Так вставайте ж, други-светы,
Защищать свои Советы,
Вашу волю, вашу власть,
Шлите пулю в волчью пасть.
Надо, братцы, торопиться
От Деникина отбиться,
И, разбив врага в бою,
Жизнь налаживать свою,
Делать собственное дело,
Терпеливо и умело,
Честно, просто, без затей,
Без помещичьих плетей.

Справа от текста предупреждение: «Всякий, срывающий этот плакат или заклеивающий его афишей – совершает контрреволюционное дело» и «№ 48».

Запись в Красную армию

Художник К. Спасский
Государственное издательство
Москва, РСФСР
Бумага; типографская печать
1919 г.
51×64 см
МЗСБ КП-1093

---

В соответствии с Постановлением ВЦИК от 29 мая 1918 г. об обязательном наборе в РККА, Красная армия комплектовалась по принципу мобилизаций. В июле 1918 г. 5-й Всероссийский съезд Советов законодательно установил всеобщую воинскую повинность трудящихся в возрасте от 18 до 40 лет. В крупных населенных пунктах запись в Красную армию проводили военные комиссариаты, в сельской местности эти функции выполняли приезжие сотрудники уездных военкоматов, инструкторы.

Плакат многосложен по композиции. Основной сюжет – запись крестьян в ряды Красной армии. В центре композиции изображен красноармеец со знаменем в левой руке; правой он указывает на лозунг момента: «Запись в Красную армию». Здесь же, у стола, на окраине села, толпятся крестьяне, некоторые из них с винтовками. На втором плане несколько крестьян ведут коней. Призывы проходили в обстановке острой классовой борьбы при недостатке оружия, обмундирования, строевых лошадей. В левой части плаката – оппозиционно настроенная к призыву группа кулаков. Надписи сверху в центре: «Российская Социалистическая Федеративная Советская Республика», правее: «Пролетарии всех стран, соединяйтесь». В правом нижнем углу авторская монограмма художника. В нижней части плаката приведены стихи Демьяна Бедного «Кулацкий плач»:

Стоит кулак и чешет бороду:
«Ох-хо-хо! Дела-дела!
Опять комиссия из городу,
Каких явилось два орла!
Имел я добрых две винтовочки,
Приберегал их до поры,
Ждал измененья обстановочки.
У, псы, едят вас комары!
Нашли винтовки под периною,
Не пулемет, как у попа,
С какой бы яростью звериною

 Я размозжил вам черепа!
Убавь, кричат мне, фанаберии,
Не то!.. Ну, что ж! В конце концов
Для ихней красной артиллерии
Пришлось отдать двух жеребцов.
В красноармейцы, вишь, охотников
Столпилось сколько у стола!
Для трех сынков моих, работников,
Давно уж очередь была.
Укрыл. Где чадушки спасаются,
Пока никто не подсмотрел.

 Худеют парни. Опасаются:
Поймают – кончено: расстрел!
Ох, что ж это такое деется?
Когда ж я обрету покой?
Терпеть, на Колчака надеяться?
Аль уж надежды никакой?»
Страдая всей своей «утробою»,
Скулит кулак: «Дела-дела!»
И смотрит с бешеною злобою
На флаг кумачный у стола. 

Антанта

Художник В. Н. Дени (Денисов)
Литературно-издательский отдел
Политуправления Реввоенсовета Республики
Москва, РСФСР
1919 г.
Бумага; типографская печать
67×52 см
МЗСБ КП-5530

---

Лидеры Белого движения в период Гражданской войны опирались на военную помощь Великобритании, Франции, США, которые к этому времени играли ведущую роль в Антанте (союз «Сердечное согласие», от франц. «Entente cordiale», начал оформляться в 1904-1907 гг. как блок Великобритании, Франции и России).

На плакате изображены генералы А. И. Деникин, А. В. Колчак, Н. Н. Юденич в виде свирепых псов с воинскими знаками различия и отличия на поводках у лидеров Антанты. Карикатурный образ лидеров Белого движения как «хищных псов» был призван объяснить рабочим и крестьянам зависимость белогвардейцев от помощи Антанты. В плакате использовались такие изобразительные средства, как лаконичность формы, образная символика. На цилиндрах трех империалистов изображены национальные флаги США, Франции, Великобритании. Преобладанием в палитре плаката черного цвета художник подчеркивает антинародность, антигуманность режима, который несут с собой руководители Белого движения при поддержке мирового империализма. Надписи сверху слева – «Российская Социалистическая Федеративная Советская Республика», справа – «Пролетарии всех стран, соединяйтесь», в левом нижнем углу – «№ 42». В нижней части плаката помещены сатирические стихи, характеризующие политику Антанты в отношении Советской России:

По пояс утопая в крови,
Антанты злобная орда
Глядит, насупив мрачно брови,
На землю вольного труда.
Таит Антанта мысли злые,
Мечтая злобно по часам
Отдать Советскую Россию
На растерзанье хищным псам.
В угоду разжиревшей клике,
Свободы растоптавшей флаг,
Рычат Юденич и Деникин,
Рычит голодный пес Колчак.

И запах золота почуя,
По ветру навострив носы,
В защиту мировых буржуев
Остервенело лезут псы.
Но мощная рука рабочих,
Подняв высоко красный стяг,
Как сор, отбрасывает прочь их,
Скрепляя боем каждый шаг.
Трещат по швам Антанты планы
Борьба что день, то горячей;
Пустеют без толку карманы
Господ союзных богачей. 

На псов надежды очень мало,
Победы путь не так уж прост –
Колчак расшибся близ Урала,
Бедняге отдавили хвост.
Подшибли глаз, помяли лапы:
Скулит облезлый пес Колчак;
Глядят союзные сатрапы
На красный заповедный флаг.
И с грудой рент и облигаций,
Решая все дела втроем,
Сидит уныло «Лига наций»
В собачьем обществе своем.

Да здравствует Красная 3-х миллионная армия!

Художник А. П. Апситис (Апсит)
Агитационно-просветительный
отдел Всероссийского бюро военных
комиссаров
Москва, РСФСР
1919 г.
Бумага; типографская печать
71×105 см
МЗСБ КП-1269
МЗСБ КП-5566

---

Рабоче-Крестьянская Красная армия, армия нового типа, на 1 апреля 1918 г. насчитывала 155 тыс. человек, к началу 1919 г. в ее рядах состояло уже 1 млн. 630 человек. Еще в октябре 1918 г. Председатель Совета Народных Комиссаров В. И. Ленин выдвинул важнейшую общегосударственную и общепартийную задачу – создание трехмиллионной армии. В июле 1919 г. состоялся пленум ЦК РКП (б), после которого этот процесс был ускорен. К концу 1919 г. задача была выполнена.

Это послужило поводом для выпуска плаката. С помощью изобразительных приемов автор показал, как многочисленные колонны красноармейцев сливаются в единый могучий поток. По заснеженным полям, балкам и лощинам, извилистым дорогам движутся сухопутные войска – основной род войск Красной армии, кавалерия – маневренная ударная сила армии. В правой средней части плаката четко прописаны сопровождающие армию обозы, мотоциклетные части. На первом плане изображен командир, который, стоя на броневике со знаменем в руке, приветствует красноармейцев. Немного впереди него, справа и слева показаны рядовые бойцы и матросы. В левой части плаката – артиллерийский расчет, буксирующий полевую пушку. Над колоннами красноармейцев реют аэропланы и самолеты. Автор дает представление о всех родах войск, входивших в состав Красной армии. В бесконечных людских потоках тут и там видны красные знамена. На среднем плане полотна написана маленькая деревенька, на дальнем плане, справа, − окраины фабричного городка. Таким образом, художник показывает основные источники пополнения армии – крестьянские массы и рабочий класс. Интересной особенностью плаката можно считать огромное количество людей, изображенных художником, и умение передать движение людских масс, сообщить произведению динамизм. В правом нижнем углу подпись автора: «СКИθ» (один из псевдонимов художника).

Товарищи, все на Урал!

Художник П. Ю. Киселис
Агитационно-просветительный отдел
Всероссийского бюро военных комиссаров
Москва, РСФСР
1919 г.
Бумага; типографская печать
104×72 см
МЗСБ КП-1276

---

Плакат относится к 1919 г., когда Восточный фронт становится главным, а лозунг «Все на борьбу с Деникиным» − наиболее актуальным. Одной из целей атак адмирала Колчака на Урал было отвлечение сил Красной армии от Южного фронта. Советское правительство, не снимая войска с южного направления, проводит ряд мобилизаций в ряды РККА. Итогом их стало пополнение Красной армии 877 тысячами человек. Из них на Восточный фронт было направлено 24 тысячи. Благодаря этому стало возможным мощное контрнаступление, начавшееся в апреле 1919 г. действиями Южной группы армий Восточного фронта, имевшее целью освобождение Урала. Это было жизненно необходимо Советской Республике, так как помимо решения чисто военных задач, Урал с его населением в 6 млн человек, с большим количеством предприятий и сельскохозяйственных угодий мог значительно улучшить снабжение армии и тыла и дать десятки тысяч новых бойцов для Красной армии.

Идейное содержание плаката заключается в лозунгах: «Товарищи, все на Урал!», «Смерть Колчаку и прочим приспешникам царя и капитализма». Вся экспрессия плаката сконцентрирована в фигуре красноармейца, стремящегося в бой. В левом нижнем углу – подпись автора и дата, в правом – указан издатель: «Издание агитационно-просветительного отдела Всероссийского бюро военных комиссаров».

Отступая перед Красной армией, белогвардейцы жгут хлеб

Художник А. П. Апситис (Апсит)
Издательство Народного
комиссариата земледелия
Москва, Петроград, Киев, РСФСР
1919 г.
Бумага; типографская печать
64×99 см
МЗСБ КП-1275

---

Плакат иллюстрирует одну из самых трагичных страниц истории Гражданской войны: бедствия и страдания мирного, беззащитного населения.

В основу сюжета положено уничтожение отступающими белогвардейцами хлебных запасов на селе. На деревенской околице белогвардеец поджигает соломенную крышу амбара, другие держат под прицелом крестьянскую семью. Рядом с генералом – священник. Советский плакат часто включал в лагерь классовых врагов православных священников с крестом. Крест выступает одним из символов, разделяющих противоборствующие стороны, хотя православна церковь не благословляла ни одну из воюющих сторон и, более того, постоянно призывала к прекращению братоубийственной войны. В левой части плаката – старик, изможденные дети, женщины, взывающие к милости, протягивающие руки к белогвардейцам. На лицах и в позах застыло выражение отчаяния и страха. Картину народного бедствия дополняет изображение охваченного огнем амбара у горизонта. Подпись автора в левом нижнем углу: «И. Осинин» (один из псевдонимов художника). Справа указано: «Издательство народного комиссариата земледелия, Москва, Пречистенский бульвар, 4 – Петроград, Морская, 42 – Киев, Владимирская, 19».

Вперед, на защиту Урала!

Художник А. П. Апситис (Апсит)
Политический отдел
Революционного военного совета Республики
Москва, РСФСР
1919 г.
Бумага; типографская печать
106×71 см
МЗСБ КП-1267

---

В 1919 г. Восточный фронт снова, как и летом 1918 г., становится главным фронтом Советской Республики. Возникает реальная угроза совместного похода на Москву объединившимися армиями А. В. Колчака и А. И. Деникина. 12 апреля 1919 г. опубликованы Тезисы ЦК РКП (б) «В связи с положением на Восточном фронте», в которых была поставлена главная политическая и стратегическая задача момента: направить все силы на разгром войск А. В. Колчака и освобождение Волги и Сибири. По мобилизации в Красную армию было призвано свыше 50 тысяч человек. В конце апреля советские войска под командованием М. В. Фрунзе и С. С. Каменева перешли в контрнаступление. Тем самым были созданы предпосылки для освобождения Урала.

В верхней части плаката призыв: «Вперед, на защиту Урала!». На переднем плане показана фигура бойца Красной армии, бегущего в атаку с винтовкой наперевес. Динамизм изображению придают силуэты устремившихся в бой вооруженных красноармейцев под знаменем. В левом нижнем углу подпись автора: «А. Петров» (один из псевдонимов художника). В правом нижнем углу эмблема и название издательства: «Издание политического отдела Революционного военного совета Республики».

Освободители

Художник В. Н. Дени (Денисов)
Литературно-издательский отдел
Политуправления
Реввоенсовета Республики
Москва, РСФСР
1919 г.
Бумага; типографская печать
68×98 см
МЗСБ КП-5531

---

В 1919 г. армии генерала А. И. Деникина занимают значительные территории Юга России. Здесь, как и на территориях, занятых Красной армией, был установлен режим военного времени. Его характерными чертами были милитаризация, бюрократизм, жестокие меры принуждения. Оказавшись на занятой «красными» или «белыми» территории, люди в равной степени подвергались давлению со стороны властей.

Решая задачи политической пропаганды, автор плаката стремится подчеркнуть жестокость командования Вооруженных Сил Юга России и правительства Юга России по отношению к гражданскому населению. Генерал А. И. Деникин, карикатурно изображенный на первом плане плаката, олицетворяет для художника белый террор, страшной иллюстрацией к которому стал расстрел мирных жителей белогвардейцами. Над названием плаката «Освободители» надпись: «Российская Социалистическая Федеративная Советская Республика» и воззвание: «Пролетарии всех стран, соединяйтесь!» Справа предупреждение: «Всякий, срывающий этот плакат или заклеивающий его афишей, – совершает контрреволюционное дело», в центре указан издатель: «Литературно-издательский отдел Политуправления Реввоенсовета Республики», справа – место печати: «17-я Государственная типо-литография (бывш. Кушнерева), Москва» и номер плаката «28».

Донецкий уголь должен быть наш!

Художник К. Спасский
Литературно-издательский отдел
Политуправления Реввоенсовета Республики
Москва, РСФСР
1919 г.
Бумага; типографская печать
104×71 см
МЗСБ КП-1271

---

В январе 1919 г. Белые армии Юга объединились под общим командованием генерала А. И. Деникина. Полностью овладев Северным Кавказом, в феврале 1919 г. командование Вооруженных сил Юга России перебрасывает добровольческие войска на Донбасс и Дон, в помощь отступающим частям Донской армии. Это направление было особенно важно для обеих воюющих сторон. Советская Республика переживала жестокую экономическую разруху, топливный голод. Борьба за донецкий уголь имела такое же значение, как и борьба на военном и продовольственном фронтах. Фабрикам, железным дорогам, водному транспорту, населению жизненно необходим был уголь. Борьба за Донецкий бассейн приняла затяжной характер и продолжалась весь 1919 г. 31 декабря 1919 г. в ходе наступательных операций Красной армии Донбасс был окончательно освобожден.

На первом плане плаката изображена фигура красноармейца, указывающего левой рукой на лозунг «Донецкий уголь должен быть наш!». Боец Красной армии попирает ногой белогвардейского генерала, придавив его еще и прикладом винтовки, к штыку которой прикреплен красный флаг с надписью «РСФСР». На дальнем плане – дымящие заводы и фабрики, к которым с разных сторон тянутся многочисленные железнодорожные эшелоны, груженные углем. Между железнодорожными ветками показаны поля – источники хлеба для голодающей России. В средней части плаката расположен текст: «Нет угля – стоят фабрики, нет угля – станут поезда, покуда Дон не наш – голод с нами». В нижней части плаката под изображением красным шрифтом выделена основная мысль: «Победа над деникинскими бандами – победа над голодом». На верхнем поле надпись: «Российская Социалистическая Федеративная Советская Республика».

На коня, пролетарий!

Художник А. П. Апситис (Апсит)
Литературно-издательский отдел
Политуправления Реввоенсовета Республики
Москва, РСФСР
1919 г.
Бумага; типографская печать
102×71,5 см
МЗСБ КП-1268

---

Одним из преимуществ Белых армий, действовавших на Юге России, был высокий процент кавалерийских соединений. В Донской армии генерала П. Н. Краснова и в Кавказской армии генерала П. Н. Врангеля доля кавалерийских соединений достигала 50% от общей численности войск. В Красной армии первые кавалерийские части начинают формироваться в январе 1918 г. из солдат-добровольцев. В это же время создаются и первые конные краснопартизанские отряды, влившиеся позже в кавалерию Красной армии. Но маневренный характер войны и широкое использование кавалерии противником ускорили процесс формирования кавалерийских соединений – бригад, дивизий, корпусов стратегической кавалерии, ставшей основным средством развития прорыва, разведки. Первые кавалерийские дивизии были сформированы в конце 1918-1919 гг., корпуса – летом 1919 г., а Первая Конная армия – в ноябре 1919 г.

Динамизм плакату придает изображение летящего во весь опор всадника в форме красноармейца и силуэты скачущих за ним бойцов-кавалеристов. В верхней части плаката надпись: «На коня, пролетарий!» В нижней части призыв: «Рабочая революция должна создать могущественную красную конницу. Коммунист должен стать кавалеристом». На верхнем поле плаката слева надпись: «Российская Социалистическая Федеративная Советская Республика», справа – «Пролетарии всех стран, соединяйтесь!». У нижнего края рамки, окаймляющей изображение всадника – издательская эмблема литературно-издательского отдела Политуправления Реввоенсовета Республики и номер плаката «52».

За Красный Петроград!

За Красную Финляндию!

Художник Йири Аррак (Jiri Arrak)
Литературно-издательский отдел
Политуправления Реввоенсовета Республики
РСФСР
1919 г.
Бумага; типографская печать
106×70 см
МЗСБ КП-1279

---

В конце сентября 1919 г. начинается второе наступление Северо-Западной армии генерала Юденича Н. Н., рассчитывавшего на активную поддержку Эстонии и Финляндии. К октябрю 1919 г. положение под Петроградом становится угрожающим. Защита Петрограда была возложена на 7-ю армию и Действующий отряд Балтийского флота. Они были усилены за счет мобилизаций рабочих и коммунистов Петрограда. Сюда же перебрасываются дополнительные части из резерва и с других фронтов. Это позволило добиться перелома в ходе боевых действий в пользу Красной армии и заставило Финляндию отказаться от помощи Юденичу.

На переднем плане красноармеец в рукопашной схватке сталкивает белогвардейца с обрыва, символизирующего границу Советской Республики. Внизу под обрывом − крепостные стены города и река. В верхней части плаката на заднем плане показана фигура красноармейца, водружающего красное знамя с надписью «Р. С. Ф. С. Р.». Ногой он попирает сорванное белое знамя. В верхнем левом углу надпись: «Пролетарии всех стран, соединяйтесь!» В нижней части плаката лозунг: «За Красный Петроград! За Красную Финляндию!». У нижнего края рамки, окаймляющей изображение, указано издательство: «Лит.-Изд. Отд. Полит. Управл. Рев. Воен. Сов. Республики» и авторская подпись художника.

Враг у ворот! Он несет рабство, голод и смерть!

Художник Д. С. Моор (Орлов)
Литературно-издательский отдел
Политуправления Реввоенсовета
Республики
Москва, РСФСР
1919 г.
Бумага; типографская печать
70×100,5 см
МЗСБ КП-1274

---

Особенно тяжелым для Советской России оказался 1919 г. Вооруженная борьба развернулась одновременно на шести фронтах общей протяженностью 8 тыс. км. Она требовала мобилизации всех сил на борьбу с врагом.

Плакат образно представляет реальную борьбу за советскую власть как сражение с мифическим чудовищем. Художник использует аллегорические образы. Справа – изображение крепостной стены с бойницами, через которые ведет по противнику огонь артиллерия Красной армии. По ступеням лестницы поднимаются шеренги красноармейцев. В нижней части плаката, на фоне крепостной стены, лозунг: «Пролетарии всех стран, соединяйтесь». На полотнище знамени надпись: «РСФСР». В левой части плаката, под черными тучами, представлены зловещие образы врага: двуглавый орел со змеиными языками, смерть в темном плаще, держащая в одной руке императора России в царской мантии, другой рукой указывающая в направлении крепости – оплота советской власти. В стане противника тут и там видны флаги кайзеровской Германии. В нижней части плаката текст: «Враг у ворот! Он несет рабство, голод и смерть! Уничтожьте черных гадов! Все на защиту! Вперед!». Надписи на верхнем поле слева: «Р. С. Ф. С. Р.», справа: «Пролетарии всех стран, соединяйтесь!». В нижней части правого поля – издательская эмблема.

Товарищи мусульмане!

Художник Д. С. Моор (Орлов)
Издание Центрального Управления Всевобуч
Москва, РСФСР
Бумага; типографская печать
71×49 см
МЗСБ КП-1104

---

Плакат иллюстрирует общую линию ленинской национальной политики. 20 ноября (3 декабря) 1917 г. было опубликовано «Обращение к трудящимся мусульманам России и Востока за подписями председателя СНК В. И. Ленина и наркома по делам национальностей И. В. Сталина, которое гарантировало сохранение обычаев, национальных и культурных учреждений.

В центре плаката представлен кавалерист-мусульманин со знаменем, на котором изображены красноармейская звезда и полумесяц. За ним – группа всадников-мусульман. Пейзаж пустыни, мусульманская символика создают особенный национальный колорит. В верхней части плаката текст: «Враги трудового народа посягают на вашу свободу, только вы сами можете защитить свои семьи, только Советская власть доставит вам ваши вольные степи, горы и скалы. Все в седла! Идите в ваши мусульманские конные полки всеобщего обучения. Поступайте на кавалерийские курсы Всевобуч! Все под красную звезду!». В нижней части плаката – текст на арабском языке. Плакат формирует мысль, что у трудящихся России и Востока общий враг, против которого необходимо объединить силы. До введения всеобщей воинской повинности на национальных окраинах подготовкой добровольцев к несению службы в рядах Красной армии ведал Всеобуч. Плакат носит ярко выраженный агитационный характер. Надписи: в правом верхнем углу – «Обращайтесь за справками: инспекция Кавалерийских Формирований Центрального Управления Всевобуч Всероссийского Главного Штаба», в левом нижнем углу – «Издание Центрального Управления Всевобуч».

Хлеб нам даст только Красная армия

Художник Н. Н. Поманский
Литературно-издательский отдел
Политуправления Реввоенсовета
Республики
Москва, РСФСР
1919 г.
Бумага; типографская печать
52×69 см
МЗСБ КП-1103

---

1919 г. − период наибольших успехов Вооруженных Сил Юга России под командованием генерала А. И. Деникина и потери захваченных территорий. Этот год оказался особенно тяжелым для Советской республики. К марту 1919 г. вместо 260 млн. пудов хлеба, запланированных по продразверстке, было собрано лишь 91,3 млн. пудов. Летом 1919 г. основные хлебопроизводящие районы были в руках Белой армии.

Эта ситуация отражена в верхней части плаката. Слева вверху, на диване, изображен  генерал А. И. Деникин, за диваном – многочисленные мешки, символизирующие запасы хлеба. Левой рукой А. И. Деникин указывает на карту, на которой представлена занятая Вооруженными силами Юга России (ВСЮР) территория. Справа вверху, как антитеза, представлены голодающие рабочие с семьями, весы со скудным пайком хлеба − 1/8 фунта. Здесь же текст: «Деникин занял Харьков и Екатеринослав – в Москве и Петрограде нет хлеба». В нижней части плаката ситуация изменилась. Исхудавший А. И. Деникин сидит на том же диване, но за ним уже нет мешков с зерном. Генерал отвернулся от карты, на которой показаны потерянные ВСЮР районы Юга России. Справа внизу та же группа рабочих с семьями, но уже в приподнятом настроении, рядом мешки с хлебом. На весах лежит более полновесный паек – 1½ фунта хлеба. Текст: «Красная армия наступает, хлеб в Советской России прибавляется». Надписи: в левом верхнем углу – «Пролетарии всех стран, соединяйтесь!»; в правом – «Российская Социалистическая Федеративная Советская Республика»; в левом нижнем углу – «Лит.-Изд. Отд. Полит. Управл. Рев. Воен. Сов. Республики» в правом – «Всякий, срывающий этот плакат или заклеивающий его афишей, совершает контрреволюционное дело».

Ты записался добровольцем?

Художник Д. С. Моор (Орлов)
Литературно-издательский отдел
Политуправления Реввоенсовета Республики
Москва, РСФСР
1920 г.
Бумага; типографская печать
106×71 см
МЗСБ КП-1270

---

Героический агитационный плакат, относящийся к периоду строительства регулярной Рабоче-Крестьянской Красной Армии. В условиях Гражданской войны Красная армия непрерывно пополнялась не только за счет мобилизации, но и за счет партийных, профсоюзных, комсомольских призывов.

Именно этим категориям населения Советской России адресован вопрос красноармейца, изображенного на плакате. Во весь рост поднялась огромная фигура бойца. Он смотрит прямо, суровый и требовательный взгляд не отпускает внимание зрителя. Это не просьба о помощи, а веление долга, призыв встать в строй. Неповторимо лицо, полное страсти и самоотверженности. Четко найден выразительный жест красноармейца. В левой руке – винтовка, правая направлена на зрителя. Вопрос, с которым красноармеец обращается к гражданам Советской России, в изобразительном плане делится на две части: надпись «Ты» − в верхнем правом углу плаката, «записался добровольцем?» − в нижней части. На втором плане изображены корпуса заводов, которые в числе прочего народного достояния призвана защищать Красная армия. Плакат «Ты записался добровольцем?» − это шедевр Д. С. Моора, в котором воплотились наиболее характерные черты советского плакатного искусства: высокий политический пафос и предельно ясная форма выражения. Плакат обладал огромной агитационной силой и стал одним из наиболее популярных плакатов не только в Гражданскую, но и в Великую Отечественную войну. Над изображением сверху указана страна издания «Р. С. Ф. С. Р.» и призыв: «Пролетарии всех стран, соединяйтесь!». Подпись автора в левом нижнем углу плаката. Ниже − место печати: «1-я Государственная типо-лит. (Пятницкое отд.) Москва, Пятницкая, 71» и номер плаката «№ 100», справа рядом с издательской маркой указано издательство: «Лит. Изд. Отдел Политуправления Реввоенсовета Республики».

Сказ про казака Ерему, попавшего в плен к большевикам

Художник К. Спасский
Литературно-издательский отдел
Политуправления Реввоенсовета Республики
Москва, РСФСР
1919 г.
Бумага; типографская печать
52×66 см
МЗСБ КП-1092

---

В период Гражданской войны на Дону сложилась особенно острая социально-экономическая и политическая обстановка. Именно здесь сосредоточились наиболее организованные непролетарские массы России – казачество. Амплитуда колебаний настроений казачества была очень велика. Основной целью агитационной работы было мобилизовать казаков вместе с рабочими и беднейшим крестьянством на сознательную борьбу с врагами советской власти.

Агитационный плакат, выполненный в лубочном стиле, состоит из шести картинок-сюжетов. Картинки поочередно показывают: мобилизацию в Донскую армию казака Еремы, боевые действия Красной и Белой армий, в результате которых казак Ерема попадает в плен. Далее казак Ерема среди красноармейцев на пропагандистских курсах, в деревне и в городе, видит большие перемены в жизни простого народа. Поняв, что только народ поведет казачество к правде, казак Ерема принимает решение биться вместе с народом против врагов советской власти до победного конца. Основные лозунги момента «Да здравствует власть Советов!», «Долой Деникина и всех царских генералов» размещены в центральной части. Плакат состоит из нескольких частей. Рассказ о казаке Ереме в картинках сопровождается стихотворным текстом:

По команде атамана
Затрещали барабаны…
По приказу царских слуг
Казаки собрались в круг.
Говорит начальство: – Братцы!
Завтра нам придется драться!
Коммунистов разобьем
И как прежде заживем!..
Хором пули засвистели,
Рвутся бомбы и шрапнели!
Рвется трудовой народ
С красным знаменем вперед!..
Словно дикие индейцы,
На конях белогвардейцы
За Деникиным идут,
Помощь богачам несут.
Но рабочих красных войско
Бьет погонников геройски!..
Враг не выдержал – сбежал, –
И Ерема в плен попал… 

Наш казак в плену как дома.
Будто с детства все знакомо,
Всяк ему в глаза глядит,
Всякий правду говорит;
Громко речи зазвучали,
В сердце пленнику запали.
Понял он, что лишь народ
К правде, к свету поведет!
А когда прочел он книжки
Про помещичьи делишки,
Понял сразу в тот же миг,
Что за штука большевик!..
Побывал он и в деревне:
Монопольки да харчевни
Приказали долго жить;
Полно им людей травить.
Но зато в советских селах
Всех ребят муштруют в школах,
А бездельникам нет мест:
Кто не трудится – не ест!.. 

Дни за днями пролетают.
Пленник в городе гуляет
Без нужды и без забот…
Вдруг глядит – валит народ,
Песни воли распевает,
Встать за волю призывает,
Рвется крик со всех сторон:
«Все за волю! Все на Дон!»
«Не сражаться с казаками,
А покончить с кулаками!»
«Воле трудовой – венец,
А Деникину конец!. .»
Эй, народ! Ребята! Братцы!
Нам ли кулаков бояться.
Мы прижмем без лишних слов
Кулаками кулаков!..
Вот вам сказка про Ерему,
Эта сказка всем знакома.
Всякий, кто ее прочтет,
Встанет грудью за народ.

Название плаката «Сказ про казака Ерему, попавшего в плен к большевикам» выполнено в виде красной транспарантной ленты, художественно раскинутой над картинками лубка. Надписи: на верхнем поле плаката слева – «Российская Социалистическая Федеративная Советская Республика»; справа – «Пролетарии всех стран, соединяйтесь» и номер плаката «№ 2», внизу – название издательства: «Лит.-Изд. Отд. Полит. Управл. Рев. Воен. Сов. Республики».

И эту падаль на свалку!

Художник К. Спасский
РСФСР
1920 г.
Бумага; типографская печать
27×24 см
МЗСБ КП-4248

---

В январе-феврале 1920 г. было предпринято масштабное наступление Красной армии, в ходе которого на юге России были разбиты войска генерала А. И. Деникина – главной ударной силы Белого движения. Эта победа и поражение А. В. Колчака на Восточном фронте означали коренной перелом в ходе всей Гражданской войны в пользу советской власти.

В этом плакате совмещены элементы героического и сатирического жанров. В центре плаката − красноармейцы, выбрасывающие на свалку изображенного в карикатурной форме генерала, имеющего черты сходства с А. И. Деникиным. На первом плане – выгребная яма, в которой уже находятся император России Николай II, адмирал А. В. Колчак, Хорват и другие лидеры Белого движения. Ниже рамки – надпись: «И эту падаль − на свалку!»

Шкуро

Фрагмент плаката с карикатурами
из серии «Кого мы били»
Художники Кукрыниксы (Куприянов М. В., Крылов П. Н., Соколов Н. А.)
СССР
После 1935 г.
Бумага, типографская печать
34×23 см
МЗСБ КП-4249

---

Шкуро А. Г. − генерал-лейтенант Белой армии. Весной 1918 г. создал белоказачий отряд, был начальником Кубанской казачьей бригады, затем дивизии в армии Деникина. Позже командовал Кубанской армией. В марте-апреле 1920 г. находился в резерве Вооруженных Сил Юга России. Не получив должности в Русской армии, в мае 1920 г. эмигрировал во Францию. А. Г. Шкуро жил в Париже, Берлине, работал наездником в цирке. В центре плаката на фоне горного пейзажа изображен убегающий белогвардейский генерал в черкеске. В нижней части плаката стихотворный текст Д. Бедного:

Слыл Шкуро – по зверству – волком,
Но, удрав от нас пешком,
Торговал с немалым толком
Где-то выкраденным шелком
И солдатским табаком.
Нынче ездит «по Европам»
С небольшим казацким скопом.
Ради скачки верховой
На арене… цирковой.

О бароне Врангеле

Фрагмент плаката с карикатурами
из серии «Кого мы били»
Художники Кукрыниксы
(Куприянов М. В., Крылов П. Н., Соколов Н. А.)
СССР
После 1935 г.
Бумага; типографская печать
34×23 см
МЗСБ КП-4250

---

11 ноября 1920 г. , ввиду безнадежности дальнейшей борьбы за Крымский полуостров, Правитель Юга России и Главнокомандующий Русской армией генерал Врангель П. Н. отдает приказ об «эвакуации и посадке на суда всех, кто разделял с армией ее крестный путь, семей военнослужащих, гражданских лиц». В результате успешно проведенной штабом генерала Врангеля военно-транспортной операции на 126 черноморских судах было вывезено из Крыма более 145 тысяч человек.

Сюжетом плаката послужил момент эвакуации генерала Врангеля на крейсере «Корнилов»: показана сгорбленная худощавая фигура генерала, сидящего на палубе корабля. Изобразительными средствами художник подчеркивает одиночество и трагизм потерпевшего окончательное поражение на Юге России генерала Врангеля, покидающего навсегда российский берег. Плакат сопровождается стихотворным текстом Д. Бедного:

Герр барон фон Врангель тоже –
Видно аспида по роже –
Был, хоть «русская душа»,
Челофек не караша!
Говорил по-русски скверно

И свирепствовал безмерно.
Мы, зажав его в Крыму,
Крепко всыпали ему.
Бросив фронт под Перекопом,
Он подрал от нас галопом. 

Убежал, баронский гнус.
За советским за кордоном
Это б нынешним баронам
Намотать себе на ус!

Оружием мы добили врага. Трудом мы добудем хлеб. Все за работу, товарищи!

Художник Н. Н. Когоут
Литературно-издательский отдел
Политуправления Реввоенсовета Республики
Москва, РСФСР
1920 г.
Бумага; типографская печать
69,6×52,5 см
МЗСБ КП-5569

---

Разгромив к началу 1920 г. основные силы внутренней контрреволюции, Советская Республика приступила к мирному строительству. Гражданская война нанесла огромный ущерб экономике страны. В числе первоочередных ставились задачи преодоления разрухи, подъема промышленности и сельского хозяйства. В 1920 г. промышленное производство составило 15% довоенного уровня; сельское хозяйство по технической оснащенности находилось на уровне 90-х годов ХIХ века.

В сюжете данного агитационного плаката отражен переход к мирному строительству. Перекрещенные винтовки, буденовка символизируют окончание войны. В центре композиции рядом с наковальней показаны бывший красноармеец и работница, занятые созидательным трудом. Массовый характер промышленного производства подчеркивают изображенные на втором плане заводские корпуса и группы рабочих. Перед наковальней − серп и молот, символизирующие союз рабочего класса и крестьянства, который будет способствовать успешному осуществлению социалистических преобразований в экономике. В нижней части плаката призыв: «Оружием мы добили врага. Трудом мы добудем хлеб. Все за работу, товарищи!» Подпись автора в правом нижнем углу. Надписи: на верхнем поле слева – «Российская Социалистическая Федеративная Советская Республика»; справа – «Пролетарии всех стран, соединяйтесь!»; в левом нижнем углу – «№ 87».

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

Художник неизвестен
Бюро производственной пропаганды
при ЦК Всероссийского Союза рабочих
металлистов
Государственное издательство
Москва, РСФСР
1920 г.
Бумага; типографская печать
70,5×52,5 см
МЗСБ КП-5568

---

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

Плакат сюжетно разбит на две части: слева, на фоне силуэта деревни, крестьяне убирают урожай; справа, на фоне силуэтов заводских корпусов, на станках работают рабочие. Произведенные ими хлеб и промышленные товары грузят в железнодорожные составы. На переднем плане – рабочий и крестьянин. Братское рукопожатие символизирует союз трудящихся Советской Республики. Рядом с ними изображены сельскохозяйственные орудия труда и орудия труда промышленного производства. В верхней части плаката надписи: «Р. С. Ф. С. Р.» и «Пролетарии всех стран, соединяйтесь!». В нижней части плаката текст: «Только тесный, неразрывный союз рабочих и крестьян спасёт Россию от разрухи и голода. Рабочие: Дайте деревне земледельческие машины, чтобы увеличить добычу хлеба республике, паровозы, чтобы перевозить хлеб в голодающие центры, Красной  армии − оружие, чтобы защитить советскую власть от капиталистов. Крестьяне: Дайте хлеба рабочим, чтобы они могли работать, продовольствие и фураж Красной армии, чтобы она могла защищать вашу землю от помещиков». Слева от основного текста рядом с издательской эмблемой указано: «Государственное Издательство. 1920 г./ ГИЗ 1167. Тираж 20 000 экз.» Справа: «Бюро производственной пропаганды при Ц.К. Всеросс. Союза Рабочих Металлистов/16-я Гос. типография МСНХ»

Врангель еще жив, добей его без пощады

Художник Д. С. Моор (Орлов)
Литературно-издательский отдел
Политуправления Реввоенсовета Республики
Москва, РСФСР
1920 г.
Бумага; типографская печать
69×50 см
МЗСБ КП-1101

---

В конце апреля 1920 г. на территорию Советской Украины вторглись польские войска. Красная армия вынуждена была перебросить часть сил на Польский фронт. В это же время активизируются на юге России войска генерала П. Н. Врангеля. К 24 июня белогвардейские войска вышли в Северную Таврию, к р. Днепр (у Никополя) и создали непосредственную угрозу Донбассу – угольным запасам страны.

Плакат написан в это трудное для Советской Республики время – в июле 1920 г. и был выпущен огромным тиражом в 65 тыс. экземпляров. Плакат успешно решал конкретные агитационные задачи, четко показывал соотношение сил революции и контрреволюции. Броская композиция, огромный эмоциональный накал характерны для этого плаката. Предельную выразительность образу придает напряженная динамика руки Врангеля, протянувшейся к Донбассу, и взмах сильных рук красноармейца, занесшего над врагом богатырский меч. Эта композиция – центр плаката, идейный смысл. Используется прием противопоставления героики и сатиры, характерный для последующей советской плакатной графики. Фигура красноармейца показана в ореоле света. В правом нижнем углу – карикатурное изображение поверженных белых генералов, в их числе А. И. Деникин и Н. Н. Юденич. В левой нижней части плаката − Донецкий угольный бассейн с шахтами. На территории Донбасса уже одной ногой стоит боец Красой армии. Надписи на верхнем поле плаката: «Российская Социалистическая Федеративная Советская Республика», «Пролетарии всех стран, соединяйтесь!» Внизу слева – «№ 102», в центре – «Типо-литография МГСПХ бывш. Н. М. Машистова» справа издательская эмблема, под ней указано издательство «Литературно-Издательский Отдел Политуправления РВСР».

Знание разорвет цепи рабства

Художник А. А. Радаков
Государственное Издательство
Петроград, РСФСР
1920 г.
Бумага; типографская печать
87×60 см
МЗСБ КП-5567

---

В процессе культурного строительства (1918-1920 гг. ) была выдвинута задача ликвидации неграмотности. 26 декабря 1919 г., в разгар Гражданской войны, был принят первый законодательный акт советской власти о всеобщем обязательном обучении – Декрет «О ликвидации безграмотности среди населения РСФСР». Согласно декрету, все население республики в возрасте от 14 до 50 лет, не умеющее читать или писать, обязательно должно было обучаться грамоте на родном или русском языке. Повсеместно организовывались пункты ликвидации безграмотности. Ликбезы обучали грамоте, давали элементарные знания по обществоведению, технике, агрономии, способствовали политическому просвещению.

В центре композиции агитационного плаката «Знание разорвет цепи рабства» − стопа книг и гусиное перо, создающие аллегорический образ знаний, образования. Прогибающаяся под тяжестью книг толстая металлическая цепь символизирует цепи рабства, которые способен разорвать только вооруженный знанием человек. В левой и правой частях плаката – заводские корпуса. В ярких, лаконичных образах композиции заключена мысль о том, что преодолеть послевоенную разруху, восстановить и построить заводы, фабрики невозможно без глубоких знаний. Подпись автора на желтом поле под изображением центральной композиции: «А. Радаков». В левом углу нижнего поля указано издательство – «Государственное Издательство, Петроград, 1920».

Казак, у тебя одна дорога с трудовой Россией

Художник Д. С. Моор (Орлов)
Литературно-издательский отдел
Политуправления Реввоенсовета Республики
Москва, РСФСР
1920 г.
Бумага; типографская печать
68×50 см
МЗСБ КП-5529

---

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

Можно провести параллели между плакатом и картиной В. М. Васнецова «Витязь на распутье», с которой был взят замысел для центральной части плаката. На плакате показаны три возможных пути казака в новой действительности. В центре композиции изображен казак на коне в полном боевом вооружении. Словно былинный герой, он остановился перед камнем на перепутье трех дорог. На камне надпись: «Направо пойдешь − в лапы белых попадешь. Прямо пойдешь – разденут догола. Налево пойдешь – встретят как родного брата». В верхней части плаката слева на фоне дымящихся труб и заводских корпусов стоит группа рабочих с лозунгом «Да здравствует коммунизм!» В центральной верхней части – капиталист с мешком денег в левой руке и табличка с надписью: «Крестьянский хлеб за царские долги» в правой руке; на шляпе надпись «Антанта». В правой верхней части плаката карикатурно изображен офицер Белой армии в образе хищной птицы.     Главной целью этого агитационного плаката было привлечение казаков на сторону советской власти. Надписи: на верхнем поле плаката –  «Р. С. Ф. С. Р.» и «Пролетарии всех стран, соединяйтесь!» в левом нижнем углу – «№ 132» и «Печатается в количестве 30.000 экземпляров», «Р. В. Ц. Москва»; в правом нижнем углу – «Литературно-Издательский Отдел Политуправления РВСР/Сретенский бульвар, 6».

Неграмотный – тот же слепой, всюду его ждут неудачи и несчастья

Художник А. А. Радаков
Государственное Издательство
Петроград, РСФСР
1920 г.
Бумага; типографская печать
93×63 см
МЗСБ КП-5570

---

Накануне Октябрьской революции неграмотное население в России составляло около 75 %. После декрета 1919 г. о ликвидации безграмотности повсеместно открывались школы грамоты, пункты ликбеза. В 1920-1921 гг. в РСФСР насчитывалось около 40 тыс. ликпунктов. Социалистическое переустройство деревни невозможно было без грамотных крестьян. Большая роль в привлечении народных масс к обучению грамоте отводилось ярким агитационным плакатам с короткими лаконичными текстами. В их числе плакат «Неграмотный − тот же слепой. Всюду его ждут неудачи и несчастья».

В центральной части изображен крестьянин с завязанными глазами, беспомощно вытянувший вперед руки. Он стоит на краю утеса, с которого в бездну срываются камни. Подпись автора и год издания в левом нижнем углу: «А. Радаков, 1920». На нижнем поле плаката слева – издательская марка Государственного Издательства, место и год издания – «Петроград, 1920». Над ними – место печати: «15-я Государственная типография, Петроград, Звенигородская, 11». Вся правая часть нижнего поля плаката занятой рекламой специальной литературы по сельскому хозяйству.

На помощь панам!

Художник В. Н. Дени (Денисов)
Государственное Издательство
Москва, РСФСР
1920 г.
Бумага; типографская печать
56,5×49 см
МЗСБ КП-1278

---

Весной 1920 г. у Советской России появился новый враг – панская Польша. Стремясь захватить правобережную часть Украины и Белоруссии, 25 апреля белополяки начали наступление на Украину. Подготовить и вооружить польскую армию помогли Франция, Великобритания и США. Еще в 1918 г. одним из организаторов военной интервенции против Советской России стал маршал Фош Ф. – председатель Высшего военного совета и Главнокомандующий армиями Антанты. Именно он на Версальской конференции 1919 г. , положившей конец Первой мировой войне, потребовал усиления Польши в противовес Советской России.

В верхней части плаката надпись: «На помощь панам!», внизу – «Последние резервы маршала Фоша». В центре композиции тучная фигура французского маршала Фоша. Он обвешан похожими на обезьянок французскими легионерами. Солдаты африканских колониальных войск стали «последними резервами маршала Фоша для Польши». Маркировка на полях плаката: в левом верхнем углу – «Российская Социалистическая Федеративная Советская Республика»; в правом верхнем углу – «Пролетарии всех стран, соединяйтесь», снизу слева – издательская марка Государственного Издательства, снизу справа – место печати (5-я Государственная типо-литография, Москва)

Врангель идет. К оружию, пролетарии!

Фотокопия плаката художника Н. М. Кочергина
1920 г.
Бумага, фотопечать
36×57,5 см
МЗСБ КП-5528

---

Весной 1920 г. основные соединения Вооруженных Сил Юга России генерала А. И. Деникина потерпели поражение на основных направлениях и отступили в Крым. Командование остатками войск принял генерал П. Н. Врангель. Восстановив боеспособность частей, реорганизовав их в Русскую армию, П. Н. Врангель планировал вернуть богатейшие угольные и хлебные районы юга страны и в дальнейшем развернуть широкие наступательные действия.

В центре плаката показана зловещая фигура генерала Врангеля, бегущего в атаку с шашкой наголо. За Врангелем идут в наступление ряды пехоты и кавалерии Белой армии. Указатель «На Царицын» подчеркивает угрозу выхода Белой армии на те рубежи, на которых она находилась в пору наибольших успехов в 1919 г. Фоном плаката служит коллаж из предметов символики и атрибутики императорской России, Белого движения. Художник не только конкретизирует опасность, но и включает в название мобилизирующий на борьбу с опасностью лозунг «К оружию, пролетарии!»

Ясновельможная Польша – последняя собака Антанты

Художник В. Н. Дени (Денисов)
Литературно-издательский отдел
Политуправления Реввоенсовета Республики
РСФСР
1920 г.
Бумага, типографская печать
67×53 см
МЗСБ КП-1277

---

Уже в начале 1919 г. на передовую антисоветского фронта выдвинулась Польша, поддержанная странами Антанты – Францией и Великобританией. Главной целью польской экспансии на восток стали земли бывшей Российской империи. Пользуясь русской смутой, поляки стремились продвинуться как можно дальше, подчеркнуто игнорируя советские власти. В апреле-августе 1919 г. польские войска захватили почти всю Белоруссию и часть Украины. С конца 1919 г. Антанта начала подготовку польской армии к большому наступлению на Советскую Республику. Это была новая попытка задушить Советскую Россию.

В центральной части плаката изображена голова бульдога в конфедератке – польском национальном мужском головном уборе с пером. Это аллегорический образ Польши. На конфедератке надпись: «Ясновельможная Польша». В правой части плаката – продолжение надписи: «последняя собака Антанты». На металлическом ошейнике бульдога – медаль с гербом первой польской княжеской королевской династии Пястов – белым орлом в короне. В нижней части плаката текст: «Польские паны хотят задушить рабоче-крестьянскую Россию! Смерть ясновельможным панам!» Слева – издательская марка Литературно-издательского отдела Политуправления Революционного Военного Совета Республики и номер плаката «89».

Что несет Деникин рабочим и крестьянам

Художник К. Спасский
Литературно-издательский отдел
Политического управления
Реввоенсовета Республики
Москва, РСФСР
1919 г.
Бумага, типографская печать
52×68 см
МЗСБ КП-1105

---

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

В верхней части плаката его название: «Что несет Деникин рабочим и крестьянам». Над ним надписи: «Российская Социалистическая Федеративная Советская Республика» и «Пролетарии всех стран, соединяйтесь». В верхней левой части плаката, как олицетворение верховной власти, изображен А. И. Деникин на троне, за которым развевается трехцветное знамя. Трон окружают представители социальных слоев, поддерживающих Деникина. Плакат состоит из нескольких сюжетов, изображающих бесчинства деникинцев: горящие избы и белогвардейцы, грабящие крестьян; виселица с повешенными, которую окружают сторонники Деникина; деникинцы, порющие мужиков; деникинцы, подвергающие насилию крестьянок в поле; группа рабочих, гонимых белогвардейцами на работу сквозь ворота фабрики на фоне повешенных товарищей; помещик, гонящий крестьян на поля, рядом с ним – белогвардеец с нагайкой. Картинки снабжены комментариями внизу плаката: «1) Деникинцы разоряют крестьянское хозяйство. 2) Деникинцы вешают и расстреливают рабочих и крестьян. 3) Деникинцы порят мужиков. 4) Деникинцы насилуют девушек. 5)  Деникинцы возвращают фабрики капиталистам. 6) Деникинцы возвращают земли помещикам». Чуть ниже центральной части плаката в рамке − композиция, символизирующая союз рабочих, крестьян и красноармейцев, и призыв к объединению против общего врага: «Дружно в ряд! Врага сокрушим». Слева и справа внизу на полях плаката – издательская марка литературно-издательского отдела Политического управления Реввоенсовета Республики и номер плаката «58».

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

Муляж плаката художника С. М. Мухарского
РСФСР
1918 г.
Бумага, типографская печать
54×32,8 см
МЗСБ НВФ-9730

---

При строительстве Красной армии возникали большие трудности в связи с нехваткой командных кадров. Подготовленных командиров из рабочих и крестьян было мало, а военные специалисты бывшей российской армии, офицеры, часто не пользовались доверием широких революционных масс. Основной формой подготовки младшего и среднего пролетарского состава стали краткосрочные командные курсы и военные школы. В феврале 1918 г. открылись первые 13 курсов подготовки командиров пехоты, артиллерии, кавалерии, военно-технических частей (в сентябре их насчитывалось 34). 24 ноября 1918 г. ЦК РКП (б) совместно с ВЦСПС и Моссоветом обратились к рабочим и крестьянам с воззванием, которое содержало призыв записываться на командные курсы. Этому посвящен плакат.

На первом плане изображена фигура командира Красной армии, увлекающего в штыковую атаку группу красноармейцев. В правой руке командира – шашка, в левой – красное знамя. Сложный рельеф местности: командир на возвышении, из низины за ним устремились в атаку бойцы − подчеркивает авторитетность, лидерские качества командиров – выходцев из среды рабочих и крестьян. В верхней части плаката текст: «Только командиры из среды рабочих и крестьян поведут Красную армию к окончательной победе». В нижней – призыв «Рабочий и крестьянин, записывайся на командные курсы».

Урок 4. «всю жизнь мою несу родину в душе…» — Музыка — 5 класс

Музыка

5 класс

Урок № 4

«Всю жизнь мою несу Родину в душе…»

Перечень вопросов, рассматриваемых по теме:

— знакомство с синтетическим жанром хоровой симфонии-действа через анализ произведения В. А. Гаврилина «Перезвоны»;

— исследование музыкального языка В. А. Гаврилина, берущего истоки в русском национальном фольклоре;

— воплощение литературного первоисточника в вокально-хоровых произведениях Г. В. Свиридова.

Тезаурус

Симфония (от древнегреческого – «созвучие, стройность») – музыкальное произведение для оркестра. Как правило, симфонии пишутся для большого оркестра смешанного состава.

Оратория (лат. oratorium) – крупное музыкальное произведение для хора, солистов и оркестра. Отличается от оперы отсутствием сценического действия, а от кантаты – большими размерами и разветвлённостью сюжета.

Действо – вид церковных служений, имевших театральный, сценический характер, в старину; драматическая пьеса или спектакль в русском театре XVII века.

Кантата (от лат. саntare – «петь») – вокально-инструментальное произведение для солистов, хора и оркестра.

Смешанный хор – наиболее распространенный тип хора, состоящий из мужских и женских голосов. В составе смешанного хора четыре партии: сопрано и альты (женские) и тенора и басы (мужские).

Солист хора — певец, исполняющий сольную партию.

Обязательная литература

Сергеева Г. П. Музыка. 5 класс. Учебник для общеобразовательных организаций. / Г. П. Сергеева, Е. Д. Критская. – 10-е изд., перераб. – М.: Просвещение, 2019. – 159 с.

Теоретический материал для самостоятельного изучения

Писатель и кинорежиссёр Василий Макарович Шукшин писал: «Всю жизнь мою несу Родину в душе, люблю её, жив ею, она придаёт мне силы, когда случается трудно и горько». Эти знаменитые строки можно отнести и к музыке русских композиторов. Народные мотивы вдохновили не одно поколение сочинителей.

Родственным Василию Макаровичу Шукшину по мироощущению был композитор Валерий Александрович Гаврилин. Он был выходцем из народа, из российской глубинки, человеком с непростой судьбой – порождением тревожного времени… Семья Валерия Гаврилина жила в городе Кадников Вологодской области. Так что с ранних лет мальчик впитывал жизнь российской деревни, народный колорит.

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

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

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

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

Вершиной творчества композитора стало монументальное сочинение «Перезвоны» – симфония-действо, написанная для солистов, большого хора, гобоя и ударных. В произведении есть подзаголовок «По прочтении В. Шукшина», где автор указал источник вдохновения – рассказы В. Шукшина.

Уже в названии слышится характер Руси! Испокон веков вся жизнь русских людей сопровождалась звоном колоколов: они и созывали народ в лихую годину, и наполняли землю светлыми переливами в дни больших праздников, и мчались по дорогам России в упряжках под дугой, и разливались смехом в скоморошьих потехах…

Жанр сочинения – симфония-действо – сочетает в себе очень разные черты, в нём сплетаются опера и оратория, симфония и мистерия.

Симфония (от древнегреческого – «созвучие, стройность») – музыкальное произведение для оркестра. Как правило, симфонии пишутся для большого оркестра смешанного состава.

От симфонии в жанр «симфония-действо» перешла масштабность творческого замысла, глубина философского обобщения.

Оратория (лат. oratorium) – крупное музыкальное произведение для хора, солистов и оркестра. Оно отличается от оперы отсутствием сценического действия, а от кантаты – большими размерами и разветвлённостью сюжета.

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

Действо – это древняя форма музыкально-поэтического театра. В русском фольклоре хорошо известна традиция «играть песню». По замыслу композитора, артисты хора должны двигаться по сцене, выражать содержание музыки жестами и мимикой.

Образ главного героя – собирательный. Показана жизнь человека, трудная дорога, а в середине – свет! «Он есть и будет в жизни всегда. И всегда будет любо выйти на простор, взглянуть, как велика и прекрасна Русская земля. И как бы ни менялся мир, есть в нём красота, совесть, надежда», – так писал о своём сочинении сам Валерий Гаврилин.

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

Между частями симфонии звучит «Дудочка», соло гобоя, имитирующее рожок или жалейку. Инструмент, одушевлённый человеческим дыханием, выполняет роль рассказчика, объединяя части в единый замысел. Интонации «Дудочки» печальны и проникновенны, близки к народным плачам.

Монолог главного героя – начало части «Смерть разбойника». Голос звучит как в народных песнях – без всякого музыкального сопровождения, свободно изливающаяся мелодия исполнена грусти.

Многогранность жизни показана в контрасте трагических частей и бытовых зарисовок, где автор использует фольклорные жанры – частушки, страдания или народную кадриль. Звукоподражание, имитация инструментов, возгласы, выкрики, междометия раскрывают многогранность возможностей человеческого голоса и соответствуют народной традиции «пения под язык». Таковы части «Ерунда», «Посиделки» или «Ти-ри-ри». Мелодии их сразу же запоминаются, как будто слушал их всю жизнь.

«Вечерняя музыка» – это любование красотой мира, природы, уходящего дня, рождающее в душе светлое чувство. Здесь нет слов (это хоровой вокализ), но есть многослойная звучащая картина Руси: переклички птиц, звуки жизни, думы людские, песни, колокольный звон. Всё это сливается в единую звуковую палитру, дрожащую в воздухе.

Смысловой кульминацией произведения является «Молитва». Здесь композитор использует текст «Поучения Владимира Мономаха» – литературного памятника XII века (в переводе академика Дмитрия Сергеевича Лихачёва), ставшего первой в истории светской проповедью, актуальной по сей день. Боязнь встать на путь зла, убить в себе духовное, утратить восприятие красоты жизни – эта мысль «Поучения» всегда волновала Валерия Гаврилина и стала основной темой его творчества.

На фоне колокольного звона и песнопения хора с закрытым ртом звучит голос чтеца, каждая фраза очень глубока и проникновенна. Церковные песнопения наводят на мысль о монастыре, но, возможно, речь идёт о «внутренней обители», о человеческой душе, которая будит совесть, стремление к красоте, доброте и правде жизни.

Георгий Свиридов стал первым в истории композитором, обратившимся к творчеству Бориса Пастернака. Поэзией этого писателя композитор восхищался с юношеских лет, но написать музыку к стихам он смог только в 1965 году, создав миниатюрный шедевр – кантату «Снег идёт» для хора и оркестра. В этом цикле композитор, будучи уже зрелым мастером, сумел минимальными средствами выразить суть поэтических строк.

Эту кантату называют «Маленький триптих», так как она состоит из трёх частей: «Снег идёт», «Душа», «Ночь». Их объединяет одна идея – отношение человека ко времени: люди совершенно не ценят время, а ведь оно так скоротечно! Один момент – это миг, и его дважды прожить нельзя.

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

Снег идёт

Снег идёт, снег идёт.

К белым звездочкам в буране

Тянутся цветы герани

За оконный переплёт.

Снег идёт, и всё в смятеньи,

Bсё пускается в полёт, –

Черной лестницы ступени,

Перекрёстка поворот.

Снег идёт, снег идёт,

Словно падают не хлопья,

А в заплатанном салопе

Сходит наземь небосвод.

Словно с видом чудака,

С верхней лестничной площадки,

Крадучись, играя в прятки,

Сходит небо с чердака.

Потому что жизнь не ждёт.

Не оглянешься — и Святки.

Только промежуток краткий,

Смотришь, там и новый год.

Снег идёт, густой-густой.

В ногу с ним, стопами теми,

В том же темпе, с ленью той

Или с той же быстротой,

Может быть, проходит время?

Может быть, за годом год

Следуют, как снег идёт,

Или как слова в поэме?

Снег идёт, снег идёт,

Снёг идет, и всё в смятеньи:

Убелённый пешеход,

Удивленные растенья,

Перекрестка поворот.

1957, Б. Пастернак

Примеры заданий из тренировочного модуля

№ 1. Какой инструмент исполняет интермедии «Дудочка» в хоровой симфонии-действе «Перезвоны» В. А. Гаврилина?

Варианты ответов: кларнет; фагот; гобой; флейта.

На уроке были изучены народные инструменты жалейка и рожок, которые имитируют наиболее близкий им по тембру инструмент симфонического оркестра – гобой.

Правильный ответ: гобой.

№ 2. Установите соответствия: творчество какого из авторов вдохновило композитора на написание музыкального произведения?

Варианты ответов: В. Шукшин; Владимир Мономах; Б. Пастернак; Эпизод «Молитва» из «Перезвонов» В. Гаврилина; «Снег идёт» Г. Свиридова; «Перезвоны» В. Гаврилина.

На уроке был разобран материал о кантате Г. Свиридова «Снег идёт» на стихи Б. Пастернака, а также было озвучено, что симфония-действо В. Гаврилина «Перезвоны» имеет подзаголовок «По прочтении В. Шукшина» и была написана композитором под впечатлением от рассказов писателя. Также упоминается о «Поучении Владимира Мономаха», текст которого лёг в основу эпизода «Молитва» симфонии-действа В. Гаврилина «Перезвоны».

Правильные ответы:

В. Шукшин / «Перезвоны» В. Гаврилина;

Владимир Мономах / Эпизод «Молитва» из «Перезвонов» В. Гаврилина;

Б. Пастернак / «Снег идёт» Г. Свиридова.

Тенденции в синтаксическом анализе: упреждение, байесовская оценка и достаточно хороший анализ

Trends Cogn Sci. Авторская рукопись; доступно в PMC 2019 25 октября. 2014 ноябрь; 18(11): 605–611.

Опубликовано онлайн 2014 сентября 5. DOI: 10.1016/j.tics.2014.08.001

PMCID: PMC6814003

NIHMSID: NIHMS1054897

PMID: 25200381

Авторская информация Количество Copyright и лицензия.0003

Процессы синтаксического разбора устанавливают зависимости между словами в предложении. Эти зависимости влияют на то, как понимающие придают значение составным частям предложения. Классические подходы к синтаксическому анализу полностью описывают его как восходящий анализ сигнала. Более поздние подходы отводят понимающему более активную роль, позволяя индивидуальному опыту, знаниям и убеждениям понимающего влиять на его или ее интерпретацию. В этом обзоре описываются разработки в трех связанных аспектах исследования обработки предложений: упреждающая обработка, байесовские/зашумленные подходы к обработке предложений и гипотеза «достаточно хорошего» синтаксического анализа.

Ключевые слова: синтаксис, синтаксический анализ, теорема Байеса, зашумленные каналы, достаточно хороший синтаксический анализ

Синтаксический синтаксический анализ включает в себя набор мыслительных процессов, которые устраняют разрыв между семантическими процессами на уровне слов и на уровне дискурса. Эти интерфейсные процессы служат для создания или восстановления зависимостей между словами в строке [1–5] (см. [6,7] о роли синтаксиса и грамматики в производстве). Структурные зависимости, концептуальная информация, предоставляемая содержательными словами, и принципы, определяющие, как тематические ролевые назначения выводятся из грамматических функций, определяют стандартную буквальную интерпретацию, приписываемую предложению. Возьмем, к примеру, содержательные слова смущать, медсестра и доктор. Этих слов самих по себе недостаточно, чтобы позволить понимающему сказать, кто что кому сделал (или как, когда и где). Синтаксические подсказки и процессы синтаксического разбора предоставляют информацию, необходимую для определения того, кто что кому сделал. Хотя значение, приписываемое данному высказыванию, зависит от множества факторов, ни одна теория понимания языка не может быть полной без рассмотрения синтаксиса (или грамматики) и синтаксического разбора.

Психолингвисты давно спорят о том, в какой степени синтаксис и синтаксический разбор представляют собой автономную модульную подсистему в более широком наборе языковых процессов производства и понимания [8–11]. Преобладающее мнение состоит в том, что, хотя существуют аспекты синтаксического разбора, которые не могут быть отнесены к другим уровням обработки (например, лексическим или дискурсивным процессам), между синтаксическими процессами и другими аспектами лингвистической интерпретации (например, предшествующим лингвистическим контекстом) существует сильное взаимодействие. , одновременная просодия) и между синтаксическими процессами и аспектами познания вне строго лингвистических систем [3,12-15]. Примеры аспектов интерпретации, которые требуют синтаксических вычислений, включают упаковку фраз (включение или исключение слов из фраз), решения о присоединении модификаторов (в случаях, когда модифицирующее выражение может принадлежать только одному из множества предшествующих слов) и определение тэта. доменов и присвоение тематических ролей (см. Глоссарий), среди прочего [16–19].

Существует общее мнение, что синтаксис играет важную роль в выделении значений, но произошел сдвиг от строго восходящих, последовательных, инкапсулированных взглядов на интерпретацию языка к более интерактивным описаниям. Три набора взаимосвязанных разработок меняют то, как психолингвисты рассматривают языковую интерпретацию в целом и природу процессов синтаксического разбора в частности. К ним относятся относительно недавний акцент на прогнозирующих или упреждающих процессах, применение байесовской оценки вероятности к пониманию языка и изменение взгляда на понимание языка через призму удовлетворительной или достаточно хорошей обработки [20–25].

Языковая интерпретация происходит быстро и поэтапно [26,27]. Понимающие могут определить семантические и синтаксические характеристики слова, а также отношение слова к предыдущему контексту в течение нескольких сотен миллисекунд после встречи с ним. Любая учетная запись, которая предполагает, что обработка происходит строго восходящим образом (анализ сигналов, за которым следует распознавание слов и лексический доступ, за которым следует синтаксический анализ, за ​​которым следует интеграция новой информации с предшествующим синтаксическим и семантическим контекстом), сильно ограничена скоростью. в котором понимающие могут получить доступ к подробной информации о вновь встреченных словах. Один из способов объяснить невероятно быстрый и поэтапный характер интерпретации состоит в том, чтобы предположить, что понимающие предвидят предстоящий ввод, а не пассивно ждут, пока сигнал развернется, а затем реагируют на него. Результаты различных экспериментальных парадигм показывают, что понимающие различают более вероятные и менее вероятные продолжения. При чтении более предсказуемые слова пропускаются чаще, чем менее предсказуемые [28–30]. Эксперименты с визуальным миром также показывают, что понимающие активно предвосхищают или предсказывают неизбежное появление еще не встреченной информации [20]. В этих экспериментах с визуальным миром участники просматривают массив, содержащий изображения различных объектов (например, торта, девушки, трехколесного велосипеда и мыши). При просмотре массива участники слушают предложения. Если предложение начинается «Маленькая девочка будет кататься…», участники делают движения глазами в сторону изображения трехколесного велосипеда еще до смещения глагола «ехать». Однако это не просто рефлекс, основанный на ассоциации между поездкой и трехколесным велосипедом. Если визуальный массив включает в себя маленькую девочку, мужчину, трехколесный велосипед и мотоцикл, участники делают упреждающие движения глаз в сторону трехколесного велосипеда, слушая «Маленькая девочка будет ездить…». Однако они совершают упреждающие движения в сторону мотоцикла в том же визуальном массиве, если подлежащее существительное — «мужчина» (как в «Человек будет ездить. ..»). Потенциальные эксперименты, связанные с событиями, показывают, что контексты, поддерживающие прогнозирование, производят меньшие ответы N400, чем менее поддерживающие контексты, даже когда внутрилексическая ассоциация остается постоянной [31].

Результаты, подобные этому, показывают, что, по крайней мере, в средах обработки, где небольшое количество референтов визуально выделяются, участники способны определить, как предложение может продолжаться. Эти прогнозы могут относиться к тому, какое понятие будет упоминаться следующим, но они могут быть даже более конкретными. Например, исследование потенциалов, связанных с событиями, проведенное ДеЛонгом и его коллегами [32], показало, что понимающие предвидели фонологическую форму предстоящей пары слов (детерминант и существительное). Кроме того, кажется, что участники действуют в соответствии с этими предсказаниями до того, как они получат окончательные восходящие доказательства, подтверждающие или опровергающие предсказание (т. слово, относящееся к этому предмету).

Хотя исследователи согласны с тем, что предвосхищение и предсказание происходят во время интерпретации предложений, точные средства, с помощью которых понимающие получают предсказания, в настоящее время не совсем понятны. Следовательно, нам нужны отчеты, которые могут рассказать нам, как делаются прогнозы, что, в свою очередь, скажет нам, почему одни прогнозы делаются, а другие нет. Гипотезы о том, как делаются прогнозы, включают использование продукционной системы для имитации говорящего [33,76], опору на внутрилексическую активацию распространения [34] или использование схематических знаний о событиях [35]. Простая гипотеза ассоциации слово-слово становится менее правдоподобной из-за экспериментов, показывающих, что синтаксические факторы влияют на реакцию на слово, когда лексическая ассоциация с предшествующим контекстом остается постоянной [36]. Кроме того, слова, которые не соответствуют синтаксически регулируемой тематической роли, не имеют преимущества при обработке просто потому, что они связаны с другими содержательными словами в предложении [37]. Например, слово топор тесно связано с существительным лесоруб. Несмотря на эту сильную ассоциацию, топор не обрабатывается быстрее, чем обычно, во фрейме предложения «Дровосек рубит топор». Интересно, что нейрофизиологическая реакция на слово, связанное с другими содержательными словами в предложении, изменяется в зависимости от предшествующего дискурсивного контекста [31,38–41]. Когда контекст дискурса активирует схему события, которая включает в себя определенное понятие, слово, относящееся к этому понятию, вызовет меньший ответ N400, даже если это слово не подходит, учитывая непосредственный синтаксический контекст. Следовательно, представления знаний о событиях, а не простое лексическое совпадение, по-видимому, предоставляют понимающим основу для получения прогнозов.

Понимающие могут предвидеть неизбежное появление определенных лексических единиц, относящихся к репрезентациям активированных событий. Исследования синтаксических процессов показывают, что понимающие также могут предвидеть структурные свойства предложений до того, как восходящие сигналы предоставят окончательные доказательства в пользу или против данной структурной гипотезы. Идея о том, что на процессы синтаксического анализа может влиять вероятность или правдоподобие определенных синтаксических структур, на самом деле существует уже давно [2,3,42]. Трусвелл и его коллеги были одними из первых, кто представил доказательства того, что условная вероятность структурного анализа в данном контексте влияла на нагрузку обработки, возложенную на понимающего [10,43]. Точное время и природа вероятностных влияний трактуются по-разному в разных подходах к синтаксическому анализу [19].,44–46].

Более поздние эксперименты показывают, что на распознавание слов влияет соответствие между профилем распределения слов по категориям и предшествующим синтаксическим контекстом [47]. Слово, которое является неоднозначным между существительным или глаголом (например, карта, вращение), может использоваться чаще как существительное или как глагол, или может появляться одинаково часто в каждой категории. Слова, не связанные с существительными, требовали больше времени для распознавания в минимальном контексте, который благоприятствовал значению глагола («to card»), в то время как противоположное верно для неоднозначных слов, связанных с глаголом («вращать»). Несколько исследований показывают, что лексическая статистика, связанная с отдельными словами в предложении (например, частота, с которой глагол появляется с прямым дополнением по сравнению с дополнением предложения), влияет на время, необходимое для разбора предложения. Есть также свидетельства того, что синтаксический контекст, в котором появляется слово, влияет на лексическую обработку (распознавание слова/лексическое решение). Подразумевается, что лексический и синтаксический уровни обработки налагают ограничения друг на друга, а не то, что один уровень имеет полный приоритет над другим.

Предыдущие исследования показывают, что понимающие предвидят, как будут продолжаться выражения (с точки зрения понятий, которые, вероятно, будут упомянуты, формы, которые будут использоваться для обозначения этих понятий, и синтаксические структуры, которые, вероятно, будут выражены). Выполнение таких прогнозов влечет за собой предпочтение понятий, которые имеют отношение к описываемой ситуации, а также может повлечь за собой предвосхищение неизбежного появления определенных слов. Точно так же понимающие могут разрабатывать гипотезы, которые дают некоторым синтаксическим структурам преимущество перед другими в упреждающей манере. Информация, которая в каком-то смысле более предсказуема или более актуальна, будь то лексическая, концептуальная или структурная, должна активироваться сильнее, чем другие виды информации. В этом случае понимающий должен иметь какие-то средства для определения того, что более вероятно, а что менее вероятно. Недавние подходы к обработке предложений включают три утверждения, относящиеся к предсказанию. Во-первых, у понимающих нет достоверного внутреннего представления входных данных [48,49].]. Во-вторых, понимающие используют всю доступную информацию для вычисления вероятности различных интерпретаций с учетом подсказок, доступных на входе [21, 24, 50–54]. В-третьих, неудачные прогнозы являются важным фактором онлайн-реакции на входные данные и способа получения знаний о языке [50]. Неожиданные отчеты предполагают, что информационная ценность данного слова в предложении зависит от его вероятности в контексте. Слова, которые относительно менее вероятны, будут нести больше информации, чем слова, которые более вероятны. При прочих равных менее вероятные (более удивительные) слова приводят к большим изменениям в базе знаний, которая используется для получения прогнозов (см. [55, 56] для родственного подхода).

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

Формулировка Гибсона и его коллег этого типа учета вводит идею о том, что степень воспринимаемого шума и предположения о видах искажений, которые могут возникнуть из-за шума, влияют на интерпретации, которые понимающие приписывают предложениям [24]. Учитывая, что канал передачи зашумлен, компоновщик может предположить, что в сигнале отсутствует компонент. Шум не обязательно должен быть чисто экологическим. «Внутренний шум» может быть вызван невнимательностью, рассеянностью, усталостью или скукой. Эти внутренние факторы влияют на скорость усвоения информации, а также на характер и качество долговременной памяти для языкового ввода [57–59].].

Понимающие с меньшей вероятностью предположат, что к сигналу было добавлено что-то ложное. Это приводит к предсказаниям того, как понимающие люди будут реагировать на определенные типы предложений, которые (если сигнал воспринимается точно) являются аномальными. Например, если человек услышал или прочитал «Мать дала свечу девочке», это менее разрушительно, чем слушание или чтение «Мать дала девочке свечу» (хотя лицензированная интерпретация в обоих случаях одинакова). В первом случае предложение можно «исправить», предположив, что шум стер часть сигнала между «свечей» и «то». Шум — менее правдоподобное объяснение аномалии во втором предложении. Гибсон и его коллеги показали, что метрика отклонения, основанная на количестве и типах правок, необходимых для того, чтобы сделать семантически аномальное предложение правдоподобным, дает точные оценки степени, в которой участники оценивают аномальное предложение как правдоподобное. Эти различия в приемлемости не предсказываются объяснением, согласно которому понимающие всегда правильно воспринимают предложение.

Подобные допущения могут объяснять другие эффекты синтаксической сложности [60] и интерференционные эффекты, основанные на сходстве [60,61]. Основанная на памяти интерференция основана на идее, что мысленные представления могут мешать друг другу и что более сходные мысленные представления мешают друг другу больше, чем менее похожие представления. Это напоминает систематическое неправильное восприятие, которое, как предполагается, лежит в основе ошибок интерпретации в отчетах о зашумленных каналах. «Доктор» и «адвокат» могут быть трудно различимы на семантическом уровне точно так же, как «в» и «как» трудно различить на фонологическом уровне. Последняя проблема была заявлена ​​сторонниками шумных каналов для объяснения явлений обработки в определенном типе сложных предложений «садовой дорожки» [62]. Структуры, предъявляющие более высокие требования к памяти, могут быть более восприимчивы к шуму (внутреннему или внешнему). Точно так же шум может иметь больший эффект, когда два репрезентации более похожи с точки зрения их фонологии (например, медсестра-кошелек) или значения (например, доктор-адвокат), чем когда они более различны (медсестра-сумочка, доктор-хомяк). 63].

В то время как байесовская оценка и гипотезы зашумленного канала объясняют различные эмпирические явления, остается неясным, применимы ли вычисления, полученные для конкретных типов предложений, для естественного языка в более широком смысле. Это происходит из-за комбинаторного взрыва, который происходит в любой системе, которая должна вычислять интерпретации, как для сигнала, так и для ближайших соседей по разным измерениям (фонологическим, лексическим, синтаксическим) и разным размерам зерна [64]. Байесовские подходы к синтаксическому анализу предполагают, что понимающий должен вычислить и оценить не только синтаксические структуры и интерпретации, которые могут быть присвоены точно воспринятой строке, но также и все ближайшие соседи, которые могут быть получены в результате редактирования строки. Учитывая количество возможных лексических, структурных и семантических замен, число рассчитанных интерпретаций было бы астрономическим. Однако могут существовать способы ограничения пространства поиска таким образом, чтобы это пространство постоянно включало предполагаемую интерпретацию, не требуя вычисления и оценки огромного количества альтернативных интерпретаций [65].

Леви [49] отметил, что байесовские модели с зашумленным каналом столкнулись с проблемой предсказания и объяснения большого разнообразия экспериментальных результатов в самых разных задачах и типах предложений. Байесовские модели с зашумленным каналом могут сопротивляться масштабированию по нескольким причинам. В настоящее время большая часть эмпирических данных о моделях зашумленных каналов исходит из суждений о предложениях, своего рода «автономной» задачи. Офлайн-задачи — это те, которые измеряют последствия осмысления, а не сам процесс осмысления. Учетная запись с полным покрытием должна быть в состоянии обрабатывать результаты работы как в автономном, так и в онлайновом режиме. Во-вторых, неясно, почему система, которая безразлична к точной природе сигнала, может надежно и очень быстро обнаруживать неграмматические ошибки. Однако, как отмечают Филлипс и Льюис, понимающие «обнаруживают практически любую лингвистическую аномалию в течение нескольких сотен миллисекунд после появления аномалии во входных данных» ([66], стр. 19).). В-третьих, некоторые онлайновые подтверждения гипотезы зашумленного канала исходят из очень ограниченных сред обработки. Например, статья Леви и его коллег по обработке редуцированных относительных предложений была сосредоточена на возможности того, что понимающие могут ошибочно воспринимать слово «at» как слово «as» [62]. Понимающие часто неверно истолковывают такие предложения, как «Тренер улыбнулся игроку, бросившему фрисби», как означающие, что игрок бросил фрисби (грамматика разрешает значение, что кто-то бросил фрисби игроку). Модель шумного канала приписывает эту неверную интерпретацию неправильному восприятию предложения (люди слышат его как «Тренер улыбнулся 9».0005 как игрок бросил фрисби’). В эксперименте 2009 года все экспериментальные предложения имели сокращенные относительные предложения в позиции объекта, и всем им предшествовало слово «at». Тем не менее, трудности с обработкой и неверная интерпретация могут остаться, даже если слово «в» было заменено различными другими словами (улыбался рядом…, улыбался перед…, с тоской улыбался в сторону…), которые не так легко спутать с « as’, хотя соответствующий эксперимент не проводился. Наконец, как отмечают Пылкканнен и МакЭлри, любой вид неполной спецификации, включая модели зашумленных каналов, может оказаться неспособным объяснить, как в первую очередь конструируются новые значения ([67], с. 540). Интерпретационные системы, основной функцией которых является распознавание образов, не могут, без некоторых важных дополнений, присваивать значения незнакомым образцам. Также, вероятно, нецелесообразно допускать синтаксическую недоопределенность в производстве, поскольку говорящие должны в конечном итоге выбрать один набор морфосинтаксических и фонологических форм для любого данного предложения [6,7]. Понимание и производство не обязательно должны работать совершенно одинаково, но есть существенные доказательства общей репрезентации и сходных, если не идентичных, процессов построения синтаксической структуры в процессе производства и понимания [68].

Подходы байесовского/шумового канала к синтаксическому анализу предполагают, что интерпретация может быть основана не на произведенном сигнале, а на аппроксимации сигнала распознавателем. Это приближение зависит как от сигналов, извлеченных из сигнала, так и от предшествующих убеждений о событиях, о том, что говорящие, вероятно, скажут об этих событиях, и как они, вероятно, будут структурировать свои выражения. Эти предположения в значительной степени, если не полностью, совместимы с направлением исследований, основанным на гипотезе достаточно хорошего синтаксического анализа [22,23,69].]. Феррейра и его коллеги обнаружили, что понимающие часто получают значения, несовместимые с грамматически лицензированными интерпретациями временно синтаксически неоднозначных предложений, а также предложений, которые были однозначными. Например, участники интерпретировали фразу «Пока Мэри одевала ребенка, игравшего на полу» как означающего, что Мэри одевала ребенка. Это значение не лицензируется сигналом (лицензионное значение состоит в том, что Мэри одевалась). Понимающие также систематически неправильно интерпретируют семантически аномальные предложения (предложения, для которых лицензированное значение неправдоподобно), особенно когда синтаксическая структура встречается реже или неканонична. Понимающие будут склонны интерпретировать предложение пассивного залога «Мышь была съедена сыром» как означающее, что мышь съела сыр. Эта тенденция сильнее, чем для предложений с активным залогом, таких как «Сыр съел мышь» (). Имеются также некоторые свидетельства того, что понимающие не разрешают синтаксическую двусмысленность, связанную с присоединением модификаторов, если к этому специально не побуждаются вопросы на понимание [70], хотя этот эффект различается в зависимости от языка и может зависеть от объема рабочей памяти понимающих [71,72]. . Поскольку интерпретации понимающих в этих исследованиях систематически склонялись к правдоподобным значениям, эти результаты предлагают четкую демонстрацию эффектов предшествующих знаний и убеждений. То есть они указывают на то, что аномальные интерпретации не принимаются, даже если синтаксис предложения дает четкие указания на то, что имелось в виду аномальное значение. Таким образом, результаты прямо совместимы с байесовским/зашумленным канальным подходом к интерпретации предложений.

Открыть в отдельном окне

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

Эти результаты сами по себе не делают различий между двумя гипотезами, касающимися синтаксического и семантического анализа. Во-первых, понимающие вычисляли синтаксическую форму в соответствии с доступными сигналами, производили семантические интерпретации на основе синтаксической формы, а затем отвергали эти значения, поскольку они противоречили предшествующим убеждениям (например, мыши едят сыр, а не наоборот). Во-вторых, семантические интерпретации были получены из лексического содержания предложений без использования синтаксически обусловленного распределения тематических ролей. Эта последняя гипотеза синтаксической недостаточной спецификации будет совместима с предложением о зашумленных каналах (т. Е. Пониматели получают приблизительный набор структур для данной строки). Однако недавняя работа, посвященная реакции понимающих на возвратные местоимения, ставит под сомнение гипотезу синтаксической недоопределенности [73]. При чтении предложений, похожих на «После того, как позвонил банкир, отец/мать Стива забеспокоились и дали себе пять дней на ответ», читатели продемонстрировали эффект гендерного несоответствия на возвратное местоимение «сам». Это означает, что читатели тратили больше времени, когда местоимение (сам) не соответствовало роду предшествующего существительного (мать).

Этот эффект несоответствия должен возникать только в том случае, если понимающие построили детальную синтаксическую структуру предложения (на основе предыдущих исследований влияния структуры предложения на кореферентность) [14,61]. Эти результаты показывают, что понимающие не недооценивают синтаксическую форму, но правдоподобные семантические интерпретации, полученные в начале предложения, не всегда замещаются на основе более поздних событий обработки [74–76]. Следовательно, хотя понимающие могут отдавать предпочтение разумным интерпретациям менее разумным (основанным на общем знании мира или информации, предоставленной из контекста), это не означает, что синтаксические структуры не вычисляются или не способствуют интерпретации предложений. Если это верно, может потребоваться модификация предположения о зашумленном канале о недоопределенном синтаксисе. Если бы было отброшено предположение о множественных активациях синтаксической структуры, взвешенных по частоте и сходству с сигналом, потребовалось бы другое объяснение эффектов расстояния редактирования. Возможно, такие эффекты могут быть результатом тех видов процесса восстановления, которые предполагаются отчетами о синтаксическом повторном анализе или самоконтроле и самокоррекции во время производства речи. Согласно такому подходу, понимающие будут строить и оценивать по одной синтаксической структуре за раз. Когда эта структура приводила к ошибочной интерпретации, понимающие лица предпринимали пересмотр синтаксической структуры или редактирование на основе слов (например, «сыр» редактируется как «шеф»), чтобы согласовать интерпретации на уровне слова, синтаксиса и предложения.

Гипотеза Байеса/зашумленного канала отвечает на несколько вопросов о том, как делаются прогнозы. Например, это указывает на то, что условная вероятность различных синтаксических интерпретаций вычисляется путем объединения информации о базовой скорости с оценкой вероятности на основе подсказок. Другие вопросы о том, как составляются прогнозы, остаются без ответа. Делаются ли прогнозы ступенчато или прогнозирование работает как неявный лексический отбор, когда в конечном итоге выбирается один кандидат? Зависит ли предсказание от подражания говорящему или пишущему? Если это так, то можно было бы ожидать, что принуждение понимающих к скрытой артикуляции нарушит процесс предсказания. Другой набор вопросов касается того, в какой степени для предсказания требуются свободные ресурсы внимания и рабочей памяти. Если предсказание зависит от свободных ресурсов, можно было бы ожидать увидеть индивидуальные различия. Понимающие люди с лучшим исполнительным контролем или большим объемом рабочей памяти должны делать больше предсказаний и предсказывать с большим успехом, чем понимающие с меньшими ресурсами. Индивидуальные различия также могут быть обнаружены в том, как понимающие приобретают знания, лежащие в основе оценок априорной вероятности. Учитывая, что байесовское объяснение апеллирует к исходной информации как к фактору, влияющему на предсказание, разные понимающие с разным воздействием языкового ввода должны делать разные предсказания или, по крайней мере, делать одни и те же предсказания с разной степенью достоверности. Учитывая, что знание событий используется для предсказаний [39], понимающие с разной степенью знаний в данной области контента должны делать разные прогнозы, основанные на их разных концептуализациях предметной области. Здесь снова ресурсы могут быть важным фактором. Если сбор априорных данных является бесплатным и автоматическим, простое знакомство с шаблонами в языке должно привести к априорным оценкам вероятностей, которые точно соответствуют общеязыковым шаблонам. Если, однако, корректировка априорных значений зависит от несоответствия между прогнозируемым и наблюдаемым вводом, если для создания прогноза требуется имитация говорящего и если все это требует некоторой степени внимания, простое воздействие не приведет к получению информации о базовой частоте или изменениям. в существующих оценках априорной вероятности. Если это так, факторы, связанные с задачей, влияющие на глубину обработки, могут играть важную роль в получении и модификации информации о базовой частоте [70,77]. Все эти вопросы потребуют тщательного изучения, прежде чем можно будет с уверенностью делать заявления.

Классические отчеты о синтаксическом разборе представляют его как в значительной степени реактивный процесс. Согласно этим классическим взглядам идентифицируются слова, вычисляются синтаксические зависимости и структурированные последовательности подвергаются семантическому анализу. Этот восходящий, инкапсулированный взгляд на обработку не предлагает элегантных или четких объяснений экспериментальных результатов, таких как выводы Альтмана и Камиде о том, что внимание переключается на концепции, которые еще не имеют аналога в сигнале [20]. Альтернативные подходы включают представление о том, что понимающие используют предварительные знания, чтобы предсказать, как строка может развернуться с точки зрения как ее лексического и семантического содержания, так и ее синтаксической структуры. Гипотеза шумового канала развивает этот подход, сосредотачиваясь на тех предположениях, которые имеют интерпретаторы относительно искажения сигнала. Байесовские подходы, как и предшествующие лексикалистские подходы к синтаксическому анализу, основанные на ограничениях, предполагают, что синтаксический анализ строки влечет за собой одновременное вычисление и оценку набора структурных и семантических альтернатив. Гипотеза достаточно хорошего синтаксического анализа напоминает байесовские/зашумленные версии в том смысле, что она предполагает, что предшествующие убеждения понимающих сильно влияют на интерпретацию, полученную для данного предложения. Это предположение подтверждается выводами о том, что понимающие предпочитают правдоподобные, незаконные интерпретации неправдоподобным, грамматически обоснованным интерпретациям.

Этот проект был поддержан Национальным научным фондом (1024003, 0541953) и Национальным институтом здравоохранения (1R01HD073948, MH099327). Автор благодарит доктора Киля Кристиансона и двух анонимных рецензентов за проницательные комментарии к предыдущему проекту.

Событийные потенциалы (ERP)	Когда нейроны возбуждаются, они генерируют электрический ток, который можно обнаружить на коже головы. Нейронная активность производит систематические колебания электрического тока. Эта активность возникает в ответ на различные раздражители. Представление стимула приводит к ERP — модели электрической активности на скальпе, которая возникает из-за стимула.
Размер зерна	Вероятностные расчеты, включая расчеты байесовского/зашумленного канала, предполагают, что люди отслеживают закономерности в языке. Эти паттерны могут встречаться на разных уровнях специфичности. Например, наиболее распространенной структурой в английском языке является существительное-глагол-существительное (NVN) (подлежащее-глагол-дополнение). Это очень крупный размер зерна. Однако такой глагол, как чихать, почти никогда не имеет прямого дополнения. Чаще всего выражается как существительное-глагол (NV). Так, при мелкой зернистости чих, скорее всего, появится в структуре NV. При большем размере зерна наиболее вероятна структура NVN.
Лексическое совпадение	некоторые слова чаще встречаются вместе, чем другие; скорее полицейская машина, чем полицейская кошка.
Лексическая единица/лексическая обработка	лексическая единица представляет собой примерно одно слово. Лексическая обработка относится к умственным операциям, которые извлекают или активируют сохраненные знания о словах по мере необходимости во время понимания и производства.
Ответ N400	N400 является характеристикой мозговых волн. Амплитуда (размер) N400 связана с тем, как часто слово появляется в языке, насколько хорошо значение слова соответствует его контексту, а также с другими факторами, которые упрощают или затрудняют идентификацию и интеграцию слова.
Сокращенные относительные предложения	относительные предложения — это выражения, которые изменяют предшествующие существительные. Они часто обозначаются релятивизатором, таким словом, как «это». В выражении «Кошка, которая нравится моей сестре», «которая нравится моей сестре» является придаточным предложением, модифицирующим кошку. Если бы слово «это» было удалено, относительное предложение было бы уменьшенным относительным предложением.
Схема	структура знаний в долговременной памяти, отражающая знания человека об определенном событии. Например, схема ресторана кодирует типичных участников, объекты и события, происходящие при посещении ресторана.
Дополнение предложения	иногда глаголы появляются вместе с целым предложением в качестве аргумента (в отличие, например, от одного именного словосочетания). В предложении «Джон знает, что ответ есть в книге», «ответ есть в книге» является дополнением предложения, которое регулируется глаголом «знает». (Что знает Джон? Что ответ есть в книге.)
Синтаксический анализ	включает набор умственных операций, которые обнаруживают и используют подсказки в предложениях, чтобы определить, как слова соотносятся друг с другом.
Синтаксическая структура	мысленное представление, фиксирующее зависимости между словами в предложениях.
Тематические роли	абстрактные семантические классы, которые охватывают общие роли, которые множество различных сущностей и объектов играют в разных предложениях. Например, в предложениях «Джон пил молоко» и «Джон дразнит медведей» Джон является инициатором описываемого действия. Джон — тематический агент. В двух предложениях молоко и медведи находятся на принимающей стороне действия, поэтому они являются тематическими пациентами.
Тета-домены	согласно Фрейзеру и Клифтону [16] некоторые слова в предложениях отводят тематические роли другим словам в предложении. Тета-домен — это часть предложения, для которой данное слово отводит тематические роли.

1. Фрейзер Л. (1979) О понимании предложений: стратегии синтаксического разбора, Лингвистический клуб Университета Индианы [Google Scholar]

2. Форд М. и другие. (1982) Теория синтаксического закрытия, основанная на компетентности. В «Ментальном представлении грамматических отношений» (Бреснан Дж. В., изд.), стр. 727–79.6, MIT Press [Google Scholar]

3. MacDonald MC и другие. (1994) Лексическая природа разрешения синтаксической неоднозначности. Психол. Преподобный 101, 676–703 [PubMed] [Google Scholar]

4. Pickering MJ and van Gompel RPG (2006) Syntactic parsing In The Handbook of Psycholinguistics (2nd edn) (Traxler MJ and Gernsbacher MA, eds), pp. 455– 503, Elsevier [Google Scholar]

5. Traxler MJ (2012) Introduction to Psycholinguistics: Understanding Language Science, Wiley-Blackwell [Google Scholar]

6. Феррейра В. и Гриффин З. (2006) Свойства производства разговорной речи В Справочнике по психолингвистике (2-е изд.) (Тракслер М.Дж. и Гернсбахер М.А., ред.), стр. 21–60, Elsevier [Google Scholar]

7 Levelt WJM (1989) Speaking: From Intention to Articulation, MIT Press [Google Scholar]

8. Altmann GTM и Steedman MJ (1988) Взаимодействие с контекстом во время обработки предложений человеком. Познание 30, 191–238 [PubMed] [Google Scholar]

9. Fodor JA (1983) Modularity of Mind, MIT Press [Google Scholar]

10. Трусуэлл Дж. К. и другие. (1993) Ограничения, связанные с глаголом, в обработке предложений: отделение эффектов лексического предпочтения от садовых дорожек. Дж. Эксп. Психол. Учиться. Мем. Когн 19, 528–553 [PubMed] [Google Scholar]

11. Клифтон С. и другие. (2003) Использование информации о тематических ролях при синтаксическом анализе: пересмотр автономии синтаксической обработки. Дж. Мем. Ланг 49, 317–334 [Google Scholar]

12. Федоренко Е. и другие. (2009) Структурная интеграция языка и музыки: свидетельство общей системы. Мем. Когн 37, 1–9[PubMed] [Google Scholar]

13. Шафер А.Дж. и другие. (2005) Влияние просодии на создание и понимание синтаксической двусмысленности в игровой задаче разговора В подходах к изучению использования языка в мире: психолингвистические, лингвистические и вычислительные взгляды на соединение продукта и традиции действия (Таненхаус М. и Трусвелл Дж., ред.), стр. 209–225, MIT Press [Google Scholar]

14. Scheepers C. и другие. (2011) Структурное прайминг в когнитивных областях: от простой арифметики до прикрепления относительных предложений. Психол. наука 22, 1319–1326 [PubMed] [Google Scholar]

15. Tanenhaus MK и другие. (1995) Интеграция визуальной и лингвистической информации в понимание устной речи. Наука 268, 1632–1634 [PubMed] [Google Scholar]

16. Frazier L and Clifton C Jr (1996) Construal, MIT Press [Google Scholar]

17. Frazier L and Fodor JD (1978) Колбасная машина: a новая двухэтапная модель синтаксического анализа. Познание 6, 291–325 [Google Scholar]

18. Jackendoff R (2002) Foundations of Language, Oxford University Press [Google Scholar]

19. Тракслер М.Ю. и другие. (1998) Дополнительное вложение не является формой разрешения лексической двусмысленности. Дж. Мем. Ланг 39, 558–592 [Google Scholar]

20. Altmann GTM and Kamide Y (1999) Инкрементальная интерпретация глаголов: ограничение области последующей ссылки. Познание 73, 247–264 [PubMed] [Google Scholar]

21. Браун М. и другие. (2012) Синтаксис кодирует информационную структуру: свидетельство понимания прочитанного в Интернете. Дж. Мем. Ланг 66, 194–209 [Google Scholar]

22. Феррейра Ф. и другие. (2002) Достаточно хорошие представления в понимании языка. Курс. Реж. Психол. наука 11, 11–15 [Google Scholar]

23. Феррейра Ф. и Патсон Н.Д. (2007) «Достаточно хороший» подход к пониманию языка. Ланг. Лингвист. Компас 1, 71–83 [Google Scholar]

24. Гибсон Э. и другие. (2013) Рациональная интеграция зашумленных свидетельств и предшествующих семантических ожиданий в интерпретации предложений. проц. Натл. акад. науч. США 110, 8051–8056 [бесплатная статья PMC] [PubMed] [Google Scholar]

25. Маховальд К. и другие. (2012) Информация/теория информации: говорящие выбирают более короткие слова в прогностическом контексте. Познание 126, 313–318 [PubMed] [Google Scholar]

26. Marslen-Wilson WD (1973) Лингвистическая структура и затенение речи при очень коротких задержках. Природа 244, 522–523 [PubMed] [Google Scholar]

27. Марслен-Уилсон В. Д. и Тайлер Л. К. (1975) Обработка структуры восприятия предложений. Природа 257, 784–786 [PubMed] [Google Scholar]

28. Rayner K (1998) Движения глаз при чтении и обработке информации: 20 лет исследований. Психол. Бык 124, 372–422 [PubMed] [Google Scholar]

29. Rayner K and Pollatsek A (1989) The Psychology of Reading, Erlbaum [Google Scholar]

30. Choi W and Gordon PC (2014) Пропуск слов во время чтения предложений: влияние лексики на парафовеальную обработку. Аттен. Восприятие. Психофиз 76, 201–213 [бесплатная статья PMC] [PubMed] [Google Scholar]

31. Lau EF и другие. (2013) Диссоциация эффектов предсказания N400 от ассоциации в контекстах, состоящих из одного слова. Дж. Когн. Неврологи 25, 484–502 [бесплатная статья PMC] [PubMed] [Google Scholar]

32. Делонг К. и другие. (2005) Вероятностная предварительная активация слов во время понимания языка, выведенная из электрической активности мозга. Нац. Неврологи 8, 1117–1121 [PubMed] [Google Scholar]

33. Пикеринг М.Дж. и Гаррод С. (2013) Интегрированная теория языкового производства и понимания. Поведение наука о мозге 36, 329–347 [PubMed] [Google Scholar]

34. Schwanenflugel PJ and LaCount KL (1988) Семантическая связь и объем облегчения для следующих слов в предложениях. Дж. Эксп. Психол. Учиться. Мем. Когн 14, 344–354 [Google Scholar]

35. Schank R and Abelson RP (1977) Scripts, Plans, Goals, and Understanding: An Inquiry in Human Knowledge Structures, Erlbaum [Google Scholar]

36. Morris RK (1994) Влияние контекста предложения на уровне лексики и сообщения на время фиксации при чтении. Дж. Эксп. Психол. Учиться. Мем. Когн 20, 92–103 [PubMed] [Google Scholar]

37. Traxler MJ и другие. (2000) Эффекты обработки при понимании предложений: эффекты ассоциации и интеграции. Дж. Психолингвист. Рез 29, 581–595 [PubMed] [Google Scholar]

38. Camblin CC и другие. (2007) Взаимодействие конгруэнтности дискурса и лексических ассоциаций во время обработки предложений: данные ERP и отслеживания взгляда. Дж. Мем. Ланг 56, 103–128 [бесплатная статья PMC] [PubMed] [Google Scholar]

39. Метусалем Р. и другие. (2012) Активация обобщенных знаний о событиях во время понимания онлайн-предложений. Дж. Мем. Ланг 66, 545–567 [бесплатная статья PMC] [PubMed] [Google Scholar]

40. Hess DJ и другие. (1995) Влияние глобального и локального контекста на лексическую обработку во время понимания языка. Дж. Эксп. Психол. Генерал 124, 62–82 [Google Scholar]

41. Тракслер М.Дж. и Фосс Д.Дж. (2000) Влияние ограничения предложения на прайминг в понимании естественного языка. Дж. Эксп. Психол. Учиться. Мем. Когн 26, 1266–1282 [PubMed] [Google Scholar]

42. Elman J (1991) Распределенные представления, простые рекуррентные сети и грамматическая структура. Мах. Учиться 17, 195–225 [Google Scholar]

43. Trueswell JC и другие. (1994) Семантические влияния на синтаксический анализ: использование информации о тематических ролях в разрешении синтаксической двусмысленности. Дж. Мем. Ланг 33, 285–318 [Google Scholar]

44. Пикеринг М.Дж. и другие. (2000) Разрешение двусмысленности при обработке предложений: доказательства против учетных записей, основанных на частоте. Дж. Мем. Ланг 43, 447–475 [Google Scholar]

45. Pickering MJ and Traxler MJ (2003) Доказательства против использования частоты подкатегоризации при обработке неограниченных зависимостей. Ланг. Познан. Процесс 18, 469–473 [Google Scholar]

46. Ролевая игра Ван Гомпеля и другие. (2001) Повторный анализ в обработке предложений: доказательства против текущих моделей, основанных на ограничениях, и двухэтапных моделей. Дж. Мем. Ланг 45, 225–258 [Google Scholar]

47. Федоренко Е. и другие. (2012) Взаимодействие источников синтаксической и лексической информации при обработке языка: случай неоднозначности существительного и глагола. Дж. Когн. наука 13, 249–285 [Google Scholar]

48. Леви Р. (2008) Синтаксическое понимание на основе ожиданий. Познание 106, 1126–1177 [PubMed] [Google Scholar]

49. Леви Р. (2008) Модель зашумленного канала рационального понимания предложений человеком при неопределенных входных данных. В материалах конференции 2008 г. по эмпирическим методам обработки естественного языка, стр. 234–243. Ассоциация компьютерной лингвистики [Google Scholar]

50. Hale JT (2001) Ранний вероятностный синтаксический анализатор как психолингвистическая модель. В материалах второго собрания Североамериканского отделения Ассоциации компьютерной лингвистики, стр. 159–166. Ассоциация компьютерной лингвистики [Google Scholar]

51. Хейл Дж. Т. (2011) Что сделал бы рациональный синтаксический анализатор. Познан. наука 35, 399–443 [Google Scholar]

52. Jaeger FT and Snider NE (2013) Выравнивание как следствие адаптации ожиданий: на синтаксическое прайминг влияет ошибка предсказания штриха с учетом как предыдущего, так и недавнего опыта. Познание 127, 57–83 [бесплатная статья PMC] [PubMed] [Google Scholar]

53. Леви Р. и другие. (2013) Обработка экстрапозированных структур на английском языке. Познание 122, 12–36 [бесплатная статья PMC] [PubMed] [Google Scholar]

54. Smith NJ and Levy R (2013) Влияние предсказуемости слов на время чтения логарифмическое. Познание 128, 302–319 [бесплатная статья PMC] [PubMed] [Google Scholar]

55. Chang F и другие. (2006) Становление синтаксическим. Психол. Преподобный 113, 234–272 [PubMed] [Google Scholar]

56. Чанг Ф. и другие. (2012) Языковая адаптация и обучение: разъяснение имплицитного обучения. Ланг. Лингвист. Компас 6, 259–278 [Google Scholar]

57. Рейхле Э.Д. и другие. (2010) Движения глаз во время бездумного чтения. Психол. наука 21, 1300–1310 [PubMed] [Google Scholar]

58. Sayette MA и другие. (2010) Выйти покурить: влияние тяги к сигаретам на зонирование во время чтения. Психол. наука 21, 26–30 [бесплатная статья PMC] [PubMed] [Google Scholar]

59. Schooler JW и другие. (2011) Метасознание, перцептивное разъединение и блуждающий ум. Тенденции Познан. наука 15, 319–326 [PubMed] [Google Scholar]

60. Гибсон Э. (1998) Лингвистическая сложность: локальность синтаксических зависимостей. Познание 68, 1–76 [PubMed] [Google Scholar]

61. Гордон ПК и другие. (2001) Помехи в памяти во время языковой обработки. Дж. Эксп. Психол. Учиться. Мем. Когн 23, 381–405 [Google Scholar]

62. Леви Р. и другие. (2009) Движение глаз свидетельствует о том, что читатели сохраняют неопределенность в отношении прошлой лингвистической информации и действуют в соответствии с ней. проц. Натл. акад. науч. США 106, 21086–21090 [бесплатная статья PMC] [PubMed] [Google Scholar]

63. Acheson DJ и MacDonald MC (2011) Рифмы, которые просматривал читатель, путали смысл: фонологические эффекты при понимании предложений в режиме онлайн. Дж. Мем. Ланг 65, 193–207 [бесплатная статья PMC] [PubMed] [Google Scholar]

64. Mitchell DC (1987) Лексическое руководство при разборе человека: локус и характеристики обработки In Attention and Performance XII (Coltheart M, ed.), стр. 601–618, Erlbaum [Google Scholar]

65. Дубей А. и другие. (2013) Вероятностное моделирование обработки предложений с учетом дискурса. Верхний. Познан. наука 5, 425–451 [PubMed] [Google Scholar]

66. Филлипс С. и Льюис С. (2013) Порядок вывода в синтаксисе: доказательства и архитектурные последствия. Стад. Лингвист 6, 11–47 [Google Scholar]

67. Пылкканнен Л. и МакЭлри Б.Д. (2006) Синтаксис-семантический интерфейс: интерактивная композиция значения предложения. В Справочнике по психолингвистике (2-е изд.) (Тракслер М.Дж. и Гернсбахер М.А., ред.), стр. 537–577, Elsevier [Google Scholar]

68. Тули К.М. и Бок Дж.К. (2014) О соотношении структурной устойчивости в производстве и понимании языка. Познание 132, 101–136 [бесплатная статья PMC] [PubMed] [Google Scholar]

69. Кристиансон К.А. и другие. (2001) Тематические роли, отведенные вдоль садовой дорожки, сохраняются. Познан. Психол 42, 368–407 [PubMed] [Google Scholar]

70. Swets B и другие. (2008) Недостаточная спецификация синтаксической двусмысленности: свидетельство самостоятельного чтения. Мем. Когн 36, 201–216 [PubMed] [Google Scholar]

71. Светс Б. и другие. (2007) Роль рабочей памяти в разрешении синтаксической неоднозначности: психометрический подход. Дж. Эксп. Психол. Генерал 136, 64–81 [PubMed] [Google Scholar]

72. Тракслер М.Дж. (2010)Анализ иерархического линейного моделирования рабочей памяти и имплицитной просодии в разрешении дополнительной двусмысленности привязанности. Дж. Психолингвист. Рез 38, 491–509 [PubMed] [Google Scholar]

73. Слэттери Т.Дж. и другие. (2013) Затянувшиеся неверные толкования предложений садовой дорожки возникают из-за конкурирующих синтаксических представлений. Дж. Мем. Ланг 69, 104–120 [Google Scholar]

74. Кристиансон К. и другие. (2010) Влияние правдоподобия на структурную грунтовку. Дж. Эксп. Психол. Учиться. Мем. Когн 36, 538–544 [PubMed] [Google Scholar]

75. Пикеринг М.Дж. и Тракслер М.Дж. (2001) Стратегии обработки неограниченных зависимостей: лексическая информация и назначение глагол-аргумент. Дж. Эксп. Психол. Учиться. Мем. Когн 27, 1401–1410 [PubMed] [Google Scholar]

76. Pickering MJ и Traxler MJ (1998) Правдоподобие и восстановление с садовых дорожек: исследование слежения за глазами. Дж. Эксп. Психол. Учиться. Мем. Когн 24, 940–961 [Google Scholar]

77. Кристиансон К. и Люк С. (2011) Контекст усиливает первоначальные неверные толкования текста. науч. Стад. Читать 15, 136–166 [Google Scholar]

[PDF] Использование теоретико-модели семантической интерпретации для руководства статистическим анализом и распознаванием слов в интерфейсе разговорного языка

• doi: 10.3115/1075096.1075163
• Corpus ID: 69
  

 @inprisprise @InPRININGES @INPRININGERS.
  title={Использование теоретико-модельной семантической интерпретации для управления статистическим анализом и распознаванием слов в интерфейсе разговорного языка},
  автор={Уильям Шулер},
  название книги={ACL},
  год = {2003}
} 

• Уильям Шулер
• Опубликовано в ACL 7 июля 2003 г.
• Информатика

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

Посмотреть на ACL

DL.ACM.ORG

Совместимость совместного синтаксического и прагматического ограничения Улучшает инкрементное понимание разговорного языка

• A. Peldszus, Okko Buß, Timo Baumann, David Schlangen

• Linguist Linguict, Custick, David Schlangen

• Linguict Linguict, Cuthist.

• 2012

Показано, что совместное удовлетворение синтаксических и прагматических ограничений улучшает производительность компонента NLU (примерно на 10 % в абсолютном выражении по сравнению с базовым уровнем, основанным только на синтаксисе).

Обучение семантическому анализу с использованием методов статистического машинного перевода

• Y. W. Wong

• Информатика

• 2005

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

Он-лайн кросс-модальная контекстная интеграция для анализа естественного языка

• Кристофер Баумгартнер

• Информатика

• 2013

В нашей работе мы представляем систему для интеграции обработки визуальной информации в процесс языковые предложения немецкого языка. Высокоуровневое представление знаний о визуальном контексте — это…

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

• Ю. В. Вонг, Р. Муни

• Информатика

  ACL

• 2007

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

Обучение композиционной семантике на основе зависимостей

• П. Лян, Майкл И. Джордан, Д. Кляйн

• Информатика

  CL

• 2011

Разработан новый семантический формализм, композиционная семантика на основе зависимостей (DCS), определено лог-линейное распределение по логическим формам DCS и показано, что система получает сравнимой точности даже с самыми современными системами, которые требуют аннотированных логических форм.

Вероятностное обоснование ситуативной речи с помощью распознавания плана и эталонного разрешения

• Peter Gorniak, D. Roy

• Информатика

  ICMI ’05

• 2005

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

Программирование агентов с использованием голосовых указаний

• Уильям Шулер

• Лингвистика

• 2003

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

Понимание ситуативного языка как фильтрация воспринимаемых возможностей

• Питер Горняк, Д. Рой

• Психология

  Cogn. науч.

• 2007

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

Концепция, основанная на аффордансе

• Д. Рой, Питер Горняк

• Психология

• 2005

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

Пространственное представление предикатов классификатора для машинного перевода на американский язык жестов

• Matt Huenerfauth

• Лингвистика

• 2004

Хотя большая часть этой работы по ASL MT все еще находится в стадии подготовки, есть надежда, что однажды система MT сможет переводить многие виды предложений с английского на ASL ; хотя некоторые специфические явления ASL, включающие сложное использование пространства для подписи, оказались трудными для традиционных подходов к машинному переводу.

ПОКАЗЫВАЮТСЯ 1-10 ИЗ 16 ССЫЛОК

СОРТИРОВАТЬ ПОРелевантностьНаиболее влиятельные документыНедавность

Характеристика слабо контекстно-зависимых грамматических формализмов

• Дэвид Дж. Вейр, А. Джоши

• Информатика

• 1988

Класс формализмов, называемый Linear Context-Free Rewriting Systems (aFRS) широкий спектр грамматических формализмов с ограниченной мощностью, и доказано, что все члены этого семейства порождают только полулинейные языки, распознаваемые за полиномиальное время.

Структура общих лесов при неоднозначном разборе

• S. Billot, B. Lang

• Информатика

  ACL

• 1989

Контекстно-свободная основа некоторых анализаторов естественного языка производит все возможные анализы CF как своего рода общий лес одно дерево должно быть выбрано с помощью процесса устранения неоднозначности, который…

Лексикализованная грамматика примыкания к дереву для английского языка

• Абей, Кэтлин Бишоп, Шэрон Кот, Ив Шабес

• Лингвистика

• 1990

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

Полностью статистический подход к интерфейсам на естественном языке

• Скотт Миллер, Д. Сталлард, Р. Бобров, Р. Шварц

• Информатика

  ACL

• 1996

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

ОГРАНИЧЕНИЕ СЛАБОЙ ПОРОЖДАЮЩЕЙ СПОСОБНОСТИ СИНХРОННЫХ ГРАММАТИК, ПРИМЕЧАЮЩИХСЯ К ДЕРЕВОМУ

• S. Shieber

• Информатика

  Вычисл. Интел.

• 1994

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

Работа с двусмысленностью путем недоопределения: построение, представление и дедукция

• Уве Рейле

• Философия

  J. Semant.

• 1993

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

Чередование синтаксиса и семантики в эффективном восходящем синтаксическом анализаторе

• Дж. Даудинг, Роберт С. Мур, Ф. Андри, Д. Моран

• Информатика

  ACL

• 1994

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

D-Tree Grammarmars

• Owen Rambow, K. Vijay-Shanker, David J. Weir

• Linguistic

  ACL

• 1995

DTG, Unlike TAG, может обеспечить MAN LAT-MAVEMEMEMEMEMP в английском и кашмирском языках, несмотря на то, что элемент wh в кашмирском языке появляется во втором предложении, а не в начале предложения, как в английском языке.

Грамматики на длинные дистанции и прилегающие к деревьям

• Тилман Беккер, А. Джоши, Оуэн Рамбоу

• Лингвистика

  EACL

• 1991
• 110101010101010101010. формализм для работы с междугородным скремблированием I в немецком языке и показать, что TAG не могут охватить весь диапазон конструкций, полученных скремблированием.

  Формулировка простой теории типов

  • А. Черч

  • Математика

    Дж. Симб. Журнал.

  • 1940

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

  Обработка естественного языка | Бумаги с кодом

  Языковое моделирование

    368 ориентиры
  

  2016 г. документы с кодом

    320 ориентиры
  

  715 листов с кодом

    2 ориентиры
  

  19 листов с кодом

    7 ориентиры
  

  5 листов с кодом

    2 ориентиры
  

  1 бумага с кодом

  2D классификация

    368 ориентиры
  

  2016 г. документы с кодом

    2 ориентиры
  

  60 листов с кодом

    3 ориентиры
  

  38 листов с кодом

  Вопрос Ответ

    155 ориентиры
  

  1656 листов с кодом

    14 ориентиры
  

  119 листов с кодом

    2 ориентиры
  

  39 листов с кодом

  39 листов с кодом

    3 ориентиры
  

  38 листов с кодом

  Посмотреть все 16 задач

  Машинный перевод

    74 ориентиры
  

  1617 бумаг с кодом

  32 бумаги с кодом

    9 ориентиры
  

  28 листов с кодом

  26 документов с кодом

  24 бумаги с кодом

  Посмотреть все 9 задач

  Увеличение данных

    1 ориентир
  

  1507 бумаги с кодом

  70 листов с кодом

  18 документов с кодом

  Обнаружение 2D-объектов

    233 ориентиры
  

  842 бумаги с кодом

    17 ориентиры
  

  187 листов с кодом

  96 листов с кодом

    1 ориентир
  

  89 листов с кодом

    7 ориентиры
  

  74 листа с кодом

  Посмотреть все 8 заданий

  Текстовая классификация

    172 ориентиры
  

  753 бумаги с кодом

    6 ориентиры
  

  172 листа с кодом

    19 ориентиры
  

  170 листов с кодом

    6 ориентиры
  

  84 листа с кодом

    6 ориентиры
  

  66 листов с кодом

  Посмотреть все 14 задач

  Генерация текста

    233 ориентиры
  

  842 бумаги с кодом

    13 ориентиры
  

  149 документов с кодом

    36 ориентиры
  

  82 листа с кодом

    4 ориентиры
  

  72 листа с кодом

    2 ориентиры
  

  63 листа с кодом

  Посмотреть все 22 задачи

  Анализ настроений

    85 ориентиры
  

  972 бумаги с кодом

    31 ориентиры
  

  123 листа с кодом

    4 ориентиры
  

  48 листов с кодом

    3 ориентиры
  

  14 листов с кодом

    1 ориентир
  

  10 листов с кодом

  Посмотреть все 15 заданий

  Распознавание именованных объектов

    86 ориентиры
  

  654 бумаги с кодом

    6 ориентиры
  

  34 листа с кодом

    7 ориентиры
  

  32 листа с кодом

    3 ориентиры
  

  16 листов с кодом

  Посмотреть все 11 задач

  Контрастное обучение

    2 ориентиры
  

  931 бумага с кодом

    1 ориентир
  

  133 бумаги с кодом

  Вложения слов

  977 документов с кодом

  18 листов с кодом

  16 листов с кодом

  6 документов с кодом

  3 листа с кодом

  Обобщение текста

    66 ориентиры
  

  257 листов с кодом

    17 ориентиры
  

  234 бумаги с кодом

    8 ориентиры
  

  152 листа с кодом

    4 ориентиры
  

  72 листа с кодом

    5 ориентиры
  

  28 листов с кодом

  Посмотреть все 12 задач

  Оптическое распознавание символов

    3 ориентиры
  

  466 листов с кодом

    10 ориентиры
  

  189 листов с кодом

    2 ориентиры
  

  41 лист с кодом

    1 ориентир
  

  20 листов с кодом

  5 листов с кодом

  Посмотреть все 9 задач

  Извлечение отношения

    69 ориентиры
  

  469 листов с кодом

    12 ориентиры
  

  109 документов с кодом

    6 ориентиры
  

  40 листов с кодом

  13 листов с кодом

    2 ориентиры
  

  11 листов с кодом

  Посмотреть все 14 задач

  Поиск информации

    11 ориентиры
  

  535 листов с кодом

    3 ориентиры
  

  71 бумага с кодом

  10 листов с кодом

    2 ориентиры
  

  5 листов с кодом

  4 бумаги с кодом

  Визуальный ответ на вопрос

    50 ориентиры
  

  443 бумаги с кодом

    3 ориентиры
  

  144 листа с кодом

  6 листов с кодом

  Логический вывод на естественном языке

    36 ориентиры
  

  532 бумаги с кодом

    1 ориентир
  

  28 листов с кодом

    2 ориентиры
  

  16 листов с кодом

    4 ориентиры
  

  15 листов с кодом

  Понимание прочитанного

    26 ориентиры
  

  414 бумаги с кодом

    3 ориентиры
  

  144 листа с кодом

    1 ориентир
  

  14 листов с кодом

    1 ориентир
  

  9 листов с кодом

    2 ориентиры
  

  8 листов с кодом

  Посмотреть все 20 задач

  Прогноз связи

    77 ориентиры
  

  565 листов с кодом

    2 ориентиры
  

  10 листов с кодом

    2 ориентиры
  

  8 листов с кодом

  1 документы с кодом

  1 документы с кодом

  Посмотреть все 6 задач

  Активное изучение

    3 ориентиры
  

  466 листов с кодом

    2 ориентиры
  

  3 листа с кодом

  Распознавание эмоций

    29 ориентиры
  

  291 бумага с кодом

    7 ориентиры
  

  59 листов с кодом

    9 ориентиры
  

  43 листа с кодом

    2 ориентиры
  

  32 листа с кодом

    2 ориентиры
  

  12 листов с кодом

  Посмотреть все 10 задач

  Понимание естественного языка

    5 ориентиры
  

  424 бумаги с кодом

  2 бумаги с кодом

  Семантическое текстовое сходство

    19 ориентиры
  

  359 листов с кодом

    8 ориентиры
  

  54 бумаги с кодом

  3 листа с кодом

  Извлечение событий

  Диалог

    13 ориентиры
  

  149 листов с кодом

    3 ориентиры
  

  95 листов с кодом

    5 ориентиры
  

  86 листов с кодом

    8 ориентиры
  

  47 листов с кодом

    1 ориентир
  

  23 листа с кодом

  Посмотреть все 20 задач

  Подпись к изображению

    31 ориентиры
  

  386 листов с кодом

  3 бумаги с кодом

  2 листа с кодом

    1 ориентир
  

  2 листа с кодом

    1 ориентир
  

  1 бумага с кодом

  Посмотреть все 6 задач

  Семантический анализ

    36 ориентиры
  

  281 бумага с кодом

    8 ориентиры
  

  36 листов с кодом

    3 ориентиры
  

  12 листов с кодом

    2 ориентиры
  

  4 листа с кодом

    2 ориентиры
  

  4 листа с кодом

  Посмотреть все 6 задач

  Анализ зависимостей

    18 ориентиры
  

  280 листов с кодом

  11 листов с кодом

    1 ориентир
  

  4 листа с кодом

    1 ориентир
  

  3 листа с кодом

    2 ориентиры
  

  3 листа с кодом

  Посмотреть все 6 задач

  Предварительно обученные языковые модели

  282 бумаги с кодом

  Моделирование пар предложений

    7 ориентиры
  

  265 листов с кодом

  Вложения предложений

    3 ориентиры
  

  149 листов с кодом

  85 листов с кодом

    1 ориентир
  

  20 листов с кодом

    2 ориентиры
  

  3 листа с кодом

  2 листа с кодом

  Прогноз траектории

    30 ориентиры
  

  158 листов с кодом

    4 ориентиры
  

  49 листов с кодом

  40 листов с кодом

  Чат-бот

    13 ориентиры
  

  149 листов с кодом

    13 ориентиры
  

  82 бумаги с кодом

  Извлечение информации

    8 ориентиры
  

  79 листов с кодом

  78 листов с кодом

    6 ориентиры
  

  40 листов с кодом

    9 ориентиры
  

  12 листов с кодом

    3 ориентиры
  

  11 листов с кодом

  Посмотреть все 10 заданий

  Многоязычный

    11 ориентиры
  

  169 листов с кодом

    13 ориентиры
  

  12 листов с кодом

  9 документов с кодом

  Корреферентное разрешение

    9 ориентиры
  

  180 листов с кодом

  7 листов с кодом

  Маркировка части речи

    16 ориентиры
  

  179 листов с кодом

  1 документы с кодом

  Тематические модели

    6 ориентиры
  

  172 бумаги с кодом

    3 ориентиры
  

  2 листа с кодом

  Связывание объектов

    23 ориентиры
  

  169 документов с кодом

  Генерация ответа

    1 ориентир
  

  162 листа с кодом

  Рассуждения здравого смысла

    34 ориентиры
  

  134 бумаги с кодом

    1 ориентир
  

  6 листов с кодом

    1 ориентир
  

  5 листов с кодом

    1 ориентир
  

  5 листов с кодом

    1 ориентир
  

  3 листа с кодом

  Посмотреть все 18 задач

  Генерация вопросов

    8 ориентиры
  

  151 бумага с кодом

  Обнаружение злоупотреблений

    18 ориентиры
  

  100 листов с кодом

    18 ориентиры
  

  27 листов с кодом

  Извлечение открытой информации

    8 ориентиры
  

  79 листов с кодом

    15 ориентиры
  

  46 листов с кодом

  Маркировка семантической роли

    8 ориентиры
  

  111 листов с кодом

    2 ориентиры
  

  7 листов с кодом

    2 ориентиры
  

  3 листа с кодом

  1 документы с кодом

  Классификация отношений

    12 ориентиры
  

  109 документов с кодом

    4 ориентиры
  

  7 листов с кодом

  4 бумаги с кодом

  1 документы с кодом

  Значение слова

    15 ориентиры
  

  104 листа с кодом

    2 ориентиры
  

  15 листов с кодом

  Ответы на открытые вопросы

    14 ориентиры
  

  119 листов с кодом

  Сбор данных

    4 ориентиры
  

  53 листа с кодом

  48 листов с кодом

  7 листов с кодом

  7 листов с кодом

  Реляционное мышление

    1 ориентир
  

  112 листов с кодом

  Обнаружение языка ненависти

    18 ориентиры
  

  100 листов с кодом

    5 ориентиры
  

  7 листов с кодом

  2 бумаги с кодом

  2D семантическая сегментация

    2 ориентиры
  

  63 листа с кодом

    10 ориентиры
  

  27 листов с кодом

  6 листов с кодом

    1 ориентир
  

  6 листов с кодом

    1 ориентир
  

  6 листов с кодом

  Посмотреть все 6 заданий

  Идентификация языка

    4 ориентиры
  

  84 листа с кодом

  16 листов с кодом

    1 ориентир
  

  4 листа с кодом

  Обнаружение поддельных новостей

    8 ориентиры
  

  104 листа с кодом

  Сходство слов

  102 бумаги с кодом

  Заполнение слота

    12 ориентиры
  

  90 листов с кодом

    3 ориентиры
  

  8 листов с кодом

    1 ориентир
  

  2 листа с кодом

  Обнаружение предвзятости

  67 листов с кодом

    3 ориентиры
  

  32 листа с кодом

  Генерация кода

    19 ориентиры
  

  89 листов с кодом

    7 ориентиры
  

  4 листа с кодом

  Исправление грамматических ошибок

    14 ориентиры
  

  78 листов с кодом

    4 ориентиры
  

  9 листов с кодом

  Классификация текстов документов

    10 ориентиры
  

  77 листов с кодом

    1 ориентир
  

  4 листа с кодом

    1 ориентир
  

  1 документы с кодом

  Обнаружение намерений

    19 ориентиры
  

  76 листов с кодом

    14 ориентиры
  

  4 бумаги с кодом

  Глубокая кластеризация

    5 ориентиры
  

  76 листов с кодом

  1 документы с кодом

  Диалог Понимание

    16 ориентиры
  

  76 листов с кодом

  1 документы с кодом

  Анализ избирательного округа

    4 ориентиры
  

  64 бумаги с кодом

    1 ориентир
  

  12 листов с кодом

  Сопоставление текста

  76 листов с кодом

  Специализированный поиск информации

    2 ориентиры
  

  46 листов с кодом

    3 ориентиры
  

  27 листов с кодом

  Овладение языком

    1 ориентир
  

  50 листов с кодом

  23 бумаги с кодом

  Диалог открытого домена

    2 ориентиры
  

  40 листов с кодом

    3 ориентиры
  

  30 листов с кодом

  Выравнивание объекта

    4 ориентиры
  

  69 листов с кодом

  Упрощение текста

    5 ориентиры
  

  69 листов с кодом

  Обнаружение позиции

    6 ориентиры
  

  63 листа с кодом

    1 ориентир
  

  1 документы с кодом

    1 ориентир
  

  1 бумага с кодом

  Тип объекта

    7 ориентиры
  

  64 листа с кодом

  1 документы с кодом

  Синтез текста в речь

    4 ориентиры
  

  62 листа с кодом

    1 ориентир
  

  1 документы с кодом

  1 документы с кодом

  Классификация намерений

    4 ориентиры
  

  61 лист с кодом

  Самообучение

  61 бумага с кодом

  Выравнивание слов

    7 ориентиры
  

  59 листов с кодом

  Межъязыковой перевод

    2 ориентиры
  

  42 листа с кодом

    8 ориентиры
  

  14 листов с кодом

  Парафразная идентификация

    8 ориентиры
  

  54 бумаги с кодом

  Чанкинг

    4 ориентиры
  

  53 листа с кодом

  Морфологический анализ

  53 бумаги с кодом

  Классификация текстов с несколькими метками

    19 ориентиры
  

  53 листа с кодом

  Поверхностный синтаксис

    4 ориентиры
  

  53 листа с кодом

  Разбор дискурса

    1 ориентир
  

  37 листов с кодом

  13 листов с кодом

  2 листа с кодом

  лемматизация

  50 листов с кодом

  Проверка фактов

    3 ориентиры
  

  49 листов с кодом

  китайский язык

    5 ориентиры
  

  41 бумага с кодом

  2 листа с кодом

  2 листа с кодом

  2 листа с кодом

  1 документы с кодом

  Посмотреть все 6 задач

  Рейтинг документов

    2 ориентиры
  

  46 листов с кодом

  Сущность

    10 ориентиры
  

  45 листов с кодом

  Обнаружение сарказма

    9 ориентиры
  

  44 листа с кодом

  Анализ настроений на основе аспектов

    11 ориентиры
  

  27 листов с кодом

    1 ориентир
  

  7 документов с кодом

    1 ориентир
  

  3 листа с кодом

    1 ориентир
  

  2 листа с кодом

    2 ориентиры
  

  1 бумага с кодом

  Посмотреть все 6 задач

  Диалог Оценка

    2 ориентиры
  

  40 листов с кодом

  Оскорбительный язык

  39 листов с кодом

  Мультимодальное глубокое обучение

    16 ориентиры
  

  34 листа с кодом

    15 ориентиры
  

  4 листа с кодом

  Анализ AMR

    8 ориентиры
  

  36 листов с кодом

  Обобщение исходного кода

    11 ориентиры
  

  30 листов с кодом

    1 ориентир
  

  5 листов с кодом

  Извлечение ключевой фразы

    6 ориентиры
  

  35 листов с кодом

  Преобразование речи в текст

    6 ориентиры
  

  33 листа с кодом

  Глубокое внимание

  33 листа с кодом

  Аннотация таблицы

    17 ориентиры
  

  14 листов с кодом

    9 ориентиры
  

  10 листов с кодом

    4 ориентиры
  

  4 листа с кодом

    2 ориентиры
  

  3 листа с кодом

    1 ориентир
  

  1 документы с кодом

  Посмотреть все 7 задач

  Кластеризация текста

    15 ориентиры
  

  16 листов с кодом

    8 ориентиры
  

  11 листов с кодом

    6 ориентиры
  

  4 листа с кодом

  Разрешение сущности

    7 ориентиры
  

  31 бумага с кодом

  Лингвистическая приемлемость

    2 ориентиры
  

  31 лист с кодом

  Генерация данных в текст

    1 ориентир
  

  15 листов с кодом

    10 ориентиры
  

  12 листов с кодом

    4 ориентиры
  

  2 листа с кодом

  Межъязыковые вложения слов

  29 листов с кодом

  Извлечение термина

    2 ориентиры
  

  29 листов с кодом

  Классификация текста с несколькими кадрами

    5 ориентиры
  

  27 листов с кодом

  1 документы с кодом

  Выбор диалогового ответа

    11 ориентиры
  

  28 листов с кодом

  Морфологический перегиб

  28 листов с кодом

  Население базы знаний

  26 листов с кодом

  1 документы с кодом

  Деидентификация

  27 листов с кодом

  Обнаружение спама

    4 ориентиры
  

  24 листа с кодом

    1 ориентир
  

  1 бумага с кодом

    1 ориентир
  

  1 документы с кодом

  Разговорный поиск

    1 ориентир
  

  26 листов с кодом

  Свертывание белков

  26 листов с кодом

  Преобразование естественного языка

    6 ориентиры
  

  23 листа с кодом

    6 ориентиры
  

  2 листа с кодом

  График в последовательность

    2 ориентиры
  

  25 листов с кодом

  Перевод слов

  25 листов с кодом

  Закрыть тест

    2 ориентиры
  

  24 листа с кодом

  Пояснение Генерация

    1 ориентир
  

  24 листа с кодом

  Математические рассуждения

    5 ориентиры
  

  17 листов с кодом

    1 ориентир
  

  5 листов с кодом

  Посмотреть все 6 задач

  Резюме предложения

  18 документов с кодом

  4 бумаги с кодом

  Извлечение сущностей с использованием GAN

  22 бумаги с кодом

  Рейтинг прохождения

    1 ориентир
  

  21 бумага с кодом

  Фраза Заземление

    5 ориентиры
  

  21 лист с кодом

  Быстрый инжиниринг

  21 бумага с кодом

  Извлечение ключевых слов

    3 ориентиры
  

  20 листов с кодом

  Морфологическая маркировка

  20 листов с кодом

  Поиск биомедицинской информации

    1 ориентир
  

  18 листов с кодом

    3 ориентиры
  

  1 бумага с кодом

  Многоязычный НЛП

  19 листов с кодом

  Обнаружение слухов

    1 ориентир
  

  18 листов с кодом

  Субъективный анализ

    2 ориентиры
  

  18 листов с кодом

  Временная обработка

    9 ориентиры
  

  12 листов с кодом

    2 ориентиры
  

  3 листа с кодом

    2 ориентиры
  

  2 листа с кодом

  Классификация токенов

  16 листов с кодом

  1 документы с кодом

  Обнаружение отрицания

    4 ориентиры
  

  12 листов с кодом

    4 ориентиры
  

  4 листа с кодом

  Проверка авторства

  16 листов с кодом

  Межъязыковая классификация документов

    3 ориентиры
  

  16 листов с кодом

  Семантическая композиция

  16 листов с кодом

  Добыча аргументов

    1 ориентир
  

  5 листов с кодом

  5 листов с кодом

    1 ориентир
  

  3 листа с кодом

    1 ориентир
  

  1 документы с кодом

    1 ориентир
  

  1 бумага с кодом

  Сходство вопросов

    1 ориентир
  

  14 листов с кодом

  1 документы с кодом

  Подведение итогов

    3 ориентиры
  

  12 листов с кодом

    23 ориентиры
  

  3 листа с кодом

  Порядок предложений

  15 листов с кодом

  Индукция смысла слова

    2 ориентиры
  

  15 листов с кодом

  Генерация диалогового ответа

    1 ориентир
  

  13 листов с кодом

    1 ориентир
  

  1 бумага с кодом

  Изучение таксономии

  7 документов с кодом

    3 ориентиры
  

  6 листов с кодом

  Лексический анализ

  7 листов с кодом

  6 листов с кодом

  Автоматическая оценка эссе

    1 ориентир
  

  13 листов с кодом

  Обратный словарь

  13 листов с кодом

  Слабо контролируемая классификация

    2 ориентиры
  

  11 листов с кодом

  1 документы с кодом

  Извлечение пары эмоций и причин

  12 листов с кодом

  Обнаружение юмора

    1 ориентир
  

  12 листов с кодом

  Генерация KG в текст

    10 ориентиры
  

  12 листов с кодом

  Лексическая нормализация

    1 ориентир
  

  12 листов с кодом

  Лексическое упрощение

  12 листов с кодом

  Диахронические вложения слов

  11 листов с кодом

  Экстремальное обобщение

    4 ориентиры
  

  11 листов с кодом

  Переоценка прохождения

    2 ориентиры
  

  11 листов с кодом

  Персидский анализ настроений

  11 листов с кодом

  Генерация обзора

  11 листов с кодом

  Обнаружение пропаганды

  8 листов с кодом

  1 документы с кодом

  1 документы с кодом

  Извлечение клинической концепции

    1 ориентир
  

  9 листов с кодом

  1 документы с кодом

  Генерация текста в изображение

  8 листов с кодом

  2 листа с кодом

  Разговорный ответ на вопрос

  10 листов с кодом

  Классификация мемов

    1 ориентир
  

  10 листов с кодом

  Распознавание вложенных упоминаний

    2 ориентиры
  

  10 листов с кодом

  Восстановление пунктуации

  10 листов с кодом

  Расшифровка

  9 листов с кодом

  Подведение итогов встречи

  9 листов с кодом

  Извлечение отношений (дистанционное наблюдение)

    2 ориентиры
  

  9 листов с кодом

  Проверка фактов на основе таблиц

    1 ориентир
  

  9 листов с кодом

  Обнаружение категории аспекта

    4 ориентиры
  

  8 листов с кодом

  Супертегирование CCG

    1 ориентир
  

  8 листов с кодом

  Диалог Акт Классификация

    1 ориентир
  

  8 листов с кодом

  Обнаружение намерений

  8 листов с кодом

  Семантический поиск

    1 ориентир
  

  8 листов с кодом

  Мультимодальный машинный перевод

  4 бумаги с кодом

    4 ориентиры
  

  2 листа с кодом

  Распознавание причин эмоций в разговорах

    1 ориентир
  

  4 листа с кодом

    3 ориентиры
  

  2 листа с кодом

  Диакритизация арабского текста

    1 ориентир
  

  6 листов с кодом

  Извлечение значения атрибута

  6 листов с кодом

  Гипероним Дискавери

    3 ориентиры
  

  6 листов с кодом

  Предварительно обученные многоязычные языковые модели

  6 листов с кодом

  Добыча предложений

  6 листов с кодом

  Сегментация тайских слов

    2 ориентиры
  

  6 листов с кодом

  Абстрактное суммирование текста

    1 ориентир
  

  4 листа с кодом

    1 ориентир
  

  1 бумага с кодом

  Обнаружение спекуляций

    3 ориентиры
  

  3 листа с кодом

    3 ориентиры
  

  2 листа с кодом

  Идентификация агрессии

  5 листов с кодом

  Анализ арабских настроений

  5 листов с кодом

  Обнаружение кликбейта

  5 листов с кодом

  Межъязыковой анализ битекста

    4 ориентиры
  

  5 листов с кодом

  Морфологическая неоднозначность

  5 листов с кодом

  Передача текстовых атрибутов

  5 листов с кодом

  Разрешение топонима

  5 листов с кодом

  Вьетнамские наборы данных

  5 листов с кодом

  Сегментация вьетнамских слов

  5 листов с кодом

  Абстрактная аргументация

  4 бумаги с кодом

  Причинно-следственные рассуждения на основе здравого смысла

  4 бумаги с кодом

  Сложная идентификация слова

  4 бумаги с кодом

  Переписывание диалогов

    3 ориентиры
  

  4 листа с кодом

  Документ ИИ

    1 ориентир
  

  4 листа с кодом

  Обнаружение гендерной предвзятости

  4 бумаги с кодом

  Открытое обнаружение намерений

    6 ориентиры
  

  4 листа с кодом

  Производство языка жестов

  4 бумаги с кодом

  Сжатие текста

  4 бумаги с кодом

  Разрешение анафоры

  2 листа с кодом

    1 ориентир
  

  1 бумага с кодом

  Обнаружение речи надежды

    1 ориентир
  

  1 бумага с кодом

    1 ориентир
  

  1 бумага с кодом

    1 ориентир
  

  1 документы с кодом

  Прогноз акций

    1 ориентир
  

  2 листа с кодом

  1 документы с кодом

  Родственное предсказание

  3 бумаги с кодом

  Выбор фактов

    1 ориентир
  

  3 листа с кодом

  Мемекс Вопрос Ответ

    1 ориентир
  

  3 листа с кодом

  Изучение языковых моделей

  3 листа с кодом

  Сжатие предложения

  3 листа с кодом

  Генерация таблицы в текст

    1 ориентир
  

  3 листа с кодом

  Извлечение временных отношений

  3 листа с кодом

  Эмоциональный интеллект

    3 ориентиры
  

  2 листа с кодом

  Извлечение аспекта

  1 документы с кодом

  1 документы с кодом

  Разбор действий

  2 листа с кодом

  Полярность категории аспекта

    1 ориентир
  

  2 листа с кодом

  Атрибуция автора

  2 листа с кодом

  Проверка китайской орфографии

    1 ориентир
  

  2 листа с кодом

  Диакритизация хорватского текста

    1 ориентир
  

  2 листа с кодом

  Диакритизация чешского текста

    1 ориентир
  

  2 листа с кодом

  Моделирование определения

  2 листа с кодом

  Маркировка домена

    1 ориентир
  

  2 листа с кодом

  Диакритизация французского текста

    1 ориентир
  

  2 листа с кодом

  Нормализация языка ненависти

  2 листа с кодом

  Диакритизация венгерского текста

    1 ориентир
  

  2 листа с кодом

  Диакритизация ирландского текста

    1 ориентир
  

  2 листа с кодом

  Диакритизация латышского текста

    1 ориентир
  

  2 листа с кодом

  Идентификация женоненавистнической агрессии

  2 листа с кодом

  Мультимодальная классификация текста и изображений

    12 ориентиры
  

  2 листа с кодом

  Обнаружение сигналов отрицания и спекуляций

    2 ориентиры
  

  2 листа с кодом

  Разрешение области отрицания и спекуляции

  2 листа с кодом

  Аннотация новостей

  2 листа с кодом

  Многозначность полифона

  2 листа с кодом

  Связывание записи

  2 листа с кодом

  Извлечение сущностей-наполнителей ролей

    1 ориентир
  

  2 листа с кодом

  Диакритизация румынского текста

    1 ориентир
  

  2 листа с кодом

  Диакритизация словацкого текста

    1 ориентир
  

  2 листа с кодом

  Диакритизация испанского текста

    1 ориентир
  

  2 листа с кодом

  Извлечение временной информации

    7 ориентиры
  

  2 листа с кодом

  Анонимизация текста

  2 листа с кодом

  Поиск текста в видео

  2 листа с кодом

  Диакритизация турецкого текста

    1 ориентир
  

  2 листа с кодом

  Идентификация поворотного момента

  2 листа с кодом

  Обнаружение событий в Твиттере

    1 ориентир
  

  2 листа с кодом

  Диакритизация вьетнамского текста

    1 ориентир
  

  2 листа с кодом

  Химическое индексирование

    1 ориентир
  

  1 документы с кодом

  Исправление китайских орфографических ошибок

  1 документы с кодом

  Обнаружение статуса клинического утверждения

    1 ориентир
  

  1 бумага с кодом

  Обоснование здравого смысла для RL

    1 ориентир
  

  1 бумага с кодом

  Переформулировка контекстного запроса

  1 документы с кодом

  Краудсорсинговое агрегирование текста

    2 ориентиры
  

  1 бумага с кодом

  Генерация диалогов

    1 ориентир
  

  1 бумага с кодом

  Резюме документа

    2 ориентиры
  

  1 бумага с кодом

  Эмерджентные сообщения об отношениях

  1 документы с кодом

  Резюмирование экстрактивных тегов

  1 документы с кодом

  Прогноз интенсивности ненависти

  1 документы с кодом

  Идентификация диапазона ненависти

  1 документы с кодом

  Прогноз работы

  1 документы с кодом

  Совместное извлечение объектов и отношений из научных данных

  1 документы с кодом

  Совместный NER и классификация

  1 документы с кодом

  Литература Майнинг

  1 документы с кодом

  Логическое мышление Чтение Понимание

  1 документы с кодом

  Поиск математической информации

    1 ориентир
  

  1 бумага с кодом

  Сегмент морфемы

  1 документы с кодом

  Многоуровневое распознавание именованных объектов

  1 документы с кодом

  Мультиагентная интеграция

    1 ориентир
  

  1 бумага с кодом

  Многоязычное машинное понимание английского хинди

    1 ориентир
  

  1 бумага с кодом

  Мультимодальное предсказание текста

    1 ориентир
  

  1 документы с кодом

  Распознавание перекрывающихся упоминаний

  1 документы с кодом

  Распознавание личности в разговоре

    1 ориентир
  

  1 бумага с кодом

  Рейтинг фраз

    2 ориентиры
  

  1 бумага с кодом

  Маркировка фраз

    2 ориентиры
  

  1 документы с кодом

  Встраивание вектора фразы

  1 документы с кодом

  Классификация стихотворных метров

    1 ориентир
  

  1 бумага с кодом

  Правильность запроса

    1 ориентир
  

  1 бумага с кодом

  Категоризация вопрос-ответ

    1 ориентир
  

  1 бумага с кодом

  Надежная разведывательная идентификация

  1 документы с кодом

  Завершение предложения

    1 ориентир
  

  1 бумага с кодом

  Анализ стереотипных предубеждений

    1 ориентир
  

  1 бумага с кодом

  Синтаксическое представление

  1 документы с кодом

  Целенаправленные диалоговые системы

    2 ориентиры
  

  1 документы с кодом

  Передача текстовых эффектов

  1 документы с кодом

  Передача стиля текста

  1 документы с кодом

  Вьетнамский анализ тональности на основе аспектов

  1 документы с кодом

  Маркировка веб-страницы

  1 документы с кодом

  Машинный перевод Zero-Shot

  1 документы с кодом

  обнаружение несоответствия

  1 документы с кодом

  встраивание многословных выражений

  1 документы с кодом

  предсказание семемы выражения из нескольких слов

  1 документы с кодом

  ARQMath3

  Автоматическая оценка письма

  Автоматическое письмо

  Жалоба Комментарий Классификация

  Обнаружение контрречи

  Классификация документов

  Извлекающее суммирование текста

  Выбор лица

  Классификация работы

  Подпись к мему

  Многоязычный нейронный машинный перевод

  Вопрос к повествовательному предложению

  Извлечение упоминаний об отношениях

  Анализ настроений в Твиттере

  Вьетнамский разбор

  Патент США

  на операции по преобразованию набора данных в патент намерения (патент № 11 144 569выпущено 12 октября 2021 г.

  )

  ПРЕДПОСЫЛКИ

  У многих пользователей есть наборы данных, с которыми они хотят выполнять различные операции. Например, пользователь может захотеть выполнить конкретный прогноз или анализ в отношении большого набора данных. Чтобы получить этот прогноз или анализ, необходимо выполнить различные функции или операции с набором данных, чтобы преобразовать его из входного набора данных в желаемый результат. Функциональные композиции используются для преобразования набора данных в желаемый результат пользователем. Функциональные композиции представляют собой серию более мелких и простых функций или операций, которые объединяются в серию для выполнения более сложного общего желаемого преобразования. Каждый шаг преобразования набора данных в желаемый результат может быть выполнен с использованием более чем одной операции. Другими словами, для каждого шага преобразования может быть много разных операций, которые можно использовать для выполнения одного шага. Кроме того, различные серии операций могут быть объединены для выполнения общего преобразования. Другими словами, общее преобразование можно было бы разбить на несколько этапов, что позволило бы выполнять разные последовательности операций, приводящих к одному и тому же желаемому результату.

  КРАТКОЕ ОПИСАНИЕ

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

  Другой аспект изобретения обеспечивает устройство, содержащее: по меньшей мере, один процессор; и машиночитаемый носитель данных, содержащий встроенный в него машиночитаемый программный код и исполняемый по меньшей мере одним процессором, при этом машиночитаемый программный код содержит: машиночитаемый программный код, сконфигурированный для приема от пользователя (i) набора данных и (ii) предполагаемый вывод из набора данных, который создается с учетом заданной аналитической структуры для набора данных, при этом предполагаемый вывод идентифицирует вывод, который пользователь хочет получить от набора данных, и при этом набор данных связан с аналитической областью; машиночитаемый программный код, выполненный с возможностью идентификации из репозитория функций набора данных, соответствующих операциям, ранее выполнявшимся над наборами данных, множества функций набора данных, относящихся к аналитической области; машиночитаемый программный код, сконфигурированный для определения из множества функций набора данных одной или нескольких функций набора данных для каждой из одной или нескольких операций, идентифицированных для преобразования набора данных в предполагаемый результат, при этом одна или несколько операций идентифицируются с использованием репозитория для идентификации операции, выполняемые над историческими наборами данных, относящимися к аналитической области, используемые для получения запланированного результата, аналогичного полученному намеченному результату; и машиночитаемый программный код, сконфигурированный для рекомендации упорядоченного подмножества одной или нескольких функций набора данных, которые будут использоваться для преобразования набора данных в предполагаемый выход, при этом упорядоченное подмножество содержит (i) одну функцию набора данных для каждой из одной или нескольких операций и (ii) заказ на выполнение одной или нескольких операций.

  В дополнительном аспекте изобретения предлагается компьютерный программный продукт, содержащий: машиночитаемый носитель данных, содержащий встроенный в него машиночитаемый программный код, машиночитаемый программный код, исполняемый процессором и содержащий: машиночитаемый программный код, сконфигурированный для приема от пользователь, (i) набор данных и (ii) предполагаемые выходные данные из набора данных, которые создаются с учетом заданной аналитической структуры для набора данных, при этом предполагаемые выходные данные идентифицируют выходные данные, которые пользователь хочет получить от набора данных, и при этом набор данных относится к аналитической области; машиночитаемый программный код, выполненный с возможностью идентификации из репозитория функций набора данных, соответствующих операциям, ранее выполнявшимся над наборами данных, множества функций набора данных, относящихся к аналитической области; машиночитаемый программный код, сконфигурированный для определения из множества функций набора данных одной или нескольких функций набора данных для каждой из одной или нескольких операций, идентифицированных для преобразования набора данных в предполагаемый результат, при этом одна или несколько операций идентифицируются с использованием репозитория для идентификации операции, выполняемые над историческими наборами данных, относящимися к аналитической области, используемые для получения запланированного результата, аналогичного полученному намеченному результату; и машиночитаемый программный код, сконфигурированный для рекомендации упорядоченного подмножества одной или нескольких функций набора данных, которые будут использоваться для преобразования набора данных в предполагаемый выход, при этом упорядоченное подмножество содержит (i) одну функцию набора данных для каждой из одной или нескольких операций и (ii) заказ на выполнение одной или нескольких операций.

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

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

  КРАТКОЕ ОПИСАНИЕ НЕСКОЛЬКИХ ВИДОВ НА ЧЕРТЕЖАХ

  РИС. 1 иллюстрирует способ рекомендации ряда операций, идентифицированных из репозитория наборов исторических данных, и операций для преобразования полученного набора данных в желаемое аналитическое назначение.

  РИС. 2 иллюстрирует примерную системную архитектуру для рекомендации ряда операций, идентифицированных из хранилища исторических наборов данных, и операций для преобразования полученного набора данных в желаемое аналитическое намерение.

  РИС. 3 иллюстрирует компьютерную систему.

  ПОДРОБНОЕ ОПИСАНИЕ

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

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

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

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

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

  Ниже будет сделана конкретная ссылка на фиг. 1-3. Следует иметь в виду, что широко проиллюстрированные здесь процессы, устройства и продукты могут быть выполнены на любой подходящей компьютерной системе или наборе компьютерных систем или в соответствии с ними, которые могут, в качестве иллюстративного и неограничивающего примера, включают в себя систему или сервер, такие как обозначенные позицией 12 ‘ на фиг. 3. В соответствии с примерным вариантом осуществления большинство, если не все этапы процесса, компоненты и выходные данные, рассмотренные в отношении фиг. 1-2 могут выполняться или использоваться с помощью блока или блоков обработки и системной памяти, таких как те, которые указаны соответственно в 9.0023 16 ‘ и 28 ‘ на фиг. 3, будь то серверный компьютер, клиентский компьютер, узловой компьютер в распределенной сети или любая их комбинация.

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

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

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

  Соответственно, вариант осуществления обеспечивает систему и способ для идентификации и рекомендации ряда операций, идентифицированных из репозитория наборов исторических данных, и операций для преобразования полученного набора данных в желаемое аналитическое назначение. Система получает от пользователя набор данных и аналитическое намерение или предполагаемый результат. Система идентифицирует различные атрибуты набора данных, например, аналитическое пространство или домен, тип информации, включенной в набор данных (например, структурированные данные, неструктурированные данные, форматы данных и т. д.), семантику набора данных и как. Система может получить доступ к одному или нескольким репозиториям, которые включают множество различных функций набора данных, соответствующих операциям, которые исторически выполнялись с наборами данных. Другими словами, функции или операции набора данных — это функции или операции, которые ранее выполнялись с предыдущими наборами данных. Из репозиториев система может идентифицировать одну или несколько функций набора данных, которые связаны или соответствуют идентифицированным атрибутам набора данных и/или аналитическому замыслу, например, одну или несколько функций набора данных, которые связаны с аналитической областью или пространством.

  Из этих идентифицированных функций набора данных система может определить одну или несколько функций набора данных для каждой из множества операций или шагов, необходимых для преобразования набора данных в аналитические цели. Чтобы определить или идентифицировать операции или шаги, необходимые для преобразования набора данных, система использует репозиторий для определения операций, которые были выполнены с историческими наборами данных, относящимися к аналитической области, и которые привели к аналитическим намерениям, аналогичным полученным аналитическим намерениям. Система может сопоставлять метаданные или метатеги, связанные с каждой из операций, для получения желаемого намерения. Метаданные или метатеги могут идентифицировать входные требования для каждой из операций, а также идентифицировать семантику выходных данных операций. Затем система может использовать обратное сопоставление, чтобы сопоставить операции с набором данных, и аналитическое намерение, чтобы рекомендовать упорядоченное подмножество функций набора данных. Например, система может сопоставить операцию, вывод которой соответствует аналитическому замыслу, и определить входные данные, необходимые для этой операции. Затем система сопоставляет этот вход с выходом другой операции. Система итеративно выполняет это сопоставление входных данных операций с выходными данными других операций до тех пор, пока не будет идентифицирована операция, имеющая входные данные, соответствующие набору данных. Затем система может предоставить пользователю рекомендацию об этой серии операций, которые приведут к общему желаемому преобразованию.

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

  РИС. 1 иллюстрирует способ рекомендации ряда операций, идентифицированных из хранилища исторических наборов данных, и операций для преобразования полученного набора данных в желаемое аналитическое намерение. По номеру 101 система получает от пользователя как набор данных, так и аналитическое намерение для набора данных. Аналитическое намерение определяет желаемый или предполагаемый результат, который пользователь хочет получить от набора данных, сгенерированного с учетом заданной аналитической структуры. Другими словами, аналитическое намерение определяет общую операцию, которую пользователь хочет выполнить с набором данных. Например, пользователь может идентифицировать конкретный прогноз в отношении набора данных, конкретный анализ в отношении набора данных и т.п., которые пользователь хотел бы узнать или понять в отношении набора данных. В качестве более конкретных примеров пользователь может захотеть выполнить анализ настроений для набора данных, пользователь может захотеть понять, существует ли корреляция между определенными атрибутами набора данных и выходными данными, предоставленными набором данных, пользователь может захотеть предсказать выходные данные оборудования, используя набор данных или что-то подобное. При определении аналитического намерения или желаемого результата пользователь может предоставить текстовые теги, которые идентифицируют желаемое аналитическое намерение. Текстовые теги могут быть просто текстом, идентифицирующим аналитическое намерение. Дополнительно или в качестве альтернативы аналитическое намерение может быть предоставлено в качестве выборки выходных данных. Например, пользователь может предоставить образец вывода, который включает метаданные или теги, идентифицирующие схему данных и назначение каждого вывода. Другими словами, пользователь предоставляет образец вывода набора данных, а затем помечает каждый из компонентов вывода тегами, которые идентифицируют схему данных выходного компонента и назначение выходного компонента. Пользователь также может предоставить метаданные, которые идентифицируют корреляции между различными частями вывода выборки.

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

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

  В 102 система идентифицирует множество функций набора данных, связанных с аналитической областью полученного или целевого набора данных. Эти функции набора данных хранятся в одном или нескольких репозиториях данных или местах хранения данных. Каждый репозиторий может включать в себя наборы данных, также называемые историческими наборами данных для простоты чтения, и операции, соответствующие этим историческим наборам данных. Операции могут включать те операции, которые были выполнены с набором исторических данных для преобразования или преобразования набора исторических данных из входного набора данных в аналитическое намерение или конкретный результат. Операции могут соответствовать функциям набора данных, которые являются функциями, которые использовались для выполнения соответствующей операции. Из всех функций набора данных, включенных в репозиторий или репозитории, система определяет, какие функции набора данных связаны с аналитической областью или пространством целевого набора данных.

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

  Затем система определяет, могут ли из набора функций набора данных, которые соответствуют аналитическому пространству, одна или несколько функций набора данных для каждой из серий операций, которые необходимо выполнить с целевым набором данных, чтобы привести к целевому аналитическому замыслу. определить или идентифицировать по телефону 103 . Чтобы сделать это определение, система определяет, какие из функций набора исторических данных соответствуют целевому набору данных и/или целевому аналитическому замыслу. Система обращается к исторической информации о выполнении для наборов исторических данных, чтобы идентифицировать операции, которые были выполнены с набором исторических данных для преобразования или преобразования набора исторических данных в исторические выходные данные, соответствующие набору исторических данных. Это позволяет системе генерировать родословную для каждого из этих наборов исторических данных. При генерации происхождения система также генерирует метаданные для создания метатегов. Метатеги идентифицируют входные требования для функции, а также формат и семантическую информацию для выходных данных функции. В качестве альтернативы, если родословная уже сгенерирована и снабжена метатегами, система может просто получить доступ к родословной и соответствующим метатегам.

  Используя родословную и метатеги, система может идентифицировать функции набора данных, которые могут соответствовать различным операциям, которые могут использоваться для преобразования или преобразования целевого набора данных в целевое аналитическое назначение. Благодаря этому сопоставлению система также определяет, какие операции необходимо выполнить для преобразования целевого набора данных в целевое аналитическое намерение. Другими словами, система может использовать историческую информацию, содержащуюся в репозитории, для идентификации одной или нескольких операций или функций набора данных, которые были выполнены с историческим набором данных, чтобы привести к аналитическому замыслу, аналогичному целевому аналитическому замыслу.

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

  После определения одной или нескольких функций набора данных, обеспечивающих желаемый результат, система просматривает входные данные для каждой из этих функций набора данных. Затем система идентифицирует другую функцию набора данных, которая приводит к выходным данным, совпадающим со входными данными функции набора данных. Другими словами, если все функции набора исторических данных A, B и C имеют выходные данные, соответствующие целевому аналитическому замыслу, система просматривает входные требования (идентифицируемые по метатегам) для функций набора исторических данных A, B и C. Затем система идентифицирует функции набора исторических данных, выходные данные которых соответствуют входным требованиям функций набора исторических данных A, B и C. Система выполняет этот итеративный анализ обратного сопоставления до тех пор, пока входные данные функции набора исторических данных не совпадут с целевым набором данных. Другими словами, система продолжает сопоставлять входные требования с выходными данными функций набора данных до тех пор, пока входное требование не совпадет с целевым набором данных. Это не только приводит к идентификации функций набора данных, которые можно использовать для каждой операции, необходимой для преобразования целевого набора данных в целевой аналитический замысел, но также определяет, какие операции необходимы для выполнения преобразования или преобразования.

  Если по номеру 103 система не может определить одну или несколько функций набора данных для одной или нескольких операций, система может попытаться определить отсутствующую одну или несколько функций набора данных по номеру 105 . Это может включать в себя определение того, что операция не должна быть включена в преобразование целевого набора данных для аналитического назначения, и отбрасывание любых функций набора данных, которые были идентифицированы с использованием этого конкретного ряда операций. В качестве альтернативы система может получить доступ к одному или нескольким другим репозиториям, чтобы определить, могут ли эти репозитории включать функцию набора данных, подходящую для операции.

  Если, однако, одна или несколько функций набора данных для каждой из операций могут быть идентифицированы по номеру 103 , система может порекомендовать упорядоченное подмножество одной или нескольких функций набора данных по номеру 104 . Упорядоченное подмножество может включать в себя идентификацию порядка, в котором функции набора данных должны выполняться для выполнения желаемого преобразования. Этот порядок идентифицируется на основе рекурсивного обратного сопоставления. Другими словами, порядок функций набора данных основан на том, какой порядок был определен из обратного сопоставления, в частности, функции набора данных, имеющие совпадающие входные требования и выходные данные.

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

  РИС. 2 представляет общую архитектуру и последовательность операций описанной системы и способа. Для репозиториев, хранящих исторические наборы данных и/или операции, система получает или получает исторические наборы данных 201 A и 201 B. Репозитории включают механизм 202 рабочего процесса аналитики, способный генерировать рабочий процесс 203 аналитики. , включая происхождение, операционные зависимости и тому подобное. Информация о рабочем процессе аналитики может быть передана в механизм обработки данных 9.0023 204 , который может извлекать входные требования, выходной формат и/или семантику и эффекты (IOPE) и помечать их метаданными 205 . Извлеченный IOPE 205 может быть предоставлен для сопоставления наборов данных с аналитикой или аналитическим намерением 206 . Извлеченный IOPE 205 также сохраняется 207 .

  Для целевого набора данных 208 система генерирует и/или идентифицирует типы форматов данных, модели данных, схемы данных и т.п., 209 . Затем система помечает набор данных метаданными в виде метатегов 210 . Затем система может определить функцию набора данных из наборов исторических данных, связав метатеги целевого набора данных с метатегами (IOPE) 207 наборов исторических данных по адресу 211 . Другими словами, система включает в себя преобразователь 211 , который сопоставляет IOPE наборов исторических данных 207 с моделями данных и/или метатегами целевого набора данных 210 . Затем система использует механизм хореографии 212 , который выполняет рекурсивное обратное сопоставление, чтобы рекомендовать упорядоченный набор функций набора данных для преобразования или преобразования целевого набора данных в целевой аналитический замысел.

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

  Как показано на РИС. 3 компьютерная система/сервер 12 ‘ в вычислительном узле 10 ‘ показана в виде универсального вычислительного устройства. Компоненты компьютерной системы/сервера 12 ′ могут включать в себя, помимо прочего, по меньшей мере один процессор или блок обработки данных 16 ′ , системную память 28 ′ и шину 18 ′ , которая соединяет различные системные компоненты, включая системную память 28 ‘до процессора 16 ‘. Автобус 18 ′ представляет по меньшей мере один из нескольких типов шинных структур, включая шину памяти или контроллер памяти, периферийную шину, ускоренный графический порт и процессор или локальную шину, использующую любую из множества шинных архитектур. В качестве примера, а не ограничения, такие архитектуры включают шину промышленной стандартной архитектуры (ISA), шину микроканальной архитектуры (MCA), шину Enhanced ISA (EISA), локальную шину Ассоциации стандартов видеоэлектроники (VESA) и межсоединения периферийных компонентов ( шина PCI).

  Компьютерная система/сервер 12 ′ обычно включает различные носители, читаемые компьютерной системой. Такие носители могут быть любыми доступными носителями, доступными для компьютерной системы/сервера 12 ‘, и включать в себя как энергозависимые, так и энергонезависимые носители, съемные и несъемные носители.

  Системная память 28 ’ может включать считываемые компьютерной системой носители в виде энергозависимой памяти, такой как оперативная память (RAM) 30 ’ и/или кэш-память 32 ′. Компьютерная система/сервер 12 ‘ может дополнительно включать в себя другие съемные/несъемные, энергозависимые/энергонезависимые носители данных компьютерной системы. Исключительно в качестве примера, система хранения данных 34 ′ может быть предусмотрена для чтения и записи на несъемный энергонезависимый магнитный носитель (не показан и обычно называется «жестким диском»). Хотя не показано, дисковод магнитных дисков для чтения и записи на съемный энергонезависимый магнитный диск (например, «гибкий диск») и дисковод оптических дисков для чтения со съемного энергонезависимого оптического диска или записи на него. может быть предоставлен диск, такой как CD-ROM, DVD-ROM или другой оптический носитель. В таких случаях каждый может быть подключен к шине 9.0023 18 ′ по крайней мере одним интерфейсом носителя данных. Как будет дополнительно показано и описано ниже, память 28 ′ может включать в себя по меньшей мере один программный продукт, имеющий набор (например, по меньшей мере один) программных модулей, сконфигурированных для выполнения функций вариантов осуществления изобретения.

  Программа/утилита 40 ′, имеющая набор (не менее одного) программных модулей 42 ′, может храниться в памяти 28 ′ (в качестве примера, а не ограничения), а также операционная система, как минимум одна прикладная программа, другие программные модули и программные данные. Каждая из операционных систем, по меньшей мере, одна прикладная программа, другие программные модули и программные данные или некоторая их комбинация могут включать в себя реализацию сетевой среды. Программные модули 42 ’ обычно выполняют функции и/или методологии вариантов осуществления изобретения, как описано здесь.

  Компьютерная система/сервер 12 ‘также может взаимодействовать по меньшей мере с одним внешним устройством 14 ‘, таким как клавиатура, указывающее устройство, дисплей 24 ‘и т. д.; по меньшей мере одно устройство, которое позволяет пользователю взаимодействовать с компьютерной системой/сервером 12 ‘; и/или любые устройства (например, сетевая карта, модем и т. д.), которые позволяют компьютерной системе/серверу 12 ′ для связи как минимум с одним другим вычислительным устройством. Такая связь может осуществляться через интерфейсы ввода/вывода 22 ′. Тем не менее, компьютерная система/сервер 12 ′ может связываться по меньшей мере с одной сетью, такой как локальная сеть (LAN), общая глобальная сеть (WAN) и/или общедоступная сеть (например, Интернет) через сетевой адаптер 20 ′. Как показано, сетевой адаптер 20 ′ взаимодействует с другими компонентами компьютерной системы/сервера 9.0023 12 ′ через автобус 18 ′. Следует понимать, что, хотя это и не показано, в сочетании с компьютерной системой/сервером 12 ‘ могут использоваться другие аппаратные и/или программные компоненты. Примеры включают, но не ограничиваются: микрокодом, драйверами устройств, резервными процессорами, массивами внешних дисковых накопителей, системами RAID, ленточными накопителями и системами архивного хранения данных и т. д.

  Это раскрытие было представлено в целях иллюстрации и описания. но не претендует на то, чтобы быть исчерпывающим или ограничивающим. Многие модификации и вариации будут очевидны специалистам в данной области техники. Варианты осуществления были выбраны и описаны для объяснения принципов и практического применения, а также для того, чтобы другие специалисты в данной области техники могли понять раскрытие.

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

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

  Машиночитаемый носитель данных может быть материальным устройством, которое может сохранять и хранить инструкции для использования устройством выполнения инструкций. Машиночитаемый носитель данных может быть, например, но не ограничиваясь этим, электронным устройством хранения данных, магнитным устройством хранения данных, оптическим устройством хранения данных, электромагнитным устройством хранения данных, полупроводниковым устройством хранения данных или любой подходящей комбинацией вышеперечисленного. Неисчерпывающий список более конкретных примеров машиночитаемого носителя данных включает в себя следующее: переносная компьютерная дискета, жесткий диск, оперативная память (ОЗУ), постоянное запоминающее устройство (ПЗУ), стираемое программируемое считываемое устройство. только память (EPROM или флэш-память), статическая оперативная память (SRAM), портативный компакт-диск с постоянной памятью (CD-ROM), цифровой универсальный диск (DVD), карта памяти, дискета, механический закодированное устройство, такое как перфокарты или выпуклые структуры в канавке с записанными на них инструкциями, и любая подходящая комбинация вышеперечисленного. Считываемый компьютером носитель данных, используемый здесь, не должен рассматриваться как преходящий сигнал сам по себе, такой как радиоволны или другие свободно распространяющиеся электромагнитные волны, электромагнитные волны, распространяющиеся по волноводам или другим передающим средам (например, световые импульсы, проходящие через оптоволоконный кабель) или электрические сигналы, передаваемые по проводу.

  Машиночитаемые программные инструкции, описанные в настоящем документе, могут быть загружены в соответствующие вычислительные/обрабатывающие устройства с машиночитаемого носителя данных или на внешний компьютер или внешнее запоминающее устройство через сеть, например, Интернет, локальную сеть, глобальную сеть сети и/или беспроводной сети. Сеть может включать медные кабели передачи, оптические волокна передачи, беспроводную передачу, маршрутизаторы, брандмауэры, коммутаторы, шлюзовые компьютеры и/или пограничные серверы. Карта сетевого адаптера или сетевой интерфейс в каждом вычислительном/обрабатывающем устройстве принимает машиночитаемые программные инструкции из сети и пересылает машиночитаемые программные инструкции для хранения на машиночитаемом носителе данных в соответствующем вычислительном/обрабатывающем устройстве.

  Машиночитаемые программные инструкции для выполнения операций по настоящему изобретению могут быть инструкциями ассемблера, инструкциями архитектуры набора инструкций (ISA), машинными инструкциями, машинно-зависимыми инструкциями, микрокодом, инструкциями встроенного программного обеспечения, данными установки состояния или любым исходным кодом или объектный код, написанный в любой комбинации одного или нескольких языков программирования, включая объектно-ориентированный язык программирования, такой как Smalltalk, C++ или тому подобное, и обычные процедурные языки программирования, такие как язык программирования «C» или подобные языки программирования. Машиночитаемые программные инструкции могут выполняться полностью на компьютере пользователя, частично на компьютере пользователя, в виде автономного программного пакета, частично на компьютере пользователя и частично на удаленном компьютере или полностью на удаленном компьютере или сервере. В последнем случае удаленный компьютер может быть подключен к компьютеру пользователя через сеть любого типа, включая локальную сеть (LAN) или глобальную сеть (WAN), или подключение может быть выполнено к внешнему компьютеру (для например, через Интернет с помощью интернет-провайдера). В некоторых вариантах осуществления электронные схемы, включая, например, программируемые логические схемы, программируемые пользователем вентильные матрицы (FPGA) или программируемые логические матрицы (PLA), могут выполнять машиночитаемые программные инструкции, используя информацию о состоянии машиночитаемых программных инструкций для персонализации. электронная схема для реализации аспектов настоящего изобретения.

  Аспекты настоящего изобретения описаны здесь со ссылкой на блок-схемы и/или блок-схемы способов, устройств (систем) и компьютерных программных продуктов в соответствии с вариантами осуществления изобретения. Следует понимать, что каждый блок иллюстраций блок-схем и/или блок-схем и комбинации блоков в иллюстрациях блок-схем и/или блок-схем могут быть реализованы машиночитаемыми программными инструкциями. Эти машиночитаемые программные инструкции могут быть предоставлены процессору компьютера общего назначения, компьютера специального назначения или другого программируемого устройства обработки данных для создания машины, так что инструкции, которые выполняются через процессор компьютера или другое программируемое устройство обработки данных устройства, создавать средства для реализации функций/действий, указанных в блок-схеме и/или блок-схеме или блоках блок-схемы. Эти машиночитаемые программные инструкции также могут быть сохранены на машиночитаемом носителе данных, который может указывать компьютеру, программируемому устройству обработки данных и/или другим устройствам функционировать определенным образом, так что машиночитаемый носитель данных, содержащий инструкции, хранящиеся на нем, содержит изделие, включающее в себя инструкции, которые реализуют аспекты функции/действия, указанные в блок-схеме и/или блоке или блоках блок-схемы.

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

  Блок-схемы и блок-схемы на рисунках иллюстрируют архитектуру, функциональные возможности и работу возможных реализаций систем, способов и компьютерных программных продуктов в соответствии с различными вариантами осуществления настоящего изобретения. В связи с этим каждый блок на блок-схеме или блок-схеме может представлять модуль, сегмент или часть инструкций, которые содержат одну или несколько исполняемых инструкций для реализации указанной логической функции (функций). В некоторых альтернативных реализациях функции, отмеченные в блоке, могут выполняться не в порядке, указанном на фигурах. Например, два последовательно показанных блока фактически могут выполняться по существу одновременно, или иногда блоки могут выполняться в обратном порядке, в зависимости от задействованной функциональности. Следует также отметить, что каждый блок на блок-схемах и/или блок-схемах, а также комбинации блоков на блок-схемах и/или блок-схемах могут быть реализованы аппаратными системами специального назначения, которые выполняют указанные функции или действия или выполнять комбинации специального оборудования и компьютерных инструкций.

  butcher :: Stackage Server

  BSD-3-Clause licensed by Lennart Spitzner

  Maintained by Lennart Spitzner

  This version can be pinned in stack with: butcher-1.3.2.3@sha256:1b8040eddb6da2a05426bf9f6c56b078e629228d64d7d61fb3daa88802487e1b, 3262

  Зависит от 14 пакетов (полный список с версиями) :

  base, бифункторы, контейнеры, deque, extra, free, microlens, microlens-th, mtl, multistate, pretty, transforms, unsafe, void

  Разбивает вызов команды или программы на удобоваримые части.

  Аналогичен пакету optparse-applicative , но с меньшими возможностями, больше гибкости и больше зла.

  Основные отличия:

  • Обеспечивает чистый интерфейс по умолчанию

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

    В optparse-applicative вы легко теряете представление о том, в каком поле вы находитесь модификация после 5-го <*> (правда, я думаю -XRecordWildCards уже улучшает этот вопрос.)

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

  • Монадический интерфейс позволяет гораздо более четкие определения командных синтаксических анализов. с (вложенными) подкомандами. Никаких надоедливых типов сумм не требуется.

  Примеры

  Минимальный пример:

   main = mainFromCmdParser $ addCmdImpl $ putStrLn "Привет, мир!"
   

  Но давайте посмотрим на более полный пример:

   main = mainFromCmdParserWithHelpDesc ​​$ \helpDesc ​​-> do
    addCmdSynopsis "Простая программа-пример мясника"
    addCmdHelpStr "очень длинный справочный документ"
    addCmd "версия" $ сделать
      фарфор <- addSimpleBoolFlag "" ["фарфор"]
        (flagHelpStr "не печатать ничего, кроме числовой версии")
      addCmdHelpStr "выводит версию этой программы"
      addCmdImpl$putStrLn$ если фарфор
        затем "0. 0.0.999 дюймов
        else "пример, версия 0.0.0.999"
    addCmd "help" $ addCmdImpl $ print $ ppHelpShallow helpDesc
    короткий <- addSimpleBoolFlag "" ["short"]
      (flagHelpStr "сделать приветствие коротким")
    имя <- addStringParam "ИМЯ"
      (paramHelpStr "ваше имя, чтобы вас правильно приветствовали")
    addCmdImpl $ сделать
      если коротко
        затем ставим StrLn$"привет,"++название++"!"
        else putStrLn $ "привет, " ++ name ++ ", добро пожаловать от мясника!"
   

  Далее:

  • Полное описание приведенного выше примера, включая пример поведения
  • Пример чистого использования CmdParser
  • Пример использования CmdParser для интерактивного ввода
  • Средство форматирования Бретани — это программа, использующая butcher для реализации своего интерфейса командной строки. Видеть его основной источник модуля или анализатор флагов конфигурации.

  Злой монадический интерфейс

  Пока вы используете только Апликативную или (Клейсли) Стрелку, вы можете использовать интерфейс свободно. Когда вы используете Monad, есть одно правило: всякий раз, когда вы читаете любые команды-части как в

   f <- addFlag ...
  p <- addParam ...
   

  вам разрешено использовать связанные таким образом привязки только в любой команде реализации, т.е. внутри параметра addCmdImpl . Вы , а не разрешено принудительно/проверить/сопоставить их с образцом до этого. хорошее использование :

   addCmdImpl $ do
    распечатать х
    напечатать у
   

  , тогда как плохой будет

   f <- addFlag
  когда е$ делай
    p <- addParam
    -- зло: существование параметра `p`
    -- зависит от результата синтаксического анализа для флага `f`.
   

  Это означает, что необходимо проверить, разрешена ли комбинация флагов. после разбора. (Но разные команды и их подкоманды (могут) иметь отдельные наборы флагов.)

  (аннотация) Намерения пакетов

  Рассмотрим вызов командной строки, например «ghc -O -i src -Main.hs -o Main». Этот Пакет предоставляет программисту возможность одновременно определить семантика вашей программы на основе ее аргументов и получения документации для пользователя. В частности, я имел в виду три цели:

  1. Прямое описание (под)команды и поведение флага
  2. Извлечение понятных документов/текстов командной строки использования/справки из этого описания, подумайте о ghc --help или stack init --help .
  3. Извлечение необходимой информации для вычисления результатов завершения командной строки от любого частичного ввода. (Это не реализовано в какой-либо серьезной степени.)

  Семантика

  Основными элементами команды являются флаги, параметры и подкоманды. Они могут быть составлены определенным образом, т. е. флаги могут иметь (или, возможно, несколько?) параметры; параметры могут быть сгруппированы в последовательности, а команды могут иметь подкоманды.

  Команды по существу Строка -> Либо ParseError из , где из могут выбираться пользователем. Например, это может быть IO() .

  Для более гибкой композиции части команды имеют «классический» тип парсера: String -> Maybe (p, String) , где p зависит от части. Разобрать префикс ввода и вернуть что-то и оставшийся ввод, или сбой с Ничего .

  Команда-анализатор содержит последовательность частей, а затем ряд подкоманд и/или некоторая реализация.

  Команды и дочерние команды

  •  myParser :: CmdParser Identity Int ()
    мойпарсер = возврат ()
     

    ввод	runCmdParserSimple input myParser
    ""	Оставлено «команда не имеет реализации»
    «х»	Оставлено «аргументы синтаксического анализа ошибки: не удалось проанализировать ввод/необработанный ввод по адресу: «x»».

  •  myParser :: CmdParser Identity Int ()
    мойпарсер = сделать
      addCmd "foo" $ addCmdImpl 2
      addCmd "бар" $ addCmdImpl 3
      addCmd "noimpl" $ чисто ()
      addCmd "twoimpls" $ сделать
        addCmdImpl 4
        addCmdImpl 5
      addCmdImpl 1
     

    ввод	runCmdParserSimple input myParser
    ""	Правый 1
    «х»	Оставлено «аргументы синтаксического анализа ошибки: не удалось проанализировать ввод/необработанный ввод по адресу: «x»».
    "фу"	Справа 2
    «пруток»	Справа 3
    «фу-бар»	Оставлено «аргументы синтаксического анализа ошибки: не удалось проанализировать ввод/необработанный ввод в: «bar»».
    «ноимпл»	Оставлено «команда не имеет реализации»
    «два импла»	Правая 5

  Флаги

  • без какой-либо аннотации, изменение порядка не допускается, и флаги должны располагаться по порядку:

     myParser :: Идентификация CmdParser (Bool, Int, Int) ()
    мойпарсер = сделать
      b <- addSimpleBoolFlag "b" [] пустой
      c <- addSimpleCountFlag "c" [] пустой
      i <- addFlagReadParam "i" [] "число" (flagDefault 42)
      addCmdImpl$(b,c,i)
     

    ввод	runCmdParserSimple input myParser
    ""	Правильно (Ложь,0,42)
    «-b-c-i 3»	Правильно (Истина, 1,3)
    «-с-б»	Оставлено «аргументы синтаксического анализа ошибки: не удалось проанализировать ввод/необработанный ввод по адресу: «-b»».
    «-с-с-с»	Правильно (Ложь,3,42)

  • на этот раз с переупорядочиванием; также «j» не имеет значения по умолчанию и, таким образом, становится обязательным, тем не менее он не должен встречаются более одного раза:

     myParser :: Идентификация CmdParser (Bool, Int, Int, Int) ()
    мойпарсер = сделать
      reorderStart -- на этот раз с переупорядочением
      b <- addSimpleBoolFlag "b" [] пустой
      c <- addSimpleCountFlag "c" [] пустой
      i <- addFlagReadParam "i" [] "число" (flagDefault 42)
      j <- addFlagReadParam "j" [] "number" mempty -- нет по умолчанию: флаг обязателен
      переупорядочитьСтоп
      addCmdImpl$(b,c,i,j)
     

    ввод	runCmdParserSimple input myParser
    «-б»	Оставлено «аргументы синтаксического анализа ошибки: не удалось проанализировать ожидаемое число ввода -j с оставшимся вводом: InputString «» в конце ввода».
    «-j=5»	Правильно (Ложь, 0,42,5)
    «-c -b -b -j=5»	Правильно (Истина, 1,42,5)
    "-j=5 -i=1 -c -b"	Правильно (Истина, 1, 1, 5)
    "-c -j=5 -c -i=5 -c"	Правильно (Ложь,3,5,5)
    «-j=5 -j=5»	Оставлено «аргументы синтаксического анализа ошибки: не удалось проанализировать ввод/необработанный ввод по адресу: «-j=5»».

  • addFlagReadParams — могут встречаться более одного раза. Обратите внимание, что значения по умолчанию имеют несколько иную семантику:

    .

     myParser :: Идентификация CmdParser (Int, [Int]) ()
    мойпарсер = сделать
      переупорядочитьНачать
      i <- addFlagReadParam "i" [] "число" (flagDefault 42)
      js <- addFlagReadParams "j" [] "число" (flagDefault 50)
      переупорядочитьСтоп
      addCmdImpl $ (i, js)
     

    ввод	runCmdParserSimple input myParser
    ""	Правый (42,[])
    «-i»	Оставлено «аргументы синтаксического анализа ошибки: не удалось проанализировать ввод/необработанный ввод по адресу: «-i»».
    "-j=1 -j=2 -j=3"	Вправо (42,[1,2,3])
    «-j»	Правый (42,[50])
    «-i=1»	Вправо (1,[])
    «-j=2»	Правый (42,[2])
    "-j=2 -i=1 -j=3"	Вправо (1,[2,3])

  Params

  TODO

  1.3.2.3 — июнь 2019 г.

  • Исправить неработающую сборку при использовании deque>=0,3

  1.3.2.2 — июнь 2019 г. (сломано, отключено при взломе)

  • Исправление слишком поверхностных описаний братьев и сестер для возвращенных частичных синтаксических анализов для интерактивного использования

  1.3.2.1 – октябрь 2018 г.

  • Адаптация/использование последней версии deque для устранения проблем ghc-8.6

  1.3.2.0 — октябрь 2018 г.

  • Исправление для simpleCompletion
  • Показать некоторые привязки, которые были забыты в предыдущем выпуске
  • Исправлены границы для ghc-8. 6 (также через пересмотр в 1.3.1.1)

  1.3.1.1 — апрель 2018 г.

  • Привязанная версия исправления

  1.3.1.0 – апрель 2018 г.

  • Добавить/выставить еще две функции: addAlternatives и varPartDesc

  1.3.0.1 – апрель 2018 г.

  • Поддержка ghc-8.4
  • Прекращение поддержки для ghc<8

  1.3.0.0 — февраль 2018 г.

  • Экспериментальная часть: скрытые команды (не отображаются в справке)
  • Экспериментальная часть: завершение Bash
  • Добавить addHelpCommandWith для поддержки определяемого пользователем количества столбцов
  • Исправление печати справочных документов (ленты)
  • Исправить поведение завершения

  1.2.1.0 — ноябрь 2017 г.

  • Исправление ошибки в «ppUsageWithHelp»
  • некоторые утилиты для интерактивного использования в новом модуле UI.Butcher.Monadic.Interactive

  1.

  2.0.0 — октябрь 2017 г.
  • Переименовать некоторые Monadic.Param.* , старые версии не рекомендуются.
    • addReadParam -> addParamRead
    • addReadParamOpt -> addParamReadOpt
    • addStringParam -> addParamString
    • addStringParamOpt -> addParamStringOpt
    • addStringParams -> addParamStrings
    • addRestOfInputStringParam -> addParamRestOfInput
  • Добавить функции addParamNoFlagString , addParamNoFlagStringOpt , аддпарамнофлагстрингс
  • Исправить поведение синтаксического анализа флага (игнорировать начальные пробелы)

  1.1.1.0 — октябрь 2017 г.

  • Добавить функцию addNullCmd , которая переходит в дочернюю команду при совпадении эпсилон
  • Добавить addStringParams функцию, которая считывает все оставшиеся слова

  1.

  1.0.2 — сентябрь 2017 г.
  • Улучшение «использования» красивой печати

  1.1.0.1 – август 2017 г.

  • Адаптация для ghc-8.2

  1.1.0.0 — май 2017 г.

  • Первая версия. Выпущен в ничего не подозревающий мир.

  Архитектура сети вещей (WoT)

  Архитектура сети вещей (WoT)

  Рекомендация W3C

  9 апреля 2020 г.

  Эта версия:

  https://www.w3.org/TR/2020/REC-wot-architecture-20200409/

  Последняя опубликованная версия:

  https://www.w3.org/TR/wot-архитектура/

  Последний черновик редактора:

  https://w3c.github.io/wot-архитектура/

  Отчет о внедрении:

  https://w3c.github.io/wot-thing-description/testing/report.html

  Предыдущая версия:

  https://www.w3. org/TR/2020/PR-wot-architecture-20200130/

  Редакторов:

  Матиас Ковач (Huawei)

  Рюичи Мацукура (Fujitsu Ltd.)

  Майкл Лагалли (Oracle Corp.)

  Тору Кавагути (Panasonic Corp.)

  Кунихико Томура (Hitachi, Ltd.)

  Кадзуо Кадзимото (бывший редактор, когда Панасоник)

  Принять участие:

  Гитхаб w3c/wot-архитектура

  Файл ошибка

  Совершить история

  Вытащить Запросы

  Авторы:

  В репозитории GitHub

  Пожалуйста, проверьте errata для любых ошибок или проблем, о которых сообщалось с момента публикации.

  Смотрите также перевода .

  Авторское право © 2017-2020 W3C ^® ( МТИ , ЕРЦИМ , Кэйо, Бэйхан). W3C обязанность, товарный знак и применяются правила лицензирования разрешительного документа.

  ---

  Аннотация

  Веб-сайт W3C of Things (WoT) предназначен для обеспечения взаимодействия между Платформы IoT и домены приложений. В целом, цель WoT должен сохранить и дополнить существующие стандарты IoT и решения. В целом, архитектура WoT W3C предназначен для описания того, что существует, а не для того, чтобы предписывать, что реализовать.

  Эта спецификация WoT Architecture описывает абстрактная архитектура для W3C Сеть вещей. Этот абстрактная архитектура основана на наборе требований, которые были получены из вариантов использования для нескольких доменов приложений, оба приведены в этом документе. Набор модульных строительных блоков также определены, подробные спецификации которых приведены в другие документы. В этом документе описывается, как эти здания блоки связаны и работают вместе. Аннотация к WoT архитектура определяет базовую концептуальную основу, которую можно сопоставлены с различными конкретными сценариями развертывания, несколько примеры которых приведены. Однако абстрактная архитектура описанный в этой спецификации, сам по себе не определяет конкретные механизмов или предписать какую-либо конкретную реализацию.

  Статус этого документа

  В этом разделе описывается статус этого документа на время его публикации. Другие документы могут заменить этот документ. Список текущих публикаций W3C и последнюю редакцию этого технического отчета можно найти в Технические отчеты W3C указатель на https://www.w3.org/TR/.

  В этом документе описывается абстрактный архитектурный проект. Однако существует Отчет о реализации, в котором описывается набор конкретных реализации на основе связанных Вещь WoT Описание Спецификация . Это реализации следуя W3C Web of Things архитектура.

  Этот документ был рассмотрен членами W3C , разработчиками программного обеспечения и другими группами W3C и заинтересованными сторонами и одобрен директором. в качестве рекомендации W3C . Это стабильный документ, и его можно использовать в качестве справочного материала или цитировать из другого документа. W3C 9Роль 4707 в составлении Рекомендации заключается в том, чтобы привлечь внимание к спецификации и способствовать ее широкому распространению. Это повышает функциональность и интероперабельность Интернета.

  Этот документ был опубликован рабочей группой Web of Things как Рекомендация.

  Гитхаб Вопросы являются предпочтительными для обсуждения этой спецификации. Кроме того, вы можете отправить комментарии в наш список рассылки. Пожалуйста, присылайте их на [email protected] (архив).

  Этот документ был подготовлен группой, работающей под W3C Патентная политика. W3C поддерживает публичный список любых патентных раскрытий, сделанных в связи с результаты группы; эта страница также содержит инструкции за раскрытие патента. Человек, обладающий реальным знанием патента, который, по мнению лица, содержит существенные Требования должны раскрывать информацию в соответствии с раздел 6 из W3C Патентная политика.

  Этот документ регулируется законом от 1 марта 2019 г. W3C Процесс Документ.

  1. Введение

  Цели Web of Things (WoT) заключаются в улучшении интероперабельность и удобство использования Интернета вещей (IoT). Благодаря сотрудничеству с участием многих заинтересованных сторон в течение много лет было выявлено несколько строительных блоков, которые помогите решить эти задачи.

  Эта спецификация ориентирована на область стандартизации W3C WoT, которые могут быть разбиты на эти строительные блоки, а также абстрактная архитектура, которая определяет, как они связаны. Строительные блоки определены и подробно описаны в отдельные спецификации. Однако помимо определения абстрактная архитектура и ее терминология и концептуальные рамках, эта спецификация также служит введением в строительные блоки WoT и объясняет их взаимодействие:

  • Web of Things (WoT) Описание вещи [ ЧТО-ТО-ОПИСАНИЕ ] нормативно обеспечивает машиночитаемый формат данных для описание метаданных и сетевых интерфейсов Вещи. Он основан на основных понятиях, введенных в этом документе, такие как возможности взаимодействия.
  • Шаблоны привязки Web of Things (WoT) [ WOT-ОБЯЗАТЕЛЬНЫЕ ШАБЛОНЫ ] содержит информационные рекомендации о том, как определить сетевые интерфейсы в Things для определенных протоколов и экосистемы IoT, которые мы называем привязками протоколов. документ также содержит примеры для ряда существующих IoT экосистемы и стандарты.
  • API сценариев Web of Things (WoT) [ WOT-СЦЕНАРИЙ-API ], который является необязательным, позволяет реализовать логика приложения вещи с использованием общего JavaScript API аналогично API-интерфейсам веб-браузера. Это упрощает Интернет вещей разработки приложений и обеспечивает переносимость между продавцов и устройств.
  • The Web of Things (WoT) Безопасность и конфиденциальность Руководство [ WOT-SECURITY ] представляют собой сквозной строительный блок. Это информационное документ содержит рекомендации по безопасной реализации и конфигурации вещей, и обсуждает вопросы, которые следует учитывать в любых системах, реализующих W3C WoT. Однако следует подчеркнуть, что безопасность и конфиденциальность может быть полностью оценен только в контексте полного набор конкретных механизмов для конкретной реализации, которые абстрактная архитектура WoT не определяет полностью. Это особенно верно, когда используется архитектура WoT. описательно для ранее существовавших систем, поскольку W3C WoT не может ограничивать поведение таких систем, оно может только Опиши их. В этом документе мы также обсуждаем конфиденциальность и риски безопасности и их снижение на высоком уровне в раздел §  10. Безопасность и Соображения конфиденциальности.

  Эта спецификация также охватывает ненормативные архитектурные аспекты и условия развертывания систем WoT. Эти рекомендации описаны в контексте примера развертывания сценарии, хотя эта спецификация нормативно не определить конкретные конкретные реализации.

  Эта спецификация служит основой для спецификаций W3C WoT и определяет основы, такие как терминология и лежащие в основе абстрактная архитектура W3C Web of Things. В Таким образом, цель этой спецификации состоит в том, чтобы предоставить:

  • набор вариантов использования в § 4. Варианты использования которые привели к архитектуре W3C WoT,
  • набор требований к реализации WoT в § 5. Требования,
  • определение абстрактной архитектуры в § 6. Архитектура WoT
  • обзор набора строительных блоков WoT и их взаимодействие в §  7. Строительные блоки WoT,
  • информативное руководство о том, как составить карту реферата архитектуры до возможных конкретных реализаций в § 8. Аннотация Служебная архитектура,
  • информативных примеров возможных сценариев развертывания в §  9. Пример WoT Развертывания,
  • и обсуждение на высоком уровне безопасности и соображения конфиденциальности, о которых следует помнить при реализации система на базе W3C Архитектура WoT в § 10. Безопасность и Соображения конфиденциальности.

  Дополнительные требования, варианты использования, концептуальные особенности и новые строительные блоки будут рассмотрены в будущем пересмотре этот документ.

  2. Соответствие

  А также разделы, отмеченные как ненормативные, все авторские рекомендации, диаграммы, примеры и примечания в этой спецификации являются ненормативными. Все остальное в этой спецификации нормативный.

  Ключевые слова МАЙ , ДОЛЖЕН , и ДОЛЖЕН в этот документ следует интерпретировать, как описано в BCP 14 [ RFC2119 ] [ RFC8174 ] когда и только когда они появляются во всех столицах, как показано здесь.

  3. Терминология

  Этот раздел не является нормативным.

  В этой спецификации используются следующие термины, определенные здесь. Префикс WoT используется, чтобы избежать двусмысленности для терминов, которые (пере)определены специально для концепций Web of Things.

  Действие

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

  Шаблоны для переплета

  Повторно используемая коллекция чертежей для связь с различными платформами IoT. чертежи предоставить информацию для сопоставления возможностей взаимодействия с специфические для платформы сообщения через WoT Thing Description как а также примечания по реализации для необходимых стеков протоколов или специальные коммуникационные драйверы.

  Потребляемая вещь

  Программная абстракция, представляющая удаленную вещь используется локальным приложением. Абстракция может быть созданный родной средой выполнения WoT или созданный как объект через скриптовый API WoT.

  Потребление вещи

  Для разбора и обработки документа ТД и создания из него Программная абстракция Consumed Thing как интерфейс для приложение в локальной среде выполнения.

  Потребитель

  Сущность, которая может обрабатывать описания вещей WoT (включая формат представления на основе JSON) и взаимодействовать с вещами (т. е. потреблять вещи).

  Схема данных

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

  Цифровой двойник

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

  Для домена Словарь

  Словарь связанных данных, который можно использовать в WoT Thing Описание, но не определено W3C WoT.

  Край Устройство

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

  Событие

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

  Открытая вещь

  Программная абстракция, представляющая локально размещенный Вещь, к которой можно получить доступ по сети удаленно Потребители. Абстракция может быть создана родным WoT Время выполнения или созданный как объект через WoT Скриптовый API.

  Открытие объекта

  Чтобы создать программную абстракцию Exposed Thing в локальная среда выполнения для управления состоянием вещи и интерфейс с реализацией поведения.

  Управление гипермедиа

  Сериализация привязки протокола в гипермедиа, которая является либо веб-ссылкой [ RFC8288 ] для навигации, либо форму для выполнения других операций. Формы можно рассматривать как шаблоны запросов, предоставленные Вещью для заполнения и отправлено Потребителем.

  Взаимодействие Доступность

  Метаданные вещи, которые показывают и описывают возможные выбора Потребителям, тем самым предлагая, как Потребители могут взаимодействовать с Вещью. Существует много типов потенциала возможности, но W3C WoT определяет три типы возможностей взаимодействия: свойства, действия и События. Четвертая возможность взаимодействия — это навигация. уже доступен в Интернете по ссылке.

  Модель взаимодействия

  Промежуточная абстракция, формализующая и сужающая отображение от намерения приложения к конкретному протоколу операции. В W3C WoT определенный набор возможностей взаимодействия представляет собой взаимодействие Модель.

  Посредник

  Сущность между Потребителями и Вещами, которая может проксировать, дополнять или создавать Вещи и переиздавать Вещь WoT Описание, указывающее на интерфейс WoT на Посредник вместо оригинальной Вещи. Для потребителей Посредник может быть неотличим от Вещи, следуя ограничение многоуровневой системы REST.

  Платформа Интернета вещей

  Определенная экосистема Интернета вещей, например OCF, oneM2M или Mozilla. Project Things со своими спецификациями для API, модель данных и протоколы, ориентированные на приложения, или конфигурации протокола.

  Метаданные

  Данные, которые обеспечивают описание абстрактного объекта характеристики. Например, описание вещи является метаданными для вещь.

  Лично Идентифицируемая информация (PII)

  Любая информация, которая может быть использована для идентификации природного лицо, к которому относится такая информация, или которое является или могло бы быть прямо или косвенно связанные с физическим лицом. Мы используем такое же определение, как [ ISO-IEC-29100 ].

  Конфиденциальность

  Свобода от вторжения в частную жизнь или дела лицу, когда это вторжение является результатом неправомерного или незаконный сбор и использование данных об этом человеке. Мы используйте то же определение, что и [ ИСО-МЭК-2382 ]. См. также Лично Идентифицируемая информация и безопасность, как а также другие связанные определения в [ ISO-IEC-29100 ].

  Частные данные безопасности

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

  Недвижимость

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

  Привязка протокола

  Отображение возможности взаимодействия с конкретным сообщения определенного протокола, тем самым информируя Потребителей как активировать Interaction Affordance. W3C WoT сериализует Привязки протоколов как элементы управления гипермедиа.

  Общественная безопасность Метаданные

  Метаданные общественной безопасности — это компонент Конфигурация безопасности, описывающая безопасность механизмы и права доступа, необходимые для доступа к Вещи. Это не содержит никакой секретной информации или конкретных данных (включая открытые ключи) и сам по себе не обеспечивает доступ к Вещи. Вместо этого он описывает механизмы, доступ к которым могут получить авторизованные пользователи, в том числе как они должны аутентифицировать себя.

  Безопасность

  Сохранение конфиденциальности, целостности и доступность информации. Такие свойства, как подлинность, подотчетность, неотказуемость и надежность также могут вовлеченный. Это определение адаптировано из определения Информационная безопасность в [ ISO-IEC-27000 ], который также включает дополнительные определения каждого из упомянуты более конкретные свойства. Пожалуйста, обратитесь к этому документ для других связанных определений. Мы дополнительно отмечаем что желательно, чтобы эти свойства сохранялись как при нормальной работе и когда система подвергается атака.

  Безопасность Конфигурация

  Комбинация метаданных общественной безопасности, частных Данные безопасности и любая другая информация о конфигурации (например, как открытые ключи), необходимые для оперативной настройки механизмы безопасности Вещи.

  Слуга

  Программный стек, реализующий строительные блоки WoT. Слуга может размещать и выставлять Вещи и/или размещать Потребителей которые потребляют Вещи. Серверы могут поддерживать несколько протоколов Привязки для обеспечения взаимодействия с различными IoT платформы.

  Подпротокол

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

  ТД

  Краткое описание вещи WoT.

  ТД Словарь

  Контролируемый словарь связанных данных от W3C WoT для маркировки метаданные вещей в WoT Thing Description, включая коммуникационные метаданные шаблонов привязки WoT.

  Thing или Web Thing

  Абстракция физического или виртуального объекта, метаданные и интерфейсы описываются WoT Thing Описание, в то время как виртуальная сущность представляет собой композицию одна или несколько Вещей.

  Каталог вещей

  Служба каталогов для TD, предоставляющая веб-интерфейс зарегистрировать ТД (аналогично [ CoRE-RD ]) и посмотреть их вверх (например, с помощью запросов SPARQL или поиска CoRE RD). интерфейс [ CoRE-RD ]).

  Трансфер Протокол

  Базовый стандартизированный протокол прикладного уровня без специальных требований или ограничений на параметры или механизмы подпротокола. Примеры: HTTP, CoAP, или МКТТ.

  Виртуальный Вещь

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

  WoT Интерфейс

  Сетевой интерфейс описанной вещи по описанию вещей WoT.

  WoT Время выполнения

  Система выполнения, поддерживающая среду выполнения для приложений и может предоставлять и/или потреблять Вещи, для обработки описаний вещей WoT, для поддержания Конфигурации безопасности и интерфейс с протоколом Реализации привязки. WoT Runtime может иметь собственный API или используйте дополнительный API сценариев WoT.

  WoT API сценариев

  Программный интерфейс для приложений, предоставляемый Слугу, чтобы облегчить реализацию поведения или приложения, работающие в WoT Runtime. Это сравнимо с API веб-браузера. WoT Scripting API является необязательным стандартный блок для W3C WoT.

  WoT Слуга

  Синоним Слуги.

  WoT Описание предмета или Описание предмета

  Структурированные данные, описывающие вещь. Вещь WoT Описание включает общие метаданные, специфичные для предметной области метаданные, возможности взаимодействия (включая поддерживаемые привязки протоколов) и ссылки на связанные вещи. Формат WoT Thing Description — это центральное здание. блок W3C WoT.

  4. Использование Дела

  Этот раздел не является нормативным.

  В этом разделе представлены области применения и варианты использования нацелены на W3C WoT и которые используются для получения абстрактной архитектуры, описанной в § 7. Строительные блоки WoT.

  Архитектура Web of Things не накладывает никаких ограничений по вариантам использования и предметным областям. Различные приложения считалось, что домены собирают общие шаблоны, которые должны быть удовлетворены абстрактной архитектурой.

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

  4.1 Домены приложений
  4.1.1 Потребитель

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

  Сценарии потребительского использования в этом разделе включают Smart Вариант домашнего использования.

  Рисунок 1 показывает Пример Умного дома. В этом случае шлюзы подключен к периферийным устройствам, таким как датчики, камеры и домашние приборы через соответствующую местную связь такие протоколы, как KNX, ECHONET, ZigBee, DECT ULE и Wi-SUN. В одном доме может быть несколько шлюзов, в то время как каждый шлюз может поддерживать несколько локальных протоколов.

  Шлюзы могут быть подключены к облаку через Интернет, в то время как некоторые приборы могут быть подключены к облако напрямую. Службы, работающие в облаке, собирают данные с пограничных устройств и анализировать данные, а затем предоставлять ценность пользователям через периферийные устройства и другие UX-устройства.

  Рисунок 1 Умный дом

  «Умный дом» предоставляет потребительские преимущества, такие как удаленное доступ и контроль, голосовое управление и домашняя автоматизация. Умный дом также позволяет производителям устройств отслеживать и обслуживать устройства удаленно. Умный дом может реализовать ценность дополнительные услуги, такие как управление энергопотреблением и безопасность наблюдение.

  4. 1.2 Промышленный

  Варианты промышленного использования в этом разделе применимы к разным отраслевым вертикалям.
  Из-за характера перекрытий в сценариях приложений разные вертикали имеют схожие варианты использования.

  4.1.2.1 Пример: Smart Factory

  Рисунок 2 показывает пример умной фабрики. В таком случае, контроллеры полевого уровня, ячейки и линии автоматизируют различные заводское оборудование на базе промышленной связи такие протоколы, как PROFINET, Modbus, OPC UA TSN, EtherCAT, или МОЖЕТ. Промышленное пограничное устройство собирает выбранные данные с различных контроллеров и делает его доступным для облачный серверный сервис, например, для удаленного мониторинга через приборной панели или анализирует ее для профилактического обслуживания.

  Рисунок 2 Умная фабрика

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

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

  Оперативный мониторинг и расчет KPI производства оборудование помогает выявлять проблемы с производительностью и оптимизировать цепочку поставок.

  4.1.3 Транспорт и логистика

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

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

  Централизованный мониторинг и управление запасами в склады и дворы могут предотвратить отсутствие на складе и чрезмерное фондовые ситуации.

  4.1.4 Коммунальные услуги

  Автоматическое считывание жилых и КИПиА (коммерческих и промышленных) метров, а биллинговые предложения непрерывны представление о потреблении ресурсов и потенциале узкие места.

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

  Мониторинг и дистанционное управление распределением оборудование помогает автоматизировать процесс дистрибуции.

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

  4.1.5 Масло и Газ

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

  Автоматизированный расчет распределенного запаса через различные резервуары для хранения и транспортировочные трубы / грузовики позволяют улучшенное планирование и оптимизация ресурсов.

  4.1.6 Страховка

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

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

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

  4.1.7 Проектирование и строительство

  Мониторинг промышленной безопасности снижает риски угрозы безопасности. Мониторинг активов на строительной площадке может предотвратить повреждение и потерю.

  4.1.8 Сельское хозяйство

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

  4.1.9 Здравоохранение

  Сбор данных и анализ данных клинических испытаний помогает осваивать новые области.

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

  4.1.10 Мониторинг окружающей среды

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

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

  4.1.11 Смарт Города

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

  Smart Parking оптимизирует и отслеживает использование и наличие парковочных мест и автоматов выставление счетов/бронирование.

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

  Контейнеры для мусора можно отслеживать для оптимизации управление отходами и маршрут сбора мусора.

  4.1.12 Умные здания

  Мониторинг энергопотребления по всему зданию помогает оптимизировать потребление ресурсов и снизить напрасно тратить.

  Мониторинг оборудования в зданиях, такого как HVAC, Лифты и т. д., а раннее устранение проблем улучшает удовлетворение жильцов.

  4.1.13 Подключенный автомобиль

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

  4.1.13.1 Пример подключенного автомобиля

  Рисунок 3 показывает пример Connected Car. В этом случае шлюз подключается к компонентам автомобиля через CAN и к автомобильная навигационная система через фирменный интерфейс. Службы, работающие в облаке, собирают данные, передаваемые из компонентов автомобиля и анализировать данные с нескольких автомобилей для определять схемы движения. Шлюз также может потреблять облачные сервисы, в данном случае для получения данных о трафике и показать водителю через автомобильную навигацию система.

  Рисунок 3 Подключенный автомобиль
  4,2 Общие шаблоны

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

  Одним из примеров этой двойной роли является датчик, который регистрирует сам с облачным сервисом и регулярно отправляет датчик показания в облако. В ответных сообщениях облако может настроить скорость передачи сообщений датчика или выберите определенные атрибуты датчика, которые должны быть переданы в будущих сообщениях. Так как датчик регистрирует себя с облаке и инициирует соединения, он находится в «клиенте» роль. Однако, поскольку он также реагирует на запросы, т.е. передается в ответных сообщениях, он также выполняет «серверную» роль.

  В следующих разделах показаны роли, задачи и шаблоны вариантов использования с возрастающей сложностью. Они не исчерпывающим и представлены для мотивации для WoT архитектура и строительные блоки, которые определены позже разделы данной спецификации.

  4.2.1 Контроллеры устройств

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

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

  Рисунок 4 Управление устройством
  4.2.2 Вещь-в-вещь

  Рисунок 5 показывает пример прямого взаимодействия «вещь-вещь». сценарий следующий: датчик фиксирует изменение комнатных условиях, например, температура выше пороговое значение и выдает управляющее сообщение, например, «включить», чтобы электронный прибор. Сенсорный блок может выдавать некоторые запускать сообщения на другие устройства.

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

  Рисунок 5 Агент управления
  4. 2.3 Удаленный доступ

  Этот вариант использования содержит мобильный пульт дистанционного управления (например, на смартфоне), как показано на рисунке 6 . Пульт дистанционного управления может переключаться между различными сетевыми подключениями и протоколами, например, между сотовой сетью и домашней сетью, которая использует такие протоколы, как Wi-Fi и Bluetooth. Когда контроллер находится в домашней сети, это доверенное устройство и никакой дополнительной безопасности или контроля доступа не требуется. Когда он находится за пределами доверенной сети, дополнительные должны применяться механизмы контроля доступа и безопасности. обеспечить доверительные отношения. Обратите внимание, что в этом сценарии подключение к сети может измениться из-за переключения между различными точками доступа к сети или сотовой базой станции.

  В этом шаблоне пульт дистанционного управления и электронное устройство имеет роль клиента и сервера, как в соответствующий сценарий на рисунке 4 .

  Рисунок 6 Несколько сетевых интерфейсов
  4.2.4 Шлюзы для умного дома

  Рисунок 7 показывает пример использования шлюза Smart Home. Шлюз между домашней сетью и Интернетом. Он управляет электронные приборы внутри дома и могут получать команды с удаленного контроллера через Интернет, например, со смартфона, как и в предыдущем случае использования. Это также является виртуальным представлением устройства. Умный дом Шлюз обычно предлагает прокси и брандмауэр функциональность.

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

  Рисунок 7 Шлюз умного дома
  4.2.5 Пограничные устройства

  Edge Device или Edge Gateway похожи на Smart Домашний шлюз. Мы используем этот термин для обозначения дополнительных задач которые выполняются пограничным шлюзом. В то время как дом шлюз на рисунке 8 прежде всего просто мосты между общественностью и доверенными сети, пограничное устройство имеет локальные вычислительные возможности и обычно является мостом между различными протоколами. Пограничные устройства обычно используются в промышленных решениях, где они могут обеспечить предварительную обработку, фильтрацию и агрегацию данных обеспечивается подключенными устройствами и датчиками.

  Рисунок 8 Пограничное устройство
  4.2.6 Цифровые двойники

  Цифровой двойник – это виртуальное представление, т. е. устройства или группы устройств, находящихся в облаке сервер или пограничное устройство. Его можно использовать для представления реальные устройства, которые могут не быть постоянно в сети, или запускать симуляции новых приложений и сервисов, прежде чем они развертываются на реальных устройствах.

  Рисунок 9 Цифровой двойник

  Цифровые двойники могут моделировать одно устройство или объединить несколько устройств в виртуальное представление комбинированные устройства.

  Рисунок 10 Цифровой двойник для нескольких устройств

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

  4.2.6.1 Готовые к облаку устройства

  Рисунок 11 показывает пример, где электронные приборы подключаются непосредственно к облако. Облако отражает приборы и, действуя как цифровой двойник, может получать команды с пульта контроллеры (например, смартфон). Авторизованные контроллеры может быть расположен где угодно, так как цифровой двойник доступный.

  Рисунок 11 Устройство-двойник для готового к работе в облаке Устройства
  4.2.6.2 Устаревшие устройства

  Рисунок 12 показывает пример, где электронные приборы не могут напрямую подключаться к облако. Здесь шлюз необходим для ретрансляции соединения. Шлюз работает как:

  • интегратор различных традиционных средств связи протоколов как в физическом, так и в логическом виде
  • брандмауэр к Интернету
  Фильтр конфиденциальности
  • , который заменяет реальное изображение и/или речи и локально записывает данные
  • локальный агент в случае, если сетевое соединение прервано
  • аварийно-спасательных служб работают локально при пожарной тревоге и подобные события происходят

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

  Рисунок 12 Цифровой двойник для устаревшего устройства
  4.2.7 Мультиоблако

  Типичные развертывания IoT состоят из нескольких (тысяч) устройств. Без стандартизированного механизма управление обновлениями встроенного ПО для конкретных облаков требуют требует много усилий и препятствует более широкому внедрению IoT.

  Основное преимущество стандартизированного механизма описание устройств и типов устройств — это возможность развертывание устройств в различных облачных средах без необходимость настройки программного обеспечения устройства / уровень прошивки, т. е. установка специального облачного кода в устройство. Это означает, что решение является достаточно гибким. описывать устройства таким образом, который позволяет использование устройств в нескольких облачных средах IoT.

  Это стимулирует внедрение устройств Web of Things, поскольку позволяет легко использовать новые устройства в существующей развертывание, а также миграция существующих устройств из одно облако в другое.

  4.2.8 Междоменное сотрудничество

  Рисунок 13 показать пример междоменного сотрудничество. При этом каждая система включает в себя другие системы в других доменах, такие как Smart Factory с Smart Город, умный город с умным домом. Этот тип системы называется «симбиотической» экосистемой, как показано в [ IEC-FOTF ]. Там две модели сотрудничества: прямое сотрудничество и непрямое сотрудничество. В модели прямого сотрудничества системы обмениваются информацией напрямую друг с другом в равноправным способом. При непрямом сотрудничестве системы обмениваться информацией через какую-либо платформу для совместной работы. В для поддержания и продолжения этого сотрудничества каждый система предоставляет метаданные своих возможностей и взаимодействует и адаптируется к другим.

  Рисунок 13 Междоменное сотрудничество
  4,3 Резюме

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

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

  Рисунок 14 Обзор варианта использования
  5. Требования

  Этот раздел является нормативным.

  5.1 Функциональные требования

  В этом разделе определяются свойства, необходимые для абстрактная архитектура Web of Things (WoT).

  5.1.1 Общие принципы
  • Архитектура WoT должна обеспечивать взаимное взаимодействие различные экосистемы с использованием веб-технологий.
  • Архитектура WoT должна быть основана на сети архитектура с использованием RESTful API.
  • Архитектура WoT должна позволять использовать несколько полезных нагрузок форматы, которые обычно используются в Интернете.
  • Архитектура WoT должна включать другое устройство архитектуры и не должны принуждать клиент или сервер реализация компонентов системы.
  • Гибкость

    Существует большое разнообразие физических устройств. конфигурации для реализации WoT. WoT абстрактная архитектура должна иметь возможность отображать и охватывать все варианты.

  • Совместимость

    Уже существует много существующих решений IoT и текущая деятельность по стандартизации IoT во многих компаниях поля. WoT должен стать связующим звеном между этими существующие и разрабатываемые решения IoT и веб- технология, основанная на концепциях WoT. ВОТ должен быть совместимость с существующими решениями IoT и действующие стандарты.

  • Масштабируемость

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

  • Совместимость

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

  5.1.2 Функциональность вещи
  • Архитектура WoT должна позволять функциональные возможности, такие как
    • чтение информации о состоянии объекта
    • обновление информации о статусе вещи, которая может вызвать срабатывание
    • подписка, получение и отписка от уведомления об изменении статуса вещи Информация.
    • вызов функций с вводом и выводом параметры, которые могут привести к определенному срабатыванию или расчет.
    • подписка, получение и отписка от уведомления о событиях, которые носят более общий характер, чем просто отчеты о переходах состояний.
  5.1.3 Поиск и обнаружение
  • Архитектура WoT должна позволять клиентам атрибуты, функциональные возможности и их точки доступа, до доступа к самой вещи.
  • Архитектура WoT должна позволять клиентам осуществлять поиск вещи по своим свойствам и функциям.
  • Архитектура WoT должна позволять семантический поиск вещи, обеспечивающие необходимые функции на основе единая лексика, независимо от наименования функциональные возможности.
  5.1. 4 Описание Механизм
  • Архитектура WoT должна поддерживать общее описание механизм, позволяющий описывать вещи и их функции.
  • Такие описания должны быть не только удобочитаемыми, но и машиночитаемый.
  • Такие описания должны позволять семантическую аннотацию его структура и описанное содержание.
  • Такое описание должно иметь возможность обмена с использованием несколько форматов, которые обычно используются в Интернете.
  5.1.5 Описание атрибутов
  • Архитектура WoT должна позволять описывать атрибуты, такие как
    • имя
    • объяснение
    • версия спецификации, формат и описание сам
    • ссылок на другие связанные вещи и метаданные информация
  • Такие описания должны поддерживать интернационализация.
  5.1.6 Описание функций
  • Архитектура WoT должна позволять описывать функциональные возможности, которые показаны в § 5.1.2 Вещь Функциональность
  5.1.7 Сеть
  • Архитектура WoT должна поддерживать несколько протоколы, которые обычно используются.
  • Такие протоколы включают
    1. протоколов, обычно используемых в Интернете, и
    Протоколы
    2. , обычно используемые в локальной сети сеть
  • Архитектура WoT должна позволять использовать несколько протоколы для доступа к той же функциональности.
  • Архитектура WoT должна позволять использовать комбинацию несколько протоколов к функциям одного и того же вещь (например, HTTP и WebSocket).
  5. 1.8 Развертывание
  • Архитектура WoT должна поддерживать широкий спектр такие возможности, как пограничные устройства с ресурсом ограничения и виртуальные вещи в облаке, основанные на та же модель.
  • Архитектура WoT должна поддерживать несколько уровней иерархия вещей с промежуточными сущностями, такими как шлюзы и прокси.
  • Архитектура WoT должна поддерживать доступ к вещам в локальная сеть из-за пределов локальной сети (Интернет или другая локальная сеть), учитывая трансляция сетевых адресов.
  5.1.9 Заявка
  • Архитектура WoT должна позволять описывать приложения для самых разных вещей, таких как краевое устройство, шлюз, облако и устройство UI/UX, используя веб-стандарт технология, основанная на той же модели.
  5. 1.10 Принятие прежних версий
  • Архитектура WoT должна позволять сопоставление устаревших IP и не-IP протоколы к веб-протоколам, поддерживая различные топологии, где такие устаревшие протоколы прекращаются и переведено.
  • Архитектура WoT должна обеспечивать прозрачное использование существующие протоколы IP без перевода, которые следуют RESTful архитектура.
  • Архитектура WoT не должна применять клиент или сервер роли на устройствах и сервисах. Устройство IoT может быть либо клиент, либо сервер, либо и то, и другое, в зависимости от Архитектура системы; то же самое верно для края и облака Сервисы.
  5.2 Технические требования

  § 4.2 Общий Шаблоны определяют абстрактную архитектуру Web of Things показывая различные варианты использования и перечисляя шаблоны для объединение архитектурных компонентов. В этом разделе описывается технические требования, вытекающие из реферата архитектура.

  5.2.1 Компоненты в сети Вещи и архитектура сети вещей

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

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

  5.2.2 Устройства

  Доступ к устройствам осуществляется по описанию их функции и интерфейсы. Это описание называется Описание вещи (TD) . Вещь Описание включает общие метаданные о устройство, информационные модели, представляющие функции, описание транспортного протокола для работы с информацией модели и информацию о безопасности.

  Общие метаданные содержат идентификаторы устройств (URI), информация об устройстве, такая как серийный номер, дата производства, местоположение и другую удобочитаемую информацию.

  Информационные модели определяют атрибуты устройства и отображать внутренние настройки устройства, управлять функциональностью и функция уведомлений. Устройства, имеющие одинаковые функциональные возможности имеют одну и ту же информационную модель независимо от используемые транспортные протоколы.

  Поскольку многие системы, основанные на архитектуре Web of Things пересекают системные домены, словари и метаданные (например, онтологии), используемые в информационных моделях, должны быть обычно понимаются заинтересованными сторонами. В дополнение к Также поддерживаются транспорты REST, PubSub.

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

  5.2.3 Приложения

  Приложения должны иметь возможность генерировать и использовать сетевые и программные интерфейсы на основе метаданных (описания).

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

  5.2.4 Цифровые двойники

  Цифровым двойникам необходимо генерировать программные интерфейсы внутренне на основе метаданных (описаний) и представлять виртуальные устройства с помощью этих программ интерфейсы. Близнец должен дать описание виртуальное устройство и сделать его доступным извне.

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

  5.2.5 Открытие

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

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

  5.2.6 Безопасность

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

  Архитектура WoT должна поддерживать множественную безопасность механизм, обычно используемый в Интернете, такой как Basic, Digest, Носитель и OAuth3. 0.

  5.2.7 Доступность

  Сеть вещей в первую очередь нацелена на межмашинное взаимодействие коммуникация. Вовлеченные люди обычно являются разработчиками которые интегрируют вещи в приложения. Конечные пользователи будут столкнулись с внешними интерфейсами приложений или физические пользовательские интерфейсы, предоставляемые самими устройствами. Оба выходят за рамки спецификаций W3C WoT. Учитывая акцент на IoT, а не на пользователях, доступность не является прямым требованием и, следовательно, не рассматривается в рамках эта спецификация.

  Есть, однако, интересный аспект на доступность: выполнение вышеуказанных требований позволяет машины, чтобы понять сетевой API устройств. Это может быть использовано инструментами специальных возможностей, чтобы предоставить пользователю интерфейсы разной модальности, тем самым устраняя барьеры к использованию физических устройств и приложений, связанных с IoT.

  6. WoT Архитектура

  Этот раздел является нормативным.

  Чтобы рассмотреть варианты использования в Разделе 4 и выполнить требованиям раздела 5, Web of Things (WoT) основывается на вершина концепции Web Things — обычно просто называется Вещи – которыми могут пользоваться так называемые Потребители. В этом разделе представлена ​​предыстория и нормативные утверждения для определения общего W3C Web of Things архитектура. Поскольку Web of Things обращается к заинтересованным сторонам из различные домены, некоторые аспекты веб-технологий более подробно разъяснить, в частности, понятие гипермедиа.

  6.1 Обзор

  Вещь — это абстракция физического или виртуального объект (например, устройство или комната) и описывается как стандартизированные метаданные. В W3C WoT описание метаданные ДОЛЖНЫ быть WoT Описание вещи (TD) [ WOT-THING-DESCRIPTION ]. Потребители ДОЛЖНЫ уметь анализировать и обрабатывать формат представления TD, основанный на JSON [ RFC8259]. Формат может быть обработан либо через классический JSON библиотеки или процессор JSON-LD в качестве основного информационная модель основана на графе и ее сериализации совместим с JSON-LD 1.1 [ JSON-LD11 ]. Использование JSON-LD процессор для обработки ТД дополнительно включает семантические обработка, включая преобразование в тройки RDF, семантические вывод и выполнение задач, поставленных на основе онтологических условия, которые заставили бы потребителей вести себя более автономный. TD зависит от конкретного экземпляра (т. е. описывает отдельную Вещь, а не типы Вещей) и внешнее текстовое (веб) представление по умолчанию Вещь. Там МОЖЕТ быть другими представлениями Вещи, такими как пользовательский интерфейс на основе HTML, просто изображение физического объекта или даже не веб-сайта представления в закрытых системах.

  Кому быть Вещью, однако, по крайней мере один TD представление ДОЛЖНО быть доступный. Вещь WoT Описание представляет собой стандартизированное, машиночитаемое формат представления, который позволяет Потребителям обнаруживать и интерпретировать возможности Вещи (посредством семантических аннотаций) и адаптировать к разным реализациям (например, к разным протоколам или структуры данных) при взаимодействии с Вещью, тем самым обеспечение взаимодействия между различными платформами IoT, т. е. различными экосистемами и стандарты.

  Рисунок 15 Взаимодействие Потребитель-Вещь

  Вещь также может быть абстракцией виртуального организация. Виртуальный объект представляет собой композицию одного или нескольких Вещи (например, помещение, состоящее из нескольких датчиков и приводы). Одним из вариантов композиции является предоставление единая, объединенная вещь WoT Описание, содержащее расширенный набор возможностей для виртуальной сущности. В тех случаях, когда состав довольно сложный, его ТД 9 мая0005 ссылка на иерархическую подвещи в композиции. Основной ТД выступает в качестве входа точки и содержат только общие метаданные и потенциально всеобъемлющие возможности. Это позволяет группировать определенные аспекты более сложных вещей.

  Связывание применяется не только к иерархическим вещам, но и к отношениям между вещами и другими ресурсов в целом. Типы отношений ссылок выражают то, как вещи относятся, например, к выключателю, управляющему светом или комнатой контролируется датчиком движения. Другие ресурсы, связанные с Это могут быть инструкции, каталоги запчастей, САПР. файлы, графический интерфейс или любой другой документ в Интернете. В целом, веб-ссылки между вещами делают Сеть вещей судоходным, как для людей, так и для машин. Это может быть дальше облегчается путем предоставления каталогов вещей, которые управляют каталог доступных Вещей, обычно путем кэширования их ТД представление. Подводя итог, WoT Thing Описания МАЯ ссылка на другие вещи и другие ресурсы на Web для формирования сети вещей.

  Рисунок 16 Связанные вещи

  Вещи должны размещаться на сетевых компонентах системы с программный стек для реализации взаимодействия через сетевой интерфейс, интерфейс WoT вещь. Одним из примеров этого является HTTP-сервер. работает на встроенном устройстве с датчиками и исполнительными механизмами взаимодействие физического объекта за абстракцией Вещи. Однако W3C WoT не требует где размещаются Вещи; это может быть на Устройство IoT напрямую, пограничное устройство, такое как шлюз или облако.

  Типичная проблема развертывания — это сценарий, в котором локальный сети недоступны из Интернета, как правило, потому, что трансляции сетевых адресов IPv4 (NAT) или брандмауэра устройства. Чтобы исправить эту ситуацию, W3C WoT позволяет Посредники между вещами и потребителями.

  Посредники могут выступать в качестве доверенных лиц для Вещей, где Посредник Описание вещи WoT, похожее на оригинальная Вещь, но которая указывает на Интерфейс WoT предоставлен Посредник. Посредники также могут дополнять существующие Вещи дополнительными возможностями или составлять новую Вещь из нескольких доступных Вещей, образуя тем самым виртуальную сущность. К Потребители, Посредники смотрят как Вещи, так как они обладают описаниями вещей WoT и предоставляют Интерфейс WoT и, следовательно, может быть неотличимы от Вещей в многослойном системная архитектура, как в Интернете [ ОТДЫХ ]. Ан идентификатор в описании вещи WoT ДОЛЖЕН учитывать корреляция нескольких TD, представляющих один и тот же оригинал Вещь или в конечном счете уникальная физическая организация.

  Фигура 17 Посредник

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

  Вещи МАЙ должны быть объединены вместе с Потребителем, чтобы включить Взаимодействие «вещь-вещь». Как правило, Потребитель поведение встроено в программный компонент, который также реализация поведения Вещи. конфигурация поведения Потребителя МАЯ может быть раскрыта через Вещь.

  Концепции W3C WoT применимы к все уровни, относящиеся к приложениям IoT: уровень устройства, уровень края и уровень облака. Это способствует распространению интерфейсов и API на разных уровнях и позволяет использовать различные интеграционные шаблоны, такие как Thing-to-Thing, Thing-to-Gateway, Thing-to-Cloud, Gateway-to-Cloud и даже облачная федерация, т. е. объединение облачных вычислений среды двух или более поставщиков услуг, для IoT Приложения. Фигура 18 дает обзор того, как WoT понятия, введенные выше, могут быть применены и объединены для рассмотреть варианты использования, кратко изложенные в § 4.3 Резюме.

  Рисунок 18 Абстрактная архитектура W3C WoT
  6,2

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

  Термин аффорданс берет свое начало в экологической психологии, но был принят в области взаимодействия человека с компьютером [ ХКИ ] на основе определения Дональда Нормана: «Доступность» относится к воспринимаемым и действительным свойствам вещи, прежде всего те фундаментальные свойства, которые определяют именно как эту вещь можно было бы использовать. " [ НОРМАН ]

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

  Принцип гипермедиа, который является одним из основных основы архитектурного стиля REST [ REST ], требует, чтобы любая информация, доступная в Интернете, была связаны с другими частями информации, чтобы потребитель информация получает явное знание о том, как перемещаться Интернет и управлять веб-приложениями. Здесь одновременный представление информации и контроль (предоставляется в форме гиперссылок) — это механизм, который предоставляет Web клиенты средства для управления веб-приложениями. В контексте, аффорданс — это описание гиперссылки (например, через тип отношения ссылки и атрибуты цели ссылки), предполагая, что Интернет клиенты, как перемещаться и, возможно, как действовать на связанной ресурс. Следовательно, ссылки обеспечивают возможности навигации.

  Основанная на этом принципе гипермедиа сеть вещей определяет взаимодействие Возможности как метаданные Вещи, которая показывает и описывает возможные варианты выбора для Потребителей, тем самым предлагая, как Потребители могут взаимодействовать с Вещью. Общая возможность взаимодействия навигация, которая активируется переходом по ссылке, тем самым позволяя Потребителям просматривать веб-сайты Вещи. §  6.4 Взаимодействие Модель определяет еще три типа возможностей взаимодействия. на W3C WoT: Свойства, действия и события.

  В целом, это определение W3C WoT в сотрудничестве с дизайнерами человеко-компьютерного взаимодействия и взаимодействия, которые создают физические вещи, а также REST и микросервисы сообщество, которое работает над веб-сервисами в целом.

  6.3 Интернет Вещь

  Web Thing имеет четыре интересующих архитектурных аспекта: его поведение , его возможности взаимодействия , его Конфигурация безопасности и ее привязки протокола , как показано на рисунке на рисунке 19 . Поведенческий аспект Вещи включает в себя как автономное поведение, так и обработчики для взаимодействия Возможности. Взаимодействие Возможности предоставляют модель того, как Потребители могут взаимодействовать с Вещью посредством абстрактных операций, но без ссылка на конкретный сетевой протокол или кодировку данных. Привязка протокола добавляет дополнительную информацию, необходимую для сопоставления каждое взаимодействие к конкретным сообщениям определенного протокола. В целом, различные конкретные протоколы могут использоваться для поддержки различных подмножества взаимодействия Возможности даже в рамках одной вещи. Охрана аспект конфигурации Вещи представляет механизмы используется для управления доступом к возможностям взаимодействия и управление соответствующей общественной безопасностью Метаданные и личная безопасность Данные.

  Рисунок 19 Архитектурные аспекты вещи
  6,4 Модель взаимодействия

  Первоначально веб-ресурс обычно представлял собой документ во Всемирной паутине, которые могут быть просто получены через Интернет клиент. С появлением веб-сервисов ресурсы стали более общими объектами взаимодействия, которые могут реализовывать любое поведение. Этот очень высокий уровень абстракции затрудняет обеспечение слабой связи между приложений и ресурсов благодаря разнообразному взаимодействию возможности. В результате на момент написания типичный Описания API состоят из статического отображения из намерение приложения к адресу ресурса, методу, запросу структура полезной нагрузки, структура полезной нагрузки ответа и ожидаемая ошибки. Это создает тесную связь между веб-клиентом и Веб-сервис.

  Модель взаимодействия W3C WoT вводит промежуточная абстракция, формализующая отображение из намерение приложения к конкретным операциям протокола, а также сужает возможности того, как интерактивные возможности могут быть смоделированный.

  В в дополнение к возможностям навигации (например, веб-ссылкам), Вещи 90 МАЯ 006 предлагают три других типа возможностей взаимодействия, определенных эту спецификацию: свойства, действия и события. Пока эта узкая талия позволяет разделить потребителей и Вещи, эти четыре типа возможностей взаимодействия все еще способен моделировать практически все найденные возможности взаимодействия в устройствах и сервисах IoT.

  6.4.1 Недвижимость

  Свойство — это возможность взаимодействия, которая раскрывает состояние Вещи. Состояние, выставленное свойством ДОЛЖЕН быть извлекаемым (удобочитаемый). Опционально, состояние, выставленное Свойство 9006 МАЯ быть обновленный (доступный для записи). Вещи МАЙ решили сделать Свойства можно наблюдать, помещая новое состояние после изменения (см. Наблюдение за ресурсами [ RFC7641 ]). Состояние только для записи должно быть обновлено с помощью действия.

  Если данные не полностью определяется используемой привязкой протокола (например, через тип носителя), Свойства МАЯ содержат одну схему данных для выставленного состояния.

  Примеры свойств: значения датчиков (только для чтения), приводы с состоянием (чтение-запись), параметры конфигурации (чтение-запись), состояние вещи (только чтение или чтение-запись) или результаты вычислений (только для чтения).

  6.4.2 Действия

  Действие — это возможность взаимодействия, позволяющая вызвать функцию Вещи. Действие МАЙ управление состоянием который не подвергается прямому воздействию (см. Свойства), манипулировать несколько свойств одновременно или управлять свойствами на основе внутренней логики (например, переключения). Вызов Действие МАЙ также запустить процесс на Вещи, которая манипулирует состоянием (включая физическое состояние через исполнительные механизмы) более время.

  Если данные указаны не полностью используемой привязкой протокола (например, через тип носителя), Действия МАЯ содержат схемы данных для дополнительного ввода параметры и выходные результаты.

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

  6.4.3 События

  Affordance взаимодействия с событием описывает событие источник, который асинхронно передает данные от вещи к Потребитель. Здесь не состояния, а переходы состояний (т.е. события) сообщаются. События МОЖЕТ запускаться из-за условий, которые не выставлены как свойства.

  Если данные указаны не полностью используемой привязкой протокола (например, через тип носителя), События МАЙ содержат схемы данных для данных событий и возможные сообщения управления подпиской (например, для подписаться с помощью URI обратного вызова Webhook).

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

  6.5 Элементы управления Hypermedia

  В Интернете аффорданс — это одновременное представление информации и средств контроля, чтобы информация становится аффордансом, благодаря которому пользователь получает выбор. Для людей информация обычно представляет собой текст или изображения, описывающие или украшающие гиперссылку. Контроль представляет собой Веб-ссылка, которая включает как минимум URI цели ресурс, который может быть разыменован веб-браузером (т. ссылку можно пройти). Но также машины могут переходить по ссылкам осмысленным образом, когда веб-ссылка далее описывается по типу отношения и набору целевых атрибутов. А управление гипермедиа — это понятное для машины описание из как активировать аффорданс. Гипермедиа элементы управления обычно поступают с веб-сервера и обнаруживаются внутриполосно, пока веб-клиент взаимодействует с сервер. Таким образом, веб-серверы могут управлять клиентами через Интернет. приложений динамически, принимая их текущее состояние и другие факторы, такие как авторизация во внимание. Это в отличие от внеполосных описаний интерфейса, которые необходимо предустановлены или жестко закодированы в клиентах (например, RPC, WS-* Web сервисы, HTTP-сервисы с фиксированным URI-методом-ответом определения).

  W3C WoT использует два типа элементов управления гипермедиа: Web ссылки [ RFC8288 ], хорошо зарекомендовавший себя элемент управления для навигации в Интернете и в Интернете формы как более мощный элемент управления, позволяющий операция. Ссылки уже используются в других стандартах IoT и Платформы Интернета вещей, такие как CoRE Link Формат [ RFC6690 ], ОМА ЛВМ2М [ ЛВМ2М ], и OCF [ OCF ]. Форма — это новый концепция, что помимо 9Также представлен 4706 W3C WoT. с помощью ограниченного языка приложений RESTful (Коралловый) [ Коралловый ] определено IETF.

  6.5.1 Ссылки

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

  W3C WoT следует определениям веб-ссылок [ RFC8288 ], где ссылка в составе:

  • контекст ссылки,
  • тип отношения,
  • цель ссылки и
  • необязательно целевые атрибуты.

  Типы отношений ссылок представляют собой набор предопределенных токены, зарегистрированные в IANA [ IANA-RELATIONS ], который должен придерживаться ABNF [ RFC5234 ] ЛОАЛЬФА *( LOАЛЬФА / ЦИФРА / "." / "-" ) (например, таблица стилей ), или типы расширений в форме URI [ RFC3986 ]. Типы отношения расширения ДОЛЖНЫ сравниваться как строки использование сравнения без учета регистра. (Если они сериализованы в другом формате, они должны быть преобразованы к URI). Тем не менее, URI со строчными буквами СЛЕДУЕТ использовать для типы отношения расширения. [ RFC8288 ]

  В Web of Things ссылки используются для обнаружения и для выражения отношений между вещами (например, иерархический или функциональный) и отношения к другим документы в Интернете (например, руководства или альтернативные представления, такие как модели САПР).

  6.5.2 Формы

  Формы позволяют потребителям (или веб-клиентам в более широком смысле) для выполнения операций, выходящих за рамки разыменование URI (например, для управления состоянием Вещь). Потребители делают это к заполнение из и подача формы на ее подачу цель. Обычно для этого требуется более подробная информация. о содержании сообщения (запроса), чем ссылка может предоставлять (например, метод, поля заголовка или другие опции). Формы можно рассматривать как шаблон запроса, где провайдер предварительно заполнил части информации в соответствии с к своему собственному интерфейсу и состоянию, а части оставили пустыми, чтобы их можно было заполняется Потребителями (или веб-клиентом в Генеральная).

  W3C WoT определяет формы как новый элемент управления гипермедиа. Обратите внимание, что определение в CoRAL практически идентично, и, следовательно, совместимый [ CoRAL ]. Форма состоит из:

  • контекст формы,
  • тип операции,
  • цель подчинения,
  • метод запроса и
  • необязательных полей формы.

  Форму можно рассматривать как заявление «Выполнить тип операции операция по форме контекст , выдать метод запроса запрос на цель представления "где необязательные поля формы могут дополнительно описывать необходимые запрос.

  Форма

  контексты и цели представления ДОЛЖНЫ оба быть интернационализированными ресурсами Идентификаторы (IRI) [ RFC3987 ]. Однако в общем случае они также будут URI. [ RFC3986 ], потому что многие протоколы (такие как HTTP) не поддерживают Радужная оболочка.

  Контекст формы и цель отправки МАЙ указывают на одно и то же ресурс или разные ресурсы, где представление целевой ресурс реализует операцию для контекст.

  Тип операции определяет семантику операция. Типы операций обозначаются аналогично ссылке типы отношений:

  • Известные типы операций ДОЛЖЕН соблюдать АБНФ ЛОАЛЬФА *( ЛОАЛЬФА / ЦИФРА / "." / "-") . Известные типы операций ДОЛЖЕН сравниваться использование сравнения без учета регистра. известные типы операций для Web of Things определенные этой спецификацией, приведены в таблице 1.
  • Набор предустановленных типов операций МАЙ будет дополнен Типы операций расширения , выбранные Приложения. Типы операций расширения ДОЛЖЕН быть URI [ RFC3986 ] которые однозначно идентифицируют тип. Типы операций расширения ДОЛЖЕН сравниваться с строки, используя сравнение без учета регистра. Тем не менее, все строчные URI ДОЛЖНЫ быть используется для типов операций расширения.

  Метод запроса ДОЛЖЕН идентифицировать один метод стандартный набор протокола, указанный в представлении целевая схема URI.

  Поля формы являются необязательными и МАЙ дополнительно указать ожидаемое сообщение запроса для данного операция. Обратите внимание, что это не ограничивается полезной нагрузки, но может повлиять и на заголовки протоколов. Форма поля МАЙ зависят от протокол, используемый для цели отправки, как указано в схема УРИ. Примерами являются поля заголовка HTTP, Варианты CoAP, независимый от протокола тип носителя [ RFC2046 ] включая параметры (т. е. полный тип содержимого) для запрашивать полезную нагрузку или информацию об ожидаемом отклик.

  Таблица 1. Известные типы операций для сети Вещи

  Тип операции	Описание
  свойства чтения	Идентифицирует операцию чтения свойства Возможности для получения соответствующих данные.
  свойство записи	Идентифицирует операцию записи свойства Возможности для обновления соответствующих данных.
  наблюдаемое свойство	Идентифицирует операцию наблюдения за свойством Возможности быть уведомлены с новыми данными, когда Свойство было обновлено.
  ненаблюдаемое свойство	Идентифицирует незаметную операцию на Свойстве Возможности для прекращения соответствующих уведомления.
  вызов действия	Идентифицирует операцию вызова действия. Возможности для выполнения соответствующих действие.
  событие подписки	Идентифицирует операцию подписки на событие Возможность быть уведомленным вещью, когда происходит событие.
  событие отмены подписки	Идентифицирует операцию отмены подписки на событие Возможности для прекращения соответствующих уведомления.
  чтение всех свойств	Идентифицирует операцию readallproperties на Вещи для получения данных всех свойств в одиночное взаимодействие.
  запись всех свойств	Идентифицирует операцию writeallproperties на Вещи для обновления данных всех доступных для записи Свойства в одном взаимодействии.
  чтение нескольких свойств	Идентифицирует операцию readmultipleproperties на Вещи, чтобы получить данные выбранных Свойства в одном взаимодействии.
  writemultipleproperties	Идентифицирует writemultipleproperties операция над вещами для обновления данных выбранных записываемые свойства за одно взаимодействие.

  Примечание редактора

  Согласно данной спецификации типы операций — это фиксированный набор, который вытекает из WoT Модель взаимодействия. Другой спецификации могут определять дальнейшую хорошо известную операцию типы, допустимые для соответствующего формата документа или форма сериализации. Более поздние версии этого спецификация или другая спецификация могут создать реестр в будущем, чтобы включить расширение и более общая модель веб-формы, которая может применяться за пределами WoT технические характеристики.

  6,6 Привязки протоколов

  Привязка протокола — это сопоставление возможности взаимодействия с конкретным сообщения определенного протокола, такого как HTTP [ RFC7231 ], CoAP [ RFC7252 ], или MQTT [ MQTT ]. Это информирует Потребителя , как активировать Доступность взаимодействия через сетевой интерфейс. Привязки протокола следуют униформе Ограничение интерфейса REST [ ОТДЫХ ] для поддержки взаимодействия. Таким образом, не всякое общение протоколы имеют право на реализацию привязок протоколов для W3C WoT; требования приведены в утверждениях ниже.

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

  6.6.1 На основе гипермедиа

  Возможности взаимодействия ДОЛЖНЫ включать один или несколько Привязки протоколов. Привязки протоколов ДОЛЖЕН быть номер серийным номером средства управления гипермедиа (см. § 6.5 Элементы управления гипермедиа), самоописательный о том, как активировать взаимодействие Доступность. Элементы управления гипермедиа ДОЛЖНЫ исходить из орган, управляющий Вещью, которая обеспечивает соответствующий Interaction Affordance. Полномочия может быть самой Вещью, производящей TD-документ во время выполнения (на основе его текущего состояние и в том числе параметры сети, такие как его IP адрес) или обслуживая его из памяти только с текущим вставлены сетевые параметры. Власть также может быть внешний субъект, обладающий полной и актуальной информацией о Вещь, включая ее сеть параметры и внутреннюю структуру (например, программный стек). Это обеспечивает слабую связь между вещами и Потребители, обеспечивающие независимый жизненный цикл и эволюция. Управление гипермедиа МАЙ кэшируется снаружи Вещь и используется для оффлайна обработка, если метаданные кэширования доступны для определения свежесть.

  6.6.2 URI

  Подходящие протоколы для W3C WoT ДОЛЖНЫ иметь связанный URI схема [ RFC3986 ] который зарегистрирован в IANA (см. [ IANA-URI-SCHEMES ]). Элементы управления Hypermedia полагаются на URI [ RFC3986 ] для определения целей ссылки и представления. Таким образом, URI схема (первый компонент до ":") идентифицирует протокол связи, который будет использоваться для взаимодействия с Вещь. W3C WoT называет эти протоколы протоколами передачи.

  6.6.3 Стандартный набор методов

  Подходящие протоколы для W3C WoT ДОЛЖНЫ основываться на стандартном наборе методов, известных априори. Стандартный набор методов делает сообщения самоописательными, чтобы включить промежуточная обработка Interaction Affordations, для экземпляр по прокси или для перевода между протоколом Крепления [ ОТДЫХ ]. Кроме того, это позволяет потребителям иметь повторно используемые стеки протоколов общих протоколов передачи, таких как HTTP, CoAP или MQTT, избегая специфичного для Thing кода или плагинов для Потребители.

  6.6.4 Типы носителей

  Все данные (также известные как контент), которыми обмениваются при активации взаимодействия Возможности ДОЛЖНЫ быть определяется типом носителя [ RFC2046 ] в привязке протокола. Типы носителей — это ярлыки для определить форматы представления, например приложение/json для JSON [ RFC8259 ] или application/cbor для CBOR [ RFC7049 ]. Они управляются IANA.

  Для некоторых типов носителей могут потребоваться дополнительные параметры. полностью указать используемый формат представления. Примеры текстовый/обычный; кодировка=utf-8 или приложение/ld+json; profile="http://www.w3.org/ns/json-ld#compacted" . Это необходимо учитывать, в частности, при описании данные для отправки в Things. Также может быть стандартизированные преобразования данных, таких как контент кодирование [ RFC7231 ]. Привязки протокола МАЙ имеют дополнительную информацию который определяет форматы представления более подробно, чем только тип носителя.

  Обратите внимание, что многие типы носителей идентифицируют только общий формат сериализации, который не обеспечивает дальнейшего семантика для его элементов (например, XML, JSON, CBOR). Таким образом соответствующие Interaction Affordances СЛЕДУЕТ объявить схему данных для предоставления более подробной информации. синтаксические метаданные для данных, которыми обмениваются.

  6.7 Компоненты системы WoT и их Межсетевое взаимодействие

  Раздел § 6.1 Обзор описал архитектуру WoT с точки зрения абстрактного WoT компоненты архитектуры, такие как вещи, потребители и посредники. Когда эти абстрактные компоненты архитектуры WoT реализованы как программный стек, чтобы играть определенную роль в WoT архитектуре такие программные стеки называются Servients. Системы, основанные на WoT архитектура включает Servients, которые общение друг с другом для достижения цели система.

  В этом разделе диаграммы конфигурации системы используются для показать, как Слуги работают вместе, чтобы построить системы на базе архитектуры WoT.

  Вещь может быть реализована Слугой. В Thing программный стек Servient содержит представление Вещи, называемой Выставленной Вещью, и делает свой интерфейс WoT доступным для Потребителей Вещи. Эта выставленная вещь может использоваться другим программным обеспечением компоненты на сервере (например, приложения) для реализовать поведение вещи.

  Рисунок 20 Слуга как вещь

  С другой стороны, Потребители всегда реализуются Слугами, поскольку они должны иметь возможность обработать описание вещи (TD) формат и должен иметь стек протоколов, который можно настроить через привязку протокола информацию, содержащуюся в ТД.

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

  Рисунок 21 Слуга как потребитель

  Экземпляр потребляемой вещи в Программный стек Servient служит для разделения уровень сложности протокола от приложений. это общение с Exposed Things на имени приложения.

  Аналогично, Посредник еще другой компонент архитектуры WoT, реализованный Servient. Посредник находится между Вещью и ее Потребителями, выполняя роли как Потребителя (к Вещи), так и Вещи (к потребители). В качестве посредника Стек программного обеспечения Servient содержит представления как Потребителя (Потребляемая Вещь), так и Вещи (Выставленная Вещь).

  Рисунок 22 Слуга в качестве посредника
  6. 7.1 Прямая связь

  Рисунок 23 показывает прямую связь между Вещью, которая раскрывает возможности взаимодействия через Описания Вещей и Потребитель, использующий Вещь посредством взаимодействия Возможности. Прямая связь применяется, когда оба Серверы используют одни и те же сетевые протоколы и доступны друг другу.

  Рисунок 23 Высокоуровневая архитектура потребителей и Вещь

  An Exposed Thing — это программное обеспечение представление абстракции Вещи, обслуживание интерфейса WoT предоставляемых возможностей взаимодействия по Вещи.

  Потребляемая вещь - это программное обеспечение представление удаленной вещи, потребляемой Потребителем, выступающим в качестве интерфейса к удаленной Вещи для приложений. А Потребитель может создать экземпляр потребляемой вещи путем анализа и обработки документ ТД. Взаимодействие между Потребителем и Вещью осуществляется Потребляемой Вещью и Выставленной Вещью, обменивающимися сообщениями по прямому сетевое соединение между ними.

  6.7.2 Непрямая связь

  На рисунке 24 , Потребитель и Вещи соединяются друг с другом через посредника. Посредник требуется, если Слуги используют разные протоколы или если они находятся в разных сетях которые требуют аутентификации и обеспечивают контроль доступа (например, брандмауэры).

  Рисунок 24 Высокоуровневая архитектура с Посредник

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

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

  Даже если используется несколько разных протоколов между посредником и вещами потребитель может косвенно общаться с этими вещами, используя единый протокол через посредника. То же самое справедливо и для аутентификации. Потребляемая вещь только потребителя необходимо пройти аутентификацию с помощью Exposed Things Посредника с использованием одного механизм безопасности, а Посредник может потребоваться несколько механизмов безопасности для аутентификации с помощью разные вещи.

  Обычно посредник генерирует описание вещи для своего прокси-объекта на основе описания вещи исходная вещь. В зависимости от требования вариантов использования, ТД для прокси-объекта может использовать тот же идентификатор, что и ТД оригинальную Вещь, или ей присваивается новая идентификатор. При необходимости ТД сгенерировано посредником МАЙ содержит интерфейсы для других протоколов связи.

  7. WoT Строительные блоки

  Этот раздел является нормативным.

  Строительные блоки Web of Things (WoT) позволяют реализация систем, соответствующих абстрактному WoT Архитектура. Специфика этих строительных блоков заключается в том, определяется в отдельной спецификации; этот раздел предоставляет обзор и резюме.

  Строительные блоки WoT поддерживают каждую из архитектурных аспекты Вещи, обсуждаемые в § 6. 3 Web Thing и изображен на рисунке 19 . Показаны отдельные строительные блоки в контексте абстрактной вещи в Фигура 25 . это реферат представление и не представляет какой-либо конкретной реализации; вместо этого он иллюстрирует отношения между зданием блоки и основные архитектурные аспекты Вещи. На этом рисунке строительные блоки WoT: выделены черным контуром. Безопасность, сквозной концерн, делится на публичный и защищенный частный составные части. Скриптовый API WoT необязательно, а шаблоны привязки познавательный.

  Рисунок 25 Отношение строительных блоков WoT к Архитектурные аспекты вещи.

  В следующих разделах мы предоставим дополнительные информация о каждом строительном блоке WoT: описание вещи WoT, Шаблоны привязки WoT и API сценариев WoT. Безопасность, хотя это сквозная проблема, может быть считается четвертым строительным блоком.

  7. 1 Описание вещи WoT

  Описание вещи WoT (TD) спецификация [ WOT-THING-DESCRIPTION ] определяет информационную модель на основе семантической словарь и сериализованное представление на основе JSON . TD предоставляют обширные метаданные для Вещи таким образом, чтобы они были удобочитаемы и машина-понятная. И информационная модель, и формат представления ТД согласованы с Связанные данные [ LINKED-DATA ], чтобы помимо необработанной обработки JSON, реализации могут выбрать используйте JSON-LD [ JSON-LD11 ] и графические базы данных для включить мощную семантическую обработку метаданных.

  Описание вещи (TD) описывает Экземпляры вещей с общими метаданными, такими как имя, ID, описания, а также могут предоставлять метаданные отношений через ссылки на связанные вещи или другие документы. TD также содержат метаданные Interaction Affordance. на основе модели взаимодействия, определенной в § 6.4 Модель взаимодействия; метаданные общественной безопасности; а также метаданные связи, определяющие привязки протоколов. ТД может быть замеченным как index.html для вещей , так как обеспечивает точку входа, чтобы узнать о предоставляемых услугах и связанные ресурсы, оба из которых описаны с использованием управление гипермедиа.

  В идеале TD создается и/или размещается Сама вещь и извлеченная при обнаружении. И все же это также может размещаться снаружи, когда вещь имеет ограничения ресурсов (например, ограниченный объем памяти, ограниченный мощность) или когда существующее устройство модернизируется, чтобы стать часть Сети вещей. Общий шаблон для улучшения обнаружение (например, для ограниченных устройств) и облегчить управление устройством заключается в регистрации ТД в каталоге. Потребителям рекомендуется использовать кэширование TD механизм в сочетании с механизмом уведомления, который информировать их, когда требуется получить новую версию ТД, если Вещь обновляется.

  Для семантической интероперабельности ТД могут использовать предметно-ориентированный словарь, для которого явное расширение предусмотрены баллы. Однако развитие какой-либо конкретной предметно-ориентированная лексика в настоящее время выходит за рамки W3C WoT деятельность по стандартизации.

  Три примера потенциально полезного внешнего IoT словари SAREF [ SAREF ], Расширения схемы для IoT [ IOT-SCHEMA-ORG ], и W3C Онтология семантической сенсорной сети [ VOCAB-SSN ]. Использовать таких внешних словарей в ТД является необязательным. В будущие дополнительные словари, специфичные для предметной области, могут быть разработаны и используются с ТД.

  Общее описание вещи WoT строительный блок способствует взаимодействию двумя способами: во-первых, TD обеспечивают связь между машинами в Сеть вещей. Во-вторых, ТД могут служить общим, унифицированным формат, позволяющий разработчикам документировать и извлекать все сведения, необходимые для создания приложений, которые могут получить доступ к IoT устройств и использовать их данные.

  7.2 Шаблоны привязки WoT

  Этот раздел не является нормативным.

  IoT использует различные протоколы для доступа к устройствам, поскольку ни один протокол не подходит для всех контекстов. Таким образом, главная задача Web of Things состоит в том, чтобы позволить взаимодействие с множеством различных платформ IoT (например, OCF, oneM2M, OMA LWM2M, OPC UA) и устройства, не соответствующие какому-либо конкретному стандарту, но предоставить подходящий интерфейс через подходящую сеть протокол. WoT решает эту проблему с помощью привязок протоколов, которые должны соответствовать количество ограничений (см. § 6.6 Протокол привязки).

  Ненормативная привязка WoT Спецификация шаблонов [ WOT-BINDING-TEMPLATES ] предоставляет набор схем обмена метаданными которые дают рекомендации о том, как взаимодействовать с различными платформами IoT. При описании конкретного IoT устройство или служба, шаблон привязки для соответствующей платформы IoT может быть используется для поиска коммуникационных метаданных, которые должны быть указанный в описании вещи для поддерживать эту платформу.

  Рисунок 26 От шаблонов привязки к протоколу Привязки

  Рисунок 26 показывает, как применяются шаблоны привязки. А Шаблон привязки WoT создается только один раз для каждой платформы IoT, а затем может использоваться повторно во всех ТД для устройств этой платформы. Потребитель, обрабатывающий ТД, должен реализовать требуемую привязку протокола путем включения соответствующего стека протоколов и путем настройка стека (или его сообщений) в соответствии с сведения, указанные в ТД.

  Метаданные связи протокольных привязок охватывают пять размеры:

  • Платформа Интернета вещей: Платформы

    IoT часто представляют проприетарные модификации на прикладном уровне, такие как как поля заголовка HTTP для конкретной платформы или параметры CoAP. Формы (см. § 6.5.2 Формы) может содержать необходимую информацию для применения эти настройки в дополнительных полях формы, определенных для используемый протокол прикладного уровня.

  • Тип носителя: Платформы

    IoT часто отличаются используемые форматы представления (также известные как сериализации) для обмена данными. Тип носителя [ RFC2046 ] идентифицирует эти форматы, в то время как параметры типа носителя могут указать их дополнительно. Формы могут содержать тип носителя и необязательные параметры в дополнительных полях формы, таких как поле типа контента, известное из HTTP, которое объединяет тип носителя и его возможные параметры (например, текст/обычный; кодировка=utf-8 ).

  • Протокол передачи:

    Web of Things использует термин протокол передачи для лежащий в основе стандартизированный протокол прикладного уровня без специфичных для приложения опций или механизмов подпротокола. Схема URI цель отправки формы содержит необходимую информацию определить протокол передачи, например, HTTP, CoAPS или WebSocket через http: , coaps: или ws: , соотв.

  • Подпротокол:

    Протоколы передачи могут иметь механизмы расширения, которые должны быть известны для взаимодействия успешно. Такие подпротоколы не могут быть идентифицированы только по схеме URI и должны объявляться явно. Примеры являются толчком обходные пути уведомления для HTTP, такие как длинный опрос [ RFC6202 ] или события, отправленные сервером [ HTML ]. Формы могут содержать необходимую информацию для идентификации подпротокола в дополнительных полях формы.

  • Безопасность:

    Механизмы безопасности могут применяться на разных уровнях коммуникационного стека и могут использоваться вместе, часто дополняют друг друга. Примеры: (D)TLS [ RFC8446 ]/[ RFC6347 ], IPSec [ RFC4301 ], OAuth [ RFC6749 ], и ACE [ RFC7744 ]. Из-за сквозного характера безопасности необходимая информация для применения правильного механизма может быть данные в общих метаданных Вещи и/или специализированные для каждого Доступа к Взаимодействию или форма.

  7,3 API сценариев WoT

  Этот раздел не является нормативным.

  API сценариев WoT является необязательным «удобный» структурный элемент W3C WoT, упрощающий IoT разработка приложений путем предоставления API на основе ECMAScript [ ECMAScript ] аналогично API-интерфейсам веб-браузера. Интегрируя скрипт систему выполнения в WoT Runtime, WoT Scripting API позволяет использовать переносимые сценарии приложений, определяющие поведение Вещи, потребители и посредники.

  Традиционно логика устройства IoT реализована в прошивка, что приводит к ограничениям производительности, аналогичным к встроенной разработке, в том числе относительно сложный процесс обновления. Скрипты WoT API, напротив, позволяет реализовать логику устройства путем многократно используемые сценарии, выполняемые в системе времени выполнения для IoT приложения, не отличающиеся от веб-браузера, и направлена ​​на повышение производительности и снижение затрат на интеграцию. Кроме того, стандартизированные API обеспечивают переносимость для модули приложений, например, для перемещения ресурсоемких логика от устройства до локального шлюза или для перемещения критическая по времени логика от облака до шлюза или границы узел.

  Ненормативный API сценариев WoT спецификация [ WOT-SCRIPTING-API ] определяет структуру и алгоритмы программирования интерфейс, который позволяет скриптам обнаруживать, извлекать, потреблять, производить и выставлять WoT Thing Описания. Система выполнения WoT Scripting API создает локальные объекты, которые действовать как интерфейс к другим вещам и их Возможности взаимодействия (свойства, действия и события). Он также позволяет сценариям раскрывать Вещи, то есть определять и реализовывать возможности взаимодействия и публиковать их. Описание вещи.

  7.4 Безопасность и конфиденциальность WoT Руководство

  Этот раздел не является нормативным.

  Безопасность является сквозной проблемой и должна учитываются во всех аспектах проектирования системы. В ВОТ архитектуре, безопасность поддерживается определенными явными функции, такие как поддержка метаданных общественной безопасности в TD и путем разделения задач при разработке WoT Scripting API. Спецификация для каждого строительный блок также включает обсуждение конкретных соображения безопасности и конфиденциальности этого строительного блока. Еще одна ненормативная спецификация, WoT Безопасность и Правила конфиденциальности [ WOT-SECURITY ], обеспечивает дополнительную сквозную безопасность и конфиденциальность руководство.

  8. Абстрактная сервисная архитектура

  Этот раздел не является нормативным.

  Как определено в § 6.7 Система WoT Компоненты и их взаимосвязь. Сервиент — это программный стек, реализующий WoT. строительные блоки, представленные в предыдущем разделе. Слуги могут размещать и выставлять Вещи и/или потреблять Вещи (т. е. размещать Потребителей). В зависимости от привязки протокола, Слуги могут работать в роль как сервера, так и клиента, отсюда и название портмоне.

  В предыдущем разделе описано, как строительные блоки WoT концептуально связаны друг с другом и как они соотносятся с абстрактную архитектуру WoT (см. § 6. Архитектура WoT). При реализации этих понятия, необходим более детальный взгляд, который требует определенных с учетом технических аспектов. В этом разделе описывается подробная архитектура Servient реализация.

  На рисунке 27 показана реализация Servient, в которой используется (необязательно) Строительный блок WoT Scripting API. Здесь WoT Runtime также является сценарием. Система выполнения, которая, помимо управления специфичным для WoT аспекты, а также интерпретирует и выполняет сценарии приложений. Серверы, поддерживающие WoT Scripting API, обычно работают на мощных устройствах, пограничных узлах или в облаке. Архитектура WoT не ограничить API WoT, обращенный к приложению Время выполнения для JavaScript/ECMAScript. Также другая среда выполнения системы могут быть использованы для реализации Servient.

  Раздел §  8.8.1 Родной WoT API представляет альтернативную реализацию Servient без скриптового API WoT структурный элемент. WoT Runtime может использовать любой язык программирования для своего прикладного API. Обычно, это родной язык программного стека Servient, например C/C++ для встроенных серверов или Java для облачные сервисы. Это также может быть альтернативный язык сценариев, такой как Lua, чтобы объединить преимущества сценариев приложений с низким ресурсом потребление.

  Рисунок 27 Реализация Servient с помощью WoT Скриптовый API

  Роль и функциональность каждого модуля показаны на рисунке 27 объясняется следующим разделы.

  8.1 Реализация поведения

  Поведение определяет общее приложение логика Вещи, которая имеет несколько аспекты:

  Включает автономное поведение Вещей (например, выборку датчиков или контуров управления). для приводов), обработчики для возможностей взаимодействия (т. е. конкретные действия, предпринимаемые при активации аффорданса), Поведение потребителей (например, управление Вещью или создание мэшапов), и Промежуточное поведение (например, просто проксировать Вещь или создавать виртуальные сущности). Реализация поведения внутри Servient определяет, какие вещи, потребители и посредники являются размещается на этом компоненте.

  Рисунок 27 изображает Servients, которые реализуют необязательный строительный блок WoT Scripting API, где сценарии переносимых приложений, написанные на JavaScript [ ECMAScript ] определить поведение. Они выполняются средой выполнения сценариев система, которая является частью WoT Runtime (когда предоставление скриптового API WoT или любой другой API на основе сценариев). Они портативны, так как они написано против общих сценариев WoT определения API и, следовательно, может выполняться любым Servient с этим строительным блоком. Это делает можно переносить логику приложения между системой компоненты, например перемещение Потребителя из из облака на пограничный узел для удовлетворения требований к сети, или перенести Посредника в облако для выполнения растущие потребности в ресурсах. Портативные приложения позволяют «установить» дополнительное поведение после развертывания Слуга.

  В принципе можно использовать любой язык программирования и API для того, чтобы определить поведение Вещи, пока Взаимодействие представлены извне через интерфейс WoT. Адаптация между API, ориентированным на приложение, и протоколом стек обрабатывается WoT Runtime. Видеть §  8.8.1 Собственный API WoT для поведения реализация без WoT Scripting Строительный блок API.

  8,2 WoT Время выполнения

  Технически абстракция вещи и ее модель взаимодействия реализованы в среде выполнения. система. Эта среда выполнения WoT поддерживает выполнение среду для реализации поведения и способен выставлять напоказ и/или потреблять Вещи и, следовательно, должны иметь возможность извлекать, обрабатывать, сериализовать и обслуживать описания вещей WoT.

  Каждая среда выполнения WoT имеет интерфейс, обращенный к приложению (т. е. API) для поведения реализация. Необязательный скрипт WoT Строительный блок API показан на рисунке 27 определяет такой интерфейс, ориентированный на приложение, который следует абстракции Thing и позволяет развертывать реализации поведения во время выполнения через приложение скрипты. См. § 8.8.1 Собственный WoT API для альтернативных API, которые также могут быть доступны во время компиляции. В общем, логика приложения должны выполняться в изолированных средах выполнения, чтобы предотвратить несанкционированный доступ к аспектам управления WoT Runtime, в частности Частные данные безопасности. В мультиарендные серверы, дополнительное исполнение изоляция от окружающей среды требуется для различных арендаторы.

  Среда выполнения WoT должна обеспечивать определенные операции по управлению жизненным циклом вещей и т. д. именно их программные абстракции и описания. А Система управления жизненным циклом (LCM) может инкапсулировать те операции жизненного цикла внутри Servient и использование внутренние интерфейсы для реализации управления жизненным циклом. детали таких операций варьируются в зависимости от реализации. Скриптовый API WoT включает функциональность LCM и, следовательно, представляет собой один из возможных реализации такой системы.

  Среда выполнения WoT должна взаимодействовать с реализация стека протоколов Servient, поскольку это отделяет реализацию поведения от деталей Привязки протоколов. WoT Runtime обычно также взаимодействует с базовая система, например, для доступа к локальному оборудованию таких как подключенные датчики и приводы или для доступа к системе услуги, такие как хранение. Оба интерфейса зависит от реализации, однако среда выполнения WoT должна обеспечить необходимую адаптацию к реализованной абстракции Вещи.

  8,3 API сценариев WoT

  Строительный блок WoT Scripting API определяет API ECMAScript, который точно соответствует спецификации WoT Thing Description [ ЧТО-ТО-ОПИСАНИЕ ]. Он определяет интерфейс между реализациями поведения и среда выполнения WoT на основе сценариев. Другой, более простые API могут быть реализованы поверх него, подобно тому, как для Например, jQuery для API веб-браузера.

  См. [ WOT-СЦЕНАРИЙ-API ] Больше подробностей.

  8.4 Открытая вещь и съеденная вещь Абстракции

  WoT Runtime создает программное обеспечение представления вещей на основе их ТД. Эти программные представления обеспечивают интерфейс к реализация поведения.

  Абстракция Exposed Thing представляет Вещь, размещенная локально и доступная из снаружи через реализацию стека протоколов Слуга. Реализация поведения может полностью управлять выставленными вещами, определяя их метаданные и взаимодействие Аффордансы и обеспечение их автономного поведения.

  Абстракция Потребляемой Вещи представляет удаленно размещенную Вещь для Потребителей, к которой необходимо получить доступ с помощью протокол связи. Потребляемые вещи прокси-объекты или заглушки. Реализация поведения ограничивается чтением их метаданных и активацией их Взаимодействие в соответствующем ТД. Потребляемые вещи также может представлять системные функции, такие как локальное оборудование или устройства, работающие по проприетарным или устаревшим протоколам связи. В этом случае WoT Runtime должен обеспечить необходимую адаптацию между системным API и Потребляемая вещь. Кроме того, он должен предоставить соответствующие ТД и сделать их доступными для реализация поведения, например, путем расширения любого Механизм обнаружения предоставляется средой выполнения WoT через API, ориентированный на приложение. (например, метод Discover() , определенный в API сценариев WoT [ WOT-SCRIPTING-API ]).

  При использовании WoT Scripting API, Exposed Thing и Consumed Thing — это объекты JavaScript, которые можно создаются, управляются и уничтожаются сценариями приложений. Однако доступ может быть ограничен с помощью механизм, например, в многопользовательских Servients.

  8.5 Частные данные безопасности

  Частные данные безопасности, такие как секретный ключ для взаимодействуя с Вещью, также концептуально управляется WoT Runtime, но намеренно не сделал прямого доступа к приложению. Фактически, в самые безопасные аппаратные реализации, такие частные данные безопасности хранятся в отдельная, изолированная память (например, на элемент или TPM) и только абстрактный набор операций (возможно, даже реализуется изолированным процессором и программный стек), которые ограничивают поверхность атаки и предотвратить раскрытие этих данных извне. Используются частные данные безопасности прозрачно с помощью привязки протокола разрешать и защищать целостность и конфиденциальность взаимодействия.

  8.6 Реализация стека протоколов

  Стек протоколов Servient реализует интерфейс WoT открытых вещей и используется Потребителями для доступа к интерфейсу WoT удаленных вещей (через потребляемые вещи). Он производит конкретный протокол сообщения для взаимодействия по сети. Серверы могут реализовывать несколько протоколов и следовательно, поддержка нескольких протоколов Привязки для обеспечения взаимодействия с различными платформами IoT.

  Во многих случаях, когда используются стандартные протоколы, стеки протоколов могут использоваться для создания специфичных для платформы сообщения (например, одно для диалектов HTTP(S), одно для CoAP(S) диалекты и один для решений MQTT и т. д.). В таком случае, коммуникационные метаданные из описания вещи используются для выбора и настройки правильный стек (например, HTTP с правильными полями заголовка или CoAP с правильными опциями). Парсеры и сериализаторы для ожидаемый формат представления полезной нагрузки (JSON, CBOR, XML, и т. д.), определяемый типом носителя [ RFC2046 ] также могут совместно использоваться этими общими стеками протоколов.

  См. [ WOT-ОБЯЗАТЕЛЬНЫЕ ШАБЛОНЫ ] для деталей.

  8,7 Система API

  Реализация WoT Runtime может предоставлять локальное оборудование или системные службы для поведения реализации через абстракцию Thing, как если они были доступны по протоколу связи. В В этом случае среда выполнения WoT должна включить реализация поведения для создания экземпляров Consumed Things, которые внутренне взаимодействуют с системы вместо стека протоколов. Это можно сделать с помощью перечисление таких системных Вещей, которые доступны только в местный WoT Runtime, по результатам механизм обнаружения, обеспечиваемый ориентированным на приложение API времени выполнения WoT.

  Устройство также может быть физически внешним по отношению к Servient, но подключенным через собственный протокол или протокол, не соответствующий требованиям интерфейса WoT (см. § 6.6 Протокол привязки). В этом случае WoT Runtime может доступ к устаревшим устройствам с такими протоколами (например, ECHONET Lite, BACnet, X10, I2C, SPI и т. д.) через проприетарные API, но может снова решить подвергнуть их поведению реализация через абстракцию вещи. Затем Слуга может выступать в качестве шлюза к наследию. устройства. Это следует делать только в том случае, если устаревшее устройство не может быть описана непосредственно с использованием описания вещи WoT.

  Реализация поведения может также обращаться к локальному оборудованию или системные службы (например, хранилище) через проприетарный API или другие средства. Однако это выходит за рамки W3C WoT стандартизация, поскольку она препятствует переносимости.

  8.8 Альтернативный слуга и WoT Реализации

  Строительный блок WoT Scripting API по желанию. Альтернативный слуга возможны реализации, где WoT Runtime предлагает альтернативный API для логика приложения, которая может быть написана на любом языке программирования язык.

  Кроме того, устройства или службы, не знающие о W3C WoT, все еще могут быть потребляется, когда можно обеспечить хорошо сформированный WoT Thing Description для них. В В этом случае ТД описывает интерфейс Вещи WoT, который имеет реализация черного ящика.

  8.8.1 Родной API WoT

  Существуют различные причины, по которым разработчик может выбрать реализовать Servient без использования Скриптовый API WoT. Это может быть связано недостаточно памяти или вычислительных ресурсов, поэтому разработчик не может использовать требуемый программный стек или полнофункциональный скриптовый движок. В качестве альтернативы для поддержки их вариант использования (например, проприетарное средство связи протокол) разработчику, возможно, придется использовать определенные функции или библиотеки, доступные только через определенный среда программирования или язык.

  В этом случае WoT Runtime может по-прежнему использоваться, но с эквивалентной абстракцией и функциональность, представленная с использованием альтернативы интерфейс, ориентированный на приложение, вместо WoT Scripting API. За исключением последнее, все описания блоков в § 8. Аннотация Служебная архитектура также действительна для Фигура 28 .

  Рисунок 28 Реализация Servient с использованием Native API WoT
  8.8.2 Вещь Описание для Существующие устройства

  Также возможна интеграция существующих IoT устройств или сервисов в W3C Web of Things и в использовать их как Вещи, создав для них Описание Вещи устройств или услуг. Такой ТД может быть создан либо вручную или с помощью инструмента или службы. Например, ТД может генерироваться службой, которая обеспечивает автоматический перевод метаданных, предоставленных другим, машиночитаемый формат, зависящий от экосистемы. Это может только сделать, однако, если целевое устройство использует протоколы который может быть описан с помощью привязки протокола. Требования для этого приведены в § 6,6 Привязки протоколов. Большая часть предыдущего обсуждения также подразумевает, что Вещь предоставляет свое собственное Описание Вещи. Хотя это полезный паттерн не обязателен. В частности, это может невозможно модифицировать существующие устройства, чтобы обеспечить их собственное описание вещи напрямую. В в этом случае описание вещи должны быть предоставлены отдельно с использованием такой услуги, как каталог или какой-либо другой внешний и отдельный распределительный механизм.

  Рисунок 29 Интеграция существующих IoT-устройств в W3C WoT
  9. Пример развертывания WoT

  Этот раздел не является нормативным.

  В этом разделе представлены различные примеры того, как Web of Абстрактная архитектура вещей (WoT) может быть создана, когда устройства и сервисы, реализующие роли Вещи и Потребителя, связаны друг с другом в различных конкретные топологии и сценарии развертывания. Эти топологии и сценарии не нормативны, а разрешены и поддерживается абстрактной архитектурой WoT.

  Прежде чем обсуждать конкретные топологии, мы сначала рассмотрим роли, которые могут играть Вещи и Потребители в сети WoT и отношения, которые они имеют с Программные абстракции Exposed Thing и Consumed Thing. Выставленная вещь и потребляемая вещь внутренне доступны для реализации поведения Слуги в ролях Вещей и Потребителей соответственно.

  9.1 Роли вещей и потребителей

  Слуга в роли Вещи создает Выставленную Вещь на основе описания вещи (ТД). TD публикуются и становятся доступными для других Servients, выступающих в роли Потребителей или Посредников. ТД могут быть опубликованы различными способами: ТД может быть зарегистрирована в системе управления, такой как служба каталога вещей, или вещь может предоставлять запрашивающим ТД при получении запроса на ТД. Можно даже статически связать TD с Вещь в определенных сценариях применения.

  Слуга в роли Потребителя получает TD Вещи, используя механизм обнаружения и создает Потребляемую Вещь на основе полученного ТД. конкретный механизм открытия зависит от индивидуального сценарий развертывания: Это может быть предоставлено руководством система, такая как каталог вещей, протокол обнаружения, через статическое назначение и т. д.

  Однако следует отметить, что ТД, описывающие устройства связанные с идентифицируемым лицом, потенциально могут быть используется для вывода конфиденциальной информации. Ограничения на поэтому распространение таких ТД должно быть включено в любой конкретный механизм обнаружения ТД. Если можно шаги для ограничения информации, раскрываемой в ТД, также может потребоваться например, отфильтровывая идентификаторы или удобочитаемые информацию, если это не является строго необходимым для конкретный вариант использования. Вопросы конфиденциальности обсуждаются на высоком уровне уровень в § 10. Безопасность и Вопросы конфиденциальности и более подробное обсуждение см. дано в [ WOT-THING-DESCRIPTION ] Технические характеристики.

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

  Функции, поддерживаемые Потребляемой вещью, предоставляются реализации поведения Потребителя через интерфейс языка программирования. В WoT Scripting API потребляемые вещи представлены предметами. Реализация поведения (что логика приложения), работающая в Thing, может задействовать через взаимодействие Доступность с потребителями с помощью интерфейс языка программирования, предоставляемый Exposed Thing.

  Вещь не обязательно представляет собой физическое устройство. Вещи также могут представлять собой набор устройств или виртуальных служб, работающих в шлюз или в облаке. Аналогичным образом Потребитель может представлять приложение или службу, работающую на шлюзе или облако. Потребители также могут быть реализованы на краевые устройства. В посредниках, один Слуга выполняет обе роли вещь и потребитель одновременно, которые используют одну среду выполнения WoT.

  9.2 Топология систем WoT и Сценарии развертывания

  Различные топологии и сценарии развертывания систем WoT обсуждаются в этом разделе. Это только пример шаблоны и другие топологии взаимосвязей также возможный. Описанные здесь топологии являются производными от Примеры использования Web of Things (§ 4. Варианты использования) а также извлеченные из них технические требования (§ 5. Требования).

  9.2.1 Потребитель и вещь на Та же сеть

  В простейшей топологии межсоединений, показанной Фигура 30 , Потребитель и Вещь находятся на той же сети и могут напрямую общаться друг с другом без посредников. Один вариант использования, когда это топология возникает, когда Потребитель является служба оркестровки или какое-либо другое приложение IoT, работающее на шлюзе и Вещь это устройство взаимодействие с датчиком или исполнительным механизмом. Тем не менее отношения клиент/сервер могут быть легко изменены на противоположные; в клиент может быть устройством в роли потребителя доступ к службе, работающей как вещь на шлюз или в облаке.

  Рисунок 30 Потребитель и вещь на одном и том же Сеть

  Если Вещь находится в облаке и Потребитель находится в локальной сети (см. рис. 1 для примера в Smart Домашний вариант использования) фактическая топология сети может быть больше сложные, например, требующие обхода NAT и запрещение определенных форм открытия. В таких случаях один из более сложных топологий, обсуждаемых позже, может быть более соответствующий.

  9.2.2 Потребитель и подключенная вещь через посредников

  Посредник играет роли Вещи и Потребителя на сеть и поддерживает как Exposed Thing, так и Consumed Thing программные абстракции в среде выполнения WoT. Посредники могут быть использованы для прокси между устройствами и сетями или для цифровых двойников.

  9.2.2.1 Посредник, выступающий в качестве Прокси

  Одним из простых приложений Посредника является прокси для Вещи. Когда посредник действует как прокси, имеет интерфейсы с двумя отдельными сети или протоколы. Это может включать внедрение дополнительных механизмов безопасности, таких как предоставление конечных точек TLS. Обычно прокси не изменяются набор взаимодействий, поэтому TD, выставленный Посредник будет иметь то же самое взаимодействия как потребляемая ТД, однако связь метаданные изменены.

  Для реализации этого шаблона прокси посредник получает TD вещи и создает потребляемую вещь. Он создает прокси-объект Вещь как софт реализация, которая имеет те же возможности взаимодействия. Это тогда создает ТД для прокси-объекта с новым идентификатором и, возможно, с новыми коммуникационными метаданными (привязки протоколов) и/или новыми Общественная безопасность Метаданные. Наконец, выставленный Вещь создается на основании этого ТД, и Посредник уведомляет других Потребителей или Посредников о ТД через соответствующий механизм публикации.

  Рисунок 31 Потребитель и вещь Соединение через Посредник, выступающий в роли доверенного лица
  9. 2.2.2 Посредник, выступающий в качестве Цифровой двойник

  Более сложные посредники могут быть известны как цифровые близнецы. А Цифровой двойник может или не может изменять протоколы или переводить между сетями, но они предоставляют дополнительные услуги, такие как кэширование состояния, отложенные обновления или даже предиктивное моделирование поведение целевого устройства. Например, если IoT устройство имеет ограниченную мощность, оно может выбрать пробуждение относительно редко, синхронизироваться с цифровым двойником, а потом сразу засыпать опять таки. В этом случае, как правило, цифровые близнецы работают на менее ограниченной мощности. устройстве (например, в облаке или на шлюзе) и может реагировать на действия на ограниченном устройстве от имени. Запросы о текущем состоянии свойств могут также быть удовлетворенным цифровым Двойники, использующие кешированное состояние. Запросы, которые приходят, когда целевое устройство IoT спит, может быть поставлено в очередь и отправлено к нему, когда он проснется. Для реализации этого шаблона Посредник, т. е. цифровой двойник должен знать, когда устройство бодрствующий. Реализация устройства как вещи может потребовать включения уведомления механизм для этого. Это может быть реализовано с помощью отдельная пара Потребитель/Вещь, или с помощью взаимодействия событий для этого цель.

  9.2.3 Устройства в локальной сети Управляется из облачной службы

  В случаях использования Умного дома устройства (датчики и домашние приборы), подключенные к домашней сети, часто контролируются а в некоторых случаях также контролируется облачными сервисами. Обычно между домашней сетью и к которому подключены устройства и облако. НАТ устройство транслирует IP-адреса, а также часто предоставляет службы брандмауэра, которые выборочно блокируют соединения. локальные устройства и облачные службы могут взаимодействовать только с друг друга, если сообщение может успешно пройти шлюз.

  Типовая структура, принятая в Рекомендации ITU-T Y.4409/Y.2070 [ Y.4409-Y.2070 ] , показано в Фигура 32 . В этой структуре есть как локальный, так и удаленный посредник. Местный посредник агрегирует возможности взаимодействия от несколько вещей в (набор) выставленных вещей, которые все могут быть отображены на общий протокол (например, HTTP, со всеми взаимодействиями сопоставляется с одним пространством имен URL с общим базовым сервером и с использованием одного порта). Это обеспечивает удаленному посреднику простой способ доступа ко всем Вещи, стоящие за устройством NAT, при условии, что локальный Посредник использовал конвергентную протокол, который может пройти через устройство NAT и каким-то образом выставить эту службу в Интернет (STUN, TURN, DyDNS, так далее. ). Кроме того, местный посредник может функционировать как прокси-сервер Thing, поэтому даже при подключении Каждая вещь использует свой протокол (HTTP, MQTT, CoAP и т. д.) и/или другой набор экосистем соглашения, Exposed Thing может объединить их в единый протокол, чтобы Потребителям не нужно было знать о различных протоколы, которые используют Вещи.

  В Рисунок 32 , есть два клиенты, подключенные к удаленному посреднику, который объединил службы, находящиеся за Граница NAT и может обеспечить дополнительную трансляцию протокола или службы безопасности. В частности, локальный посредник может находиться в сети с ограниченным возможности и сделать эту услугу доступной для всех пользователей может оказаться невозможным. В этом случае доступ к локальному Посредник только предоставляется удаленному посреднику. затем удаленный посредник реализует более общий механизм контроля доступа, а также может выполнять кэширование или регулирование для защиты потребителя от избыточного движение. Эти потребители также будут использовать единый протокол подходит для открытого Интернета (например, HTTPS) для связи с посредником, который делает разработка клиентов намного проще.

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

  Рисунок 32 облачных приложений, реализованных как потребители Подключен к локальным устройствам, реализованным как вещи через Парные посредники

  В более сложных случаях обход NAT и брандмауэра может работать не так, как показано. В частности, провайдер может не поддерживает общедоступные адреса или STUN/TURN и/или DyDNS может не поддерживаться или быть недоступным. В этом случае, если Посредники могут альтернативно поменяйте роли клиент/сервер между ними, чтобы настроить начальное соединение (с локальным посредником, сначала подключающимся к удаленному посредник в облаке), то пара Посредников может установить туннель (например, с помощью Secure WebSocket, который использует TLS для защиты соединения). Затем можно использовать туннель. для кодирования всех сообщений между посредниками с использованием специального протокола. В этом если первоначальное соединение все еще может быть выполнено через HTTPS используя стандартные порты, и от локального посредника к удаленному посреднику идентично обычному браузеру/веб взаимодействие с сервером. Это должно быть в состоянии пересечь большинство домашние брандмауэры, и поскольку соединение является исходящим, трансляция сетевых адресов не вызовет никаких проблем. Однако, несмотря на то, что требуется собственный протокол туннелирования, удаленный посредник все еще может переводить этот пользовательский протокол обратно в стандартные внешние протоколы. Подключенные Потребители и Вещи не нужно знать об этом. Также возможно продлить это пример использования случаев, когда и вещи, и потребители могут подключаться по обе стороны NAT граница. Однако для этого также требуется двунаправленный туннель. устанавливается между двумя посредниками.

  9.2.4 Обнаружение с помощью вещи Каталог

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

  Однако, когда удаленный посредник является частью облачной платформы, обслуживающей клиента приложений, клиенты должны иметь возможность найти устройство информацию, например, путем доступа к каталогу подключенные устройства. Для простоты на рисунке ниже мы предположили, что все локальные устройства реализованы как вещи, а все облачные приложения — как потребители. Сделать метаданные локальных устройств реализовано как вещи, доступные в облаке приложений, их метаданные могут быть зарегистрированы с Служба каталогов вещей. Этот метаданные - это, в частности, TD локальных устройств изменены, чтобы отразить метаданные общественной безопасности и коммуникационные метаданные (протокол Bindings), предоставленные удаленным посредником. После этого клиентское приложение может получить метаданные, необходимые для связи с локальными устройства для достижения своей функциональности, запрашивая Справочник вещей.

  Рисунок 33 Облачная служба с каталогом вещей

  В более сложных ситуациях, не показанных на рисунке, также могут быть облачные сервисы, которые действуют как Вещи. Они также могут зарегистрироваться в Справочник вещей. Поскольку каталог вещей является веб-службой, он должен видны локальным устройствам через NAT или брандмауэр устройство и его интерфейс могут быть даже снабжены собственным ТД. Локальные устройства, выступающие в качестве потребителей, могут затем обнаружить вещи в облаке через каталог вещей и подключиться к вещам напрямую или через локального посредника, если, например, протокол нужен перевод.

  9.2.5 Сервис-сервис Соединения между несколькими доменами

  Несколько облачных экосистем, каждая из которых основана на разных IoT платформы могут работать вместе, чтобы сделать более крупную, экосистема системы систем. Опираясь на ранее обсудили структуру экосистемы облачных приложений, на рисунке ниже показаны две экосистемы, связанные друг с другом сделать систему систем. Рассмотрим случай, когда клиент в одной экосистеме (т. е. Потребитель A ниже) должен использовать сервер в другой экосистеме (т. е. Вещь Б ниже). Существует более одного механизма для достижения этого межэкосистемного приложения-устройства интеграция. Ниже объясняются два механизма, каждый из которых используя рисунок, чтобы показать, как это может быть достигнуто.

  9.2.5.1 Соединение через вещь Синхронизация каталогов

  В Рисунок 34 , синхронизация двух каталогов вещей информацию, которая позволяет Потребителю А получить информацию о Вещь B через Вещь Каталог A. Как описано в предыдущих разделах, удаленный посредник B поддерживает теневая реализация Thing B. By получив ТД этого теневого устройства, Потребитель А может использовать Вещь Б через удаленного посредника Б.

  Рисунок 34 Несколько подключений к облаку через Thing Синхронизация каталогов
  9. 2.5.2 Подключение через прокси Синхронизация

  В Рисунок 35 , два выносных Посредники синхронизируют Информация об устройстве. Когда тень Вещи Б созданный на удаленном посреднике B, ТД тени одновременно синхронизируется с удаленный посредник A. Удаленный посредник A, в свою очередь, создает свою собственную тень вещи B и регистрирует ТД с каталогом вещей A. С этим механизм, синхронизация между каталогами вещей не необходимый.

  Рисунок 35 Несколько подключений к облаку через Промежуточная синхронизация
  10. Вопросы безопасности и конфиденциальности

  Этот раздел не является нормативным.

  Безопасность и конфиденциальность — сквозные вопросы, которые необходимо решать учитываться во всех WoT строительные блоки и реализации WoT. Эта глава обобщает некоторые общие вопросы и рекомендации, помогающие сохранить безопасность и конфиденциальность конкретных реализаций WoT. Однако это лишь общие рекомендации и абстрактный такая архитектура, как описанная в этом документе, сама по себе не может гарантировать безопасность и конфиденциальность. Вместо этого детали необходимо рассмотреть конкретную реализацию. Для более подробный и полный анализ вопросов безопасности и конфиденциальности, см. Правила безопасности и конфиденциальности WoT спецификация [ WOT-SECURITY ].

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

  Однако, особенно для новых систем, архитектура WoT должен ли включить использование лучших практик в области безопасности и конфиденциальность. В целом, архитектура безопасности WoT должна поддерживать цели и механизмы протоколов IoT и системы, к которым он подключается. Эти системы различаются по своей безопасности. требования и устойчивость к риску, поэтому механизмы безопасности будут также различаются в зависимости от этих факторов.

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

  Как правило, безопасность и конфиденциальность не могут быть гарантированы. это WoT не может превратить небезопасную систему в безопасный. Тем не менее, архитектура WoT не должна навредить: он должен поддерживать безопасность и конфиденциальность, по крайней мере, так же, как системы, которые он описывает и поддерживает.

  10.1 Вещь WoT Описание Риски

  Метаданные, содержащиеся в описании вещей WoT (TD), потенциально чувствительный. В качестве наилучшей практики следует использовать ТД. вместе с механизмами защиты целостности и доступом политики управления и должны предоставляться только авторизованным пользователи.

  Пожалуйста, обратитесь к соображениям безопасности и конфиденциальности раздел спецификации WoT Thing Description для дополнительные детали и обсуждение этих моментов.

  10.1.1 Вещь Описание Частный Риск безопасности данных TD

  предназначены для переноса только метаданных общественной безопасности. Производители TD должны гарантировать, что никакие частные данные безопасности не включены в ТД. Должно быть строгое разделение Метаданные общественной безопасности и Частные данные безопасности. ТД должен содержать только общественную безопасность Метаданные, позволяющие потребителям узнать, что им нужно сделать, чтобы получить доступ к системе тогда и только тогда, когда они иметь авторизацию. Авторизация, в свою очередь, должна основываться на отдельно управляемой частной информации.

  Встроенные схемы безопасности ТД, определенные в ТД спецификация намеренно не поддерживает кодировку Частные данные безопасности. Однако, существует риск того, что другие поля, такие как человекочитаемый описания могут быть неправильно использованы для кодирования этой информации, или новые схемы безопасности могут быть определены и развернуты через механизм расширения, который кодирует такую ​​информацию.

  Снижение риска:

  Создатели ТД и расширений, предназначенных для использования в ТД должны убедиться, что только метаданные общественной безопасности когда-либо хранящиеся в ТД.

  10.1.2 Вещь Описание Риск информации, позволяющей установить личность

  Описания вещей потенциально могут содержать идентифицирующие личность Информация различных типов. Даже если это не явно, TD и его связь с идентифицируемым человек может быть использован для вывода информации об этом человеке. Например, ассоциация дактилоскопических ТД, выставленных мобильными устройствами, местоположение которых может быть определено, может быть отслеживание риска. Даже если конкретный экземпляр устройства не может быть идентифицирован, тип устройства, представленного ТД, когда связанные с лицом, могут представлять собой личные Информация. Например, медицинское устройство может быть использовано для сделать вывод, что у пользователя есть заболевание.

  Как правило, личная информация в TD следует максимально ограничить. В некоторых случаях, однако этого нельзя избежать. Потенциальное присутствие как прямая, так и выводимая PII в TD означает, что TD следует рассматривать как другие формы PII. Они должны быть храниться и передаваться безопасным образом, должны быть предоставляемые авторизованным пользователям, следует кэшировать только для ограниченное время, следует удалять по запросу, следует только использоваться в целях, для которых они были предоставлены согласия пользователя, и в противном случае они должны удовлетворять всем требования (включая любые юридические требования) для использования ПИИ.

  Снижение риска:

  Хранение PII в ТД должно быть сведено к минимуму возможный. Даже без явной PII в TD отслеживание и может существовать риск конфиденциальности идентификации. Чтобы свести к минимуму этого риска, к TD обычно следует относиться так, как если бы они содержала PII и подчинялась той же политике управления как другие PII. Они должны предоставляться только уполномоченным Потребители. Информация, ненужная для конкретного использования случай не должен быть выставлен в ТД, когда это возможно. За пример, явное определение типа и экземпляра информацию в ТД также не следует включать, если она не требуется по варианту использования. Даже если этого требует использование случай, чтобы свести к минимуму риски отслеживания, распределенные и идентификаторы с ограниченной областью действия следует использовать всякий раз, когда возможные, а не глобально уникальные идентификаторы. Другой формы информации, такие как человекочитаемый описания, также могут быть опущены в некоторых случаях использования, чтобы снизить риски дактилоскопирования.

  10.1.3 Вещь Описание Риск коммуникационных метаданных

  Привязка WoT Шаблоны должны корректно поддерживать безопасность механизмы, используемые базовой платформой IoT для этой платформы, которые следует учитывать подходит для использования с WoT. В связи с автоматизацией сети взаимодействия, необходимые для масштабного развертывания IoT, операторы необходимо убедиться, что вещи выставлены и потребляются в соответствии с их безопасностью политики.

  Снижение риска:

  По возможности создатели ТД должны использовать проверенные коммуникационные метаданные, представленные в шаблонах привязки WoT. Когда создание TD для экосистемы IoT, не охватываемой Привязка WoT Шаблоны, убедитесь, что вся безопасность Требования платформы IoT доволен.

  10. 2 API сценариев WoT Безопасность и Риски конфиденциальности

  Реализация WoT Runtime и WoT Scripting API должен иметь механизмы для предотвращения злонамеренного доступа к системе и изолировать сценарии в мультиарендных серверах. Более в частности, WoT Runtime реализация при использовании с WoT Scripting API должна учитывать следующее риски безопасности и конфиденциальности и реализовать рекомендуемые смягчения последствий

  10.2.1 Межскриптовая безопасность и Риск конфиденциальности

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

  Снижение риска:

  Среда выполнения WoT должна работать изоляция экземпляров скрипта и их данных в кейсах когда сценарии обрабатывают связанные с конфиденциальностью или другие важные данные безопасности. Точно так же реализация WoT Runtime должна выполнять изоляция WoT Runtime экземпляры и их данные, если на устройстве WoT более один арендатор. Такая изоляция может быть выполнена в пределах WoT Runtime с использованием платформы механизмы безопасности, доступные на устройстве. Для большего информацию см. в разделах "WoT Servient Single-Tenant" и «Мультитенант WoT Servient» из Безопасность WoT и спецификация Руководства по конфиденциальности [ WOT-БЕЗОПАСНОСТЬ ].

  10.2.2 Прямое физическое устройство Безопасность доступа и риск конфиденциальности

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

  Снижение риска:

  Среда выполнения WoT должна избегать напрямую раскрывая собственные интерфейсы устройства для разработчики скриптов. Вместо WoT Реализация среды выполнения должна обеспечивать аппаратное уровень абстракции для доступа к собственному устройству интерфейсы. Такой уровень аппаратной абстракции должен отказаться от выполнения команд, которые могут поставить устройство (или окружающей среды) в небезопасное состояние. Кроме того, в чтобы уменьшить урон физическому устройству WoT в случаев, когда скрипт скомпрометирован, важно свести к минимуму количество открытых интерфейсов или доступным для конкретного скрипта на основе его функциональность.

  10.3 Безопасность выполнения WoT и Риски конфиденциальности
  10. 3.1 Подготовка и обновление Угроза безопасности

  Если реализация WoT Runtime поддерживает постпроизводственную подготовку или обновление собой, скриптами или любыми связанными данными (включая безопасность учетные данные), это может быть основным вектором атаки. Злоумышленник может попытаться модифицировать любой вышеописанный элемент во время процесс обновления или подготовки или просто предоставление код и данные злоумышленника напрямую.

  Снижение риска:

  Постпроизводственная подготовка или обновление скриптов, самой WoT Runtime или любой другой связанные данные должны быть сделаны безопасным способом. Множество рекомендаций по безопасному обновлению и постпроизводственное обеспечение можно найти в Правила безопасности и конфиденциальности WoT спецификация [ WOT-SECURITY ].

  10.3.2 Учетные данные безопасности Безопасность хранилища и риск конфиденциальности

  Обычно WoT Runtime должен хранить учетные данные безопасности, предоставленные Устройство WoT для работы в сети. Если злоумышленник может поставить под угрозу конфиденциальность или целостность этих учетные данные, то он может получить доступ к активам, выдавать себя за другие Вещи, устройства или услуги WoT, или запускать атаки типа «отказ в обслуживании» (DoS).

  Снижение риска:

  Среда выполнения WoT должна надежно хранить любые предоставленные учетные данные безопасности, гарантируя их целостность и конфиденциальность. В случае, если на одном Устройство с поддержкой WoT, среда выполнения WoT реализация должна гарантировать изоляцию каждого предоставленные учетные данные безопасности арендатора. Кроме того, чтобы свести к минимуму риск того, что предоставленные учетные данные безопасности скомпрометированы, Реализация WoT Runtime не должен предоставлять какой-либо API для скриптов для запроса предоставленные учетные данные безопасности. Такие полномочия (или еще лучше, абстрактные операции, которые используют их, но делают не раскрывать их) должны быть доступны только Привязка протокола реализации, которая их использует.

  A. Последние изменения спецификации
  • Без нормативных изменений, незначительные редакционные исправления и стабильная версия внешние ссылки.
  • Сделать информативным раздел Терминология.
  • Реорганизованный реферат и введение.
  • Расширенное обсуждение конфиденциальности и смягчение последствий.
  • Рисунки адаптированы к изменениям текста.
  • Обновлены и расширены определения.
  • Обновлены ссылки:
    • Добавлены нормативные ссылки: RFC2046
    • Ссылки на нормативные документы удалены или перемещены в информативные раздел: IANA-RELATIONS, MQTT, RFC4395, RFC6838, RFC7049, RFC7231, RFC7252
  • Скорректированы цвета фигур в зависимости от доступности Обратная связь.
  • Незначительные редакционные исправления, такие как опечатки и капитализация.

  Отличия от Первый публичный рабочий проект

  • Пересмотренные и расширенные варианты использования.
  • Реорганизованные требования.
  • Определение абстрактной архитектуры.
  • Пересмотренная и уточненная терминология.
  • Дополнения к реализации и развертываниям.
  • Добавление соображений безопасности и конфиденциальности.
  Б. Благодарности

  Особая благодарность Майклу МакКулу, Такуки Камия, Казуюки Ашимура, Себастьян Кебиш, Золтан Кис, Елена Решетова, Клаус Хартке, Ари Керянен, Казуаки Нимура и Филипп Ле Эгаре за их вклад в этот документ.

  Большое спасибо персоналу W3C и всем другим активные участники W3C Web of Things Interest Группу (WoT IG) и Рабочую группу (WoT WG) за их поддержку, технический вклад и предложения, которые привели к улучшению этот документ.

  Рабочая группа WoT также хотела бы поблагодарить новаторскую усилия в отношении концепции «сети вещей», которая началась как академическая инициатива в виде публикаций, таких как [ WOT-ПИОНЕРЫ-1 ] [ WOT-ПИОНЕРЫ-2 ] [ WOT-ПИОНЕРЫ-3 ] [ WOT-ПИОНЕРЫ-4 ] и, начиная с 2010 года, ежегодный международный семинар по Сеть вещей.

  Наконец, отдельное спасибо Йоргу Хойеру за руководство WoT. IG в течение 2 лет с момента его основания и руководство группой в будущем с концепцией строительных блоков WoT, включая Вещь Описание.

  С. Ссылки
  C.1 Нормативные ссылки

  [RFC2046]

  Многоцелевой Расширения электронной почты Интернета (MIME), часть вторая: мультимедиа Типы . Н. Фрид; Н. Боренштейн. IETF. ноябрь 1996. Проект стандарта. URL-адрес: https://tools.ietf.org/html/rfc2046.

  [RFC2119]

  Ключ слова для использования в RFC для обозначения требования Уровни . С. Браднер. IETF. 19 марта97. Лучший Текущая практика. URL-адрес: https://tools.ietf.org/html/rfc2119.

  [RFC3986]

  Униформа Идентификатор ресурса (URI): общий синтаксис . Т. Бернерс-Ли; Р. Филдинг; Л. Масинтер. IETF. январь 2005. Интернет-стандарт. URL-адрес: https://tools.ietf.org/html/rfc3986.

  [RFC3987]

  Интернационализированный Идентификаторы ресурсов (IRI) . М. Дюрст; М. Суиньяр. IETF. Январь 2005 г. Предлагаемый стандарт. URL-адрес: https://tools.ietf.org/html/rfc3987

  [RFC5234]

  Дополненный БНФ для спецификаций синтаксиса: ABNF . Д. Крокер, Ред.; П. Оверелл. IETF. Январь 2008 г. Интернет-стандарт. URL-адрес: https://tools.ietf.org/html/rfc5234.

  [RFC8174]

  Неоднозначность Прописные и строчные буквы в RFC 2119Ключевые слова . Б. Лейба. IETF. Май 2017 г. Передовая современная практика. URL-адрес: https://tools.ietf.org/html/rfc8174

  [RFC8259]

  Обмен данными в нотации объектов JavaScript (JSON) Формат . Т. Брей, изд. IETF. декабрь 2017. Интернет стандарт. URL-адрес: https://tools.ietf.org/html/rfc8259.

  [RFC8288]

  Интернет Связывание . М. Ноттингем. IETF. Октябрь 2017. Предлагаемый стандарт. URL-адрес: https://httpwg.org/specs/rfc8288.html.

  C.2 Информационные ссылки

  [Коралл]

  Ограниченный язык приложений RESTful (КОРАЛ) . Клаус Хартке. IETF. Март 2019. Интернет-Черновик. URL: https://tools.ietf.org/html/draft-hartke-t2trg-coral

  [CoRE-RD]

  Каталог ресурсов CoRE . М. Костер; С. Борман; П. ван дер Сток; К. Амсуэсс. IETF. 13 июня 2019 г. Интернет-Черновик. URL-адрес: https://tools.ietf.org/html/draft-ietf-core-resource-directory-21

  [ECMAScript]

  ECMAScript Спецификация языка . Экма Интернэшнл. URL-адрес: https://tc39.github.io/ecma262/

  [HCI]

  Энциклопедия взаимодействия человека и компьютера, 2-я Эд . Фонд интерактивного дизайна. 2013. URL: https://www.interaction-design.org/literature/book/the-encyclopedia-of-human-computer-interaction-2nd-ed

  [HTML]

  HTML Стандарт . Энн ван Кестерен; Доменик Деникола; Ян Хиксон; Филип Ягенштедт; Саймон Питерс. WHATWG. Уровень жизни. URL: https://html.spec.whatwg.org/multipage/

  [IANA-СВЯЗИ]

  Ссылка Отношения . ИАНА. URL-адрес: https://www.iana.org/assignments/link-relations/

  [СХЕМЫ IANA-URI]

  Единый идентификатор ресурса (URI) Схемы . ИАНА. URL-адрес: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml

  [МЭК-FOTF]

  Фабрика будущего . МЭК. Октябрь 2015. URL: https://www.iec.ch/whitepaper/pdf/iecWP-futurefactory-LR-en.pdf

  [IOT-SCHEMA-ORG]

  Схема Расширения для группы сообщества IoT . URL-адрес: https://www.w3.org/community/iotschema/

  [ИСО-МЭК-2382]

  Информационные технологии — Словарь . ИСО. 2015. URL: https://www.iso.org/obp/ui/#iso:std:iso-iec:2382:ed-1:v1:en

  [ИСО-МЭК-27000]

  Информационные технологии. Методы обеспечения безопасности. Системы управления информационной безопасностью. Обзор и словарный запас . ИСО. 2018. URL: https://www.iso.org/obp/ui/#iso:std:iso-iec:27000:ed-5:v1:en

  [ИСО-МЭК-29100]

  Информационные технологии. Методы обеспечения безопасности. Структура конфиденциальности . ИСО. 2011. URL: https://www.iso.org/obp/ui/#iso:std:iso-iec:29100:ed-1:v1:en

  [JSON-LD11]

  JSON-LD 1.1 . Грегг Келлогг; Пьер-Антуан Шампен; Дэйв Лонгли. W3C. 16 марта 2020 г. Кандидат W3C Рекомендация. URL: https://www.w3.org/TR/2020/CR-json-ld11-20200316/

  [СВЯЗАННЫЕ ДАННЫЕ]

  Связано Проблемы проектирования данных . Тим Бернерс-Ли. W3C. 27 Июль 2006 г. Внутренний документ W3C. URL-адрес: https://www.w3.org/DesignIssues/LinkedData.html.

  [LWM2M]

  Легкая машина к машине Технический Спецификация: Core . ОМА СпецВоркс. Август 2018. Утвержденная версия: 1.1. URL-адрес: http://openmobilealliance.org/release/LightweightM2M/V1_1-20180710-A/OMA-TS-LightweightM2M_Core-V1_1-20180710-A.pdf

  [MQTT]

  MQTT версии 3.1.1 плюс исправления 01 . Эндрю Бэнкс; Рахул Гупта. Стандарт ОАЗИС. декабрь 2015 г. URL-адрес: http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/mqtt-v3.1.1.html

  [НОРМАН]

  Психология повседневных вещей . Дональд А. Норман. Основные книги. 1988.

  [ОКФ]

  Основная спецификация OCF . Открытое подключение Фундамент. Апрель 2019 г. Версия 2.0.2. URL: https://openconnectivity.org/developer/specifications

  [ОТДЫХ]

  ОТДЫХ: Архитектурные стили и дизайн Сетевые программные архитектуры . Рой Томас Филдинг. Калифорнийский университет, Ирвин. 2000. Кандидатская диссертация. URL-адрес: https://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf

  [RFC4301]

  Безопасность Архитектура Интернет-протокола . С. Кент; К. Сео. IETF. Декабрь 2005 г. Предлагаемый стандарт. URL: https://tools.ietf.org/html/rfc4301

  [RFC6202]

  известно Проблемы и рекомендации по использованию длинных опросов и Потоковая передача в двунаправленном HTTP . С. Лорето; П. Сен-Андре; С. Сальсано; Г. Уилкинс. IETF. апрель 2011 г. Информационная. URL-адрес: https://tools.ietf.org/html/rfc6202.

  [RFC6347]

  Дейтаграмма Безопасность транспортного уровня, версия 1.2 . Э. Рескорла; Н. Модадугу. IETF. Январь 2012 г. Предложено Стандарт. URL-адрес: https://tools.ietf.org/html/rfc6347.

  [RFC6690]

  Ограничено RESTful Environments (CoRE) Формат ссылки . З. Шелби. IETF. Август 2012 г. Предлагаемый стандарт. URL-адрес: https://tools.ietf.org/html/rfc6690

  [RFC6749]

  Платформа авторизации OAuth 2.0 . Д. Хардт, Ред.. IETF. Октябрь 2012 г. Предлагаемый стандарт. URL-адрес: https://tools.ietf.org/html/rfc6749.

  [RFC7049]

  Краткий Двоичное представление объектов (CBOR) . С. Борман; П. Хоффман. IETF. Октябрь 2013 г. Предложено Стандарт. URL-адрес: https://tools.ietf.org/html/rfc7049.

  [RFC7231]

  Гипертекст Протокол передачи (HTTP/1. 1): семантика и Содержание . Р. Филдинг, изд.; Дж. Решке, изд. IETF. Июнь 2014 г. Предлагаемый стандарт. URL: https://httpwg.org/specs/rfc7231.html

  [RFC7252]

  Протокол ограниченных приложений (CoAP) . З. Шелби; К. Хартке; К. Борман. IETF. Июнь 2014 г. Предложено Стандарт. URL-адрес: https://tools.ietf.org/html/rfc7252.

  [RFC7641]

  Наблюдение Ресурсы в протоколе ограниченных приложений (КоАП) . К. Хартке. IETF. Сентябрь 2015. Предлагаемый стандарт. URL-адрес: https://tools.ietf.org/html/rfc7641.

  [RFC7744]

  Использование Случаи аутентификации и авторизации в Constrained Среды . Л. Зейтц, изд.; С. Гердес, изд.; Г. Селандер; М. Мани; С. Кумар. IETF. январь 2016 г. Информационная. URL-адрес: https://tools.ietf.org/html/rfc7744.

  [RFC8446]

  Версия протокола безопасности транспортного уровня (TLS) 1,3 . Э. Рескорла. IETF. Август 2018 г. Предложено Стандарт. URL-адрес: https://tools.ietf.org/html/rfc8446.

  [САРЕФ]

  Смарт-устройства REFerence (SAREF) онтология . ЕТСИ. Ноябрь 2015 г. URL: https://sites.google.com/site/smartappliancesproject/ontologies/reference-ontology

  [VOCAB-SSN]

  Семантический Онтология сенсорной сети . Армин Халлер; Кшиштоф Янович; Саймон Кокс; Дан Ле Фуок; Керри Тейлор; Максим Лефрансуа. W3C. 19Октябрь 2017. W3C Рекомендация. URL: https://www.w3.org/TR/2017/REC-vocab-ssn-20171019/

  [WOT-ОБЯЗАТЕЛЬНЫЕ ШАБЛОНЫ]

  Интернет of Things (WoT) Шаблоны привязки . Майкл Костер; Эге Коркан. W3C. 30 января 2020 г. Примечание W3C. URL-адрес: https://www.w3.org/TR/2020/NOTE-wot-binding-templates-20200130/

  [ВОТ-ПИОНЕРЫ-1]

  Взаимодействие мобильного сервиса с сетью Вещи . Э. Рукцио, М. Паолуччи; М. Вагнер, Х. Берндт; Дж. Хамард; А. Шмидт. Труды 13-го Международная конференция по телекоммуникациям (ICT 2006), Фуншал, остров Мадейра, Португалия. Май 2006 г. URL: https://pdfs.semanticscholar.org/3ee3/a2e8ce93fbf9ba14ad54e12adaeb1f3ca392.pdf

  [ВОТ-ПИОНЕРЫ-2]

  ОТДЫХАТЬ . Эрик Уайлд. UCB iSchool Report 2007-015, Калифорнийский университет в Беркли, Беркли, Калифорния, США. Ноябрь 2007 г. URL: http://dret.net/netdret/docs/wild-irep07-015-restful-things.pdf

  [ВОТ-ПИОНЕРЫ-3]

  Краткое содержание постера: Dyser — на пути к поиску в реальном времени Движок для Web of Things . Бенедикт Остермайер; Б. Марьям Элахи; Кей Ремер; Майкл Фармайр; Вольфганг Келлер. Материалы ACM SenSys 2008, Роли, Северная Каролина, США. Ноябрь 2008 г. URL: https://www.vs.inf.ethz.ch/publ/papers/ostermai-poster-2008.pdf

  [ВОТ-ПИОНЕРЫ-4]

  Ресурсно-ориентированная архитектура для Интернета Вещи . Доминик Гинар; Влад Трифа; Эрик Уайльд. Материалы Интернета вещей 2010 г. Международная конференция (IoT 2010). Токио, Япония. Ноябрь 2010 г. URL: https://ieeexplore.ieee.org/abstract/document/5678452.

  [WOT-СЦЕНАРИЙ-API]

  Сеть Вещи (WoT) Скриптовый API . Золтан Кис; Даниэль Пайнтнер; Йоханнес Хунд; Казуаки Нимура. W3C. 28 октября 2019. Рабочий проект W3C. URL: https://www.w3.org/TR/2019/WD-wot-scripting-api-201

  /

  [WOT-БЕЗОПАСНОСТЬ]

  Интернет of Things (WoT) Безопасность и конфиденциальность Руководство .