Daten Dump / bulk download

[akuckartz]

Wie kommt man am einfachsten an alle Daten auf einmal?

[akuckartz]

Rekursiv

[akuckartz]

Ich öffne dieses Issue aus verschiedenen Gründen wieder. Dazu gehört, dass last_modified nicht von allen RIS unterstützt wird, eine hohe Server-Belastung durch unzählige rekusive Abfragen sowie die überschaubaren Datenmengen (ohne Dateien) selbst bei großen Kommunen. Nicht zuletzt ist die Spezifizierung nicht besonders aufwändig.

[akuckartz]

Siehe auch #104

[akuckartz]

Damit die Datenmenge überschaubar bleibt, ist es wichtig, dass nur die Metadaten enthalten sein sollen, also keine Dateien (PDF etc.). Dies gilt wohl auch für entsprechende Texte der Eigenschaft text von oparl:Document-Objekten.

[marians]

Zwei Anmerkungen:

• Ich halte einen Full Dump persönlich für nicht besonders erstrebenswert
• Die Anforderung für Server-Implementierer könnten enorm sein.

Aus dem zweiten Grund kann es keine zwingende Anforderung sein. Damit glaube ich nicht, dass viele das implementieren werden. Also könnten wir es für auch 1.0 gut weglassen und uns die Mühe sparen, das zu spezifizieren.

[akuckartz]

Die Anforderung sollte einfach umzusetzen sein. Eine Implementierung kann z.B. aus einem OParl-Client ohne GUI bestehen, der regelmässig auf dem Server läuft und die externe Netz-Bandbreite nicht belastet.

[akuckartz]

Das Gesamt-Beispiel ist in einem entsprechenden Format:
https://github.com/OParl/specs/blob/master/example/ris.example.org.jsonld

Wesentlich ist die Verwendung von @graph. Eventuell sind noch weitere Angaben, insbesondere ein Datum, zu ergänzen.

[akuckartz]

Falls zwei Eigenschaften als owl:inverseOfdeklariert sind, dann sollte in einem bulk file aller Daten eine der beiden Eigenschaften ausreichen, da die jeweils andere durch einen Client mittels Reasoning ergänzt werden kann. Anders sieht es möglicherweise bei einem Teildump nur einer Klasse aus.

Siehe #118

[akuckartz]

Siehe Beispiel "Example 49: Identifying and making statements about a graph" aus http://www.w3.org/TR/json-ld/#named-graphs

{
  "@context": {
    "generatedAt": {
      "@id": "http://www.w3.org/ns/prov#generatedAtTime",
      "@type": "http://www.w3.org/2001/XMLSchema#date"
    },
    "Person": "http://xmlns.com/foaf/0.1/Person",
    "name": "http://xmlns.com/foaf/0.1/name",
    "knows": "http://xmlns.com/foaf/0.1/knows"
  },
  "@id": "http://example.org/graphs/73",
  "generatedAt": "2012-04-09",
  "@graph":
  [
    {
      "@id": "http://manu.sporny.org/about#manu",
      "@type": "Person",
      "name": "Manu Sporny",
      "knows": "http://greggkellogg.net/foaf#me"
    },
    {
      "@id": "http://greggkellogg.net/foaf#me",
      "@type": "Person",
      "name": "Gregg Kellogg",
      "knows": "http://manu.sporny.org/about#manu"
    }
  ]
}

EDIT: Im Gegensatz zu dem Beispiel ist als Zeitstempel-Datentyp besser xsd:dateTime geeignet - wie in der PROV-Ontologie.(http://www.w3.org/TR/prov-o/#generatedAtTime). Eine Alternative ist eventuell dcterms:W3CDTF (siehe auch OpenGovLD#109).

[akuckartz]

Ein bulk download kann als basic Linked Data Fragment (#165) angesehen werden, bei dem weder object noch predicate oder object festgelegt sind.

[akuckartz]

Ich hatte dieses von mir angelegte Issue am 4.7.2014 etwas übereilt geschlossen. Der Grund war nicht etwa, dass ich Daten Dumps nicht mehr für sinnvoll, notwendig und einfach zu implementieren halte, sondern der durch die Abwendung von JSON-LD erhöhte Aufwand.

[eFrane]

Datendumps sind mit OParl 1.0 durch einfaches rekursives durchlaufen aller Verknüpfungen ausgehend von System trivial.

[akuckartz]

@eFrane

Datendumps sind mit OParl 1.0 durch einfaches rekursives durchlaufen aller Verknüpfungen ausgehend von System trivial.

1. Das ist so zwar einigermaßen trivial zu implementieren, aber - wie bereits in Daten Dump / bulk download #64 (comment) kommentiert - praktisch unbrauchbar.
2. Auch der Workshop am 1.4.2015 hat sich dieser Auffassung offenbar angeschlossen.

Ich bitte also darum, dass dieses Issue wieder geöffnet wird.

/cc @lu-j