Стратегия запросов RDF Sesame для реализации паруса

правильно ли, что оператор SPARQL ADD реализован методом executeAdd в классе SailUpdateExecutor?

Это верно.

правильно ли я интерпретирую, что слой SAIL представляет собой тройное извлечение из исходного графа и вставку его в целевой граф

Да, это реализация по умолчанию.

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

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

Как сказано выше, базовое хранилище может делать это в реализациях метода SailConnection, которые имеют объект UpdateContext в качестве одного из своих параметров.

SailUpdateExecutor просто выполняет обновление на логическом уровне. Оптимизация его выполнения по-прежнему полностью зависит от базового хранилища.

Если это не было предусмотрено в интерфейсе паруса, существует ли какой-либо из интерфейсов запросов SESAME, который применяет эту стратегию: как можно больше протолкнуть запрос в хранилище? Или стратегия обратная: когда запрос можно исследовать, он выполняется немедленно.

Я не совсем уверен, что следую, но запросы всегда полностью отправляются в базовое хранилище. Единственное, что происходит заранее, это то, что запрос анализируется и преобразуется в алгебраическую модель. Эта алгебраическая модель отправляется в базовое хранилище, которое имеет полную свободу оптимизировать/преобразовывать/выполнять ее любым удобным для него способом. Конечно, для удобства предусмотрена стратегия оценки по умолчанию, но ее можно переопределить.

Наконец, можно ли настроить стратегию выполнения запросов? Я нахожу в исходном коде ссылку на оптимизаторы выполнения запросов, но не могу найти, можно ли их настроить для каждого экземпляра хранилища?

В большинстве экземпляров магазина Sail эти оптимизаторы не настраиваются — они просто применяют их внутри по своему усмотрению. Обычно это происходит в методе SailConnection.evaluate (точнее, в AbstractSailConnection.evaluateInternal). Здесь реализация магазина также выбирает стратегию оценки для использования (либо стратегию по умолчанию, либо свою собственную оптимизированную стратегию).