(U01)

www.btinternet.com/~adrian.larner/database/newint2

A New Interpretation of Data

(continued)

A database paper by Adrian Larner

 

IDENTITIES

 

 

We need to distinguish this sort of relative identity from other identities:

Given any merely reflexive identity, “I”, we may define its completion, say “I”, which will be totally reflexive:
 
    xIy  =df  xIy Ú (¬xIx Ù ¬yIy)
 
Any relative identity classifies the entities to which it is applied exclusively (no entity falls into more than one class), but - if it is not totally reflexive - not exhaustively. The completed identity effects exactly the same classification, and additionally classifies the previously unclassified entities into one extra class.
 
The completion of is the same person as is:
 
    Either x is the same person as y or neither x nor y is a person.
In any formal system there is one and only one identity, say “Ï”, that is totally reflexive and that is related as follows to any identity, “I”, expressible in the system:
 
    "x "y xÏy ® xIy
 
If x is identical to y under this systemic identity, then x is identical to y under the completion of any identity expressible in the system. In a system based on the FOPC with a finite number of primitive predicates, the systemic identity is easily definable.
It is commonly – but not here – accepted that there is (“in reality”) a totally reflexive identity that we shall call absolute identity; and that the systemic identities of some – or perhaps all – systems are to be interpreted as this absolute identity. Absolute identity has extratheoretically the characteristics of systemic identity. The “identity theory” found in most manuals of logic (as in “the first order logic with identity”) is generally regarded as absolute identity. Within any theory, of course, and ignoring interpretation, absolute is indistinguishable from systemic identity.
We have already seen how the use of relative identities allows expansion of a theory (and, by extension, of a database – a collection of information) without redefinition of already established concepts. Consider what would happen if the relative identity, “is the same individual dog as”, were treated as absolute identity. We wish to introduce the predicate, “is a puppy”. This predicate can come out false of one thing and true of another thing even if those two things are one and the same individual dog. It is merely another classification (into two classes, puppies and non-puppies). But no predicate can be false of and true of one and the same thing, in the sense “false of x and true of y” if x is absolutely identical to y.

We would therefore have completely to rethink our concepts, perhaps construing individual dogs as sets of timeslices of dogs (earlier timeslices being puppies, and later being non-puppies). Again, we would have to decide whether a breed or a species was to remain a set of individual dogs (a set of sets of timeslices of dogs), or was to become a set of timeslices of dogs (and have individual dogs as subsets rather than as members).

Notice that it is not time alone that forces such distinctions on us. Any distinction finer than any previously formalised will have the same effect: it might be location, role, or many other features that we might wish to record. We will see some other examples, below.

 

Counting and Naming

 

 

We now show, following [Geach], how relative identities can be used in counting and naming. Suppose that we have a collection of inscriptions of symbols – a certain page of printing, for example. The term “alphabetic letter” is now defined on the full criterion of identity, “is the same alphabetic letter as”, which we represent by “I”. Intuitively, x is the same alphabetic letter as y when x is an A and y is an A, or x is a B and y is a B, or ... x is a Z and y is a Z. In a very obvious sense: there are exactly 26 alphabetic letters, and therefore no more than 26 on the chosen page. (Remember that any two inscriptions of “A” are the same alphabetic letter, and that “a” is the same alphabetic letter as “A”.) The definition of “is an alphabetic letter” is:

ax  =df  xIx
As remarked above, an alternative – equivalent – definition is: $y xIy. An inscription is an alphabetic letter when there is something that is the same alphabetic letter as it.

We count the alphabetic letters on the page by the following algorithm:

Assume all inscriptions on the page untagged. Say the word “zero”.
 
Repeatedly, until there is no untagged alphabetic letter on the page:
 
Point to an untagged alphabetic letter on the page, utter the next count number (i.e. “one” on the first occasion, “two” on the next, etc.), and thereby tag that alphabetic letter – that inscription and each inscription that is the same alphabetic letter as it.
When the algorithm terminates, the last uttered count number is the count of alphabetic letters on the page. It is proposed that there is no essentially different way to count. Clearly we must have some identity to count under, for a count is invalidated if we count the same thing twice; so we must know, literally, what is to count as the same thing. Moreover, the identity used must be not so fine as to prevent any progress being made. In the case of “is the same alphabetic letter as”, we have a definite limit: as the count approaches 26, we know we are coming to the end. But “is the same contiguous inscription as” would also force progress on us, as long as we counted over a limited universe (the inscriptions on a particular page) – x is the same contiguous inscription as y when, assuming the printing black on white, x and y are all black and a point can move from any position in x to any position in y without entering a non-black position. (Notice that lower case “i” and “j” are alphabetic letters, but not contiguous inscriptions.)

To illustrate the use of relative identities in naming, consider a small child given the name “Richard” (perhaps, but not necessarily, at a formal naming ceremony). What now entitles this man to that name? The physical material of the child, at the point of receiving the name, is now a widely scattered object; but why is it this man, rather than that scattering of atoms, that is called “Richard”? The reason is: because the name was given under a particular criterion of identity, is the same person as. The name “Richard” was given to the baby, and to each thing that (tenseless) is the same person as it. Notice that the use of the identity works even backwards in time. We may refer to the newborn Richard, even though the name was not given until some weeks later (permissibly years later, even posthumously).

 

Systemic and Absolute Identities

 

 

A systemic identity, apart from its special role in its theory, is merely a relative identity. In a theory of inscriptions whose sole primitive predicate was “is the same alphabetic letter as”, “I”, the systemic identity would be “I”. But this is a perfectly ordinary relative identity. Let us call the theory, “Q”. If we now added to Q a new primitive, say “is lower case”, we would get a new theory, say F, having Q as a sub-theory (so that every truth of Q became a truth of F). The vocabulary of F would contain “I”, in exactly the same sense, but “I” would not be the systemic predicate of F (because, in F, we could distinguish upper and lower case letters, say a Q and a q, that were I-identical).

This shows, we might reckon, that the systemic identities of theories are not generally to be interpreted as absolute identity. Indeed, the systemic identity of Q, when used as a subtheory of F, simply cannot be interpreted as absolute identity; and it would be peculiarly perverse so to interpret it for Q when not used as a subtheory of F. That would make “Q on its own” and “Q as a subtheory of F” different theories, and show that, in general, it was not possible to make one theory a subtheory of another (because it would become a different theory, not that “one” at all).

Obviously, if absolute identity is to be formalised in a theory, it will have to serve as the systemic identity of that theory. We may read an absolute identity as: is the same as, with neither explicit nor implicit understanding of a count noun after “same”. Not “the same such-and-such as” for any such-and-such. Not “the same person”; not “the same dog”. “The same thing”, perhaps: we have no criterion of identity for things (except in the special sense of maximal coherent objects – the sort of “thing” one might throw individually across a room).

Whether we should admit the concept of absolute identity is a difficult question. But we should at least observe some of its problems:

Interpreting an identity (which must be systemic) in a theory as absolute identity risks massive re-interpretation of the terms of the theory if it is ever enhanced (i.e. another theory built, having the original theory as subtheory).
 
It is not possible to count under absolute identity – to answer questions like “How many things are there in this room?” Absolute identity is too fine-grained, even in a finite universe. If one attempted to count the things that are inscriptions under absolute identity, one might tag something with “one”, and attempt to progress. But we could point (apparently) to that thing and say, “Count that as ‘two’.” After all, it is now tagged (formerly not); and probably now missing an atom or two (formerly present). And that makes it not absolutely the same. By counting under a coarser grained relative identity we exclude such quibbles. Being tagged, or suffering slight decay, does not usually make an inscription no longer the same alphabetic letter. But any even undetectible difference is a difference in absolute identity.
 
Even more obviously, it is not possible to give a name under absolute identity: the passage of the shortest time would end the existence of everything absolutely identical to the named object.

 

THE CLASSICAL INTERPRETATION

 

 

It is true that [Codd1970] did not explicitly propose a modelling from, or interpretation of, the records that were themselves modelled by tuples. However, there was such an interpretation implicit in Codd’s approach, hidden – alas – by the popular interpretation of tuples as “entities”: witness even Codd’s early use of expressions like “entity integrity”. But notice the following remark from [Codd1990]:

[The relational model] takes advantage of the large numbers of assertions all of the same type. The predicate in the logician’s sense that is common to all the assertions of one type is factored out and becomes the relation name.
What Codd appears to be saying is that a relation (type) is interpreted not as a kind of entity but as a predicate. A predicate is an open sentence, such as “... is father of ...”, that holds true or false of the entities of the theory of which the predicate is a component; in the example, true or false of things taken pairwise, because the predicate has two “places” into which names of the things might be inserted to create a proposition. Recall that a proposition is a sentence that is either true or false (an “assertion” in Codd’s nomenclature). So each tuple in the relation is interpreted not as an instance of an entity but as a proposition, presumably a proposition formed by inserting names into the places of the predicate represented by the relation.

On its own, this remark of Codd’s would be scant evidence that such an interpretation had ever been intended. However, we should also bear in mind that:

This is precisely the interpretation that is directly represented in the domain calculus, which is effectively the FOPC, whose variables range over (ambiguously) either the values in tuples or things named by the values in tuples.
 
The “relational algebra” is nothing but the Boolean algebra of polyadic predicates, an algebraic representation of the predicates of the FOPC.
 
Historically, as the very term “relation” shows, relations were indeed predicates (called “relations” in the first instance to distinguish them from the traditional, Aristotelian, monadic predicates). The meaning of the term was, we might say, “extensionalised” by the mathematicians. We start from a predicate like “... is father of ...”, and the propositions formed from it by inserting names in its places:
 
Abraham is father of Isaac.
Isaac is father of Jacob.
Jacob is father of Reuben.
Jacob is father of Dinah.
 
Now we slightly misinterpret “a dyadic predicate is true or false of things taken pairwise” to mean “a dyadic predicate is true or false of ordered pairs of things”. It actually means: predicates are true or false of things; of course, for a dyadic (triadic, polyadic) predicate the things have to be taken two (three, many) at a time to make it true or false. But, ignoring such scruples (as mathematicians do) we get the ordered pairs:
 
(Abraham, Isaac)
(Isaac, Jacob)
(Jacob, Reuben)
(Jacob, Dinah)
 
So we take the predicate, “... is father of ...”, which we now call “FATHERHOOD”, to be true of these pairs. Then, to handle the positioning – because Abraham and Isaac have to be in that order for it to be true that the first is father of the second – we “number” or index the elements of the pairs by names, say FATHER and PERSON, instead of 1st and 2nd. This gives us unordered pairs (of ordered pairs!)
 
{(FATHER: Abraham), (PERSON: Isaac)}
{(FATHER: Isaac), (PERSON: Jacob)}
{(FATHER: Jacob), (PERSON: Reuben)}
{(FATHER: Jacob), (PERSON: Dinah)}
 
And now we write the name that stands for the predicate, and factor out the indices of the places, to get the familiar “relation”:
 
FATHERHOOD:  FATHER    PERSON
             Abraham   Isaac
             Isaac     Jacob
             Jacob     Reuben
             Jacob     Dinah
 

Here then is what we have asked for: a language interpretation of records; moreover, one that has a formal basis, the FOPC. And this interpretation does cover the data manipulation operators.

 

Data Manipulations Interpreted

 

 

The FATHERHOOD relation is interpreted as:

x is father of y
If we form its Cartesian product with (another copy of) itself, we get a relation interpreted (according to the interpretation of Cartesian product) as:
x is father of y AND u is father of v
Now the equijoin (on CHILD of the first and PARENT of the second):
x is father of y AND y = u AND u is father of v
The projection (of FATHER and CHILD of the first, CHILD of the second):
$u x is father of y AND y = u AND u is father of v
And, to get the composition, another projection:
$y $u x is father of y AND y = u AND u is father of v
So the composition – let us take a special case, Isaac and Dinah – is interpreted as:
There is something and there is something, and they are identical, and that identical something has Isaac as father and is father of Dinah.

Or, in a word: Isaac is paternal grandfather of Dinah. If we wanted an intelligent front end to interpret “paternal grandfather” we would have to give it the definition:

x is paternal grandfather of v  =df  $y  x is father of y Ù y is father of v
It should then be able, given knowledge of the kept FATHERHOOD records, to formulate and have performed the Cartesian product, equality restriction, and projections. This “classical” interpretation of relations and the manipulations on them underlies not only the relational algebra and domain calculus but also other, “semantic” data languages. See, for instance the description of Datalog in [Korth], or that of EFDM in [Gray]. It is not clear why, in the light of this marked resemblance between relational and some “semantic” systems, the classification chosen by these authors should put the relational model with the hierarchical and network models, which really are (it seems) without a “real world” interpretation.

 

Foundations of the Classical Interpretation

 

 

In the design of a database, either directly or indirectly, we attempt to define kept records (tuples in base relations) in one of the higher normal forms (second through fifth), which means – in essence – that we decompose records, using the projection operation, in such a way that we can recompose them using natural joins. These two operations are also of major importance in the formulation of other views and of user queries. We need therefore to understand their interpretations in terms of the FOPC, and to understand the constraints that arise from those interpretations.

Let us use “a”, “b”, “c”, etc. for names, and (as usual) “x”, “y”, “z”, etc. for variables of the FOPC. A predicate – a relation type, or record type – is written as P(x), Q(x,y), R(x,y,z), etc. and accordingly a record (tuple) instance as P(a), Q(a,b), R(a,b,c), etc. The values in such a tuple are, it should be noted, interpreted as names.

A projection is interpreted as the existential quantification of the columns that are not projected. Thus, the projection of the second and third columns of R(x,y,z) is:

$x R(x,y,z)
Notice that each such quantification yields a predicate with one less place: while R is triadic, the quantified predicate shown above is dyadic. (A similar effect is given by substituting a name for a variable, thus:
R(a,y,z)
This is roughly what would be effected by a restriction on R with condition “x = a”.) Looking at a particular instance, the same projection of R(a,b,c) gives us:
$x R(x,b,c)
Recall that R(a,b,c) is a proposition, a true or false sentence; and so is its projection, above. If no projection operation is to mislead a user (whether a human user, a program, or an intelligent front end), i.e. if no proposition is to be false when it is a projection of a true proposition, then we require that the following be an implication (guaranteed by the logic):
R(a,b) ® $x R(x,b)
This severely constrains what may be used for “a”, i.e. as a name. To take an obvious example, let R be “... is a child of ...”, and let a be “no-one” and b be “Diogenes”. From “No-one is a child of Diogenes” we cannot derive “There is something that is a child of Diogenes.” But this is merely to show that there are some constraints on what counts as a name; we need to identify what those constraints are.

There is one simple way to state the constraint we need: “a” is an acceptable name, as far as making projection safe, if all instances of the following schema hold true:

R(..., a, ...) ® $x R(..., x, ...)
We will need to consider natural joins before we can fully constrain allowable names, but we can now consider one class of names – or, more strictly, places – that overthrow the required implication. Following [Geach], consider the (true) proposition:
Hannibal worshipped Moloch.
If we construe this as formed from the dyadic predicate, “... worshipped ...”, by inserting the names “Hannibal” and “Moloch”, we can project the worshipper and get:
There is something such that Hannibal worshipped it.
I.e. There is something that Hannibal worshipped. But there is not: these false gods are, as Isaiah tells us, nothings. “Moloch” does not name anything; and the place in “Hannibal worshipped ...” has the strange property of intentionality: inserting such a pseudo-name as “Moloch” in it can create a true proposition. Intentional places in “predicates” pertain to objects of seeking, aiming, or striving towards: and we may seek, aim, or strive towards (including “worship”) things that are not there at all.

The FOPC does not admit intentional predicates. Of course not, “P(a) ® $x P(x)” is a theorem of the FOPC. Notice that “... worshipped Moloch” is a perfectly acceptable predicate. Strictly, it is places – not predicates – that are intentional.

Intentionality is not a problem restricted to theological data bases. Do we have a vacancy record showing that we wish to employ an expert on French, Algerian, and Sudanese law? It does not follow that there is an expert on French, Algerian, and Sudanese law that we wish to employ (or, indeed, at all). Have we signed a contract to deliver a ruggedised processor for use in the Antarctic? It does not follow that there is such a ruggedised processor that we have signed a contract to deliver.

On the face of it, it looks as if quite a lot of the values in our databases might be pseudo-names in the intentional places of predicates, and that an incautious projection might lead our users from truth to falsity. Human users, with application domain knowledge, may avoid being misled (despite our worst efforts); intelligent front ends face a somewhat bigger challenge.

In projection, therefore, values give us problems if they are supposedly names, yet fail to designate anything at all. We now turn to natural joins, where, we shall find, values give us problems if they designate more than one thing. If, as illustrated above, we join by Cartesian product and restriction – as we do in some data manipulation languages, including SQL, but not for database design (higher normalisation) purposes – we might hope that the equalities used would be encapsulated: their meanings given by the data types (the domains) of the joined columns. But implementation of encapsulated types is, alas, rare in current relational systems. It is obvious that we would wish the equijoin of FATHERHOOD to have its equality, “=”, interpreted as “is the same person as” (and applying over a domain of persons).

But apparently (it is, it seems, nowhere clearly stated) the equality used in equijoins and other restriction conditions, and implicit in natural join, is intended to be, at least, the systemic identity of the system, and probably absolute identity. But what is “the system” of which it is the systemic identity? It is the theory that comprises (at least) the FOPC itself and the propositions represented by each record kept in the database.

As we have seen, if it is the systemic identity that is intended, there may be radical re-interpretation in store for us as we incrementally design the database. If we keep data about species and breeds, our systemic identity may well hold between any two animals of the same breed. Introducing records about individual animals will require a new systemic identity, and may therefore require reformulation of every query and view definition that uses “=” to mean the old systemic identity (“is the same breed as”).

If “=” is intended invariably to mean absolute identity, our database of breeds is in error (perhaps not perceptible) even before we add information on individual animals. Two animals of the same breed are not absolutely identical. And then adding the extra information gives us the same problem, in practical terms, as it did with merely systemic “=”. But it leaves us with more niggling doubts, for even two things that are one and the same individual animal are not absolutely identical.

Again, we need to consider whether this is a practical problem. Suppose that we have records interpreted as:

S1 supplies P1
P1 is used in J1
S1 is a supplier, P1 a part, J1 a project. A hackneyed example: we form their composition. Notice that we apply the logic perfectly mechanically: if we have not already gone wrong, the formalism protects us.
There is something that S1 supplies and (that very same thing) is used in J1.
I.e. S1 supplies something that is used in J1: the classical join trap. We know that S1 could supply P1 and P1 be used in J1 without S1 supplying anything that is used in J1. For “P1” names, let us suppose, x and y, and x is distinguishable from y within the system – perhaps S1 supplies x and S1 does not supply y (because S2 does), and this “supplies” predicate is a component of the system (it is the predicate used in “S1 supplies P1”). x is not systemically identical to y.

It should be stressed that this join trap, and many others, are not fallacies; they do not involve human mistakes in informal logic. The argument – the interpretation of the composition – is flawless. The mistake is the use as a value of something that is not a proper name (does not name one and only one thing) under the systemic identity. The mistake is in the interpretation of the kept records; not in the interpretation of the query.

What follows from this? Perhaps we can ensure that each value in our database is such a proper name, and – on any modification to the database – ensure that each value is still a proper name, and make appropriate adjustments to all affected views and queries. But, if we cannot do this (unless we are happy to allow our users to derive falsehoods from truths), the classical interpretation is ruled entirely out of court.

We cannot, in practice, perform this massive policing job on our databases; neither initially nor intermittently thereafter. Think of all the values we keep. What will it take to ensure that “green”, “2.5 kilograms”, “Wednesday”, and so on are invariably interpreted and used as proper names? So we have to abandon the classical interpretation, and along with it the interpretations of the relational algebra, the domain calculus, Datalog, and so on.

But we can at least say this for the classical interpretation: it was so well specified that it could bring about its own definitive destruction. Contrast the entity interpretation which is too malleable and ductile to stand any argumentative strain. Decisive refutations are to be welcomed. But, even more, robust reconstructions; to which we will shortly turn.

 

Self-Interpretation

 

 

We may be convinced that, because often their values are not proper names, our databases have serious problems of interpretation, including join traps. But the refutation above seems to show that we have overwhelmingly serious problems; that our databases do not work at all. But we know they do. We have surprisingly few problems of interpretation. Why?

Suppose we wished to keep records showing which persons worshipped which false gods. We would (let us assume, ignorant of intentionality) have a two column relation, WORSHIP, with columns, WORSHIPPER and DEITY. We can give the records in this table a perfectly respectable interpretation:

The sentence formed by prefixing ... and suffixing ... to “worshipped” is true.
To form a record (a proposition) we would insert “‘Hannibal’” and “‘Moloch’” into the places of this predicate. Notice that what we are inserting may be thought of as names of names:
The sentence formed by prefixing “Hannibal” and suffixing “Moloch” to “worshipped” is true. I.e. “Hannibal worshipped Moloch” is true. I.e. Hannibal worshipped Moloch.
What, for practical purposes, makes true the proposition represented by this record? It is the record itself. To find whether “Hannibal worshipped Moloch” is true the system searches the WORSHIP relation, and there finds the (Hannibal, Moloch) record. So the records in the database are interpreted in terms of themselves. And that is safe: the only identity with which we are concerned is typographical (or bit configuration) identity, which is unproblematical. And, as each name is represented by the character string (or bit string, or whatever) that it designates, we can be quite confident that each value names one and only one thing.

We are, so to speak, processing forms; without necessarily giving a second thought to what those forms tell us about “the real world”, the world outside the record-keeping facility. And yet users of such databases do derive from them information about the world. Of course, human users know that an employee record tells us that there is such and such a person employed by the company, that a delivery note gives information about some delivered goods, and so on. But these interpretations are entirely informal.

When a user is misled by a join trap in such a system, strictly speaking, the analyst is innocent (merely technically innocent, we might judge). All the analyst was committed to was:

The sentence formed by prefixing “S1” and suffixing “P1” to “supplies” is true.
The sentence formed by prefixing “P1” and suffixing “J1” to “is used in” is true.
The analyst can claim: I never used “P1” as a proper name, or indeed at all. I used “‘P1’” as the proper name of “P1”, which it is. Technically, we have to blame the user because this interpretation, self-interpretation, in terms of the records themselves, is utterly safe (for the analyst!); but it really is “record-oriented”. It has no interpretation in terms of “the real world”, nor even of English utterances about the world (other than the database itself).

And this is why our databases are not the disasters that we might expect. They are magnetic stores of forms: and our users know how to interpret, and even how to manipulate, their own forms. Our databases need to capture no external interpretation at all; their human users can still get by. For intelligent front ends, and even human users on a bad day, it is a different story.

We should perhaps understand the tuple calculus (including SQL) in this way. Its variables range over (so the entities of its theory are) tuples in relations. And we can understand the domain calculus and the relational algebra as pertaining to values in records, and not to anything designated by those values. Notice that for the “inherently self-representing” records, like invoices, this is a perfectly acceptable interpretation: far from such records being problematical, they are the only records with an unproblematical interpretation.

Some idea of human users’ subtlety, and how much mistaken (or merely absent) interpretation it covers, can be appreciated from the following:

We have CAR records, with Car-Id and Model. We say that they mean, “Car ... is of model ....” And we have MODEL records with Model, Material, and Test-Method. We say that they mean, “Car model ... is framed in ... and has been tested as follows: ....” Here are two specific records:
(Car-Id: F197PDU) (Model: 740)
(Model: 740) (Material: Steel) (Test-Method: Dummy Destruction)
They mean: F197PDU is a model 740; the model 740 is framed in steel and tested to destruction by a dummy. The user understands that.
 
So, we ask, has F197PDU (as we would expect from the natural join) been tested to destruction by a dummy? No, of course not. Some car that is a model 740 has been tested like that, but not F197PDU. So, we confidently assume, we cannot conclude that F197PDU is framed in steel, merely that some car that is a model 740 is framed in steel, but not necessarily F197PDU. Oh no: F197PDU is a model 740, and – as you see – the model 740 is framed in steel, so F197PDU is framed in steel.
That is how our users – with immense ingenuity, and bringing to bear massive knowledge of their application domain – interpret our databases; better than we might ever have hoped. And then we blame them for the few join traps that they miss. They deserve better of us; which we now attempt to provide.

 

 

Return to the start of A New Interpretation of Data.
Reread this section of A New Interpretation of Data.

 

Continue reading A New Interpretation of Data
with the section on THE EPI INTERPRETATION.

 

 

SITE HOME PAGE

 

 

THE DATABASE PAGE

 

THE DATABASE PAPERS

 

DOWNLOAD

Download A New Interpretation of Data in Restricted Text Format (rtf, Word for Windows compatible)

Another database paper ...

 

Copyright © 1994, 2001 Adrian Larner. The author asserts all moral rights.

The decorative image of a key (cc004239.gif) used on this page was obtained from IMSI's MasterClips/MasterPhotos© Collection, 1895 Francisco Blvd East, San Rafael, CA 94901-5506, USA.