Naming them DAML unproperties

Terminology

E‐R cardinality constraints are where the clearest definitions of one‐to‐one, one‐to‐many, many‐to‐one and many‐to‐many come from, so we’ll start by assuming knowledge of the relevant terms.

In this context, daml:UniqueProperty denotes a monodrome relation (a resource may not be related to anything, but if it is, it is related to at most a single property value) and daml:UnambiguousProperty a relation with a monodrome transpose (some things in the rdfs:range of the property may not be used as a value for any resource, but if they are, they are only used for a single resource). That makes daml:UniqueProperty a 0:N to 0:1 relation, which is a the class of many‐to‐one relations. daml:UnambiguousProperty is a 0:1 to 0:N relation, and becomes the class of one‐to‐many relations.

In fact, the DAML semantics are the widest possible for relations (that is, forgetting the possibility of multirelations). Any one‐to‐many or many‐to‐one relation can be embedded in a relation with the semantics of daml:UnambiguousProperty or daml:UniqueProperty, respectively. This suggests to me that webont:OneToMany and webont:ManyToOne are quite suitable as names for the unproperties. The only trouble comes from the fact that one‐to‐many, in the original E‐R sense, covers many‐to‐one as well, maybe leading to some confusion about the distinction between the two senses.

However, some references define the terms differently. They use one‐to‐many to denote any relation where at least one object in the domain is related to more than one object in the range. Many‐to‐one relations work the other way around, one‐to‐one relations are the ones which are neither many‐to‐one nor one‐to‐many and many‐to‐many relations are those which are both. I find this usage of the terms confusing, and judging by the discussion pointed to, above, RDF people understand the matter the way E‐R folklore has it. I don’t think this particular confusion would be an issue if webont:OneToMany and webont:ManyToOne were to be adopted.

Finally, I seem to recall a couple of expositions of database theory I’ve read using one‐to‐many and many‐to‐one to refer to ways of implementing a general relation. The first uses links embedded in the left hand component of an E‐R connection, the second on the right. (Such distinctions aren’t relevant for current RDBMS’s, of course.) But what’s interesting is the meaning given to many‐to‐many in this case—I seem to recall I’ve seen the term being used of multiway relations. What I mean by that is something most easily modelled by ordinary relations between the power sets of the domain and the range. That is akin to what TopicMap associations do (each association can have a variable number of participants, something which forces us to model such associations as a separate class in RDF), only the latter are undirected. Here, half an hour or so of Googling didn’t turn up a reference, so I guess this particular usage of the terms is not really significant to DAML considerations.

To extrapolate, the E‐R usage is in tune with the idea of relation types, while talking about the actual relations the way the second sense of one‐to‐many does, isn’t. Types are what we’re working with in DAML and WebOnt, so it hardly matters what the actual relations will eventually look like. I find it likely that people working with ontologies will interpret the term one‐to‐many in accordance with the E‐R definition, since relationship types are the subject here, not relations of those types.

So, my vote goes to webont:OneToMany and webont:ManyToOne. webont:FunctionalProperty and webont:InverseFunctionalProperty I consider worse than the current names, as they don’t tell practically anything about the properties they’re supposed to type. They actually lead me to think of something having to do with functionality, like #pragmas in C, which isn’t really something we would want to do in a static KR model.

Failing the above reasoning, some secondary suggestions I was able to come up with are:

daml:UnambiguousProperty

webont:NameLikeProperty

Not all unambiguous properties are actually names, but if one can understand how foaf:mbox works, this will ring a bell.

webont:CharacteristicProperty

An unambiguous property is a property which uniquely characterizes an object.

webont:InverseMonodromeRelation

If we want to be high‐brow, that’s what it is.

daml:UniqueProperty

webont:SingleValuedProperty

That’s what unique properties are, no? The only problem I can envision is that the single value isn’t a required one. The domain is 0:N, not 1:N, and somebody might well get confused.

webont:MonodromeRelation

If we want to be high‐brow, that’s what it is.

My dilemma

Then on to injectivity and surjectivity. If we take the E‐R/math definitions as a base, the formal connection is that a many‐to‐one relation is injective. A one‐to‐many one is a partial function, which means that it has an injective transpose. A one‐to‐many, many‐to‐one relation will be one‐to‐one, but not necessarily total. It can be restricted to its range and domain to give an ordinary, invertible (bijective) function. If we require a relation to be one‐to‐one and surjective, and to have a surjective transpose, that relation will become an invertible function in itself.

So, injectivity is highly relevant to one‐to‐manyness and many‐to‐oneness, while surjectivity is simply an added constraint which could be useful in connection with the others. It is the possibility of arriving at definitions of (partial) invertibility either via imposing both surjectivity and injectivity, or alternatively one‐to‐manyness and many‐to‐oneness, which easily makes us think of these four terms as intrinsically related.

Models and theories

Finally a brief note about models and theories, and about the sense in which those terms are used in RDF and mathematical logic. This has absolutely nothing to do with the above, or the title.

In math, models are a thing separate from logic theories. We say a model satisfies a theory if we can find a mapping of the real objects in the model to the variables of the theory which doesn’t lead to a contradiction. This means that we can do things like those done by DAML axiomatic semantics to the unproperties: the semantics are defined by giving a logic formula which makes two objects equal under certain conditions. If we try to interpret a model where the conditions do not hold, this leads to a contradiction, and we immediately see that the model does not satisfy the theory. Either the theory needs to be fixed or we have to find another model which satisfies the theory.

In math other than mathematical logic we work solely on the theory. Whatever we know about the world is what we can derive from the theory, and so it makes sense to actually equate two objects if the theory tells us they are the same. (This happens, for example, when we derive an equivalence to show that there is only one number satisfying a given constraint.)

In KR and RDF the situation is not so clear cut. KR languages, including RDF with the suitable high lever structure, are both substrates for reasoning and languages representing invariable real world data. So, what troubles me is the following: when should RDF objects be treated as part of an invariant, given‐from‐outside model, and when as a part of our theory, subject to whatever rules we have chosen as our axioms? Or more precisely, should there be a way to distinguish between the two, and if so, what should it be like? (After all, making the judgment seems very much AI‐complete.)

For a concrete example: suppose we encounter daml:UnambiguousProperty with the same value for two different objects. I see two equally good ways in which to deal with the situation:

1. Take the values to be a part of the model. In this case, they are separate and we immediately know that the model does not satisfy the theory. We raise a validation error; either the data is faulty, or we discard the theory and work out a new one which better describes the universe we’re working in.
2. We take the facts to be a part of our theory, and subject to its rules. The theory now tells us that two objects are the same, so that’s what they are. We merge them and end up having acquired some new information in the process. (We have suddenly become aware that two objects we previously thought were different are in fact the same.)

This is reminiscent of trust, but the issue isn’t quite the same. Somehow it also seems that flagging the difference could be extremely useful. Further, this all somehow brings blank nodes to my mind. Perhaps anonymous nodes are part of the theory while named ones belong to the model?

Reality doesn’t work that way, I know, but if I’m not reading TimBL entirely wrong, something akin to the above lives between the lines telling us about the virtues of anonymous resources. Or did I just forget to wake up, this morning?