From: Peter F. Patel-Schneider ([email protected])
Date: 02/07/01
From: Dan Connolly <[email protected]> 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 <[email protected]> > > 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 sizeDecimal). > > -- > Dan Connolly, W3C http://www.w3.org/People/Connolly/ > office: tel:+1-913-491-0501 > pager: mailto:[email protected] > (put return phone number in from/subject)
This archive was generated by hypermail 2.1.4 : 04/02/02 EST