Implementation: New York City Notices

[timgdavies]

Via @mikaelmh regarding mapping of OCDS for publishing New York City Notices

No equivalent Fields in OCDS

There are a few fields for which we are unable to find the equivalent OCDS fields. How do we handle these? Could you include a suggested sample JSON-string snippet for how we should include them? (Our dilemma is that while some of these fields don’t bring any additional value for users, they are apart of the data that needs to be made available according to the law.)

Fields/value	Comments
EndDate/2014-11-20 00:00:00	- When the notices should no longer be displayed.
SectionID/6	what section it should be placed under in the paper copy of the city record
RequestedBy/someuser	- what username posted the notice internally in the system
Printout/CONSULTING SERVICES FOR ....	The text to appear in the notice. Based on the fields that are available in the database.
ConfirmationNumber/20141114011	A number assigned to the notice once it is approved.
CategoryDescription/Services other than human services	General category for the procurement process
PhoneRequested/5511234567	Internal reference for the person who posted the add.
AddressToRequest/150 William Street Room 9J2 Floor New York NY 10038	Internal reference for the person who posted the add

[timgdavies]

The best approach here looks to me to be creating a small extension to sit at the release level to describe the noticeMetaData and then using a mix of custom properties, and re-used objects from OCDS.

For requestedBy we can re-use the organization block (just using the properties you need from this), and then for most of the other sections this would need some custom properties.

At a quick sketch that might look a bit like this:

{
    "releases": [
        {
        "ocid":"",
        "date":"",
        "tag":"",
        "noticeMetaData": {
            "startDate":"",
            "endDate":"",
            "requestedBy": {
                "name":"",
                "address": {
                    "streetAddress":"",
                    "locality":"",
                    "region":"",
                    "postalCode":"",
                    "countryName":""
                },
                "contactPoint":{
                    "name":"",
                    "email":"",
                    "telephone":"",
                    "faxNumber":"",
                    "url":""
                }
            },
            "confirmationNumber": "",
            "categoryDescription":""
        },
        "...":"..."

        }
      ]
}

Using the extension model of OCDS, if this looks about right, we could put together a quick use-case and extension document - and then could put this out to the community to see if there are any other common cases where people have a need for notice meta-data, which might help us find a more general solution - but allowing you to still use this as a working model in the meantime.

What do you think?

[timgdavies]

Via @mikaelmh:

Does extension method imply adding the JSON objects under an "extension/metadata" header? Do we attach this to the record, or do you recommend that we store it separately?

This raises a good question. It would be easy to attach the new noticeMetaData object to a release using the approach above.

When compiled into a Record, which might contain information from multiple releases, then the approach above has the limitation that the noticeMetaData from the most recent release would be the only notice meta-data stored (as merging multiple releases, the most recent noticeMetaData object would overwrite past objects.

The way around this would be to:

• Turn noticeMetaData into an array, and add a releaseId property to the object
• Set-up the mergeStrategy, so that a list of different noticeMetaData objects can get built up in the record

This is a little tricky to explain in the abstract - so happy to work up an example...

[jpmckinney]

Most of these fields are internal-only, and OCDS is intended as data format for public disclosure, so most of these fields would only be considered for a local extension.

As for the others: CategoryDescription seems like a classification, for which we have fields/extensions. Many implementations would put Printout in the tender description.