File Input Handler

File Input Handler (Port:7201)

Der File Input Handler sucht im angegeben Bucket eines MinIO Object Storage nach Dateien, die er verarbeiten kann.

Findet er Dateien in den Formaten TTL, XML/RDF und OWL, werden diese in ein GraphDB Repository importiert. Neben diesen Dateien werden auch alle JSON-Dateien, die Metadaten enthalten, in RDF umgewandelt und die Metadaten in das GraphDB Repository importiert.

Dateien anderer Formate werden künftig an die jeweiligen Konverter gesendet, bevor sie ggf. in GraphDB importiert werden. CSV- und TXT-Dateien werden z.B. an den Csv2Rdf Converter gesendet, sodass die konvertierte und auf MinIO hochgeladene TTL-Datei ebenfalls importiert werden kann.

Wenn die Dateien WKT-Strings oder anderweitig Geometrien enthalten können, werden diese zum Import in die Postgres-Datenbank an den Geometrie Handler gesendet (derzeit alle Dateien in XML, CSV, TXT). Der Geometry Handler sendet Informationen zu den importierten Geometrien zurück, die in Triple umgewandelt und als Instanzen der Geometrien in GraphDB importiert werden. Vom Topology Service ermittelte geometrische Beziehungen können ebenfalls in Triple umgewandelt und in die Datenbank importiert werden, um die darin enthaltenen Instanzen der Geometrien aus Postgres auf semantischer Ebene topologisch in Beziehung zu setzen.

IFC-Dateien werden auf den BIMserver hochgeladen, welcher Metadaten (ProjektId, RevisionsId) zurückgibt. Diese werden als Triple in GraphDB importiert, um eine Verknüpfung zum Modell im BIMserver herstellen zu können. Die IFC-Datei wird außerdem an den IfcContour Creator gesendet, welcher die Kontur des Gebäudegrundrisses als Datei auf MinIO speichert. Diese Datei wird vom File Input Handler gelesen und jeder Zeile eine Id vorangestellt. Wenn darin kein Extended WKT (EWKT) ist, wird jeder Zeile der EPSG-Code des Systems ETRS89 UTM 32 angehängt. Außerdem erhält die Datei eine Kopfzeile (id; wkt; epsg oder id; wkt) je nach Inhalt. Im Anschluss wird die Datei wieder auf MinIO hochgeladen und der Geometry Handler mit der Verarbeitung beauftragt. Als nächstes wird eine neue IFC-Datei erzeugt, in der alle Entitäten mit Bezug zur Geometrie der Bauelemente entfernt wurden. Dazu werden Entitäten bestimmter IFC-Klassen in der Datei über String-Vergleiche gesucht, deren Referenzen ermittelt und entfernt. Für die gefunden Referenzen erfolgt dieser Prozess iterativ. Die Datei enthält danach hauptsächlich Bauteilentitäten und deren Properties. Diese Property Datei wird mit Hilfe des IFCtoRDF Converters von Pieter Pauwels in RDF als Turtle Syntax konvertiert. Im Anschluss wird diese TTL-Datei in GraphDB importiert.

Bei jedem Import wird im MinIO Bucket eine bucketlist.txt angelegt bzw. geupdated, in der die Namen der verarbeiteten Dateien gespeichert werden. Beim erneuten Ausführen des Imports wird die Liste gelesen und darauf stehende Dateien werden nicht erneut verarbeitet. Der Import kann mit dem Scheduler Service automatisiert werden. Neben dem Import können auch Triple geupdatet oder gelöscht werden. Außerdem lassen sich neue GraphDB Repositories erstellen.

An den GraphDB Triplestore können über die API diverse Abfragen gestellt werden, die Daten einfügen, löschen oder abfragen.

Funktionsweise

Import

[GET] /inputhandler/import/miniobucket/{bucket}/repository/{repo}

• Angabe eines MinIO Bucket als Quellordner und eines GraphDB Repositories als Zieldatenbank
• Ordner wird nach serialisierten RDF-Dateien mit den Endungen .ttl, .rdf, .owl durchsucht und diese werden nach GraphDB importiert
• JSON-Dateien mit "metadata" im Namen werden als Triple in Turtle-Syntax serialisiert und in die Datenbank geschrieben
• leere Metadaten werden dabei ignoriert
• Namespace der Triple wird, wenn vorhanden, auf Dateipfad der beschriebenen Datei gesetzt
• Standardnamespace ist "https://terrain.dd-bim.org/" + Dateiname
• GraphDB verhindert automatisch redundanten Import von Tripeln
• Geometriedateien werden an den Geometry Handler gesendet
• `IFC- Dateien werden auf den BIMserver geladen und weiter verarbeitet
• Scheduler Service kann den Request automatisiert in festen Zeitintervallen ausführen

[POST] /inputhandler/import/topology/repository/{repo}

• Geometry Handler sendet JSON-String mit Triple Elementen, bestehen aus Subjekt, Prädikat und Objekt Key-Value-Paaren
• diese werden als Triple in eine temporäre Datei im innern des Containers geschrieben
• zum Schluss wird die Datei in GraphDB importiert

[POST] /inputhandler/import/postgresinfos

• REST-Schnittstelle empfängt Metadaten vom Geometry Handler
• mit Prädikaten der TerrainTwin Ontologie werden diese als Triple in eine temporäre Datei im Container geschrieben
• zum Schluss wird die Datei in GraphDB importiert

[POST] /inputhandler/import/triple/repository/{repo}

• Import eines einzelnen Triples in das angegebene GraphDB repository
• Angabe des Triples als JSON:

  {
    "subject": "string",
    "predicate": "string",
    "object": "string"
  }

Update

[POST] /inputhandler/update/repository/{repo}

• alter und neuer Stand eines oder mehrerr Triple können über folgendes JSON-Schema angegeben werden:

{
  "namespaces": {
    "additionalProp1": "string",
    "additionalProp2": "string",
    "additionalProp3": "string"
  },
  "pairs": [
    {
      "oldTriple": {
        "subject": "string",
        "predicate": "string",
        "object": "string"
      },
      "newTriple": {
        "subject": "string",
        "predicate": "string",
        "object": "string"
      }
    }
  ]
}

• erforderliche Namespaces werden mit "Präfix": "URI" angegeben
• daraus werden je ein DELETE und INSERT SPARQL-Befehl generiert und an die Datenbank gesendet

Delete

[DELTE] /inputhandler/delete/topology/repository/{repo}

• erzeugt für alle Topologie-Prädikate (sfEquals, sfTouches, sfWithin, sfContains, sfOverlaps, sfCrosses, ehCovers, ehCoveredBy) DELETE SPARQL-Befehle und sendet die an die Datenbank
• kann genutzt werden, wenn die topologischen Beziehungen neu berechnet wurden, um zunächst alle Beziehungen zu entfernen, damit keine falschen Beziehungen bestehen bleiben

[DELTE] /inputhandler/delete/resource/repository/{repo}/id/{id}

• erzeugt einen DELETE SPARQL-Befehl, um alle Triple, die auf eine Resource mit der angegebenen ID verweisen, zu löschen
• z.B. wenn eine Geometrie aus Postgres entfernt wurde, kann diese über die ID auch in GraphDB gelöscht werden

[DELTE] /inputhandler/delete/repository/{repo}

• erzeugt einen DELETE SPARQL-Befehl aus den im folgenden Schema angebenen Triplen und sendet diesen an die Datenbank

{
  "namespaces": {
    "additionalProp1": "string",
    "additionalProp2": "string",
    "additionalProp3": "string"
  },
  "triples": [
    {
      "subject": "string",
      "predicate": "string",
      "object": "string"
    }
  ]
}

• damit lassen sich auch komplexere Befehle zum Löschen bestimmter Triple erstellen, die selbst mehrere Triple beinhalten

Create

[GET] /inputhandler/createRepo/{repo}

• erzeugt ein neues GraphDB Repository mit dem angegeben Namen
• folgendes Schema wird dafür verwendet:

#
# RDF4J configuration template for a GraphDB Free repository
#
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix rep: <http://www.openrdf.org/config/repository#>.
@prefix sr: <http://www.openrdf.org/config/repository/sail#>.
@prefix sail: <http://www.openrdf.org/config/sail#>.
@prefix owlim: <http://www.ontotext.com/trree/owlim#>.

[] a rep:Repository ;
    rep:repositoryID "defaultRepository" ;
    rdfs:label "" ;
    rep:repositoryImpl [
        rep:repositoryType "graphdb:FreeSailRepository" ;
        sr:sailImpl [
            sail:sailType "graphdb:FreeSail" ;
            
            owlim:base-URL "http://example.org/owlim#" ;
            owlim:defaultNS "" ;
            owlim:entity-index-size "10000000" ;
            owlim:entity-id-size  "32" ;
            owlim:imports "" ;
        	owlim:repository-type "file-repository" ;
            owlim:ruleset "rdfsplus-optimized" ;
            owlim:storage-folder "storage" ;
 
            owlim:enable-context-index "false" ;

            owlim:enablePredicateList "true" ;

            owlim:in-memory-literal-properties "true" ;
            owlim:enable-literal-index "true" ;

            owlim:check-for-inconsistencies "false" ;
            owlim:disable-sameAs  "true" ;
            owlim:query-timeout  "0" ;
            owlim:query-limit-results  "0" ;
            owlim:throw-QueryEvaluationException-on-timeout "false" ;
            owlim:read-only "false" ;
        ]
    ].

• das Schema liegt als Datei im volumes Ordner und wird zur Laufzeit in den Container gemountet (Dateiname: repo-config.ttl)
• dadurch könne an den Einstellungen vom Administrator Änderungen für das Erstellen der Repositories in der Datei vorgenommen werden

Request

[GET] /inputhandler/repositories

• gibt die Namen aller Repositories aus

[GET] /inputhandler/namespaces/repository/{repo}

• gibt alle Namespaces in Form von URI und Präfix zurück, die in einem Repository verwendet wurden
• kann z.B. vor dem Updaten oder Löschen von Triplen genutzt werden, um die dafür benötigten URI's zu erhalten

[GET] /inputhandler/geometry/tinVersion/repo/{repo}

• gibt bei Eingabe einer TIN ID deren Version und, wenn vorhanden, die ID des orignal TIN zurück
• Eingabe der TIN ID als Path Variable

[GET] /inputhandler/geometry/tinAllVersions/repo/{repo}

• gibt alle TIN Versionen aus, die mit der eigebenen in Verbindung stehen

[GET] /inputhandler/geometry/tinInfos/repo/{repo}

• gibt alle in GraphDB gespeicherten Informationen zu einem TIN zurück
• Eingabe der TIN ID als Path Variable

[GET] /inputhandler/geometry/tinBreaklines/repo/{repo}

• gibt die Bruchkanten ID's der im TIN enthaltenen Bruchkanten zurück
• Eingabe der TIN ID als Path Variable

[GET] /inputhandler/geometry/dimension/repo/{repo}

• gibt di Dimension eines bestimmten Geometrieobjektes im repository zurück
• Angabe der IRI des Geometrieobjektes