Lifecycle issues

[davidread]

Public bodies change frequently and it would be good to agree how to deal with this. I think having a sense of permanence for URLs is useful, so I suggest:

Suggest:

• URLs for a body must never change
• Title should not change. If a body changes its name then it should be handled as if it died and a new one was created.
• When a body dies it should be marked as inactive.
• If a body takes over the main role of a previous body, then the old body should have a 'redirect' to the new body stored with it.
• If a body's abbreviation or other property changes then that is ok (e.g. DBIS -> BIS)

[rufuspollock]

Really good suggestions. Suggests we add a status field to our csvs and agree some enumerations. Big +1 on this.

[jpmckinney]

Change management is very hard. Easier to just aim to represent the "current state of affairs." The data sources publishing information on public bodies in the vast majority do not communicate any information about changes, so I wonder how any of these changes will be tracked. Going through the proposal:

URLs for a body must never change

I'm happy with this rule, but URLs should not contain the names of bodies, because names can change.

Title should not change. If a body changes its name then it should be handled as if it died and a new one was created.

Departments in the Government of Canada regularly rename according to the whims of the current government. It doesn't make sense for an entire department to be represented as being dissolved and a "new" department to be represented as being founded as the result of a simple name change.

When a body dies it should be marked as inactive.

There is no "inactive" body as the result of a renaming. On the other hand, if a body is in fact dissolved, then marking it as inactive makes sense.

If a body takes over the main role of a previous body, then the old body should have a 'redirect' to the new body stored with it.

I don't think this makes sense. Bodies very rarely take over the roles of other bodies very cleanly. Sometimes, the roles are distributed among several bodies. Sometimes, some roles are not adopted by any other body, while others are. I think you can at most say "see also". A redirect suggests identity, or something close to it, and this is hardly ever the case in the use case described.

[bill-anderson]

Is it worth categorising reasons for name changes? Cosmetic, merger, spin-off, functional...

Redirects may indeed be too simple, but being able to follow a trail is essential: both backwards from a current body and forward from a redundant one.

[jpmckinney]

Does anyone have an example where a data source provides this information? I've never seen that so far. Do we expect maintainers to do the change tracking, e.g. by reading news articles about public bodies undergoing name changes (assuming such changes are newsworthy) or by tracking legislation (assuming such legislation is available in that country)?

Most of the use cases I know of for this dataset have to do with the present: sending FOI requests, reconciling a current list of public bodies, etc. Before we put too much time into historical features, what are the popular historical use cases?

[davidread]

I agree that we need to not go crazy with lots of historical stuff - it could spiral and is a different use case, although simply tracking killed public bodies would be most helpful.

To give some examples of where the info comes from, in the UK we recently had a 'bonfire of the quangos' where a public document clearly laid out which public bodies were to be killed and to which body any remaining work was going to be reassigned.

Aside from that sort of thing, the best source of info about the status of public bodies that I've found is wikipedia. The info about previous names, the major changes to them etc. is usually there and easier to find than trawling through press releases or legislation, although they would be the fall-backs.

A key use case I have is looking for an organisation like 'British Cycling' or 'British Waterways' and wondering why they aren't in the list. They got killed. The former's work was essentially dropped. The latter was converted into a charity called 'Canal & River Trust', with the same remit. So rather than deleting these two from the dataset, it would be very useful to keep them, but mark them inactive. It would be a bonus to store extra data saying what happened to them, but I can see that could be a can of worms that is worth dropping from our model, although a simple name-change seems a useful thing to record.

Actually, the FOI and Reconcilliation use cases that @jpmckinney mentions would both benefit from telling the user that these no-longer exist, rather than the user thinking they are simply missing from the system.

@bill-anderson mentions following the trail of body name changes in both directions. I guess this might be a function of the web-app, but the data model only needs the links in one direction.

Just having a field 'became' or something might suffice, and the instructions for the field being 'if the body is inactive and replaced by a broadly similar body, then put the name/ID of it in this field.'

[jpmckinney]

Adding a status field and some fields to describe changes sounds fine.

The Registered Organization Vocabulary uses the term "orgStatus".

The Organization Ontology has a section on transformations, and uses the term "resultingOrganization". Change events can contain notes using the property rdfs:comment.