RE: definition/assertion (WAS rdf as a base for other languages)

> Ah, now I have painted myself into a corner, since I never fully
understood the definition/assertion distinction myself, though it seemed

> central to many folk (and still does). Although to be fair, the idea
of a definition is a pretty common one in mathematics and life
generally, in > spite of its having no obvious logical content.

...

> Now, I can guess from your earlier emailings that you think of these
matters in a fairly strict model-theoretic way, as I do myself, and
within a > strict extensional model theory there really is no principled
way to make this distinction on logical grounds. 

It does indeed have an intuitive appeal -- I agree with you there is no
immediately obvious logical content, and I actually find that a bit
surprising. I have been pondering this issue, in one form or another, in
recent weeks as I have been interacting in my professional life with
engineers on constructing ontologies and representational systems.
Consider something simple like working with a "class of bachelors",
which by definition means that every instance of a bachelor must be not
married -- a married bachelor would be a logical error of an intuitively
different order than any other assertion, such as a bachelor's place of
residence or some such thing. I am seeking some "logic grounded' way of
expressing what is behind this, perhaps using some combination if and
only if statements, but have not been satisfied yet. 

You are correct in concluding that my academic training has been in
hard-core model theory, and the interaction with software engineers has
been a bit jarring. In my opinion years and years of Object-Oriented
dogma/brainwashing has created a generation of engineers who cannot
conceive of representational modelling that does not reduce everything
to simple property/value pairs attached to objects -- this has
apparently affected the creators of RDF as well, hence the insistence on
triples, subject-predicate-object, etc. that has become so familiar to
readers of the threads on this list. The loss of expressiveness that
this mind-set may entail for the future Semantic Web will be problematic
IMHO.

For example, it was pointed out in a recent posting on this list, I
cannot recall the exact one, that a triple connecting a parent with a
child, in a subject-predicate-object format of person-parentOf-child,
leaves much unsaid -- a parent may have several children. If predicates
serve as functions, then this "function" might not have a well-defined
value precisely because the value could be any of a number of children.
Of course one could make the object a list, but that too has drawbacks.
Logic long ago handled these matters by distinguishing between relations
and functions. But because relations can be multi-placed and do not
always fall neatly into the subject-predicate-object framework, they are
anathema to many, to the detriment of the representational tools.

The matter also relates to the definition/assertion issue. Suppose that
one wishes to express a common bank account for a couple. One
straightforward way would be to model this as a function on pairs or
2-tuples, so that one would have a function BankAccount(Homer,Marge) =
AZ3468 or whatever, and in a relational data-base this might appear as a
table with three columns. But of course, a function on pairs is
problematic to the folks who work with s-p-o triples, so the suggestion
I have heard is that one create objects called Couples, so that e.g. one
would have an object called Couple#34 with Member1(Couple#34) = Homer,
Member2(Couple#34) = Marge, BankAccount(Couple#34) = AZ3468. This can
work, but in the function on 2-tuples case, the "definition" of the pair
was "built-in" in the sense that the function would automatically
understand that it should deal differently with a pair
(Montgomery,Marge) as opposed to a pair (Homer,Marge) because the
identity of the pair is tied to the identity of it constituents.
Reducing it to the triples level means that the function Member1 is on a
par with the function BankAccount, and it seems as if the "identity" of
Couple#34 would be as little changed by changing the value of Member1
from Homer to Montgomery as it would if the value of BankAccount were
changed from AZ3468 to BX4579. Something, somewhere seems to have gotten
lost in the translation.


Cheers,

Ziv