kebab-case instances implemented

[lukeshope]

Thanks for this Si. Couple of high-level things to consider (the detail looks fine):

Should instances fall under a different prefix, or be separated into different documents altogether?

There's a part of me that's uneasy about the blending of conceptual matters (e.g. uo:Sensor) with instances (e.g. uo:earth-atmosphere). The former is more typical for the contents of a vocabulary, while the latter should potentially exist in a cross-UO API rather than a vocabulary. Hopefully that makes sense...

Essentially, I'm asking if it should be more along the lines of:

• Sensor: https://standards.urbanobservatory.ac.uk/latest/ns#Sensor
• Earth atmosphere: https://api.urbanobservatory.ac.uk/feature-of-interest/earth-atmosphere

Should we include this in the main standards doc as guidance for other implementations?

I think so.

[SiBell]

I agree.

So next question is how we implement this. In particular how we add new definitions.

I was going to offer to create a web app and microservice to manage this, because I've basically already done it for Birmingham specific stuff (screenshot below), but actually it's probably overkill and simply creating JSON files on here for each of the classes, e.g. units.json, observable-properties.json is almost certainly good enough.

If you agree I'll start creating these extra JSON files.

[lukeshope]

I think that works. Just to be clear - you're suggesting we have JSON files on here for the various instances, and then presumably an Express/similar server will serve them up at the appropriate URLs?

[SiBell]

Yer exactly.

User goes to:

https://api.urbanobservatory.ac.uk/units

An ExpressJS server retrieves the JSON from:

https://raw.githubusercontent.com/urbanobservatory/standards/master/docs/latest/instances/unit.json

... for example, or a cached version, and serves it to the user as JSON.

If the user asks for a specific unit, e.g. degree-celsius then ExpressJS just pulls this out of the JSON file.

As tempting as it is to start using a common database, e.g. so we can add some validation, my worry is that one of us then has to manage and maintain this single point of truth. To me having github as the single point of truth would work nicely and we can just use github's access controls to decide who can and can't edit it.

The reality is I'll probably periodically pull these JSON files into my own database for efficient access to a single instance, but the point is that each observatory is free to decide whether they want to to something similar or not.

I'll go ahead and create these instance JSON files on this case-change branch and you can see what you think. My feeling is that I don't need to bother with any metadata/context at the top of files? It can just be an array of objects.

[SiBell]

Okie dokie I've implemented this in 60522de7d8f47d3409f8c5af509609ba2d9d4f5b. Let me know what you think.

Here's a link to JSON files. The original JSON file is certainly a lot smaller now, although if we plan to add all the sosa and ssn terms we've used (but with a uo: prefix) it'll soon grow.

[lukeshope]

This looks good to me. I've opened #33 which is now required to handle the single compact IRI uo: prefix.