Tracking objects over application boundaries

An object is a thing in the world. A specific building is one, and a company is another. The world has many buildings, and every system that records a building manages it on its own: the commercial register, a statistics office and every database that lists it. Object identity answers two questions about a record: what kind of thing is this, and which one of that kind. Both answers are a classification of the object. The id that a database gives the object is a handle for that classification and means nothing on its own. This page states the model of a client’s information platform I am developing as part of my research focus.

Type fields are a classification system

Often objects have one or more types assigned to them, and the type is the first half of its classification. A record of a building is a record of a building, whichever organization wrote it, and a merge never changes the class of an object.

The second half is which building the record describes. The register codes and the same-as links in the sections below give that answer. A shared name alone does not, because two buildings can carry the same name.

The id is a connection

The id answers neither question. It lets every table, URL and search document point at the same object at a given time, usually in the past.

Every object has one id, and that id belongs to nothing else. One allocator draws from one sequence and skips every number that an object or an assertion already holds. An entity is created object first: the object row and its assertions are written in one transaction.

An id that is unique only within its table is ambiguous as soon as a second table holds ids of the same kind. The price of one id space is a central allocator that every writer depends on.

Versions belong to the object

An edit creates a version of the object, and the object row stays the same. Every relation, URL, permission check and search document uses the object id to mean the thing itself.

The version boundary is the complete mutation: one user submit or one import item creates at most one version. A rollback is a new version too, so the history only grows.

Storage sees many row writes for one change, and a history cut at that level is unreadable for the person who made it. The version is defined by the mutation a user sees, and the tests assert how many versions it creates.

Relationships are objects

A relationship such as the role of a person in a company is often a data row owned by one of its endpoints. Such a row has no identity and cannot be versioned or retired alone.

Each relationship family is an object type of its own. A relationship has its own id and its own versions, and its two endpoints are assertions on it. A contract between two companies can end while both continue, and that end is a version of the contract. The cost is more objects and one more join on every traversal.

Register codes are a shared key

An internal id means nothing to a statistics office. Both sides hold the register code. The rule is one datatype per register and per administrative tier. The code stays a string end to end, because a leading zero is part of it.

Two limits apply to what a code proves. Registers reuse codes, so a code that names one place in one edition can name another place in the next. A shared identifier is weak evidence for a merge, because records that share an identifier or a web link often differ in a basic fact. It only generates a candidate for the de-duplication review.

Same-as links

A same-as link asserts that two objects denote one thing in the world, in the strict sense of owl:sameAs. Both objects keep their ids and histories, so withdrawing a link is one change. Only accepted, published links enter the identity closure.

Confidence is a value on one assertion and is not transitive: a score for A and B and a score for B and C yield no score for A and C. Hard vetoes run before acceptance, and no score overrides them. A veto is a contradiction between the two objects, such as a dissolved company and an active one.

Conclusion

A system that manages record-based information needs software that identifies the classes of these objects, verifies the facts about them, rates the sources and keeps the data current. The need is the same between organizations and users, where several systems hold copies of one object, and where registers and partners hold their own records of the same thing.

The systems on the market today do not meet this need. A database gives an object an id and leaves the scaffolding of the classification and the updating to its users. As a result, systems tend to become outdated and/or corrupted over time. The system I am designing helps users to better deal with these challenges: mutable definitions of its structure, uniform classification, versions that belong to it, connected objects as a shared key, and rules that can block or enable.