Turning the rules of government into code using OpenFisca

OpenFisca helps people turn law into software. So it's one of the tools-- it's a platform-- that enables computational law to happen. So I'll just give you a couple examples rather than talking in detail about what computational law is. If you just go to openfisca.org, it works like this. And there are a couple of examples.

One of the first examples is to calculate people's rights. We'll go to more detail right after. But first, this is an example of-- so it's in French, but you don't need to understand French. The stuff that's greyish are inputs. And it's about a company that has a number of employees and some status in which is these employees are hired.

And you can just vary how many hours these employees are paid for, how much is their gross salary, and you can get, as you can see, a nice UI that tells you just how much paying that person is going to cost you with all rebates and taxes included, and how much that person is going to actually get in terms of net income. And you can then have all the details of exactly which taxes were paid, for what, to whom.

So that's an example of a tool that makes law computable. It uses it. You just described something, and it tells you what your rights should be. No need for an accountant. The computer is the accountant here. Very simple.

This works for companies, but computational law can also be applied for individual situations. So here I'm going to go a bit more into details and show you a benefits entitlement tool that was made in France, for which I was the product manager for awhile. And I'm going to translate it into English so you don't have to understand it all. The translation is fully automatic by Google translate, so if some words are off. Sorry about that. I don't think you need all the details. But I'll walk you through that so you can get an idea of what it is that we're talking about.

So I'm a person who is born on the 12th of December. I'm French. I'm not a student. Let's say that I am disabled, and I'm very highly disabled. So I'm going to make a situation that illustrates just how many benefits I can get. So I'm going to go way to the extreme here.

So I go further. Let's say that I also have a kid that is born in 2000, and they are on my tax return. And so, we'll do that. I have a kid.

And I live alone. It's been very recently that I've been living alone. Someone just opened their microphone. If you can please switch it off. Or if you have something to say because I cannot see the camera, so if you can just switch your microphone on if you have something to say, or otherwise, please keep it off. Thanks.

And I'm tenant in my house. Is not a shared accommodation. My landlord is not my father or anything. We can go a bit quickly here-- no need to have all the details. I pay some amount here. So I pay 800 euros a month for this-- I understand it might be numbers that are not so familiar for Kiwis to just pay a monthly amount that's under 1,000 for accommodation, but it actually has happened in some parts of the world.

[LAUGHTER]

So I have a salary. and I might as well also be an interpreter. So I also have some business income. I earn 1200 euros a month. And last year I made 900, just because I did a couple of things here and there, every now and then.

No, my child is not working yet. And I have not paid alimony. That's it. Let's see what we have here. Wow, I have quite a few benefits that I am entitled to.

So what I'm seeing there is, to me as a user, the result of the computation that I did not have to think about all. I just talked about myself. I just filled my personal situation, the situation of my family. Yet, I was presented with a result that goes cross-agency.

Here, every single item that you see is the action of the different agency. So without such a tool, I would have needed to know each agency that could give me some benefits, to know at least the name of the benefit I would likely apply to, and perhaps even need to have a basic understanding of the rules that would be applied to my case to decide if it's worth sending the data form or not. And here, just under five minutes, I was able to define which benefits it's worth sending a navigation for. I can get more information later.

So this is another example of what you can do when you have law that's made computable. It works for companies, it works for individuals, it works for agencies, it works for everyone. And the idea of the process is always the same. I put my personal information-- the stuff that I know about-- and get information that's related to my situation. I don't need to know or care about who is making the decisions.

So I've shown these examples for government services, but when you have these rules that are made computable, anyone can reuse them. So these services could, as well, be provided by the private sector. For example, we also have a company-- a start-up-- that's using this set of rules to help companies assess which tax rebates they can apply to. This was not provided by the state, because there was no investment-- no specific team dedicated to creating this tool or this product. But with no specific investment by the state, that company was able to provide that service. The state has just invested in creating the rule set for some of the products that they had decided to invest in.

And that opens the ability for other actors to create additional services. And this also works for-- it's always surprising and unexpected stuff, like this tool that's been made by an individual-- I'm sorry. I don't know why Google Translate doesn't want to translate it, but. It starts here by my drama. Back in 2013, I divorced. I had four children, and the alimony was poorly assessed. And that man has been struggling since then.

And to demonstrate how unfair this all was and how the law should be changed, he used the rule set to create this interactive assessment, where you can input the situation of the people living as a couple, when and how they did split, the situation of each of the two ex spouses together, and then what's the result. So I'm not going to take the time to fill it in. But if you fill in this this spreadsheet that we have here.

And this guy did it all by himself. Nobody asked him for it. He just came at some point saying, hey, I did that, by the way. So that's always what happens when you enable, when you empower, others to reuse public infrastructure.

So I've really focused on what you can achieve. Why it is that we could make law computable. Because making law computable by itself is not super interesting. Law impacts humans. It does impact machines. There is no point in making machines understand it. The whole point is helping humans understand law better.

So this is why we are doing it. This is what it can enable. Now, how, as a tool creator, are we going to use this set of rules? Well, by using an API.

So API stands for Application Programming Interface. You don't necessarily need to understand all the details of that. But basically, you are used to interacting with machines through what we call user interfaces. You click on buttons, you input text with a keyboard. With application programming interfaces, it's a way for machines to talk to each other. So there's just a different set of constraints. They don't operate with keyboard and mouse, they operate by text. So you just need to formalise what's the format of these text messages that they are sending to each other.

So I'm going to demonstrate very quickly this API-- how it looks like. So here are the rules. Basically, that's different type of information you can get or post to. You don't need to-- if you're interested, I can talk about that more. But I will wait for you to ask questions. I won't go into that level of detail yet.

I just want to show you how we can calculate something. How we can run a simulation. Because you've seen it from the user interface perspective. But I'm now going to show you how it looks like when the machine does it.

So you just need to send that kind of text. Same thing-- I'm not going too much in details here, but you just create a family, with children, with parents, and you give some basic information, like what was your salary in 2017 for each parent? And then there are some elements that you don't have the information for, but you would like computation to be done.

So you just say, for these taxes, I don't know. Currently, it's no. I don't know. And you just send that request so that piece of text, which is basically just like a description of a situation with blank holes in it. You say, I earn that much, and I paid that much in tax, but the tax part is blank. You send it to the machine, and it replies with something.

And that something is here. I get the exact same text that I sent in, but all the no parts were filled in by the machine. So I now know that, for this family that I have described, their tax was that much in 2017. So that's it.

When you think about it, you realise that what we had been doing earlier with Mes Aides or with all these different tools that just provide a user interface, it's all about capturing the situation. So if you are a reuser of computational law of an OpenFisca instance, if you want to create a tool from it, you would just need to create the user interface to capture the details to create a situation. And then just format it in this textual format, send it to the OpenFisca instance, get the results back, and show it to the user in a way that's understandable to them. Pretty simple.

Now, the next question is, obviously, how do I know which names are there? How do I call that? Do I call it salary? Do I call it income? Do I call it tax? Yearly tax?

Well, I can't know that in advance. But I could have a look at the code. But OpenFisca is fully standardised and has an ecosystem of tools around it-- can someone just?

Yeah.

Ask them to be silent? Thank you.

So just like I've shown you right now, these tools that help you exercise the API. I'm not going to show you this other tool, which we call the legislation explorer. And what I showed you until now were examples from the French OpenFisca instance. But I'm very happy to announce today that we already have the New Zealand Aotearoa instance that's ready. It's not huge yet, but thanks to Hamish here, who has been working on that for the last days, we already have some variables and parameters that model the system, which means that you can already interrogate the system.

So Hamish, do you want to talk about one variable, maybe? So you've been really focused rates rebate I think. If you wanted to show us how it looks like.

Hello. I'm Hamish. Hamish Fraser And this has been my world for the last few weeks. The work we have done so far has been just exploring using OpenFisca for a project we've been doing within LabPlus for calculating rates rebates for people.

And so, we've set up a number of variables and parameters that relate specifically to that problem. It's been a really interesting time coming to this from a more of programming background and getting my head around some of the ontology issues. So I'm looking at this, saying, things like "dependents", that's probably not very well named. We might have to revisit this one shortly, because that gets used a lot in different places, but in different ways.

So all of the variables that you see here are generally related to rates rebates. If we just click through one of them, So this is one that is an additional variable or monetary value that gets assigned per dependant. And it's got a database system there. I chose one which only had two dates.

I've got some which have changes every year back to 1974, I think it is, which is something that Matti hasn't necessarily touched on yet. And that is that when we set this up within OpenFisca, we can compute historically. So we can look back at the same scenario and say, well, in 1970 you would have got this. And in 1987 you would have got this, which does provide some really interesting opportunities for doing modelling, historical modelling. And also projections-- so looking forward.

So date-based instances are baked in to the computational engine. So every time we set the variables up, we assign a date that that variable is true going forwards. Which also means that as legislation changes-- we can continue to just add, and at this point, at this date, this has changed.

I'll see if I can just demonstrate here--

Maybe, can you show us the rates rebates variable, rather than-- yeah, so that's a parameter with a huge history pool.

Yeah so this is the income threshold, and it goes back to 1974. And so, you can just glance at this and start to see there was a big change in 2008. It jumped from 7,400 to 20,000. It's super fascinating actually, looking at the history, and just seeing the way the discussions around this legislation has changed.

So, yeah, that's what we've been working on. Have you got a link to the front-end--

No, I don't.

[INTERPOSING VOICES]

If you can show it.

--currently. I'll just see if I can remember the URL.

Sorry. Do you want me to switch it to Australian? Sorry about that.

That's all right.

Australian.

Yeah, there's no New Zealand in our keyboard input. But apparently the closest they come up with was Australia.

I actually don't if I can remember this off the top of my head. I'm going to try.

[LAUGHTER]

No, I don't remember the address.

OK, I can tell you it in a second.

If someone wants to Skype it to--

All right.

Merci. But we do-- we've been working on the UI. It's not actually live yet, but it's running of the computational engine. Successfully, actually. So if you've got any question around--

Can you maybe-- so what we've seen until now has been parameters. So there are two main-- I want to make sure that people remote can still hear me. We've been we've been showing mostly parameters. That is, elements in the legislation that are just values, and they evolve over time. But there's another type in OpenFisca which are called variables. That is, obviously, things that need a formula for computation. It's not just, what do you do with all these values?

And so, these are called variables. So this one, for example, is how you compute the yearly rebate applied to housing rates. So here you have the full formula. This is how it's actually coded in OpenFisca. And I think one thing that's really important to understanding why I think OpenFisca can succeed where so many other tools have failed-- because obviously, OpenFisca is not the first tool to try and make computational law happen-- is we moved away from the fantasy of having policymakers who would be able to code themselves, because all of a sudden we invented a super language that's extremely easy to write.

This never happens. I think this is one of the big fantasies. But it's been 40 years now that engineers have been trying to achieve that. And it does not work.

Hamish, I posted the URL for you in the chat here.

H: Sweet. I'm struggling with this keyboard.

M: Yeah.

H: It won't do the forward slash like my one does.

M: So rather than pretending that-- can someone please-- we have an echo now.

Do you want the URL.

That's Brenda.

Yeah. Please, Brenda, can you do that on another channel? Because we're currently using 30 people's attention. Thank you.

So we're not pretending that policy makers will be able to write the rules themselves. And we're not pretending that the voters will be able to do everything on their own as well. So what we have now is a tool that allows for collaboration between at least these two groups of people.

So this formula does not aim at being writeable by policy makers, but it aims at being understandable by policy makers if they are equipped with a developer at their site. And I see that someone is not convinced. And I can tell you, I've seen it happen.

I'm not pretending that this can be ready right now. I'm just certain that you can pair together. Because it's just seeing through the bits of these thoughts and stuff. But then, what you realise is, one of the main issues when you're collaborating between developers and policy makers is that you have a very different ontology in mind. You're using the same words, but you're talking about different things.

So what you're seeing there, this formula has been augmented. And all the variables or the parameters that you are seeing, you can click on them, and you go to the definition. That's currently modelled in OpenFisca. So there's no amiguity here. If we're talking about these rates rebate maxim threshold, for example, if I'm just saying that you and I might have a very different understanding of what the maximum threshold is. But if you go and see what's the list of all the values this has been through, we know precisely what it is that we're talking about.

And you can also have references. So this one, we know where the data is coming from. But for-- do you have an example of a parameter where we have a link to legislation?

Yeah.

Yeah, sure. So you have to-- we strongly recommend, and there's a whole ecosystem of tools around that that will strongly help you source every single element that's been modelled so that you can always navigate to the original legislative source for that element. So what that means is not only that there is accountability-- it's not so much about that. It's more about the fact that we have a model, this model will never be complete, because the law will always evolve, right? And there's always understanding of the law.

But by making sure that we know where the knowledge is originally coming from, we can trace it back, and we can then evolve our standard. And I've seen this happen time and again. You have a model, you have a formula that has been implemented, and after two months, someone, maybe an individual, maybe an agency comes up with a test case that says that this doesn't work. This is wrong. And it's fine. It's fine.

If you're not fine with that, you're never going to make computational law happen, because you're going to wait to be 100% perfect. And no law has any implementation that 100% perfect, because you cannot define all the edge cases from the beginning. What does happen with a computable model though, is that you can exercise many more cases than you would usually.

And when you identify find one edge case, you can replicate it. You can run it again and again and again. And you can try many different ways to fix that. You can say, we would like, even in this specific case, to reach that result. Well, you don't need to draft policy, then work with some consultancy or some other people to try and assess and think through what this could be like, you can literally do the change in the code and see what that amounts to. So that's why it's so powerful.

So yeah.

My French isn't very good, but I think this says the Wi-Fi is down.

It says loading. Yes, exactly. It's says Wi-Fi is down. All right. So I'm sorry, we won't be able to demonstrate that. But basically, there are references that you click through and they will guide you straight away to legislation on .govt.nz. So you can see if this formula has been properly implemented, or at least if your understanding is the same as the person who has in the first place implemented the formula.

And as you can see there, you could very easily edit it, because it's all open source. So you are very welcome to suggest an improvement. And then we can have a discussion around, does your implementation, does your understanding fit more with that common reference we have to legislation or not? And we can bring many people on hand here. Obviously, the best would be to have people who actually wrote the policy on board. And this is extremely powerful.

So that's why I think OpenFisca has a chance of succeeding where most other tools have failed. It's because it focuses on fostering the community around actual results, not about making law computable, because it would be an end in itself and would be driven either by engineers or by policy makers. It's about all these actors having a common shared goal, because they all have direct benefits from using such a tool. And there's infrastructure in place to support the collaboration between all of them, so that their goals are aligned, and every bit of information that's put in the model, everything that you do to improve your own situation, your own goal, your own tool, your own new drafting policy, this will be beneficial for the whole of the ecosystem.

Yeah. That's it. And there's one more thing. We've seen this example of using products. Hamish has touched on the idea that we can a huge history of coverage, because OpenFisca offers that out of the box. We know that legislation evolves over time. It's not just about having one implementation at a given instance of time. You can cover as much as you want. And we actually have several research papers that have been published by economists who have been using OpenFisca to see how much tax has evolved. In France we have some elements that date back to 1945 to see how that amounted to.

And one more thing I wanted to touch on quickly is that, technically, this is implemented through virtual computation. Don't understand that? It doesn't matter. What that means is it takes about the same amount of time and resources to do the computation for one family or one company as it does for one million.

So once you have your model that you needed to create for a tool that has direct usage for entitlements, or rates rebates, or whatever, well, you can now plug this by feeding it actual data sets from the national census. And just see how many people are actually entitled to anything. You can also create some random cases. And this can be done, and you can run through a situation with several hundred thousand people under 20 minutes, and you would have the results.

So what you're seeing here is an article that's been published by the French movement for the universal basic income, and they've used OpenFisca to make everyone agree on who would be winning or losing if a universal basic income was introduced in France and if was to replace some of the entitlements and benefits. And how they did it-- each of these dots here is one type of individual. They just created random people with a distribution of income and taxes that reflected what was given by the national stats agency. And then you can see how every one of these individuals is impacted by the change in legislation.

OpenFisca supports this through virtual computation, making it very easy and as costly to make a computation for one to several million individuals. But it also has first-class support for reforms. That means you can have the main, current legislative model, and you could add reforms on top of it. And you can compute the difference at any time extremely easily.

So that's why we have started have lawmakers who are extremely interested in this tool. The impact assessment is incredibly simpler. And you can see how, over time, this could be used by groups, lobbyists, however you want to call them, not necessarily in a democratic way. You could totally see how, rather than having a discussion that's purely on words, you could have each party, each pressure group that presents what would be, in their understanding, the best way to implement a reform. And it would be trivial to then run these different reforms on a national data set of the population and see what would be the most effective based on some specific metric that we want to optimise for.

So that's what can be achieved with a tool that enables computational law. And I think OpenFisca is very well-placed to be in that space. It's already used by several services, companies, researchers. organisations in France. It's used by different countries. In Tunisia, there's been an extremely impressive grass roots initiative to model the Tunisian model, and this has been mainly led by a nonprofit that wanted to help the transition to a democratic regime.

And now we have New Zealand has started. Do you want to talk more about the Rates Rebate app, maybe? But what we've shown with the model will be exercised through this interface which should go live quite soon?

Yes. I haven't been working on this interface myself, but the-- and it's also still in development, so it could just entirely disappear in the next second.

[LAUGHTER]

But if give you just a very quick and simple demonstration of how it-- yeah, that's fine.

Find bugs for me.

[LAUGHTER]

So that's not yet used OpenFisca, but that's just done the address look-up and got their rates So this is about input. And now we have to rates number-- how much they're going to pay. And then the other thing we need to know is how many dependants they have. Now surprisingly, that is all the information that we now need to at least give them some sense of perspective on whether it's worth their while to apply for a rates rebate.

So we've framed these three discussions based on that, which is basically, if you are earning less than 43,000, or you're more than 47,000, or if you're in-between And if they're less than, we can immediately tell them that they can get the maximum rebate. If they're more than the 47, we can tell them, look, you're not eligible. And if they're somewhere in the middle, then OpenFisca does the computation on what they owe.

Now OpenFisca did actually do the computation right then to find out those two numbers-- the less than more than number as well. So it just entirely changes the process as to how it's currently done. Currently you spend quite a long time filling in paperwork and stuff, just to find out if you're eligible. So this immediately cuts that off at the chase, and these people get through. So shout out to the team for having a working demo today.

[LAUGHTER]

If you click on one of those buttons, you can show them maybe the less than one,

So yeah, that's just computed the result for the last year. We're still waiting on report requests coming through that should say 620 dollars.

[LAUGHTER]

But that's the maximum amount. And so, now-- is that what you're saying? Click through the apply now?

If you want to show them that.

Yeah, so it just takes their information. And now it introduces the service aspect. But I think at that point that ends the OpenFisca demonstration, but it provides that power to do those computations.

Yeah. And actually, that's the whole point with the tools such as OpenFisca. The aim is not to be visible, it's to create this infrastructure that would power all the actors to develop such tools much, much, much more-- in a much leaner way, so that you can focus not on understanding law, but on reusing what has already been modelled, and then focus on the user experience from that.

So that's it. Thank you very much. And, yeah, we'll go more questions I think. And Nadia, do you have any idea how we can do that, to have also people remotely.

Well, they might have to open their mic. If you close yours while they open theirs.

Yeah.

Oh, close yours maybe?

Do you plug in the speakers so that everyone can hear them. Well, let's see if they can come through yours. Let's see.

Does anyone have questions?

I was really interested in what you said about how it would be used in practise. That seems to take us to straight to the better rules sort of approach that we experimented with. That this would be the tool, the platform, that you would use in common for us try and sort of model from the outset how the policy would be developed, the implications of that, how it would reflect that, make sure we're all giving to that intended outcome.

So as you said, you'd sort of do working side-by-side. There's no intention here that the policy developers in place with this correctly you still need that development, which is the model we ended up using and started doing exactly that. So, that's sort of aligning nicely, doesn't it Nadia?

It does. But I think it's still doing the work of agreeing on what the logic model is before you sit down to do that.

Yes, Yeah, absolutely.

Like we did--

[INTERPOSING VOICES]

Too many parameters to fit into your variables. Yeah.

And Hamish has got a really good point about a particular variable called property.

So we've been struggling with the word "property" as it's a keyword within the programming language. So it's more of a side-story, because it is easy to work around, but it's quite an interesting thinking process in terms of making legalisation and code the same thing. Where do they collide? And here, in the English language, because the French are laughing at us because they don't have this problem, and it's because the English language has dominated the computing landscape.

So we have this keyword property within the Python language which is what OpenFisca is built on. So we can't directly use it. So then we sit there and scratch our heads, going, well, that is the perfect word. What can we do instead? So there are some interesting points there. But they are an interesting sideshow, but they start to raise some really interesting questions.

But because you don't see it, then in a real world sense isn't going to be a problem, because sits behind.

Yeah, no. Exactly.

because that means you can't have a one-to-one.

Yeah. That's really the developer and the legislator to continue to--

[INTERPOSING VOICES]

So another word that you can use for that is copyright. That's also a platform word that's on the list.

H: Yes.

M: Yeah, I think to highlight also some other side effects of trying to model law in computer languages is that you end up realising just how many grey areas there are in law. Because you need to make everything super explicit for the computer. And that's where you see how sometimes policy just is very vague. And sometimes, words actually conflict with some other parts of the legislation. And the whole process of expliciting everything is extremely valuable. And I think, would it be only for that, it's worth the investment. Now, what would be good is focusing on the way to feed this back into the legislation itself, but this will probably take years before actually people can do this

Is there a need for definitions to be standardised? Because property can be different-- if you're talking about terrace property is quite different from property. Funds-- let's say properties, funds, assets... But you have very wide definitions of property for certain purposes, and very narrow definitions of property for other purposes in different legislation. So because a standard--

Yeah, I would rephrase that to make sure, like, that's what's going around here.

Yeah

So there's a question-- I will rephrase it. If it's not clear, let me know. Do we need unique ontology for all the terms Involved? And the answer is yes and no. That is, technically, yes, you will need to have unique identifiers for all elements. That's what I've shown earlier. Each of the elements that are in the legislation explorer-- so what you're seeing now with these dependants and everything-- all of them must be unique. There must be no conflict. We can't have two things that are called dependant.

And that might be surprising for people who come more from an engineering background. We don't have first-level support for namespacing or anything. We actually made it extremely open. That is, the only constraint is the identifier has to be unique, but then you call it however you want. So you're very welcome to use property for-- what was the example.

Oh, just something like terrace property is a much wider than a property than say...

Sometimes you might use it to refer to all things capable of being owned.

Yes.

But then you might have legislation which is concerned only with land.

Yes.

With real property-- so it just refers to it as property, because the context of whole legislation provides the qualification. So you might have legislation that has rules about property, and then one statute that means anything capable of being owned, and now that same word is used just to mean land.

Yeah.

So what you're saying, if I understand the ideas, that doesn't matter, because you can have different unique identifiers in your code. Or are those terms sitting behind the statutes.

What I'm saying is that that's one of the biggest problems you always have when your are trying to create one, single consolidated model. In France right now, there's about 3,500 unique identifiers. So obviously, how can you make sure that you're not defined twice the same thing with different names.

And once again, there's a design choice here. OpenFisca will actually let you do that, let you define twice the same thing with different names. It's really annoying. It's a problem, because then, when you update one, you might not necessarily the other. But there's there's, necessarily, a compromise there. Because either it's that, or you're trying to prevent people-- you would likely force anyone to read through all of the previous stuff that's been there before you were able to come in.

So what I mean is you're totally free to define the naming scheme that you prefer. The tool, OpenFisca, is agnostic to that. So what I would really recommend, you have the opportunity here in New Zealand to be starting this model. So if you can get multiple people involved-- get a working group on that-- it would be great.

The way I've seen it work the best is by having people available to answer questions. Like, for example, if Hamish has this issue with, oh, I cannot reuse property because of technical reasons, who can I ask for some help about which other term would be appropriate? And I think that has already happened actually.

But someone would say to you, Hamish, is, here you should use asset, but here you should use land.

[LAUGHTER]

H: Yeah. And that's--

That's pretty much what I said.

That's fine. In this situation here you can see it with "dependents". Dependents really needs to be described as dependents in regards to a rates rebates.

Exactly.

And you can have a big, long name on there.

Yes.

The name can be a big description. And then the problem goes away.

Yeah.

M: Yeah. I think, basically, we will always have that problem. You will always have words that have different meanings in different contexts. And this tool is not aiming at forcing you to make every context explicit, it's just giving you the power to make this context explicit if you want to. So the overlaps in terms are really up to your teams to define.

The reason why is no one has a thorough understanding of the whole system. So there is no way we can come up with a priori version of the proper ontology. It does not exist. It will always need to be refined. So one year from now, you will probably need to rename half of the stuff that's in there. And it's going to take two weeks, and it's going to be very long and frustrating. But there is no way we can know right now how to call all these different variables, all these different parameters. We don't know yet what our environment looks like.

But there's nothing stopping the end-user consuming the JSON, the file, and in their interface calling it something completely different is there? Like, property that's my house. So as a real estate agent, I could just call that houses, apartments, whatever I like. But I'm just using that background.

M: Yes, absolutely. The point that was made was that user interface can then display whatever. It's not because you have a unique identifier that's specific that then the user interface needs to be so. And that's absolutely true.