Last night an issue was raised on the RDF
IG IRC channel
about the DAML
naming of `daml:UnambiguousProperty`

and `daml:UniqueProperty`

. Dan Connolly
pointed to the fact
that the Web Ontology WG isn’t happy
with the current names, and is looking for better ones. A discussion
ensued, where such suggestions as `webont:OneToMany`

/`webont:ManyToOne`

and
`webont:FunctionalProperty`

/`webont:InverseFunctionalProperty`

were brought up as alternatives. The latter appear to be leading
the chase with WebOnt WG.

In this context, I also began wondering what one‐to‐many, many‐to‐one, injectivity, surjectivity, uniqueness and unambiguity have to do with each other. I’ll try to gather up some of my thoughts, below.

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
`#pragma`

s 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.

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.

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:

- 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.
- 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?