This snippet begs all the important questions. How is the value of "aggregate_periods_from_last_five_years of personal.property_ownership" calculated? What does it mean to own a property? Does it count if you jointly own a property with someone else? If so, how much of a percentage of ownership counts as ownership? What about if for some part of the 730 days the ownership of the property was subject to dispute and it could have been owned or not owned by the person in question?
The whole thing smacks of false precision to me. It's precise about things that are not legally complex to be precise about in the current system, and the language gives the false impression that it's actually going to be possible to be precise about everything.
Secondly, it feels like it will have a similar drawback to sql[1] in that it seems on the surface to be non-technical, but actually requires significant technical expertise to avoid numerous beartraps and understand anything beyond the very most obvious.
[1] Which was originally intended to be a formal version of natural language understandable to non-technical people (hence the original name SEQUEL "Structured English Query Language")
> How is the value of "aggregate_periods_from_last_five_years of personal.property_ownership" calculated?
How is the value of "during the 5-year period ending on the date of the sale or exchange, such property has been owned and used by the taxpayer as the taxpayer’s principal residence for periods aggregating 2 years or more" calculated?
> What does it mean to own a property?
What does it mean to own a property under the non-formalized law?
In the end, it means that if you file a tax return that the tax authorities aren't happy with, you can argue in front of a judge whether you think you own something, and the judge will decide whether you do. Based on this they will decide whether your tax return was valid or not. The technicalities of whether you own something in the eyes of the judge have nothing to do with whether your tax return was based on your reading of the law or on a tool based on this language. Either way you must decide whether you think you own something, and the rest of the computation is based on this decision.
> Does it count if you jointly own a property with someone else?
Search the paper for "joint returns", it quotes both the law and its formalization.
> The whole thing smacks of false precision to me. It's precise about things that are not legally complex to be precise about in the current system
<scratches head> The questions you raised do appear legally complex to me. But also I think you misunderstood the whole problem domain. The law currently spells out an algorithm for computing something. The inputs to this algorithm include questions like "do you legally own stuff". These inputs are outside the specific algorithm spelled out in Section so-and-so. They are similarly outside the specific algorithm spelled out in the computer program.
The law doesn't specify anything as precise as an algorithm. The law has multiple statutes, codes, precedents etc with overlapping applicability. Then in a particular case these are tried and humans come to a decision.
Trying to pretend it's precise like a computer algorithm is I think a really big problem.
The reason I posed those particular questions is that if you try to make this answer the questions you rapidly approach a level of complexity similar to the existing legal codes and still don't have something that could automatically be evaluated.
> The law doesn't specify anything as precise as an algorithm. The law has multiple statutes, codes, precedents etc with overlapping applicability.
Again, I think you're arguing about something that the paper doesn't claim to do. It doesn't claim to formalize "the law" as a whole. It claims to formalize part of a single section of a single statute. That specific statute describes precise rules into which you feed boolean and numeric data, and the application of which rules spits out boolean and numeric data. These rules are written specifically so that they are not ambiguous, so that anyone given the same input data would come to the same output conclusion. That's an algorithm.
What is indeed ambiguous are questions of ownership: Did you own a certain property for two years within a five-year period if for part of that period it was co-owned with a friend who then became your spouse and then later divorced you and got the property? But again, this is not what the paper claims to decide. This is something that the algorithm in the paper, and the algorithm of this specific section of the tax code, takes as input as a boolean flag.
> The reason I posed those particular questions is that if you try to make this answer the questions [...]
But again, you do not try to make this answer these questions. And the paper never claims that it does.
The tool described in the paper does not contain a function like "given THE ENTIRE STATE OF THE REAL WORLD, compute whether I owned such-and-such property for two years in a five-year period". The tool described in the paper only contains a function like "given a boolean flag modeling MY CLAIM to have owned (or not) such-and-such property, compute a number for me".
Your reasoning for having owned (or not) a certain property is not checked by the tool described in the paper. It takes your claim about property ownership as a boolean flag and says "well, if you are really sure that your claim is correct, then your tax liability is such-and-such". It doesn't claim to check whether your claim is correct.
Sure, but the problem is then it's not very interesting. There are lots of real-world systems already that do this with existing laws and existing programming languages (eg in the UK where I live the the tax service has a free web filing system where you fill in your tax return online, it checks it for correctness and tells you how much you owe or are owed (if you have overpaid).
The whole thing smacks of false precision to me. It's precise about things that are not legally complex to be precise about in the current system, and the language gives the false impression that it's actually going to be possible to be precise about everything.
Secondly, it feels like it will have a similar drawback to sql[1] in that it seems on the surface to be non-technical, but actually requires significant technical expertise to avoid numerous beartraps and understand anything beyond the very most obvious.
[1] Which was originally intended to be a formal version of natural language understandable to non-technical people (hence the original name SEQUEL "Structured English Query Language")