timgdavies
commented
7 years ago This has also come up with US-EIN, where EINs for non-profits can be searched in one place, for listed companies in another, but where private firm EINs might only be available from the organisations direct.
Option 3 is definitely out, as we should aim for only one prefix for each identifier 'series' (ah - we thought moving from the language of 'Registration Agency' -> 'List' would solve problems... but then it turns out some identifiers are split across 'lists' even if from the same 'series'!)
Option 2 I think is the best option both short and medium term - as even if we allow multiple URLs, there will be cases (like the SEC case above) where we need to explain which list to use when.
Option 1 I think could factor into the next refresh of the full codebase, potentially with some care taken to make sure we don't impact on existing consumers of the raw files.
Would you be up for having a go at (2)? You might want to look at some of the other tickets about what we display to users (and some of the issues with current data we need to fix up for consistency too).
On Tuesday, September 19, 2017, Bob Harper notifications@github.com wrote:
We had an issue recently in finding that there are certain types of organisation in Italy that, though they have a tax number ('Codice Fiscale'), they do not appear on the Register of Businesses.
However, we did find another list which included some of those organisations along with the same identifier.
I had put this information (about the second list) into access.onlineAccessDetails. The Business Register (let's call it the primary list) took the url. However, the online access details are not currently displayed on org-id.guide and I therefore included the access information for the secondary list in access.guidanceOnLocatingIds as well so that it would be available to users.
If this presents a problem (of having the same identifier in more than one accessible location) there are a few possible solutions:
- Change schema so that multiple urls can be added
- Make changes to the org-id app so that onlineAccessDetails are displayed
- Divide the identifier across multiple lists, one for each online location
The first option might lead to issues with existing code, and is not as straightforward to manage. The second option strikes me as the easiest and most logical solution, but is it the best long term solution? The third might create problems where we have the same identifier but with different prefixes referring to the same organisation.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/org-id/register/issues/66, or mute the thread https://github.com/notifications/unsubscribe-auth/AAU6YOL4508pkp08U_YwboDTHyZgKnP-ks5sj89lgaJpZM4PcfA0 .
--
w: http://www.timdavies.org.uk | m: 07834 856 303 | twitter: timdavies
Co-director of Practical Participation: http://www.practicalparticipation.co.uk
Practical Participation Ltd is a registered company in England and Wales -
We had an issue recently in finding that there are certain types of organisation in Italy that, though they have a tax number ('Codice Fiscale'), they do not appear on the Register of Businesses.
However, we did find another list which included some of those organisations along with the same identifier.
I had put this information (about the second list) into
access.onlineAccessDetails. The Business Register (let's call it the primary list) took theurl. However, the online access details are not currently displayed on org-id.guide and I therefore included the access information for the secondary list inaccess.guidanceOnLocatingIdsas well so that it would be available to users.If this presents a problem (of having the same identifier in more than one accessible location) there are a few possible solutions:
onlineAccessDetailsare displayedThe first option might lead to issues with existing code, and is not as straightforward to manage.
The second option strikes me as the easiest and most logical solution, but is it the best long term solution? The third might create problems where we have the same identifier but with different prefixes referring to the same organisation.