List of Capabilities/Tools/Machines

[moritztim]

Inspired by the "This Hackerspace has a ..." in the Hackerspaces wiki, an array of predefined and/or custom tools/machines/capabilities would be nice to have. Maybe each of them could have a wiki link and a type property.

[moritztim]

An example of such a tool is a 3D Printer, which Foulab has.

[s3lph]

Generally sounds good to me. I'm a bit concerned about the set of predefined values though:

• When wiki.hackerspaces.org, which you use here as inspiration, wants to add a new type of equipment, they can simply create a new wiki page and can start using it as an SMW attribute target. wiki.hackerspaces.org benefits from the SMW graph database approach here, where the possible values are also just nodes in the same graph, as well as having only THE ONE wiki.hackerspaces.org SMW schema, which doesn't really have to coordinate with anyone else.
• SpaceAPI as a specification for a decentralized standard being implemented by lots of different endpoints and clients, which don't necessarily (and in practice often don't) agree on the same version of the schema, doesn't have the luxury of "simply just adding new values to the list". We could only extend the predefined list by releasing a new version of the specification, so any changes to such a predefined list would be rather slow (months to years) to land in the standard, in endpoints and in clients.
• Furthermore. The only way we could provide a normative list of predefined values using JSONSchema would be to have an attribute with an enum specification with the allowed values set. This would however require that ONLY these values be used, any additional values would cause the endpoint to not validate. Anything else only allows us to provide the predefined list in the human-readable description of fields.

So as much as it pains me, I currently don't see a way how we could model such a predefined but extensible list using JSONSchema. (@SpaceApi/core feel free to correct me if I missed something and this is possible after all)

Having said that, I could imagine this new feature to look somewhat like the following:

{
    "space": "Chaos Computer Club Basel",
    // ...
    // The term "equipment" used by wiki.hackerspaces.org for their implementation sounds the most fitting to me
    "equipment": [
        {
            "description": "Bambu Lab P1S",
            "type": "3D Printer",
            "url": "https://wiki.ccc-basel.ch/index.php/Bambu_Lab_P1S",
        },
        // ...
    ],
    // ...
}

@moritztim @SpaceApi/core Are there any properties you'd like to see in this new field apart from description, type (on second thought: do we actually need both or would one suffice?) and URL?

[dbrgn]

We could use a string field, and simply refer to the type definitions in the hackersapces.org wiki?

[moritztim]

Yeah, the predefined list isn't really a future proof approach... I think a good way of unifying it is to add an optional but encouraged field for a hackerspace wiki article path. This way, it stays virtually up to date with the wiki. The field could even be mandatory, and you'd just have to create a new article for a new type of device... but maybe that's too limiting (and takes away some of the decentralization).

As for fields, I think some type of access property would be nice, to convey wether the tool can be used by anyone, requires prior instruction or is restricted in other ways. I will look into that tmr. Also, the url of the manufacturer's product page could be useful, along with a model identifier. A photo wouldn't hurt either.