Re: trusting external information

From: Peter F. Patel-Schneider (
Date: 02/07/01

From: Dan Connolly <>
Subject: Re: added diagrams to "Using XML Schema Data Types..."
Date: Wed, 07 Feb 2001 12:40:10 -0600

> "Peter F. Patel-Schneider" wrote:
> > 
> > From: Dan Connolly <>
> > Subject: Re: added diagrams to "Using XML Schema Data Types..."
> > Date: Wed, 07 Feb 2001 11:23:18 -0600
> > 
> > > "Peter F. Patel-Schneider" wrote:
> [...]
> > > > I would be much happier with a solution that had a single property, namely
> > > > size, that mapped directly into a datatype.  I don't see any benefits from
> > > > having these multiple properties; only disadvantages.
> > >
> > > The advantage is that parsing formulas (RDF documents)
> > > remains independent of other stuff, including trust issues.
> > >
> > > Otherwise, if I put the range(size, Decimal) information in
> > > in file X, and then I <size>10</size> in file Y,
> > > the interpretation of Y depends on whether I have seen
> > > (or believed etc.) file X. That doesn't seem workable to me.
> > 
> > Either you trust the definition of a property or you don't.  If you don't,
> > then you don't get to use the information therein, and lots of things may
> > break.  If you do, you do get to use the information therein, and
> > everything should work.  As far as timing goes, if you don't have
> > information on how to parse some input, why not defer the parsing until you
> > have more information?
> I'm not sure what you mean by "the definition of a property".
> Do you mean that there's always exactly one such definition?
> how much stuff goes in a definition? I know what documents
> are and I know what statements/formulas/assertions are.
> Maybe I can read "a document containing statements relevant
> to some property" in place of "the definition of a property."

Yes.  I'm not committing to the definition of a property being all in one
place.  Perhaps for this discussion, we might consider only the range
of a property, which may or may not (all) be in one place.

> As to why not defer parsing... a major goal of all this
> logic-and-the-web stuff, to me, is a certain sort of scalability
> where we can analyze documents independently, see
> what they mean (i.e. what formulas they state) and then
> merge information from multiple documents in a monotonic
> fashion. This is a major feature of RDF. It's something I
> would require even if we threw out RDF syntax and started over
> with XML and URIs.

I view this as a pipe dream.  Information is interconnected.  If you need
to use information about an object, you need to (possibly) go where that
information is defined.

> To have the parsing of one document depend on the
> contents of another conflicts with that goal/principle.

No more than having the interpretation of a document depend on the contents
of another, in my opinion.

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

I'm not arguing for this either.  I am, however, arguing for a scheme that
puts parsing outside of RDF (and DAML+OIL).

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

I'm not proposing a scheme where the input is parsed as a string.  I am
instead arguing for a scheme that defers parsing until typing information
is known.  I am also arguing that this parsing occurs outside of RDF (and
DAML+OIL).  This may impose some burden on RDF (and DAML+OIL) implementers,
but no more than a scheme that has to reparse (as in going from size to

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

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