Closed marians closed 10 years ago
Dies sollte in Zusammenhang mit #12 behandelt werden.
Es geht hier allgemein um eine Abfragesprache / query language.
Schon mal ein Hinweis auf JSON-LD Framing. Ich werde im Laufe der nächsten Wochen möglicherweise darauf zurückkommen. Das Abstract lautet:
JSON-LD Framing allows developers to query by example and force a specific tree layout to a JSON-LD document.
Als Query Language kommt möglicherweise auch LDPath in Frage.
LDPath is a simple path-based query language, similar to XPath or SPARQL Property Paths, that is particularly well-suited for querying and retrieving resources from the Linked Data Cloud by following RDF links between resources and servers. http://marmotta.incubator.apache.org/ldpath/introduction.html http://wiki.apache.org/marmotta/LDPath
Zu klären ist, inwieweit das "simple" sowohl für die Verwendung im Client als auch für die Implementierung auf RIS-Seite zutrifft.
Ich halte inzwischen zumindest eine informelle Empfehlung zugunsten von SPARQL für sinnvoll.
Ich vermute, dass eine strikte Anforderung in OParl 1.0 gegenwärtig nicht akzeptiert würde. Denkbar ist aber, an einer zentralen RIS-unabhängigen Stelle einen SPARQL-Endpoint für OParl-Daten anzubieten. Dafür kommen eventuell oparl.de oder govdata.de in Frage. Für govdata.de habe ich dieses Issue angelegt: https://github.com/fraunhoferfokus/GovData/issues/65
Workshop: MUST Anfangs und Ende-dateTime als Parameter für Filter. Relevant für Sitzung: Termin, Drucksache: Freigabedatum.
Ich werde mal schauen, ob ich in der Vorbereitung für den nächsten Workshop eine SPARQL-Engine mit den dann vorhandenen Beispieldaten sowie ein paar exemplarische Requests zugänglich machen kann. Dann sind manche Aspekte der Spezifikation leichter zu demonstrieren und zu prüfen. (Und eventuell kommt ja auch der eine oder andere Anbieter auf den Geschmack ;-)
Wurde heute nochmal im Workshop diskutiert, mit dem Ergebnis, dass es bei den Start- udn EndDatum-Parametern bleibt.
Hier gibt es keine offenen Aufgaben mehr.
Hier soll das Für und Wieder von und die Alternativen zu URL-Parametern bei Methodenaufrufen diskutiert werden.
Eine Möglichkeit, um beispielsweise von einer Methode
http://einris.de/api/sessions
die öffentlichen Sitzungen abzurufen, wäre:Was spricht dagegen? Welche bessere Möglichkeit gibt es?
(Die Diskussion wurde schon in #13 begonnen und nun in ein eigenes Issue ausgelagert.)