Jena/ARQ: Różnica między modelem, wykresem i zestawem danych

Question

Zaczynam pracować z Jena Engine i myślę, że mam pojęcie o tym, czym jest semantyka. Jednak mam problemy ze zrozumieniem różnych sposobów, aby reprezentować kilka trójek w Jenie i ARQ:

• Pierwszą rzeczą, można natknąć się podczas uruchamiania jest Model a dokumentacja mówi jego nazwa Jenas dla grafów RDF .
• Jednak istnieje również Graph co wydawało się być niezbędne narzędzie gdy chcę zapytać unii modeli, jednak nie wydaje się, aby dzielić wspólny interfejs z Model, chociaż można uzyskać Graph z pomocą Model
• Następnie w ARQ jest DataSet, co również wydaje się być zbiorem trójki.

Pewnie, po rozejrzeniu się w API, znalazłem sposób na konwersję z jednej na drugą. Podejrzewam jednak, że jest w tym coś więcej niż 3 różne interfejsy tego samego.

Pytanie brzmi: Jakie są kluczowe różnice projektowe między tymi trzema? Kiedy powinienem użyć którego? W szczególności: kiedy chcę trzymać pojedyncze kije trójki, ale sprawdzam je jako jedną dużą wiązkę (zjednoczenie), z której z tych struktur danych powinienem korzystać (i dlaczego)? Czy też "tracę" cokolwiek, gdy "konwertuję" z jednego na inny (np. Czy model.getGraph() zawiera mniej informacji w pewnym stopniu niż model)?

Answer 1

Jena jest podzielony na API dla programistów aplikacji, oraz SPI dla programistów systemów, takich jak osoby dokonujących silniki bagażu, wnioskowania itd

DataSet, Model, Statement, Resource i Literal to interfejsy API i zapewniają wiele udogodnień dla programistów aplikacji.

DataSetGraph, Graph, Triple, Node są interfejsy SPI. Są dość spartańskie i łatwe do wdrożenia (jak byś miał nadzieję, gdybyś zaimplementował te rzeczy).

Różnorodne operacje API są rozwiązywane aż do wywołań SPI. Aby podać przykład, Model interface ma cztery różne metody: contains. Wewnętrznie każda prowadzi rozmowy:

Graph#contains(Node, Node, Node) 

takie jak

graph.contains(nodeS, nodeP, nodeO); // model.contains(s, p, o) or model.contains(statement) 
graph.contains(nodeS, nodeP, Node.ANY); // model.contains(s, p) 

Odnośnie swoje pytanie odnośnie utraty informacji, z Model i Graph ty nie (o ile dobrze pamiętam). Bardziej interesujący przypadek to Resource versus Node. Resources wiedzieć, do którego modelu należą, dzięki czemu można (w api) napisać resource.addProperty(...), który ostatecznie staje się Graph#add. Node nie ma takiej wygody i nie jest powiązany z konkretnym Graph. Stąd Resource#asNode jest stratny.

Wreszcie:

Kiedy chcę trzymać poszczególne pęki trójek ale kwerendy je jako jeden duży pęczek (Unia), która z tych datastructures należy używać (i dlaczego)?

Jesteś wyraźnie normalnym użytkownikiem, więc potrzebujesz interfejsu API. Chcesz przechowywać trójki, więc używaj Model. Teraz chcesz zapytać modele jako jeden związek: Możesz:

• Model#union() wszystko, co skopiuje wszystkie trzy formy do nowego modelu.
• ModelFactory.createUnion() wszystko, co spowoduje utworzenie związku dynamicznego (tj. Bez kopiowania).
• Przechowuj modele jako nazwane modele w magazynie zestawów danych TDB lub SDB i użyj opcji unionDefaultGraph.

Ostatnia z tych prac jest najlepsza dla dużej liczby modeli i dużych modeli, ale jest nieco bardziej zaangażowana w konfigurację.

Answer 2

Krótka odpowiedź: Model to tylko opakowanie bezpaństwowca z wieloma wygodnymi metodami w pobliżu Graph. ModelFactory.createModelForGraph(Graph) zawija wykres w modelu. Model.getGraph() pobiera zawijany wykres.

Większość programistów aplikacji użyłaby Model. Osobiście wolę używać Graph, ponieważ jest to prostsze. Mam problem z zapamiętywaniem wszystkich błędów na klasie Model.

Dataset s to zbiór kilku Model: jeden "domyślny model" i zero lub więcej "nazwanych modeli". Odpowiada to pojęciu "zestawu danych RDF" w SPARQL. (Mówiąc technicznie, SPARQL nie jest językiem zapytań dla "wykresów RDF", ale dla "zestawów danych RDF", które mogą być kolekcjami nazwanych wykresów RDF plus domyślny wykres.)