search

OParl / spec

Spezifikation für eine offene Schnittstelle für Ratsinformationssysteme
https://oparl.org
Creative Commons Attribution Share Alike 4.0 International
61 stars 21 forks source link

URL-Parameter für Methodenaufruf #30

Closed marians closed 10 years ago

marians commented 11 years ago

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:

http://einris.de/api/sessions?public=1

Was spricht dagegen? Welche bessere Möglichkeit gibt es?

(Die Diskussion wurde schon in #13 begonnen und nun in ein eigenes Issue ausgelagert.)

akuckartz commented 11 years ago

Dies sollte in Zusammenhang mit #12 behandelt werden.

akuckartz commented 11 years ago

Es geht hier allgemein um eine Abfragesprache / query language.

akuckartz commented 11 years ago

http://code.google.com/p/linked-data-api/wiki/API_Query_Parameters

akuckartz commented 11 years ago

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.

http://json-ld.org/spec/latest/json-ld-framing/

akuckartz commented 11 years ago

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.

akuckartz commented 10 years ago

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

akuckartz commented 10 years ago

Workshop: MUST Anfangs und Ende-dateTime als Parameter für Filter. Relevant für Sitzung: Termin, Drucksache: Freigabedatum.

akuckartz commented 10 years ago

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 ;-)

marians commented 10 years ago

Wurde heute nochmal im Workshop diskutiert, mit dem Ergebnis, dass es bei den Start- udn EndDatum-Parametern bleibt.

marians commented 10 years ago

Hier gibt es keine offenen Aufgaben mehr.