OpenGovLD vs. OParl

OpenGovLD was forked from OParl. The list below contains some of the reasons why OpenGovLD is a separate project. In spite of this OpenGovLD is collaborating with OParl as far as this helps 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 one is an exception):

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

• Project state: OpenGovLD is a living project. On 2014-11-08 there had been no changes of the unreleased OParl specification document for about 4 months. This abrupt change of speed at the end of June, beginning of July 2014 essentially coincided with the decision of a former OParl developer to drop out of OParl and create the OpenGovLD-project.

• JSON-LD: OpenGovLD is JSON-LD, OParl is pure 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

• Governance: OpenGovLD will adopt simple governance rules based on W3C expertise, governance of OParl is not defined, https://github.com/OParl/specs/issues/237 which already has led to transparency issues https://github.com/OParl/specs/issues/225

• 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.