W3C home > Mailing lists > Public > public-opengov@w3.org > March 2013

RE: Introductions

From: Dan Melton <DanM@granicus.com>
Date: Wed, 20 Mar 2013 16:39:00 +0000
To: "public-opengov@w3.org" <public-opengov@w3.org>
Message-ID: <496935BDA26A834B8C28798C3617E0E70BA2FA40@MBX021-W3-CA-5.exch021.domain.local>
Hi Everyone,

I'm Dan Melton, deputy CTO at Granicus. Previously, I worked as the CTO for Code for America. At Granicus, we're publishing data for about 1000 govt's across north america for public meetings. We plan to extend that in the next few months, and I am very interested in mapping to this standard for interoperable data.

At the moment, I'm focused on the process of creating unique ids for jurisdictions/organizations and would love thoughts on the topic, or pointers to resources.

We have a particular challenge in our data, in that, we maintain data on all levels of government, including special districts, school districts etc.  Rather than assigning an internal granicus id to special district X, I'm curious if anyone has ideas around a country-subregional-id-model or some other paradigm to approach the problem?  I've been using the fips info for the US and am tackling Canada shortly…so plan to use the official designation id from CA gov.

I see the standard has several types of identifiers (DUNS, TIN) in the proposed spec, which could work, but as a data provider, maintaining a multi-national set of unique identifiers gets a little more difficult (nonuniques ids across different types of sources)..totally doable though, but is there a country or other such code we might append/prepend to the identifier (USA-FIPS-45678, or USA-DUNS-34456-3211)?

Also, should we be using a private corporation's record identifier (DUNS) or the federal government designation of the country? I.e. IRS or FIPS for the US?

The main question is, should we provide guidance on the main id to encourage cross compatible look ups? Or just rely on identifier block matching?

Thoughts?

Thanks
Dan
Received on Wednesday, 20 March 2013 21:07:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:38:53 UTC