Skip to content

OpenGovLD vs. OParl

Jump to bottom Edit New page
Andreas Kuckartz edited this page Feb 4, 2018 · 23 revisions

Recently there has been friendly communication with the people who are now developing OParl. Some of the issues below have been resolved. The text therefore is not up-to-date. 2015-08-29

OpenGovLD was forked from OParl on July 4, 2014. The list below contains some of the reasons why OpenGovLD is a separate project. In spite of this OpenGovLD tries to collaborate with OParl as far as that project is still alive. This can help to develop a common vocabulary and to help those developers interested in creating polyglot servers or clients which implement both specifications.

In any case there is no intention to denigrate anybody who contributed to OParl. And everybody who contributed to OParl did contribute at least something which is used in OpenGovLD. The following list of differences does not change this.

That being said here is a list of differences, not ordered by importance (the first ones are an exception):

  • Governance: OpenGovLD uses simple and transparent governance rules based on W3C and IETF expertise, governance of OParl is not defined, https://github.com/OParl/specs/issues/237 which already has led to severe transparency issues https://github.com/OParl/specs/issues/225 Official supporters of OParl as well as the general public are not informed about activities of the project - this includes decisions made by unknown people in announced conference calls https://github.com/OParl/specs/pull/270

  • Stakeholders: As a project of the W3C Open Government Community Group OpenGovLD is open for all stakeholders. OParl has deliberately rejected the requirements of the Linked Data community (and not even accepted an offer from one of the main authors of the JSON-LD standard) and also rejected the requirements of those interested in support for other languages than German. All in the name of a specification which is "simple" to use for non-professional programmers (but has a length of about 60 pages!) - and reducing the time to release!

  • Linked Data: OpenGovLD is Linked Data, OParl ist not, https://github.com/OParl/specs/issues/237

  • Bulk/export format OpenGovLD provides a bulk format, OParl confirmed that it does not plan to specify such a format, https://github.com/OParl/specs/issues/278#issuecomment-112318573 A corresponding OParl-issue was closed with the comment that data can be downloaded recursively, https://github.com/OParl/specs/issues/64#issuecomment-109893515

  • RESTful API: OpenGovLD is RESTful, that includes the HATEOS constraint as formulated by Roy Fielding. OParl does not satisfy this constraint (https://github.com/OParl/specs/issues/268) and requires a significant amount of out-of-band information.

  • JSON-LD: OpenGovLD is JSON-LD, OParl is only JSON (even when it is looking like JSON-LD)

  • Design: OpenGovLD attempts to base all decisions on sound technical reasons. Some technical decisions made by OParl are neither effective nor efficient to fullfil stated requirements, worse: this happened even when the unsuitability was known, https://github.com/OParl/specs/issues/226

  • ObjectType and DataType: OpenGovLD uses properties with URLs as ranges where appropriate and does not mix them with strings. OParl mixes URLs and strings (which is a problem because URLs also are strings); example: ranges consisting of strings and skos:Concept objects, originally no strings were allowed in such cases, this change was made in OParl without anyone having filed an issue https://github.com/OParl/specs/issues/212

  • Best vs. current practices: OpenGovLD is preparing the future and not just expressing current practices and limitations. On the other side attempts by OParl supporters representing vendors to restrict OParl to the status quo even when there were no technical reasons given for that were successful. One characteristic example: a long debate on wether allowing a Person in multiple Bodys is reasonable or not - in which several examples of this situation in reality had been mentioned! The decision then was that OParl 1.0 makes it impossible to express such a situation https://github.com/OParl/specs/issues/243

  • I18N: OpenGovLD supports i18n as a fundamental feature. On the other side i18n was removed from OParl although there was an explicit request to support i18n, https://github.com/OParl/specs/issues/237#issuecomment-48591285

  • Collaboration: OpenGovLD is actively interested in close collaboration with other standardization efforts on this planet. OParl even let an offer from one of the JSON-LD authors drop to the ground. He had offered to create a JSON-LD context based on the current status of OParl.

  • Global character: OpenGovLD is an international initiative. OParl in practice is (only) oriented towards German municipalities and almost unknown outside Germany.

  • Vocabulary: OpenGovLD will always provide a vocabulary which is at least as expressive as the one used by OParl.

  • Avoid need for vendor extensions: OpenGovLD is listening to suggestions from vendors and others. OParl closes such issues even when there is an announcement by a vendor to create a (technically unsound) vendor extension due to missing feature and a suggestion is submitted on how the requirement can be fulfilled in a reasonable way https://github.com/OParl/specs/issues/258

  • Version numbers: OpenGovLD does not use version numbers as marketing instruments. OParl seems to intend to claim "1.0" for something which does not even resolve all reported issues.

  • Quality: the OpenGovLD project wants to hear, know and inform about all potential issues and questions, large ones and small ones. OParl has deleted unresolved questions https://github.com/OParl/specs/pull/270 without resolving or tracking them.

  • Security: Obviously OParl data is about political material. Therefore encrypted data transfer makes some sense. But OParl mentions forwarding from https to http as an option (yes, that direction). https://github.com/OParl/specs/issues/271 And the project deleted a question asking if that is ok. But not only that. The main author praised that deletion as "looking good". https://github.com/OParl/specs/pull/270#issuecomment-71373009 Is any further comment necessary?

  • Standard Conformance: OpenGovLD does not contradict well-established standards like HTTP but is based on them. OParl prescribes the use of HTTP Status Code 200 ("OK") for deleted objects: https://github.com/OParl/spec/issues/394

Add a custom footer
Add a custom sidebar
Clone this wiki locally