TBD: Add a formal "custom" placetype

[straup]

This is mostly so that non-core data repositories (for example SFO Museum) can use a well-known wof:placetype value for records that don't have a formally recognized placetype but continue to work with tools that enforce strict (placetype) validation.

Possible ancestor trees could be a) none or b) everything. I am not sure which makes the most sense but I am leaning towards (a) since it enforces the idea that operations involving custom placetypes (for example constructing hierarchies) are left entirely to the bespoke tooling for that dataset and are not handled by any core WOF tooling.

Thoughts @nvkelso @stepps00 @vicchi @tomtaylor ?

[stepps00]

I like the idea. A custom placetype is less-important for WOF admin and venue repositories (but maybe helpful in the future for some campus-style places?), but I'm interested in supporting such a placetype.

I'd only be concerned with impacts to WOF's current export and PIP tooling, but that seems like it could be addressed pretty simply.

[nvkelso]

I'm good with (a) no default hierarchy. Or another way of saying that is optional hierarchy – since sometimes we would be setting these things. But it's up to the author to configure that and others shouldn't expect it to be there?

[thisisaaronland]

I think I was unclear in the original proposal. What I meant was whether or not there should be anything in the wof:parent property for the "custom" placetype definition. For example:

{
    "wof:id": 12345,
    "wof:name": "custom",
    "wof:role": "optional",
    "wof:parent": [  ],
    "wof:concordances": {
    }
}

That property is used by the code that builds hierarchies but to @nvkelso 's point I think these details should be left to individual projects and not anything that "core" WOF tries to handle.