RDF4J Workbench: почему один SPIN-конструктор очень медленный?

Question

RDF4J Workbench: почему один SPIN-конструктор очень медленный?

Я прошу прощения за длину этой публикации. Я пытаюсь сделать эту медленную проблему правил воспроизводимой.

Я использую TopBraid Composer FE для создания RDF-файла с онтологией и конструкторами SPIN. Целью конструкторов SPIN является проверка соответствия в экземплярах отдельных классов, определенных в онтологии. Я считаю, что выполнение конструктора SPIN очень медленное, и я хотел бы знать, почему.

Онтология, включая конструкторы SPIN SXXIComplianceCheck18.rdf

Я изменяю / очищаю свой репозиторий (In Store Store с поддержкой RDFS+SPIN) и загружаю эту онтологию в рабочую среду RDF4J:

Затем я использую два запроса SPARQL Update по очереди для создания отдельных классов, определенных в онтологии (файл RDF выше), и таким образом стимулирую запуск конструкторов SPIN.

Первый запрос SPARQL Update (создает экземпляры отдельных элементов данных и при необходимости вызывает конструкторы синтаксического анализа... выполняется быстро):

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX sxxicc: <http://www.disa.mil/dso/a2i/ontologies/PBSM/Interface/SXXIComplianceCheck#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX sp: <http://spinrdf.org/sp#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX smf: <http://topbraid.org/sparqlmotionfunctions#>
PREFIX fn: <http://www.w3.org/2005/xpath-functions#>
PREFIX spl: <http://spinrdf.org/spl#>
PREFIX spin: <http://spinrdf.org/spin#>
PREFIX arg: <http://spinrdf.org/arg#>
PREFIX SXXIComplianceCheckIndividuals: <http://www.disa.mil/dso/a2i/ontologies/PBSM/Interface/SXXIComplianceCheckIndividuals#>
PREFIX sxxicci: <http://www.disa.mil/dso/a2i/ontologies/PBSM/Interface/SXXIComplianceCheckIndividuals#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>


INSERT DATA
{
   sxxicci:testPub7Proposal_DataItem110 a sxxicc:Pub7DataItem110 ;
           sxxicc:pub7DataItemHasRawStringValue "(C) M221.5"^^xsd:string .  

   sxxicci:testPub7Proposal_DataItem500 a sxxicc:Pub7DataItem500 ;
           sxxicc:pub7DataItemHasRawStringValue "S181"^^xsd:string .

   sxxicci:testPub7Proposal_DataItem300 a sxxicc:Pub7DataItem300 ;
           sxxicc:pub7DataItemHasRawStringValue "DC"^^xsd:string .

   sxxicci:testPub7Proposal_DataItem113 a sxxicc:Pub7DataItem113 ;
           sxxicc:pub7DataItemHasRawStringValue "FX"^^xsd:string .

   sxxicci:testPub7Proposal_DataItem511 a sxxicc:Pub7DataItem511 ;
           sxxicc:pub7DataItemHasRawStringValue "SIGHT SEEING"^^xsd:string .

   sxxicci:testPub7Proposal_DataItem501 a sxxicc:Pub7DataItem501 ;
#            sxxicc:pub7DataItemHasRawStringValue "M002"^^xsd:string .
           sxxicc:pub7DataItemHasRawStringValue "M018,     160727"^^xsd:string .

   sxxicci:testPub7Proposal_DataItem503 a sxxicc:Pub7DataItem503 ;
           sxxicc:pub7DataItemHasRawStringValue "CUBESAT, TOM"^^xsd:string .

   sxxicci:testPub7Proposal_DataItem504a a sxxicc:Pub7DataItem504 ;
           sxxicc:pub7DataItemHasRawStringValue "FAS Agenda line 1"^^xsd:string ;
           sxxicc:pub7DataItemHasOrdinalNumber "1"^^xsd:integer .

   sxxicci:testPub7Proposal_DataItem504b a sxxicc:Pub7DataItem504 ;
           sxxicc:pub7DataItemHasRawStringValue "FAS Agenda line 2"^^xsd:string ;
           sxxicc:pub7DataItemHasOrdinalNumber "2"^^xsd:integer .           

   sxxicci:testPub7Proposal_DataItem504c a sxxicc:Pub7DataItem504 ;
           sxxicc:pub7DataItemHasRawStringValue "FAS Agenda line 3"^^xsd:string ;
           sxxicc:pub7DataItemHasOrdinalNumber "3"^^xsd:integer .

   sxxicci:testPub7Proposal_DataItem504d a sxxicc:Pub7DataItem504 ;
           sxxicc:pub7DataItemHasRawStringValue "FAS Agenda line 4"^^xsd:string ;
           sxxicc:pub7DataItemHasOrdinalNumber "4"^^xsd:integer .         

   sxxicci:testPub7Proposal_DataItem504e a sxxicc:Pub7DataItem504 ;
           sxxicc:pub7DataItemHasRawStringValue "FAS Agenda line 5"^^xsd:string ;
           sxxicc:pub7DataItemHasOrdinalNumber "5"^^xsd:integer .

   sxxicci:testPub7Proposal_DataItem504f a sxxicc:Pub7DataItem504 ;
           sxxicc:pub7DataItemHasRawStringValue "FAS Agenda line 6"^^xsd:string ;
           sxxicc:pub7DataItemHasOrdinalNumber "6"^^xsd:integer .

   sxxicci:testPub7Proposal_DataItem144 a sxxicc:Pub7DataItem144 ;
           sxxicc:pub7DataItemHasRawStringValue "Y"^^xsd:string .

   sxxicci:testPub7Proposal_DataItem005 a sxxicc:Pub7DataItem005 ;
           sxxicc:pub7DataItemHasRawStringValue "SF"^^xsd:string .

   sxxicci:testPub7Proposal_DataItem102 a sxxicc:Pub7DataItem102 ;
           sxxicc:pub7DataItemHasRawStringValue "S   881234"^^xsd:string .

   sxxicci:testPub7Proposal_DataItem017 a sxxicc:Pub7DataItem017 ;
           sxxicc:pub7DataItemHasRawStringValue "C"^^xsd:string .
}

Второй запрос SPARQL Update (создает предложение, которое связывает воедино элементы данных, созданные в первом запросе, и запускает конструктор проверки соответствия... выполняется очень медленно, около 20 секунд на моем компьютере):

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX sxxicc: <http://www.disa.mil/dso/a2i/ontologies/PBSM/Interface/SXXIComplianceCheck#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX sp: <http://spinrdf.org/sp#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX smf: <http://topbraid.org/sparqlmotionfunctions#>
PREFIX fn: <http://www.w3.org/2005/xpath-functions#>
PREFIX spl: <http://spinrdf.org/spl#>
PREFIX spin: <http://spinrdf.org/spin#>
PREFIX arg: <http://spinrdf.org/arg#>
PREFIX SXXIComplianceCheckIndividuals: <http://www.disa.mil/dso/a2i/ontologies/PBSM/Interface/SXXIComplianceCheckIndividuals#>
PREFIX sxxicci: <http://www.disa.mil/dso/a2i/ontologies/PBSM/Interface/SXXIComplianceCheckIndividuals#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>

INSERT DATA
{

   sxxicci:TestPub7Proposal a sxxicc:Pub7Proposal ;
           sxxicc:pub7ProposalHasDataItem sxxicci:testPub7Proposal_DataItem005 ;
           sxxicc:pub7ProposalHasDataItem sxxicci:testPub7Proposal_DataItem017 ;
           sxxicc:pub7ProposalHasDataItem sxxicci:testPub7Proposal_DataItem102 ;
           sxxicc:pub7ProposalHasDataItem sxxicci:testPub7Proposal_DataItem110 ;
           sxxicc:pub7ProposalHasDataItem sxxicci:testPub7Proposal_DataItem113 ;
           sxxicc:pub7ProposalHasDataItem sxxicci:testPub7Proposal_DataItem144 ;
           sxxicc:pub7ProposalHasDataItem sxxicci:testPub7Proposal_DataItem300 ;
           sxxicc:pub7ProposalHasDataItem sxxicci:testPub7Proposal_DataItem500 ;
           sxxicc:pub7ProposalHasDataItem sxxicci:testPub7Proposal_DataItem501 ; 
           sxxicc:pub7ProposalHasDataItem sxxicci:testPub7Proposal_DataItem503 ;
           sxxicc:pub7ProposalHasDataItem sxxicci:testPub7Proposal_DataItem504a ;
           sxxicc:pub7ProposalHasDataItem sxxicci:testPub7Proposal_DataItem504b ;
           sxxicc:pub7ProposalHasDataItem sxxicci:testPub7Proposal_DataItem504c ;
           sxxicc:pub7ProposalHasDataItem sxxicci:testPub7Proposal_DataItem504d ;
           sxxicc:pub7ProposalHasDataItem sxxicci:testPub7Proposal_DataItem504e ;
#           sxxicc:pub7ProposalHasDataItem sxxicci:testPub7Proposal_DataItem504f ;
           sxxicc:pub7ProposalHasDataItem sxxicci:testPub7Proposal_DataItem511 .


}

Этот второй запрос занимает много времени, около 20 секунд. Это не согласуется с другими проверками соответствия (не включенными в этот RDF). Я выделил это одно правило из 13 других похожих правил (в основном, для анализа строк и сравнения), потому что оно доминирует во времени.

(Правильные, но отложенные) результаты:

Рассматриваемый конструктор SPIN (для sxxicc:Pub7Proposal учебный класс):

# NEED MINUTE <M> NOTE M002 IN CIRCUIT REMARKS LISTING IRAC DOCUMENT GIVING APPROVAL FOR THIS ASSIGNMENT. (501 08)
CONSTRUCT {
    ?this sxxicc:pub7ProposalHasComplianceMessage "NEED MINUTE <M> NOTE M002 IN CIRCUIT REMARKS LISTING IRAC DOCUMENT GIVING APPROVAL FOR THIS ASSIGNMENT. (501 08)"^^xsd:string .
}
WHERE {
    ?this a sxxicc:Pub7Proposal .
    ?this sxxicc:pub7ProposalHasDataItem ?dataItem102 .
    ?dataItem102 a sxxicc:Pub7DataItem102 .
    ?dataItem102 sxxicc:pub7DataItemHasStringValue ?serialNumString .
    ?this sxxicc:pub7ProposalHasDataItem ?dataItem500 .
    ?dataItem500 a sxxicc:Pub7DataItem500 .
    ?dataItem500 sxxicc:pub7DataItemHasStringValue ?iracNotesString .
    ?this sxxicc:pub7ProposalHasDataItem ?dataItem501 .
    ?dataItem501 a sxxicc:Pub7DataItem501 .
    ?dataItem501 sxxicc:pub7DataItemHasStringValue ?notesFreeTextCommentsString .
    ?this sxxicc:pub7ProposalHasDataItem ?dataItem113 .
    ?dataItem113 a sxxicc:Pub7DataItem113 .
    ?dataItem113 sxxicc:pub7DataItemHasStringValue ?stationClassString .
    ?this sxxicc:pub7ProposalHasDataItem ?dataItem300 .
    ?dataItem300 a sxxicc:Pub7DataItem300 .
    ?dataItem300 sxxicc:pub7DataItemHasStringValue ?stateCountryForTransmittingStation .
    BIND (SUBSTR(?serialNumString, 1, 4) AS ?orgString) .
    BIND (SUBSTR(?stationClassString, 1, 2) AS ?stationClassCode) .
    FILTER (((((?orgString = "S   "^^xsd:string) && (?iracNotesString = "S181"^^xsd:string)) && (?notesFreeTextCommentsString != "M002"^^xsd:string)) && (?stationClassCode = "FX"^^xsd:string)) && (?stateCountryForTransmittingStation = "DC"^^xsd:string)) .
}

Почему этот конструктор работает так медленно на современном ПК (четырехъядерный процессор AMD 2,3 ГГц под управлением Windows 8 с 16 ГБ физической памяти и без значительной дополнительной загрузки приложения)? Другие конструкторы быстро работают на одной и той же машине и используют те же факты, делая схожие вещи.

Вот вывод Jave VisualVM Sampler от выполнения этого примера:

RDF4J org.eclipse.rdf4j.common.concurrent.locks.LockManager$1.release() и org.eclipse.rdf4j.common.concurrent.locks.LockManager.createLock() доминируют во времени самостоятельной работы. Зачем?? Есть ли что-то, что я могу сделать, чтобы переписать свои правила, чтобы избежать этого времени?

ЗАМЕТКИ:

Первая тройка предложения WHERE не требуется в конструкторе SPIN, потому что это устанавливается автоматически. Однако я включил его, чтобы упростить отладку, скопировав этот конструктор в запрос SPARQL (Explore/Query) в рабочей среде. Я также нахожу удобным заменить предложение CONSTRUCT на "SELECT DISTINCT *", оставляя предложение WHERE в такте для отладки конструктора.
Единственная цель предложения WHERE в этом конструкторе - предоставить сопоставление с шаблоном графа, которое показывает условие ошибки для сообщения об исправленной ошибке в предложении CONSTRUCT. Никакие привязки не переносятся из предложения WHERE в предложение CONSTRUCT, но предложение WHERE все еще пропускает утверждение тройки в предложении CONSTRUCT.

ОБНОВИТЬ

Я изменил конструктор, удалив один FILTER и связанные триплеты из конструктора:

FILTER (?iracNotesString = "S181"^^xsd:string) .

?this sxxicc:pub7ProposalHasDataItem ?dataItem500 .
?dataItem500 a sxxicc:Pub7DataItem500 .
?dataItem500 sxxicc:pub7DataItemHasStringValue ?iracNotesString .

В результате получается конструктор, показанный ниже в TBC FE:

Выполняя тот же тест с теми же двумя запросами на обновление SPARQL, второй запрос имеет очень нелинейное сокращение времени выполнения с более чем 20 секунд до менее чем 2 секунд. Опять же, это не кажется правильным.

1

sparql rdf sesame rdf4j topbraid-composer

Источник

user6501799 29 авг '16 в 18:35

0 ответов

Другие вопросы по тегам sparql rdf sesame rdf4j topbraid-composer