Фото: independent.co.uk

Федеральное правительство Швейцарии планирует вынести на референдум вопрос о безусловном доходе для граждан страны. Референдум состоится в июне, а сам вопрос касается всех без исключения граждан. Похоже на то, что проблема безусловного дохода (БД) становится новым трендом нашего времени. Такой тип дохода планируется ввести, например, в Финляндии, здесь размер выплат составит 800 евро. Не слишком много, но эта сумма покрывает все расходы граждан на жизнь, так что если не хочется работать, то можно этого не делать.

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

В Швейцарии предлагается выплачивать еще больше, чем в Финляндии — не 800 евро в месяц на человека, а около 2200 евро (2500 швейцарских франков). При этом выплаты будут производиться как тем, кто работает, так и тем, кто не работает (по разным причинам). Кроме того, планируется выплачивать средства и детям, в размере 625 швейцарских франков на человека. Подобные выплаты, по замыслу законодателей, должны сломать зависимость вид работы/размер дохода.

Согласно опросу, проведенному Demoscope Institute ранее, большинство граждан Швейцарии собирается продолжать работу и после начала выплат. Так что, судя по всему, страна не останется без работников.

Что касается финансовой стороны дела, то перевод всех на такой тип дохода обойдется казне в 208 миллиардов франков в год (чуть менее 200 миллиардов евро). 150 миллиардов франков будут брать из налогов, плюс еще 55 миллиардов предоставит такая статья, как социальное страхование. Надо заметить, что при введении безусловного дохода могут отменить все социальные выплаты, пособия и льготы, которые выплачивались до момента ввода БД.

У проекта есть и противники, причем как в составе левых партий, так и в составе правых. Противники введения БД считают, что результаты опроса со стороны Demoscope Institute не отвечают действительности. Также треть респондентов еще одного опроса (в нем приняли участие 1076 человек) считают, что если предложение будет реализовано, люди просто перестанут работать. Еще 56% опрошенных считают, что БД — это просто идея, которая не будет реализована никогда.

ссылка на оригинал статьи https://geektimes.ru/post/270200/

Ведущий дизайнер проекта Тодд Гриффин демонстрирует секцию 50-метровой лопасти

Национальные лаборатории США Sandia National Laboratories представили дизайн лопастей для гигантских прибрежных ветрогенераторов с горизонтальной осью вращения. Конструктивная особенность новых лопастей – беспрецедентная длина (до 200 м) и возможность автоматически складываться при сильном ветре для предотвращения разрушения ветряка.

Типичная длина лопасти современного ветрогенератора составляет до 20 до 60 метров. Распространённые в США ветряки имеют 80 м в высоту и максимальную мощность в 1,5 МВт. Максимальная из коммерчески доступных турбин выдаёт 8 МВт при помощи 80-метровых лопастей.

Перспективная разработка от Sandia National Laboratories направлена на создание ветрогенератора с расчётной мощностью в 50 МВт. В данный момент в лабораториях созданы лопасти длиной 50 м и проведены все расчёты для 100-метровых лопастей. Планируется, что новые гигантские ветряки будут размещаться на воде в прибрежных зонах.

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

Складывающиеся лопасти

Изюминка проекта в том, что лопасти от Sandia National Laboratories будут составляться из сегментов, что облегчит их установку, при этом они будут располагаться с подветренной стороны башни, в отличие от обычных ветряков. Это позволит им автоматически складываться при сильном ветре наподобие ветвей пальм. Конструкция позволит уменьшить вес лопастей и сделать их устойчивыми к ураганам.

Турбина в Дании, у которой отказали тормоза, в результате чего она слишком быстро раскрутилась

Sandia National Laboratories являются подразделениями Lockheed Martin. Они ведут своё начало с Манхэттенского проекта — программы США по разработке ядерного оружия, осуществление которой началось 17 сентября 1943 года.

ссылка на оригинал статьи https://geektimes.ru/post/270198/

Вспомним первые дни Android платформы, когда не существовало хороших UI фреймворков и большинство Android устройств не поддерживали гибридные приложения, которые разрабатывались с помощью веб-технологий, таких как HTML5, CSS и JavaScript.

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

В этом уроке, я покажу вам, как создать простое, гибридное приложение To-Do List (список дел) для Android. Интерфейс приложения будет соответствовать спецификации Material Design от Google, нативному виду под Android Lollipop и Marshmallow. Для достижения этой цели, мы будем использовать Polymer, Polymer paper elements, и Apache Cordova.

Подготовка

Что нам понадобится для работы:

• последняя версия Android SDK
• последняя версия Node.js
• Android устройство или эмулятор под управлением Android 5.0 или выше
• базовые знания HTML5, CSS, и JavaScript

Если вы новичок в работе с Cordova, рекомендуем прочитать статью Введение в Cordova: Основы.

Почему используем Polymer?

Polymer — это фреймворк, который позволяет быстро создавать пользовательские веб-компоненты — Polymer элементы. При использовании Polymer элементов, вы можете сделать ваши веб-приложения модульным, благодаря этому, ваш код будет более универсальным. После создания Polymer элемента, его можно будет использовать наряду с простыми HTML-тегами в HTML-страницах. Например, если вы создали пользовательский элемент и назвали его my-element, вы можете использовать его в любом месте HTML страницы, добавив следующий код:

<my-element></my-element> 

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

Что такое Polymer Paper Elements?

Polymer Paper Elements, элементы созданные на основе гайдлайна Material Design. Их можно использовать в качестве альтернативы обычным HTML элементам. Например, если вы хотите добавить кнопку в стиле Material Design, вы можете использовать элемент paper-button:

<paper-button> Click Me! </paper-button> 

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

Что такое Apache Cordova?

Приложение созданное с использованием Polymer и Polymer elements — это просто коллекция HTML, CSS и JavaScript файлов. Для работы такого приложения, необходим браузер. В мобильных устройствах, в качестве браузера нативного приложения, используется веб-представление (web-view).
Apache Cordova — это основа, которая позволяет создавать нативное приложение, содержащее веб-представление с целевой HTML-страницей. В этом уроке, мы будем использовать Apache Cordova, для создания приложения To-Do List (список дел) под Android устройства.

Настройка проекта

Чтобы ускорить разработку и сделать отладку проще, большинство разработчиков начинает создавать свои гибридные приложения в качестве веб-приложений. Мы сделаем также. Начнем создание приложения списка дел как обычный веб-проект, который будет работать в браузере.
Создайте новую папку проекта и назовите её todoWebApp

mkdir ~/todoWebApp 

Для управления проектом мы будем использовать Bower. Для его установки можете воспользоваться npm командой:

sudo npm install -g bower 

После установки Bower, перейдите в папку проекта и используйте команду bower для установки Polymer paper elements:

cd ~/todoWebApp bower install PolymerElements/paper-elements 

Создание пользовательского Polymer элемента

Теперь давайте создадим пользовательский Polymer элемент, который будет содержать код макета и основную функциональность веб-приложения To-Do List. Начнем с создания нового файла tasks-list.html.

Шаг 1: Импорт Paper Elements

Каждый Paper Elements, используемый в макете пользовательского элемента должен быть импортирован в индивидуальном порядке. Для разработки интерфейса веб-приложения, мы будем использовать следующие элементы:

• paper-toolbar для создания toolbar
• paper-button для создания различных кнопок
• paper-fab для создания плавающей кнопки
• paper-listbox для создания списка задач
• paper-item для создания отдельных задач вне списка
• paper-checkbox для создания чекбосксов, благодаря которым, пользователь будет помечать выполненные задания
• paper-icon-button для создания кнопки с иконкой
• paper-input для создания текстового поля, в котором пользователь будет записывать задачу
• paper-dialog для создания диалогового окна
• iron-icons для создания иконок

Кроме того, для использования привязки данных, предоставляемую Polymer, нам придется импортировать сам фреймворк Polymer. Добавьте следующий код в HTML файл:

<link rel='import' href='bower_components/polymer/polymer.html'/>   <link rel='import' href='bower_components/paper-toolbar/paper-toolbar.html'/> <link rel='import' href='bower_components/paper-button/paper-button.html'/> <link rel='import' href='bower_components/paper-fab/paper-fab.html'/> <link rel='import' href='bower_components/paper-listbox/paper-listbox.html'/> <link rel='import' href='bower_components/paper-item/paper-item.html'/> <link rel='import' href='bower_components/paper-checkbox/paper-checkbox.html'/> <link rel='import' href='bower_components/paper-icon-button/paper-icon-button.html'/> <link rel='import' href='bower_components/paper-input/paper-input.html'/> <link rel='import' href='bower_components/paper-dialog/paper-dialog.html'/> <link rel='import' href='bower_components/iron-icons/iron-icons.html'/> 

Шаг 2: Создание DOM

Вы можете думать о Polymer элементах, как HTML-страницах. Так же, как и HTML-страницы, Polymer элементы имеют свое собственное DOM дерево, которое содержит различные метки для элементов UI, теги style и script.
Для создания DOM, используем тег dom-module, к которому добавим id с именем tasks-list. Обратите внимание, что имя должно содержать дефис.

<dom-module id='tasks-list'>   </dom-module> 

Шаг 3: Создание макета

Создание макета, с помощью Polymer элементов, также просто, как и с HTML элементами, отличаются только теги. Убедитесь, что все элементы находятся внутри тега template.
Скопируйте следующий код в элемент dom-module:

<template>         <!-- Create a toolbar/actionbar -->         <paper-toolbar>             <div class="title"> My Tasks </div>         </paper-toolbar>           <div>             <!-- Create a list of tasks -->             <paper-listbox>                 <template is='dom-repeat' items='{{ tasks }}'>                     <!-- Create an individual task -->                     <paper-item>                         <paper-checkbox checked='{{ item.isComplete }}'                             class='flex-11 taskBox' on-change='toggleTask'>                                 {{ item.taskName }}                         </paper-checkbox>                                                     <paper-icon-button                             icon='delete'                             class='flex-1'                             style='color: gray'                             on-click='deleteTask'>                         </paper-icon-button>                                         </paper-item>                 </template>             </paper-listbox>               <!-- Create a floating action button -->             <paper-fab icon='add'                        style='position:absolute; bottom: 30px; right:24px'                        on-click='showAddTaskDialog'>             </paper-fab>               <!-- Create a modal dialog -->             <paper-dialog id='addTaskDialog' modal>                 <paper-input label='What do you have to do?' value='{{ latestTaskName }}'>                 </paper-input>                 <div class='buttons'>                     <paper-button dialog-dismiss>Cancel</paper-button>                     <paper-button on-click='addTask'>Add</paper-button>                 </div>             </paper-dialog>         </div> </template> 

Обратите внимание, теги Polymer элементов можно свободно использовать наряду с обычными HTML-тегами.
Добавление обработчика событий в теге Polymer тега, схоже с добавлением HTML тега. В приведенном выше коде, мы использовали два типа обработчиков событий, on-click для определения нажатий на кнопку и on-change для проверки состояния чекбокса.
Вы также могли заметить, что помимо Polymer элементов и HTML-тегов, мы использовали атрибут dom-repeat тега template. Он может использоваться в качестве оператора, а также производит перебор элементов массива.

Шаг 4. Регистрация элемента

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

Polymer({     is: 'tasks-list',        // more code goes here }); 

Инициализация элементов

На странице нашего проекта, мы использовали два свойства tasks и latestTaskName, но мы еще не добавили данные свойства к Polymer элементу. Чтобы добавить и инициализировать их, мы должны использовать метод ready. Сейчас, мы можем просто инициализировать пустой массив tasks и пустую строку latestTaskName.
Добавьте следующий код после свойства is:

ready: function() {     this.tasks = [];     this.latestTaskName = ""; }, 

Шаг 6: Хранение, обновление,= и удаление информации

Для постоянного хранения заданий, в списке дел, мы будем использовать объект localStorage.
Макет уже содержит paper-dialog, который имеет поле ввода для ввода задачи. Для открытия диалогового окна, добавим обработчик on-click с методом open:

showAddTaskDialog: function() {     this.$.addTaskDialog.open(); }, 

Благодаря двусторонней привязке данных Polymer, пользователь вводит данные в поле paper-input и они сразу будут доступны в свойстве latestTaskName. Таким образом, при нажатии на кнопку «Add» в диалоговом окне, мы можем просто добавить latestTaskName в localStorage используя метод setItem.
localStorage хранит данные в виде пары ключ-значение. Для хранения задачи, мы будем использовать имя задачи в качестве ключа, а его статус в качестве значения. Так как localStorage работает только со строками, сохраняем yes если задача выполнена и no — если задача не выполнена.
После добавления задачи, мы можем закрыть диалоговое окно, используя метод close:

addTask: function() {     // Сохранение новой невыполненной задачи     localStorage.setItem(this.latestTaskName, 'no');       // Сброс latestTaskName     this.latestTaskName="";       // Закрытие диалога     this.$.addTaskDialog.close();       // Обновление списка задач     this.updateTasks(); }, 

Точно так же, когда пользователь меняет статус чекбокса, который связан с задачей, мы можем обновить значение, хранящееся в объекте localStorage путем вызова метода setItem. Так как мы используем dom-repeat в теге template для создания отдельных элементов paper-listbox, мы можем использовать объект model в случае изменения события on-change. Кроме того, мы должны преобразовать логическое значение чекбокса в строки «yes» или «no», прежде чем сохранить его в localStorage.

toggleTask: function(e) {     // Получение имени задачи     var taskName = e.model.item.taskName;       // Конвертация     if(e.model.item.isComplete)         localStorage.setItem(taskName, 'yes');     else         localStorage.setItem(taskName, 'no'); }, 

Если пользователь захочет удалить задачу, он сможет нажать на кнопку paper-icon-button связанную с этой задачей. Чтобы удалить задачу навсегда, вызовите метод removeItem объекта localStorage события on-click в paper-icon-button.

deleteTask: function(e) {     var taskName = e.model.item.taskName;     localStorage.removeItem(taskName);       // Обновление списка задач     this.updateTasks(); }, 

Шаг 7. Отображение задач

Возможно вы заметили вызовы updateTasks в методах addTask и deleteTask. В методе updateTasks, мы обновляем массив tasks, который инициализируется в методе ready, для отображения содержания объекта localStorage. Это необходимо, так как dom-repeat работает только с массивом.
В массиве tasks, мы используем JSON объекты для отображения задач. Каждый JSON объект имеет два поля,taskName и isComplete. taskName — это строка, которая содержит имя задачи, isComplete — логическое значение, которое указывает на состояние задачи.
Чтобы Polymer обнаружил изменения в массиве tasks, мы должны вместо использования стандартных функции массива, использовать методы работы с массивом Polymer элемента. Мы будем использовать метод splice, для удаления всех элементов из массива и метод push, для добавления элементов в массив.
Следующий код создает метод updateTasks, который перебирает все элементы в localStorage и добавляет их в массив tasks.

updateTasks: function() {     // Очистка массива     this.splice('tasks', 0);       // Добавление элементов из localStorage     for(var taskName in localStorage) {         var task = {             taskName: taskName,             isComplete: localStorage.getItem(taskName) == 'yes'         };         this.push('tasks', task);     } }, 

На данный момент, массив tasks обновляется только когда пользователь добавляет или удаляет задачу. Для того, чтобы показать текущие задачи при запуске приложения, мы должны добавить вызов метода updateTasks внутри метода ready.
Теперь пользовательский Polymer элемент готов к использованию.

Использование пользовательского Polymer элемента

Давайте создадим HTML страницу и добавим пользовательский элемент. Создайте новый файл, назовите его index.html.
Перед использованием элемента, мы должны добавить тег link для импорта tasks-list.html. Кроме того, для удаления свойств Padding и Margin, а также использовать гибкий макет, добавьте классы fullbleed, layout и vertical к тегу body. Поскольку эти CSS классы определяются как элемент iron-flex-layout, мы должны добавить тег link для его импорта.
Затем мы можем добавить тег tasks-list:

<html>     <head>         <link rel="import" href="bower_components/iron-flex-layout/iron-flex-layout.html"/>          <link rel="import" href="./tasks-list.html"/>     </head>     <body class="fullbleed layout vertical">                   <!-- Use the custom Polymer element -->         <tasks-list></tasks-list>       </body> </html> 

Запуск приложения в браузере

Наше приложение To-Do List — готово. Так как для запуска Polymer Фреймворка необходим HTTP-сервер, вы можете создать его при помощи Phyton SimpleHTTPServer в директории проекта.

python -m SimpleHTTPServer 

Для просмотра вашего приложения, перейдите по ссылке http://localhost:8000/.

Настройка проекта Cordova
Теперь, когда мы успешно запустили приложение в браузере, настало время, превратить его в Android приложение при помощи Cordova.
Для начала мы должны установить Cordova CLI (интерфейс командной строки), используя npm:

sudo npm install -g cordova 

Чтобы создать новый проект Cordova, можно воспользоваться командой cordova create. В качестве аргументов, нужно добавить имя каталога, в котором будет создан проект Cordova, обратное доменное имя в качестве идентификатора и имя приложения.
Следующая команда создает проект Cordova для приложения под названием To-do внутри каталога todo, который содержит веб-проект, расположенный в todoWebApp:

cordova create todo com.tutsplus.code.hathi.todoapp "To-do" --copy-from=/home/me/todoWebApp 

Теперь необходимо добавить платформу для нашего проекта. Чтобы добавить поддержку Android платформы, перейдите в каталог todo и используйте команду cordova platform.

cd todo cordova platform add android 

Запуск гибридного приложения

Без единой строки кода, наш проект Cordova уже готов к работе. Давайте скомпилируем его, используя команду cordova build. Убедитесь, что в значении переменной ANDROID_HOME задан путь к Android SDK.

export ANDROID_HOME=/home/me/Android/Sdk/ cordova build android 

Если компиляция не удалась, и появляется сообщение — не возможно добавить файл web-animations.min.js.gz в APK, попробуйте удалить этот файл и снова скомпилировать проект.

rm -f ./www/bower_components/web-animations-js/web-animations.min.js.gz cordova build android 

После успешного компилирования, запустите свое приложение на Android устройстве, используя команду cordova run.

cordova run android 

Заключение

В этом уроке вы узнали, как использовать Polymer и Polymer paper elements, для создания веб-приложения To-Do List. Вы также узнали, как интегрировать веб-приложение в проекта Cordova, чтобы оно работало в качестве гибридного приложения на Android устройствах. Вы также можете без труда запустить приложение на устройствах под управлением iOS без каких-либо изменений в коде. Для этого снова запустите команду cordova platform и укажите ios платформу.

ссылка на оригинал статьи https://habrahabr.ru/post/276267/

Статья будет посвящена простому, но эффективному паттерну — Composite Converter [составной конвертер].

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

using System.Windows.Data;  namespace Aero.Converters.Patterns {     public interface ICompositeConverter : IValueConverter     {         IValueConverter PostConverter { get; set; }         object PostConverterParameter { get; set; }     } } 

using System; using System.Globalization; using System.Windows.Data; using Aero.Converters.Patterns;  namespace Aero.Converters {     public class InlineConverter : IInlineConverter, ICompositeConverter     {         public IValueConverter PostConverter { get; set; }         public object PostConverterParameter { get; set; }         public event EventHandler<ConverterEventArgs> Converting;         public event EventHandler<ConverterEventArgs> ConvertingBack;          public object Convert(object value, Type targetType, object parameter, CultureInfo culture)         {             var args = new ConverterEventArgs(value, targetType, parameter, culture);             var handler = Converting;             if (handler != null) handler(this, args);             return PostConverter == null                 ? args.ConvertedValue                 : PostConverter.Convert(args.ConvertedValue, targetType, PostConverterParameter, culture);         }          public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)         {             var args = new ConverterEventArgs(value, targetType, parameter, culture);             var handler = ConvertingBack;             if (handler != null) handler(this, args);             return PostConverter == null                 ? args.ConvertedValue                 : PostConverter.ConvertBack(args.ConvertedValue, targetType, PostConverterParameter, culture);         }     } } 

using System; using System.Globalization; using System.Linq; using System.Windows; using System.Windows.Data; using System.Windows.Markup; using Aero.Converters.Patterns;  namespace Aero.Converters {     [ContentProperty("Cases")]     public class SwitchConverter : DependencyObject, ISwitchConverter, ICompositeConverter     {         public static readonly DependencyProperty DefaultProperty = DependencyProperty.Register(             "Default", typeof(object), typeof(SwitchConverter), new PropertyMetadata(CaseSet.UndefinedObject));          public SwitchConverter()         {             Cases = new CaseSet();         }          public object Default         {             get { return GetValue(DefaultProperty); }             set { SetValue(DefaultProperty, value); }         }          public CaseSet Cases { get; private set; }          public bool TypeMode { get; set; }          public object Convert(object value, Type targetType, object parameter, CultureInfo culture)         {             if (TypeMode) value = value == null ? null : value.GetType();             var pair = Cases.FirstOrDefault(p => Equals(p.Key, value) || SafeCompareAsStrings(p.Key, value));             var result = pair == null ? Default : pair.Value;             value = result == CaseSet.UndefinedObject ? value : result;             return PostConverter == null                 ? value                 : PostConverter.Convert(value, targetType, PostConverterParameter, culture);         }          public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)         {             if (TypeMode) value = value == null ? null : value.GetType();             var pair = Cases.FirstOrDefault(p => Equals(p.Value, value) || SafeCompareAsStrings(p.Value, value));             value = pair == null ? Default : pair.Key;             return PostConverter == null                 ? value                 : PostConverter.ConvertBack(value, targetType, PostConverterParameter, culture);         }          private static bool SafeCompareAsStrings(object a, object b)         {             if (a == null && b == null) return true;             if (a == null || b == null) return false;             return string.Compare(a.ToString(), b.ToString(), StringComparison.OrdinalIgnoreCase) == 0;         }          public IValueConverter PostConverter { get; set; }         public object PostConverterParameter { get; set; }     } } 

Это позволит объединять конвертеры в логические цепочки различной длины и запросто строить новые на базе существующих.

<Grid.Resources>     <BooleanConverter x:Key="YesNoConverter" OnTrue="Yes" OnFalse="No"/>          <SwitchConverter x:Key="CompositeSwitchConverter" PostConverter="{StaticResource YesNoConverter}">         <Case Key="0" Value="False"/>         <Case Key="1" Value="True"/>     </SwitchConverter> </Grid.Resources>  <TextBlock Text="{Binding Number, Converter={StaticResource CompositeSwitchConverter}}"/>  Number == 1 => out: Yes Number == 0 => out: No 

Гениальное просто! Пользуйтесь на здоровье!
Живые примеры доступны с библиотекой Aero Framework.

Спасибо!

P.S. Предыдущая статья о встраиваемых конвертерах

ссылка на оригинал статьи https://habrahabr.ru/post/276273/

Концептуальные и реляционные понятия

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

В предыдущем тексте Классы, множества, группы, системы было предложено различать два типа понятий: концептуальные и специализирующие. Концептуальное понятие характеризует индивид от его появления/рождения до исчезновения/смерти (Жучка пожизненно собака), а специализирующие лишь эпизодически – на отдельных отрезках существования индивида (несколько лет Жучка была ездовой собакой). Можно сказать, что концептуальное понятие указывает на то, чем индивид является по своей сути, а не ситуационно. Американский философ Линн Раддер Бейкер обозначая концептуальное понятие как «первичный вид» так описывала его специфичность: «Проверить, является ли вид первичным или не первичным, можно, задав вопрос: если бы эта (например) кошка не была бы кошкой, продолжала бы она существовать? Ответ отрицательный; кошка – это первичный вид. А если бы мы спросили, существовала бы студентка, не будь она студенткой? Ответ положительный; студентка – не первичный вид» [Бейкер, 2011].

Формальной особенностью концептуального понятия, в отличие от специализирующего, является имманентность первого. Мы фиксируем подпадание индивида под концептуальное понятие вне и до всякого отношения его с другими объектами, в то время как для выделения специализации обязательно требуется указать связь индивида с другим объектом. Для ответа на вопрос «что такое лайка?» нам достаточно указать пальцем на лайку или, если ее нет перед глазами, начинать перечислять типовые атрибуты породы. А вот для разъяснении значения понятия «ездовая»  потребуется указать на нарты и объяснить понятие «езда в упряжке», и лишь потом заключить, что Жучка «ездовая» потому, что она имеет отношение к «нартам» и «езде». Или, к примеру, человек подпадает под понятие «студент» не просто сам по себе, а только по причине наличия связи «персона – ВУЗ».  Но мужчиной этот человек является  имманентно – независимо от каких-либо отношений с другими объектами. Поэтому «лайка» и «мужчина» – это концептуальные понятия, а «ездовая собака» и «студент» –  специализирующие. Хотя после этих пояснений специализирующее понятие точнее было бы называть «реляционным», поскольку фиксируется оно только и исключительно через отношения объектов.  Еще раз хотелось бы подчеркнуть, что различение концептуальных и реляционных понятий вполне формально и абсолютно – оно не нивелируется выбором какой-либо, включая субъективную, точки зрения. Вряд ли найдется такой аналитик, который сможет объяснить, что такое «ездовая собака» без ссылки на понятие «езда» (никак изначально не связанное с собакой) или кто такой «студент» без упоминания связи с понятием «высшее учебное заведение».

Далее в тексте речь пойдет только об концептуальных понятиях.

Иерархия концептуальных понятий

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

Первое, что бросается в глаза, а точнее, приходит на ум при анализе приведенного ряда концептуальных понятий, это то, что перед нами однозначная иерархия – соподчиненность по степени обобщения-уточнения. Также можно заметить, что понятия в этой иерархии не одинаково концептуальны, то есть не равноценно характеризуют то, чем же является Жучка сама по себе. Ясно, что если, указав на Жучку, спросить «кто это?», то  ответ, разумеется, будет «собака». Возможно, собачники дополнительно уточнят породу – «лайка», а обобщающее понятие «животное» никто и не вспомнит, хотя все его знают. Следовательно, в иерархии концептуальных понятий, под которые подпадает индивид, можно выделить одно – базовое, максимально точно выражающее сущность, содержание, природу индивида. Это наиболее концептуальное из концептуальных понятий будем называть «концептом».

Основная мысль, на которой хотелось бы акцентировать внимание при выделении концептов из иерархии концептуальных понятий, заключается в понимании, что мир мы изначально воспринимаем и мыслим именно на базовом уровне концептов и только в специальных случаях поднимаемся до обобщений и детализации. Вот как эту идею излагает Дж. Лакофф: «Именно на этом уровне опыта мы четко отличаем тигров от слонов, стулья от столов, розы от нарциссов, спаржу от брокколи, медь от цинка и т. д. Один уровень вниз – и все значительно усложняется. Гораздо труднее отличить один вид жирафа от другого, чем жирафа от слона. Наша способность гештальтного восприятия на базовом уровне не приспособлена для того, чтобы легко делать четкие различения на таких более низких уровнях» [Lakoff, 2004]. И тут, анализируя практику построения моделей предметных областей, мы должны спросить себя: не опрометчиво ли мы  поступаем, начиная строительство онтологического дерева сверху, с самых общих понятий? Не подгоняем ли мы при этом структуру концептуального уровня под искусственно придуманную схему? Не правильнее было бы начинать строительство моделей предметных областей с выделения базовых концептов, развивая ее вверх и вниз по мере необходимости?

Пока оставим эти вопросы без ответа (хотя он и очевиден) и обратимся к структуре иерархии концептуальных понятий. До нас ее (хотя, конечно, еще не называя так) анализировал Э. Рош [Rosch, 1976], который выделил три уровня – высший, базисный и подчиненный (в полном соответствии с нашим примером).

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

Концепт

• Отвечает на вопрос: что это?

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

Категория

• Отвечает на вопрос: к чему относится? в чем сущность этого?

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

Тип

• Отвечает на вопрос: в чем смысл? что с этим делают? к какой деятельности относится?

Тип указывает на специальное предназначение концепта в рамках категории, на способ функционирования, на цель его использования в конкретной деятельности. Типы механизмов: транспортное средство, прибор, подъемное средство и пр. Типы живых организмов: животные, растения, гриб.  Следует особо подчеркнуть, что тип – это не подкласс категории (хотя так представлять довольно удобно), а  именно тип концепта в категории. То есть следует говорить так: есть концепт «автомобиль», он относится к категории «механизмы» и его тип, предназначение (в этой категории) «транспортное средство».

Род

• Отвечает на вопрос: для чего, как конкретно использовать? какие задачи решаются?

Род фиксирует функцию, приспособление, специализацию концепта: как используется автомобиль? для каких задач? для чего собака?  –  легковой автомобиль, охотничья собака [примечание: здесь понятие «охотничья» является именно концептуальным, а не реляционным, поскольку характеризует не специализированное использование конкретной Жучки на определенном этапе ее жизни, а типовое использование группы пород – любая лайка, даже если она ни разу не была на охоте, концептуально будет охотничьей собакой]. Род традиционно поименовывается словосочетанием, состоящим из имени концепта и поясняющего определения: красное вино, договор аренды, стол офисный.

Вид

• Отвечает на вопрос: какой?

Вид – это конкретная реализация рода: какой у вас автомобиль? какая собака? – «Жигули», лайка. Вид обычно обозначается собственным уникальным именем, напрямую не указывающим на какую-либо специфику. Вид продукта часто обозначается именем производителя.

Разновидность

• Отвечает на вопрос: который из? какая реализация?

Разновидность – это конкретная реализация, особенная адаптация вида («Жигули 2101», карело-финская лайка). Название строится на основе имени вида с уточняющим пояснением.

Индивид

Индивид – это единичная конкретная вещь, обладающая в той или иной степени пространственно-временной локализацией: моя машина, моя собака, прошлое лето. Фиксация индивида, различение его от других индивидов реализуется утверждением о подпадании его под тот или иной концепт. Один индивид может подпасть под несколько концептов, при условии, что концептуальные функции индивида не совпадают по времени (автомобиль-самолет либо едет по дороге, либо летит по воздуху).

Разные субъекты могут указать для одного индивида разные концепты (ну, если кому-то, к примеру, потребовалось забивать микроскопом гвозди). Для фиксации концепта индивида нет необходимости приписывать ему атрибуты или отношения – он является концептом по самому факту утверждения субъектом подпадания индивида под концепт.

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

В таблице приведены примеры концептуального описания индивидов «моя машина», «бутылка вина на столе», «приложение на моем компьютере», «моя Жучка».

Уточнения

Следует сделать несколько уточнений и комментариев по поводу приведенной концептуальной иерархии:

1. Следует понимать, что описание через иерархию «категория – тип – концепт – род – вид – разновидность – индивид» это не классификация индивида. Приведенная иерархия фиксирует уровни восприятия, уровни отношения к индивиду, задает его понятийную целостность.
2. Поскольку для обозначения уровней иерархии используются широко распространенные термины, активно использующиеся в других понятийных системах, то неизбежны терминологические биения, вопросы, претензии, мол, тип это про другое, и категорию следует понимать иначе и т.п. Ответ на это простой: важна сама понятийная схема, а не частное поименование уровней, которое каждый может изменить на приемлемое в другой терминологической сетке.
3. Обязательно будут возникать ситуации, когда для индивида либо невозможно будет выделить все уровни классификации (скажем, отсутствует разновидность), либо, что более вероятно, потребуется введение промежуточных ступеней. По поводу первого случая можно сказать лишь: ну нет, так и нет. А для реализации второй ситуации придется включать фантазию. То, что ни одна классификация не может быть исчерпывающей и универсальной – это общее место.

Литература

1. Бейкер Л.Р. Онтологическое значение артефактов // Онтологии артефактов: взаимодействие «естественных» и «искусственных» компонентов жизненного мира. Под ред. О.Е. Столяровой. М., 2012.
2. Lakoff Dzh. Zhenshchiny, ogon' i opasnye veshchi. Chto kategorii yazyka govoryat nam o myshlenii / Per. s angl. I. B. Shatunovskogo. M.: Yazyki slavyanskoj kul'tury, 2004. 792 s.
3. Rosch E. et al. Basic Objects in Natural Categories // Cognitive Psychology. 1976. № 8. P. 382–436.

ссылка на оригинал статьи https://habrahabr.ru/post/276271/