Add owner key

[the-metalgamer]

This object is to the describe the owner association, if it is different from the space name. For example our space "Chaosstuff" is run by the local CCC, Chaos Computer Club Lëtzebuerg. So it would be good to include this information in the spaceapi.

This might also be useful in the future, if an association runs multiple hackerspaces and every space would have it's own spaceapi to show the opening status. With this apps could link those spaces together for example.

[dbrgn]

We actually discussed this with @gidsi. A general is-part-of relation would be great (maybe also multiple), but I'm not sure whether owner is the right approach.

[the-metalgamer]

The relation is just a nice side-effect.

For me it is more important to represent ownership/run-by in the spaceapi.

[gidsi]

Sounds interesting! But i dont fully understand what do you want to achieve, what do i do with the information as a consumer? Do you want to tell who legally owns the place or is it more like "We have five buildings and they should all have their own spaceapi"?

Fyi: I think "run-by" sounds much nicer than "owner"

[the-metalgamer]

Both.

This information would be used to describe who manages the space, because this is sometimes different from the space name and a consumer could use this information to get more information about that organisation.

The second thing is, that, if an organisation has more buildings, every building would have his own opening status.

[the-metalgamer]

Any update on this? Should it be changed?

[dbrgn]

I still think it's a bit unclear what "owner" means. I still think a more generic is-part-of relation would be better. But it would need some more discussion on what we want to achieve and what the spaces actually need for the specification to work.

Do any of the current spaces use nonstandard fields to link to an owner?

[gidsi]

The "is-part-of" attribute would be a bit different from this in my opinion, for instance, the hackerspace of the CCC Essen is part of the CCC (obviously) and the Freifunk Rheinland. But the space itself is run by (in term of legal owner) the foobar e.V. which it is not a part of.

I think we're going into pretty fine details about what is what (is the SpaceApi file the space or the organisation? etc.) and im pretty sure every space handles this completly differently. Questions, i think, that can't be answered right now. I would pull this into the draft until we have a better solution for it (which might not come up).

I don't know of any space that makes use of this right now.

Never the less, i'm still not happy with the word "owner", "run_by" sounds way more appealing and less confusing (e.g. the rooms and therefore the space can be owned by a different legal party than it is run by).

[dbrgn]

I would pull this into the draft until we have a better solution for it

Putting something into a standard always comes with compatibility issues, so I'd stick with non-standard fields (using EXT_owner is possible right now) until we're sure that it's useful to many hackerspaces.

[the-metalgamer]

For now I think it's better to use EXT_owner until we are clear what to do with it.

To be clear, this key should represent an organisation that is responsible for the space, for example if something breaks in the space, that organisation is the one to contact etc... So as @gidsi said the legal owner of the place. Now the question is, is there any space, where the legal owner is different from the organisation which runs the space.

I had another idea for an additional key, which would be inhabitants, that would list all organisations which live in the space (for example, a lot of spaces have a Freifunk Community which is an legal entity by itself, or some user groups). I don't know if is-part-of is the right term for that.

My initial thought was, that a lot of spaces have their own name, which is different from the organisation which runs it. And for people on the outside, don't necessarily know, which organisation is behind the space.

[gidsi]

Ah, okay, for me it's not part of the standard until we declare the actual draft as the new version. But yeah, you're right, we never talked about how we will actually do that and therefore it should be considered "in" the moment we merge it.

[dbrgn]

I think we can close this for now, since the consensus seems to be to start with ext_ fields. If this extension field is starting to get picked up by other spaces, it might be worthwhile to integrate it into the main spec.

(@the-metalgamer I hope that's correct. If not, let me know in a comment :slightly_smiling_face:)