Re: added diagrams to "Using XML Schema Data Types..."

From: Dan Connolly (
Date: 02/08/01

pat hayes wrote:
> PPS. Any objections to putting this discussion onto rdf-logic? It
> seems to belong there.

no, no objection.

> >Another way to state this principle is that
> >the knowledge contained in two documents, X and Y,
> >is always the conjunction of the knowledge in X with
> >the knowledge in Y. To allow X to change what Y says
> >in some non-monotonic way doesn't seem scalable/workable
> >to me.
> two points:
> (1) you need to get clear about what counts as a document and what
> you take X and Y to be *about*. (content language or meta-language,
> see above.) If 'documents' are any amount of information about
> anything, then this is an impossible requirement. (Suppose I want to
> say 'either X or Y'. If I conjoin X or Y then I've said too much; if
> I don't include them then nobody is going to know what I'm talking
> about.)
> (2) Jim Hendler is right. If the meaning of Y depends in part on the
> meaning of X, that doesnt automatically produce nonmonotonicity. It
> just means that one has to use X to figure out the meaning of Y. The
> monotonicity would be produced, maybe, if one insisted on making
> assumptions about the meaning of Y without knowing X, which might
> later turn out to be wrong. But sometimes you can wait until you do
> know, or report back to something else that you can't make progress
> until you are told, or whatever. I agree these complexities make for
> boring reading, but I don't think that there is any way out, in
> general: we are going to have to deal with things like this whether
> we want to or not, ultimately because INFORMATION is like this. It
> just is, however we encode it. Life is not a monotonic conjunction of
> cherries.

I am not convinced; I'm not even quite sure we're talking
about the same thing. I'm not talking about any deep
sense of what the formulas mean; I'm just talking about
knowing what formula you're looking at without having
to look anywhere else.

Let me try a few mundane examples
from programming langauges to illustrate...

Consider ex1.c:

	#include "otherThingy.h"
	#include <stdio.h>

	main(int argc; char **argv)

The meaning of ex1.c -- what program it contains, or how
to compile it to ex1.o -- depends on otherThingy.h. It's
either a program that prints "x" or a program that prints "y", but
we're not sure which without looking in otherThingy.h.

On the other hand, consider ex2.c:

	int printf(const char*, ...);
	int otherThing();

	main(int argc)
		if(otherThing() < 10){

we can tell what this compilation unit means; we can
compile it to ex2.o. It's a program that calls the otherThing()
function, and depending on the result, prints "a" or "b".

I'm happy to have one RDF/DAML+OIL document interact with
another in ex2 style, but I'm not happy for the syntactic
meaning of an RDF/DAML+OIL document to be dependent on another
in the way that ex1.c depends on otherThingy.h.

I don't see how you can claim that there is something fundamental
about information that forces our language to include
garbage like the C preprocessor. Surely we can design our
language so that the formulas contained in each document
are syntactically evident, no?

KIF has this property, after all. You either write

	(size x "10")
	(size x 10)

and there's nothing that can be written in some other
file (or some other part of this file, for that matter)
that will change the formula that a given piece
of KIF represents.

CycL is an example of making the choice the
other way: the syntax of formulas depends on context;
	(both (tall Fred) (green TheCar))
might be a two-place predicate applied to two
function terms, or a new logical connective
applied to two predicates, depending on whether
(isa both Connective) is true when it's parsed.

A related issue came up in the design of
XML namespaces. It might seem more convenient
if you could just open a bunch of namespaces
and use names from any of them ala:

	<aDoc xmlnss="http://example/fruits

but that's no good because it's not syntactically
evident wither tomatoe is a fruit or a vegetable
(or... if you're a dumb computer: a mineral).

This was part of a whole requirements document
about extensible languages:

  Lack of ambiguity 

  Some programming languages allow one to introduce
  identifiers from new name spaces in such a way that
  it is not possible to know which namespace a local identifier
  belongs to without accessing both the module interface
  specifications and checking which one has with the highest
  priority, or  most recently in the document, redefined a given
  local identifier. 

  This may have some uses in a programming language such
  as Java[Java], but it has a serious flaw in that when one
  module changes (without the knowledge of the designers of the
  other module), it can unwittingly redefine a local identifier
  used by the second module, completely changing the meaning of
  a previously written document. Clearly, in the Web world in
  which modules evolve but documents must have clearly defined
  meanings, this is unacceptable.  Contrast with Modula-3,
  where all names are either lexically scoped or fully
  qualified [SPwM3]. 


> > > In particular, it seems to me that your proposal has exactly the same
> > > problem.  You also depend on external information on how properties should
> > > work.
> >
> >But the various bits of information accumulate in
> >the normal monotonic fashion; I don't have
> >the situation where I initially parsed it as
> >a string, but then I discover I was wrong or something
> >and I have to undo stuff.
> If you don't parse until you know how to parse, you won't get into
> this position. So what you really want, I think, is to know (locally
> and absolutely, ie monotonically with respect to new info. from
> elsewhere) whether or not you do have enough information to parse
> monotonically. (In many languages, for example, a parser on finding
> an identifier will look it up in a table of declared forms and if it
> isnt there, will post an error condition and refuse to compile.) But
> that's not the same as requiring that you must have, locally, enough
> information to parse. Same point applies to other things as well as
> parsing, of course.

Yes, we could go there without introducing the problem
I'm trying to avoid, but I don't see sufficient reason to.

> Pat Hayes
> PS.  Dan, thanks for stating these design principles in black and
> white. I think that more discussions at this level about what people
> see as their over-riding aims and basic assumptions would be very
> useful. Knowing them would have been very helpful to me in
> understanding the rationale for the  RDF design decisions, for
> example.


Dan Connolly, W3C
office: tel:+1-913-491-0501
  (put return phone number in from/subject)

This archive was generated by hypermail 2.1.4 : 04/02/02 EST