Beta Release of the Open Contracting Data Standard
0 views
Skip to first unread message
Michael Roberts
Sep 4, 2014, 10:00:35 AM9/4/14
to publi...@webfoundation.org
|
| The Open Contracting Partnership is pleased to share for broad consultations the Beta Release of the Open Contracting Data Standard (OCDS). The Standard, which aims to enhance and promote disclosure and participation in public contracting, is a core product of the Open Contracting Partnership (OCP). The objective of the Data Standard is to support governments to publish contracting data in a more accessible, interoperable and useful manner and to enable the widest possible range of stakeholders to use contracting data effectively. This Beta Release of the Open Contracting Data Standard provides:
The development of the Open Contracting Data Standard is an open process and inputs and feedback are encouraged. Although this will be an ongoing process, those comments provided before September 30 will be more likely to fully inform version 1.0 of the Standard. These comments will help refine the standard, both the structure and fields, in preparation for the initial release version. You can share your comments in two ways:
We appreciate you taking the time to go through this information and helping us improve the final details of the Standard before the launch of the Version 1.0 later this year. For specific details on the process of the development of the standard please email partn...@open-contracting.com. --- The Open Contracting Data Standard is a core product of the Open Contracting Partnership (OCP). Version 1.0 of the standard is being developed for the OCP by the World Wide Web Foundation, through a project supported by The Omidyar Network and the World Bank. |
---
Michael RobertsOpen Data Technical Manager
+1 514 802 9528
@michaeloroberts | mich...@webfoundation.org
World Wide Web Foundation | 1110 Vermont Ave NW, Suite 500, Washington DC, 20005, USA | www.webfoundation.org | Twitter: @webfoundation
@michaeloroberts | mich...@webfoundation.org
World Wide Web Foundation | 1110 Vermont Ave NW, Suite 500, Washington DC, 20005, USA | www.webfoundation.org | Twitter: @webfoundation
Tim Davies
Sep 4, 2014, 11:50:52 AM9/4/14
to publi...@webfoundation.org
Hello all
Thanks for Michael for sharing this with the list. So far we've benefited from some great input and feedback from many people (not least the list you will find here of people who have made fantastic contributions at our development sprints in Montreal and Berlin: https://github.com/orgs/open-contracting/people)
I thought it might be useful to highlight a few things we would really value feedback on, and help with as we head into the next few iterations to refine towards a full release of the standard later this year. (broadly ranging from the least to the most technical...)
Thanks for Michael for sharing this with the list. So far we've benefited from some great input and feedback from many people (not least the list you will find here of people who have made fantastic contributions at our development sprints in Montreal and Berlin: https://github.com/orgs/open-contracting/people)
I thought it might be useful to highlight a few things we would really value feedback on, and help with as we head into the next few iterations to refine towards a full release of the standard later this year. (broadly ranging from the least to the most technical...)
Your use cases
If you don't feel able to dive in depth into the details of the standard at this point - we would still welcome you to share your use-cases for open contracting data on the list, and we'll try and think about and respond on how the standard might currently (or might need to develop) to meet them (and to invite others thoughts on the challenges we might still need to think about).
If you don't feel able to dive in depth into the details of the standard at this point - we would still welcome you to share your use-cases for open contracting data on the list, and we'll try and think about and respond on how the standard might currently (or might need to develop) to meet them (and to invite others thoughts on the challenges we might still need to think about).
If you have chance to do any preliminary work mapping your own data to the standard, and can help us understand strengths and weaknesses of this we would be massively grateful.
Tim
--
You received this message because you are subscribed to the Google Groups "Public OCDS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public-ocds...@webfoundation.org.
To post to this group, send email to publi...@webfoundation.org.
Visit this group at http://groups.google.com/a/webfoundation.org/group/public-ocds/.
To view this discussion on the web visit https://groups.google.com/a/webfoundation.org/d/msgid/public-ocds/594043E2-7950-444B-A278-776EA89FBFE2%40webfoundation.org.
--
--
Tim Davies
Research Coordinator, Open Data Research Network
@timdavies | @odrnetwork | www.opendataresearch.org
World Wide Web Foundation | 1110 Vermont Ave NW, Suite 500, Washington DC 20005, USA | www.webfoundation.org | Twitter: @webfoundation
Bibhusan Bista
Sep 26, 2014, 1:49:15 AM9/26/14
to publi...@webfoundation.org
Dear Michael and Tim,
First of all, I would like to congratulate you guys and the entire OC team for your effort in developing this standard. The standard is comprehensive enough to capture majority of elements that best describes the contracting process and individual contracts. It is now upto the community to see how the standard fits into different context.
At our end in Nepal, we will try to see how the standard fits into the open contracting portal (http://opencontracting.opennepal.net ) that we are piloting. Please expect some queries and confusion over next few weeks once we start testing the data we have in the pilot portal with the standard.
At the same time, i would like to bring OC community's attention to some of the points that we have going through the standard. I won't be surprised if some of these points do not make sense or have already been discussed and resolved as I had been little off touch from the discussion lately.
1. OC ID
Defining a globally unique ID for each of the OC process following the standard is definitely a the right thing to do. However, my concern is about the implementation side of it. How do we make it happen ? Will we have a central registry (similiar to IATI) that provides id for everyone ?
The way we see at the moment is that not every agency that is involved in public procurement (at least in countries like Nepal) are equipped with right knowledge, skill and incentive to adopt this process of standardising things with unique ID. We have seen cases where the ids are not consistent even within a single agency. If we consider multiple agencies, there is whole lot of confusion on it.
2. Incorporating Feedback from other systems and mechanisms
If we look at the demand side scenario, there are many third party initiatives around the world that look into monitoring projects and public procurement and provide feedback on project performance to a large extent. These may not be part of official project Monitoring frameworks and often led by civil society that provide significant insight on project efficiency and effectiveness.
For eg. we are currently rolling out Development Check as a tool for community monitors to monitor infrastructure development projects (dealing largely with public contracts issued by different agencies) together with Integrity Action. Rather than being a stand alone tool to crowdsource feedback from the community only, it is a tool used by trained monitors in different countries to provide feedback on how these infrastructure projects are doing. There are individual cases like http://www.developmentcheck.org/project-view/1603 which provide significant insight on the performance of respective projects.
In this context, i was wondering how these kind of feedback could be link up with the standard in situations where the projects/contracts follow OCDS. It would be really good if the standard could some how facilitate a process that link up to these kind of feedback for specific contracts and gives a holistic picture.
Also, I see a great value for the standard to be looking into this issue as it will eventually help bringing initiatives together and further enhance OC community in general.
Do let me know if there are any specific queries on what i've said above.
Cheers,
Bibhusan
To view this discussion on the web visit https://groups.google.com/a/webfoundation.org/d/msgid/public-ocds/CAOA4sPDgOrkZ9%2BXSiwS0_1nY%2BJ_4jDcNq976n81nT-JW6tj14w%40mail.gmail.com.
Bibhusan Bista
CEO
-----------------------------
YoungInnovations Pvt. Ltd.
GPO 8976 CPC 241
Kumaripati, Lalitpur, Nepal
Kumaripati, Lalitpur, Nepal
-----------------------------
-----------------------------
Skype: bibhusan
Twitter: @BibhusanBista
Twitter: @BibhusanBista
-----------------------------
*DISCLAIMER*
This email contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system.
-----------------------------
Willem van der Westhuizen
Sep 27, 2014, 5:34:12 AM9/27/14
to publi...@webfoundation.org
Hi Tim,
I would suggest that JSON models also be consumable in XML. There are two primary motivations
1. It is much easier for human reading, and the conversion can be fairly automated.
2. There are fairly strong schema tools available to validate the structure of data provided. When you are dealing with data interchange formats, such as the one suggested, I believe that strong schema validation capabilities are critical for data integrity.
Willem
I would suggest that JSON models also be consumable in XML. There are two primary motivations
1. It is much easier for human reading, and the conversion can be fairly automated.
2. There are fairly strong schema tools available to validate the structure of data provided. When you are dealing with data interchange formats, such as the one suggested, I believe that strong schema validation capabilities are critical for data integrity.
Willem
Ian Makgill
Sep 27, 2014, 3:35:45 PM9/27/14
to publi...@webfoundation.org
Plus one for json
--
You received this message because you are subscribed to the Google Groups "Public OCDS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public-ocds...@webfoundation.org.
To post to this group, send email to publi...@webfoundation.org.
Visit this group at http://groups.google.com/a/webfoundation.org/group/public-ocds/.
To view this discussion on the web visit https://groups.google.com/a/webfoundation.org/d/msgid/public-ocds/abddbade-b82b-4b0e-979b-b304d6cd2f5f%40webfoundation.org.
Tim Davies
Sep 27, 2014, 4:29:41 PM9/27/14
to publi...@webfoundation.org
Hello Bibusan
Many thanks for your feedback on the standard - this is really helpful.We are currently logging all the issues to address in GitHub issues and trying to propose solutions to each, and will be making a next round of revisions to the draft in early November, following an extended period for discussion in October. To respond to your specific issues below:
1. OC IDDefining a globally unique ID for each of the OC process following the standard is definitely a the right thing to do. However, my concern is about the implementation side of it. How do we make it happen ? Will we have a central registry (similiar to IATI) that provides id for everyone ?The way we see at the moment is that not every agency that is involved in public procurement (at least in countries like Nepal) are equipped with right knowledge, skill and incentive to adopt this process of standardising things with unique ID. We have seen cases where the ids are not consistent even within a single agency. If we consider multiple agencies, there is whole lot of confusion on it.
We are currently thinking along the lines of IDs being composed from a prefix, which should be globally unique to that organisation, and then the organisation appending their own string onto that prefix to get a globally unique ID for particular contracts.
We recognise organisations might have multiple 'series' of identifiers, with duplicate IDs across them, and in these cases, they would build their OCID from their prefix, an identifier for the series of contracts they are dealing with, and then an identifier for a given contract.
This of course doesn't solve the case where an organisation has one ID for a tender, a different ID for the award data when a supplier is selected, and yet another different ID for the information published about the contract, with nothing other than human-readable text linking these three bits of data together. Is this the scenario you were thinking of?
This of course doesn't solve the case where an organisation has one ID for a tender, a different ID for the award data when a supplier is selected, and yet another different ID for the information published about the contract, with nothing other than human-readable text linking these three bits of data together. Is this the scenario you were thinking of?
In these cases - there may not be a terribly easy technical solution (although some sort of reconcilation services might be able to tie together the data on different bits of the contracting process) - and it is likely to be a policy one of trying to encourage use of a shared identifier at each stage of the process. However, other ideas for solutions to this really welcome.
The work Sarah has done on converting Canadian contract data into the draft OCDS standard documented here http://standard.open-contracting.org/field-notes-transforming-canadian-procurement-data-to-ocds-format/ might be useful to reference, as, from what I understand, in this case there is not a unique identifier throughout the whole process right now, but there is enough overlap between identifiers used such that a unique contracting process can be identified, and then assigned a unique ID.
The work Sarah has done on converting Canadian contract data into the draft OCDS standard documented here http://standard.open-contracting.org/field-notes-transforming-canadian-procurement-data-to-ocds-format/ might be useful to reference, as, from what I understand, in this case there is not a unique identifier throughout the whole process right now, but there is enough overlap between identifiers used such that a unique contracting process can be identified, and then assigned a unique ID.
2. Incorporating Feedback from other systems and mechanismsIf we look at the demand side scenario, there are many third party initiatives around the world that look into monitoring projects and public procurement and provide feedback on project performance to a large extent. These may not be part of official project Monitoring frameworks and often led by civil society that provide significant insight on project efficiency and effectiveness.For eg. we are currently rolling out Development Check as a tool for community monitors to monitor infrastructure development projects (dealing largely with public contracts issued by different agencies) together with Integrity Action. Rather than being a stand alone tool to crowdsource feedback from the community only, it is a tool used by trained monitors in different countries to provide feedback on how these infrastructure projects are doing. There are individual cases like http://www.developmentcheck.org/project-view/1603 which provide significant insight on the performance of respective projects.In this context, i was wondering how these kind of feedback could be link up with the standard in situations where the projects/contracts follow OCDS. It would be really good if the standard could some how facilitate a process that link up to these kind of feedback for specific contracts and gives a holistic picture.
Absolutely. This is something we've been thinking about. There is nothing to stop a third-party publishing a 'contracting release' that provides some extra documents or data about a given contracting process (identified by its OCID), and other services then choosing to include this when they merge together all the releases to get the snapshot contracting record (again, the walk through at http://standard.open-contracting.org/field-notes-transforming-canadian-procurement-data-to-ocds-format/ might give a slightly more concrete impression of how this could work, if you imagine the third party inserting their own data into this process).
The way releases are merged into a record maintains some provenance information about where each bit of data came from, so this should help if third-parties provide services that seek to discover, and merge together all that is known about a given contracting process (or even if governments are bold enough to bring the third party content into their own records directly).
Also, I see a great value for the standard to be looking into this issue as it will eventually help bringing initiatives together and further enhance OC community in general.
It would be great to be able to test out this concept with some live examples for the prototype release in November: is it possible right now to identify the contracts that relate to a given Development Check project for example in a way that would support some exploration of this?
All the best
Tim
Tim
To view this discussion on the web visit https://groups.google.com/a/webfoundation.org/d/msgid/public-ocds/CAETyBug0EwW2Pg5wuwe4oDR2T7qvHF0GmhcouzqGzGxhVP%3DUeg%40mail.gmail.com.
Tim Davies
Sep 27, 2014, 4:35:58 PM9/27/14
to publi...@webfoundation.org
Hello Willelm,
I would suggest that JSON models also be consumable in XML. There are two primary motivations
1. It is much easier for human reading, and the conversion can be fairly automated.
2. There are fairly strong schema tools available to validate the structure of data provided. When you are dealing with data interchange formats, such as the one suggested, I believe that strong schema validation capabilities are critical for data integrity.
Many thanks for raising this. I've added an issue to the tracker at https://github.com/open-contracting/standard/issues/76 with the request for XML.
On our current roadmap this is not something we would have in place by November, but our approach has certainly been based around the idea of supporting other serialisations, each following the idioms of the respective data formats.
If there was anyone with an interest in testing out how to render the JSON model as XML - that's something we'd love to see - particularly if it helped us identify any ways the current models could be strengthened to make XML->JSON roundtrips work best in future.
On our current roadmap this is not something we would have in place by November, but our approach has certainly been based around the idea of supporting other serialisations, each following the idioms of the respective data formats.
If there was anyone with an interest in testing out how to render the JSON model as XML - that's something we'd love to see - particularly if it helped us identify any ways the current models could be strengthened to make XML->JSON roundtrips work best in future.
On schema validation, Sarah has done a lot of work with JSON-Schema to check that we can validate the structure of data provided, and whilst not as advanced as XML validation tools, this appears to be robust enough for the initial release of the standard. You can find and test the validator at http://ocds.open-contracting.org/validator/ if you are interested - and the full JSON Schema is at https://github.com/open-contracting/standard/tree/master/standard/schema
All the best
Tim
Willem
On Thursday, September 4, 2014 4:00:35 PM UTC+2, Michael Roberts wrote:![]()
![]()
The Open Contracting Partnership is pleased to share for broad consultations the Beta Release of the Open Contracting Data Standard (OCDS).
The Standard, which aims to enhance and promote disclosure and participation in public contracting, is a core product of the Open Contracting Partnership (OCP). The objective of the Data Standard is to support governments to publish contracting data in a more accessible, interoperable and useful manner and to enable the widest possible range of stakeholders to use contracting data effectively.
This Beta Release of the Open Contracting Data Standard provides:
- A description of the overall Open Contracting Data Standard Model, and
- A JSON Schema for open contracting releases and records that includes a set of recommended fields.
The development of the Open Contracting Data Standard is an open process and inputs and feedback are encouraged. Although this will be an ongoing process, those comments provided before September 30 will be more likely to fully inform version 1.0 of the Standard. These comments will help refine the standard, both the structure and fields, in preparation for the initial release version.
You can share your comments in two ways:
- Inline comments on the document - Log in to the Open Contracting Data Standard Github site and then highlight portions of text to add comments. To "reply" to an existing comment, highlight the same portion of text, and then add your comment. See instructions at the top of the Github login page for more help on commenting.
- Mailing list - If you have more general comments that don't fit well as inline comments, please join the OCDS mailing list and start a discussion with your thoughts.
We appreciate you taking the time to go through this information and helping us improve the final details of the Standard before the launch of the Version 1.0 later this year.
For specific details on the process of the development of the standard please email partn...@open-contracting.com.
---
The Open Contracting Data Standard is a core product of the Open Contracting Partnership (OCP). Version 1.0 of the standard is being developed for the OCP by the World Wide Web Foundation, through a project supported by The Omidyar Network and the World Bank.
---Michael RobertsOpen Data Technical Manager+1 514 802 9528
@michaeloroberts | mich...@webfoundation.org
World Wide Web Foundation | 1110 Vermont Ave NW, Suite 500, Washington DC, 20005, USA | www.webfoundation.org | Twitter: @webfoundation
--
You received this message because you are subscribed to the Google Groups "Public OCDS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public-ocds...@webfoundation.org.
To post to this group, send email to publi...@webfoundation.org.
Visit this group at http://groups.google.com/a/webfoundation.org/group/public-ocds/.
To view this discussion on the web visit https://groups.google.com/a/webfoundation.org/d/msgid/public-ocds/abddbade-b82b-4b0e-979b-b304d6cd2f5f%40webfoundation.org.
--
--
Tim Davies
Research Coordinator, Open Data Research Network
@timdavies | @odrnetwork | www.opendataresearch.org
World Wide Web Foundation | 1110 Vermont Ave NW, Suite 500, Washington DC 20005, USA | www.webfoundation.org | Twitter: @webfoundation
Friedrich Lindenberg
Sep 27, 2014, 5:15:16 PM9/27/14
to publi...@webfoundation.org
+1
To view this discussion on the web visit https://groups.google.com/a/webfoundation.org/d/msgid/public-ocds/CAFh8OXEMmkDpKnAth49XkkRwUCGTUqPFUL_Ma-jRvttcP1HjuQ%40mail.gmail.com.
Sarah Bird
Sep 30, 2014, 8:08:39 PM9/30/14
to publi...@webfoundation.org
Hi Willem,
Regarding validation. We have a validator up here: http://ocds.open-contracting.org/validator/validate/It uses the validation library: https://github.com/Julian/jsonschema
however, there are many json schema validation libraries - 28 are listed here http://json-schema.org/implementations.html - so you do not have to use our validator.
Sarah Bird
--
You received this message because you are subscribed to the Google Groups "Public OCDS" group.
To unsubscribe from this group and stop receiving emails from it, send an email to public-ocds...@webfoundation.org.
To post to this group, send email to publi...@webfoundation.org.
Visit this group at http://groups.google.com/a/webfoundation.org/group/public-ocds/.
To view this discussion on the web visit https://groups.google.com/a/webfoundation.org/d/msgid/public-ocds/abddbade-b82b-4b0e-979b-b304d6cd2f5f%40webfoundation.org.
--
Aptivate - Ethical IT for International Development
Aptivate | http://www.aptivate.org | Phone: +44 1223 967838
Citylife House, Sturton Street, Cambridge CB1 2QF
Aptivate is a not-for-profit company registered in England and Wales
with company number 04980791.
Reply all
Reply to author
Forward
0 new messages