Mitglieder der Kindklasse sind nicht als Mitglieder der Oberklasse im LUBM-Benchmark klassifiziert

Question

Ich versuche, den LUBM-Benchmark auszuführen, aber ich habe einige Probleme mit der Klassifizierung nach der Argumentation.

Die Dateien Ich benutze sind:

The main ontology

The output of the LUBM generator 1.7

Das Problem ist, dass die Mitglieder von GraduateStudent und UndergraduateStudent sind nicht als Mitglieder der Superklasse Student klassifiziert werden.

Ich versuchte Pellet, Einsiedler und Tatsache Denker auf Protege 5.0 und alle haben versagt. Folglich ist auch die Benchmark-SPARQL-Abfrage Nr. 10 fehlgeschlagen.

#-- Query10 
#-- This query differs from Query 6, 7, 8 and 9 in that it only requires the 
#-- (implicit) subClassOf relationship between GraduateStudent and Student, i.e., 
#-- subClassOf rela-tionship between UndergraduateStudent and Student does not add 
#-- to the results. 

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> 
PREFIX ub: <http://www.lehigh.edu/~zhp2/2004/0401/univ-bench.owl#> 

SELECT ?X WHERE { 
    ?X rdf:type ub:Student . 
    ?X ub:takesCourse <http://www.Department0.University0.edu/GraduateCourse0> 
} 

Sie einen Screenshot von meinem Protegé Klassifizierung finden Sie hier (sorry ich habe nicht genug Ruf direkt das Bild, um es).

Auf Protege 4.3 Klassifizierung arbeitet mit Pellet und Einsiedler, aber die SPARQL-Abfrage immer noch nicht.

Ich habe bereits die Reasoner-Einstellungen so geändert, dass alle abgeleiteten Kenntnisse angezeigt werden, also nicht, weil sie nur versteckt sind.

Ich finde dieses Verhalten sehr verwirrend, vor allem wenn man bedenkt, dass dies ein bewährter Maßstab sein sollte. Ich denke, es gibt eine sehr triviale Lösung, aber ich kann es nicht finden, also würde jede Hilfe sehr geschätzt werden!

EDIT: Es ist mir gelungen, den Benchmark zu laufen. Ich habe den XML-Code der ABox (die ich vom Generator bekommen habe) manuell in die TBox kopiert. Auf diese Weise funktioniert die Klassifizierung auf Protege 4 und über API. SPARQL-Abfragen funktionieren auch mit SPARQL, wie hier vorgeschlagen. Bei Protege 5 funktioniert die Klassifizierung noch immer NICHT. Ich bin gespannt, was das verursacht hat.

Answer 1

Der Generator allein erzeugt nur Daten, die ausreichen, um eine Teilmenge der Abfragen zu beantworten (Abfragen 1-3 und 14). Damit ein SPARQL-System alle Abfragen beantworten kann, die es benötigt, um Rückschlüsse zu ziehen. Wie es das ist, ist ein umsetzungsspezifisches Detail. Auch für viele Systeme ist die Inferenz standardmäßig deaktiviert und muss aktiviert sein.

Je nach verwendetem System müssen Sie wahrscheinlich die Hauptontologie angeben, die Sie mit Ihrem System verknüpft haben, und die erforderlichen Einstellungen vornehmen.

Es kann sein, dass SPARQL-Abfragen in Protege abgeleitetes Wissen nicht berücksichtigen, aber ich habe nie Protege verwendet, also kann ich kein bestimmtes Tool kommentieren.