No identifier for a 'project' in code.json?

[CanDoAnything]

Should there be an identifier for a 'project' similar to how it is in open data? We have data assets where the name has changed, but the identifier has remained the same. I imagine the same happening with 'projects' for the open source initiative.

[mattbailey0]

Good idea. I've seen that use case a lot. The reverse also happens - a new sysetm is developed but is given the same name as the legacy system for the purpose of operational continuity.

Given the namespacing provided by the agency: and organization: (both strings but very easy to ensure are effectively UIDs, would it be reasonable to ask agencies to just assign these manually in their own context - i.e. there would be a repository "1" at GSA and another unrelated one at, say, Interior?

Also, I'd be concerned with the mechanism for ensuring these don't get arbitrarily reassigned over time, so that when the string associated with an ID changes it is safe to assume that it's the same system.

[ckaran]

An alternative is is to use actual UUIDs. On OS X and linux, there is the uuidgen utility, which generates UUIDs in the format specified by RFC 4122. UUIDGEN.exe should do the same under Windows (I'm unable to test this as I don't have the development tools installed).

The advantage of using actual UUIDs is that there is no need for a central authority to maintain control; developers can simply create their own at the start of a project, and then never touch the ID again. In addition, since UUIDs have no special meaning to human beings, there won't be any particular urge to change the UUID when the agency or organization's name changes. That should handle the problem os reassignment from above.

[DanielJDufour]

Great point to discuss. Our schema has upgraded and stabilized on 3.0. We'll discuss this issue again during the next major schema upgrade, but that won't be for a while though. We try not to change it up on folks too quickly.