Outline Data Model
This Data-Model is universal, i.e., can be applied to land-ownership anywhere.
In the diagram the asterisk (*) depicts “many,” (i.e., any number of participants), so, from Right to Left, the diagram reads: Many OWNERS to one SHARE; many SHARES to one INTEREST; Many INTERESTS to one PARCEL.
Each Class of Object (PARCEL, INTEREST, SHARE and OWNER) can be expanded to provide more details.
A line joining two Classes indicates that there is an Association (or Relationship) between them (e.g., an OWNER owns a SHARE).
Words used in the Data-Model have the specific meanings given to them in the model; each word has a unique and unambiguous meaning, unlike similar words used in the outside world.
Unified Modelling Language (UML)
The diagrams in this post are drawn using the Unified Modelling Language (UML). It has been said that UML can be used in either of three modes: Sketch, Blueprint or Programming Language.
When used as a Blueprint, a set of Diagrams describes a proposed system in full detail; all the computer programmer has to do is translate the meanings depicted by the diagrams into programming language.
When used as a Programming Language, a programmer describes the system fully in UML Diagrams drawn to strict rules. A computer program then automatically translates (or “compiles,” to use the technical term) the Diagrams into Machine Code to run on a computer.
I am here using UML in sketch mode, i.e., to explain important aspects of the system, but not in sufficient detail to provide a Blueprint. I show that the Data Model is coherent, but do not bore the reader with excessive detail. Sketch Mode is aimed at a general audience, including policy-makers, politicians, lawyers, surveyors, and interested members of the public, as well as computer-programmers. (UML as a programming language is directed at being understood by a computer).
By providing this outline Data-Model, I am saving organizations proposing to implement a Land Titles System from the considerable expense of developing a Data-Model from scratch. I am also saving them from the error, frequently made, of computerizing legacy models of title registration, which can be expensive, limiting and incoherent.
Expanding the PARCEL Class
A PARCEL may be either a GROUND-PARCEL (i.e., a plot of ground of whatever size), or a STRATUM-PARCEL (an apartment or other unit on a floor of a multi-story building, or a part of any stratum under or over the surface of the land). This is illustrated in the following expansion of the PARCEL Class:
We also see that a PARCEL is either a GROUND-PARCEL or a STRATUM-PARCEL, the triangular graphic indicating a “generalization,” i.e., that “PARCEL” is a general name for Objects that are either GROUND-PARCELS or STRATUM-PARCELS.
The GROUND-PARCEL Object-Class
We can now proceed to examine the characteristics of the GROUND-PARCEL Class:
An Attribute is a static statement about the Object (such as its Identity number, name, address, etc.).
An Operation is some procedure that the system carries out by means of the Object – for example, Area-Calc in relation to a GROUND-PARCEL is a mathematical operation that calculates the area of the GROUND-PARCEL by applying a formula to its coordinates.
There are UML notations for depicting more details of each Attribute or Procedure, but these only become relevant in a detailed model. We do not show here all the properties of the GROUND-PARCEL, but just those we wish to discuss at this point.
The Attributes of GROUND-PARCEL
We make the following observations about the Attributes of GROUND-PARCEL listed in the above diagram:
Ground-Parcel-Number: Every Object entered into the system will have a unique number by which it is identified; in this case the Ground-Parcel-Number.
The Coordinates are specified as a string of numbers which signify the Latitude and Longitude of each point where the boundary changes direction. From these, a computer can draw a visual map of the GROUND-PARCEL.
Creation-Date is the date on which this GROUND-PARCEL was created; Creation-Instrument is the Instrument Number by which it was created. (These are part of the Audit Trail by which every piece of data in the system can be checked as to the legitimacy of its origin).
Cancellation-Date and Cancellation-Instrument: a GROUND-PARCEL is cancelled when it is subdivided to form two or more new GROUND-PARCELS or merged with another to form a single GROUND-PARCEL. The original GROUND-PARCEL remains in the Database, but is now marked as Cancelled, which means it is not part of the current information, but is available for historical research and Audit. The default value of these fields is blank.
“Strata(Y/N)?” is a Boolean Field, i.e., an attribute that can have one of two values, meaning Yes or No. Y indicates that this Ground Parcel contains a building divided, as to ownership, into Strata. N, the default value, indicates that it does not.
The Location descriptors might be derived from an existing mapping system (e.g., of the official mapping agency) at the time of entering the Ground-Parcel, or, if none such, keyed in by a user when registering the property; additional, locally-used descriptors and postal address and postal-code, if any, can be added. All these options would be spelt out in a detailed model.
As to the Procedures of the GROUND-PARCEL:
“Get-Location:” This is an action whereby the SLT obtains the geographic location descriptors (e.g., Street and Town names) from an existing digital map. If the geographical location has not already been obtained, it passes the coordinates of the GROUND-PARCEL to the digital map with a request for the Location-Descriptors corresponding to those coordinates.
“Area-Calc:” If the area has not already been calculated, the coordinates of the GROUND-PARCEL are fed to a formula that calculates the Area. This gives the surface-area as if it were flat. The actual surface-area may be greater, if the ground is sloped.
“Centroid-Calc:” For some purposes, it is convenient to pass the coordinates of a single point to a search engine, rather than the coordinates of all the boundary points, for example, where we wish to find from another agency's mapping system where the property is located or its distance from school, church and shops, or other useful information. “Centroid-Calc” is a formula for calculating a central point for this purpose. We don't call it the “Centre,” because, for an irregularly-shaped GROUND-PARCEL, there may be no definitive centre.
“Pass-the-Parcel:” When entering details of the property, a user will specify whether the GROUND-PARCEL contains a building which is divided into separately-owned Strata (e.g., Floors). The default value of the STRATA? Attribute would be N, in which case, the GROUND-PARCEL would forward its own GROUND-PARCEL Number to the PARCEL Object-Class as the basis of the ownership records. If, however, the value of STRATA? Is Y, then the GROUND-PARCEL, instead, refers to a Schedule of STRATA-PARCELS related to the GROUND-PARCEL, and it is the STRATA-PARCEL Numbers that are passed on to the PARCEL Object-Class.
The STRATUM-PARCEL
Every Stratum-Parcel will inherit its geographical location (coordinates and location descriptors such as town and street name) from the underlying GROUND-PARCEL. It will have its own Creation-Date, and, where relevant, Cancellation-Date.
It will add additional Attributes of its own, for example its Stratum-Number (i.e., Floor-Number) and Unit-Number, or whether it is Residue or Ground or Air Space.
SUPER-PARCELS
We have seen that a GROUND-PARCEL is a single plot of ground, or, more precisely, a plot of ground bounded by an unbroken boundary line, (excluding any GROUND-PARCELS contained inside that boundary line) of which ownership of an Interest is recorded in our SLT. The only instance where our scheme allows a PARCEL to be contained within another PARCEL is the instance of a STRATUM-PARCEL, which is contained within the bounds of a GROUND-PARCEL. Overlapping PARCELS are only allowed to the extent that the overlap is recorded as a disputed boundary.
There will be instances, however, where our registration system will find it convenient to record information about larger areas of ground encompassing multiple PARCELS. Obvious examples of these are towns and districts. Another example could be a Shopping Centre or Industrial Estate, either of which could contain multiple GROUJND-PARCELS within its boundary.
A SUPER-PARCEL would not be a PARCEL, but would be an area of ground actually or potentially more extensive than GROUND-PARCELS about which the SLT might record some pieces of information shared by all land within the SUPER-PARCEL boundary.
This concept is incidental to the SLT Data-Model and requires no further treatment here.
A Table for GROUND-PARCEL
The Attributes of Objects can be represented in the form of Tables. The Table for GROUND-PARCEL could be as follows:
|
GROUND-PARCELS |
||||||
|
GPNumber |
Coords |
Strata? |
Urban? |
Town/ Area |
District |
.. |
|
7654321 |
XXXXXX.. |
N |
Y |
Cork |
North Monastery |
.. |
|
.. |
.. |
.. |
.. |
.. |
.. |
.. |
A Class Diagram sets out the Attributes and Actions of each Class of Objects in the system. Since a corresponding Table can easily be drawn to implement each Class Diagram, the model is fully described in the Diagrams, (if presented in full detail), without actually drawing the Tables. Examples are given here just for the purpose of explanation.
Tables for Associations
As well as deriving Tables from Diagrams of Object-Classes, we can also derive tables for Associations (or Relationships) depicted in Diagrams.
Repeating, here, the part of the Diagram in Paragraph 1 of this Post, depicting the PARCEL-INTEREST relationship, we then proceed to draw a Table implementing the Diagram:
The Table implementing the Diagram consists of a column of Parcel-Numbers and a column of corresponding Interest-Numbers:
|
PARCEL-INTEREST ASSOCIATION |
|
|
Parcel-Number |
Interest-Number |
|
9999 |
7777 |
|
9999 |
7778 |
|
9999 |
7779 |
|
10000 |
5432 |
|
… |
|
Since there can be several INTERESTS in relation to one PARCEL, we note that a particular Parcel-Number can occur in more than one Row of the Parcel-Number Column, and will relate to a different Interest-Number in each case. Because it is a One-to-Many relationship, of course, a particular Interest-Number will appear only once in the Table.
So PARCEL Number 9999 appears three times in the above Table, each time related to a different Interest-Number. We gather from this that three INTERESTS exist in PARCEL number 9999. The PARCELS Table will give us details of PARCEL Number 9999, and the INTERESTS Table will give us details of each of the three INTERESTS.
Expanding the INTEREST Class
An un-fettered FREEHOLD Interest is the greatest INTEREST one can own in land. All other Interests are carved out of the Freehold, and, in our model, we call them LESSER-INTERESTS (not indicating less in value, but lesser in the hierarchy of Interests).
We distinguish between FREEHOLD and LESSER-INTEREST Objects, because they have some different qualities in our model. In particular, every LESSER-INTEREST is a Burden on some other INTEREST, whereas a FREEHOLD is at the top of the hierarchy and a Burden on none.
Our expanded Diagram for INTEREST is, therefore, as follows:
We see that an INTEREST is either a FREEHOLD or a LESSER-INTEREST, and that a LESSER-INTEREST will always be a Burden on an INTEREST, but that there may be several Burdens on one INTEREST (e.g., a Lease, a Right of Way, and a Mortgage, perhaps). However, it is possible that there would be no Burden at all on an INTEREST.
In existing systems, we often find that an INTEREST is a Burden on several INTERESTS, for example where a single MORTGAGE captures several properties. We feel that the model is more coherent by allowing an INTEREST to be a Burden on no more than one INTEREST. As a result, the MORTGAGE, in our example, would be recorded under a separate Instrument-Number on each of the separate properties, but these would all be tied by a Link by which all would be reported as related to the same Mortgage Transaction.
There can be many different types of INTEREST, including: Freehold, Leasehold, Tenancy, Mortgage, Charge, Rent-Charge, Perpetual-Rent, Feudal-Right, Tribal-Right, and Trust. Every such INTEREST comes within the Model, but does not add much complexity since all comply with the same structure.
The SHARE Class
Here is a diagram depicting the SHARE Class:
The attributes that distinguish it from other Objects are its Numerator and Denominator, both being positive Integers, i.e., whole numbers greater than 1 in value. The value of a share is represented by the Numerator over the Denominator. For example, if the Numerator is 5 and the Denominator is 7, then the value of the Share is 5/7, or five sevenths.
The default value of both the Numerator and Denominator is One, so that the default value of SHARE is 1/1, i.e., 1. This is the value that applies when there is a sole owner, or co-owners who are Joint Owners, rather than Owners-in-Common.
The Operation we call “Tot-shares” has a number of functions:
Starting off with the default value, when a Share is created, its value is deducted from 1. We call the result of this calculation “the Remainder.” If there was already a registered Owner of the Interest, he becomes, at this point, registered Owner of the Remainder. If there was no registered Owner of the Remainder, its Ownership is recorded as “Not Known.”
As successive Shares are defined by a Transaction, the Remainder is reduced by the value of each succeeding Share.
Tot-Shares also totals the value of all Shares created in the relevant INTEREST, and, if the total exceeds 1, returns an error message, allowing the user to correct the input values.
The OWNER Class
An OWNER can be a PERSON or a CORPORATION. We have also seen (Chapter 12 of SLT) that an Appurtenant Right attaches, not to an Owner but to an INTEREST. This means that the INTEREST is modelled as one of OWNER'S Sub-Classes.
When it comes to CORPORATIONS (by which we mean Corporate Bodies), we have seen that there are several classes of such, including Limited Companies, Statutory Authorities of various sorts, Cooperative Societies and Sovereign States. There may not be a single register covering all corporate bodies, and different rules of behaviour may apply to the different types, so each needs to be modelled as a separate Sub-Class of CORPORATION.
The OWNER Class is, therefore, expandable as shown in the following diagram:
While every OWNER has a unique identifying Number, a Date on which registered as Owner, an Instrument-Number linking to the Instrument under which he was registered, and, potentially, a Cancellation-Date and Instrument, each Sub-Class of OWNER has properties particular to its Sub-Class. For example, PERSON has a Social-Security-Number and, potentially an operation or group of operations for accessing information from registers of births, marriages, deaths, and calendars of Probate and Administration, while LIMITED-COMPANY has a Number in the Register of Companies, DIRECTORS and SECRETARY, and SIGNATORY of specified documents.
Summary
An Outline Data Model shows that the essence of the Ownership-model is found in the Object-Classes: PARCEL, INTEREST, SHARE and OWNER. There would, potentially, be Many (i.e. any number of) OWNERS to one SHARE, Many SHARES to one INTEREST and Many INTERESTS in one PARCEL.
Each of these Object-Classes can be expanded to show more detail: for example
· A PARCEL is either a GROUND-PARCEL or a STRATUM-PARCEL (the latter occurring where a building or other stratum is subdivided);
· An INTEREST is either a FREEHOLD or a LESSER-INTEREST, which latter must be a Burden on another INTEREST; LESSER-INTEREST has several Sub-Classes, including LEASE, MORTGAGE, CHARGE, SERVITUDE, etc.
· The value of a SHARE is depicted by a Numerator and a Denominator;
· An OWNER is either a PERSON or a CORPORATION, or, in the case of an Appurtenant-Right, an INTEREST.
Drilling down from the outline model of the system, we can add many levels of detail until a coherent model of full detail is described. We have used the Unified Modelling Language (UML) in Sketch Mode to illustrate the logic of the system.
No comments:
Post a Comment