From: Peter F. Patel-Schneider (pfps@research.bell-labs.com)
Date: 02/02/01
From: Jim Hendler <jhendler@darpa.mil> Subject: Re: Concrete types: next steps? Date: Thu, 1 Feb 2001 23:56:57 -0500 > folks- > Been following the conc. types argument but staying quiet (a rarity > for me). I don't feel strongly on the issue, although I have a > suspicion that I tend to side with Dan and Tim away from a strong > separation. > I do want to propose a way forward - based on my now infamous "no > aesthetic arguments" edict -- what I really meant was that when we > had issues that seemed to have multiple ways ahead, instead of > arguing based on "what looked good" we would try to propose some use > cases that required the new features (i.e. start with a relatively > minimal language, add features only when people said "i need an X" > and showed the current language really couldn't handle it, and not > worry too much about things that could be mapped to one another by > the computer). > In this case, Dan has created an example in his mailing about using > the XML schema types in RDF. When I tried back of the envelope to > translate these into the Peter/Ian style (whcih I admit I did very > quickly and ad hoc) I didn't see a lot of problems with doing so. I strongly agree with Jim's comments here. What Ian and I have tried to do is precisely a solution to the 10 vs 10.0 problem that Dan discusses in the first two-thirds of his document (modulo the issues having to do with rdf:value, which I don't really understand). We tried to import as much machinery as possible completely intact, and with as little change as possible to the existing proposal. > So I find myself asking for some specific examples of the > DIFFERENCES between the two approaches in terms of something I can DO > in one and not in the other (yes Peter, I know there are semantic and > computational differences, but I'm a stupid DARPA guy and can't > understand these deep issues - I need to see some practical examples) The operational difference appear, to me, to be two-fold: 1/ Combination classes cannot be formed in Ian's and my approach. That is, you can't create the class of ``integers greater than 15 or people with two brothers who are doctors''. 2/ The only concrete classes that can be formed are those that are part of the concrete type system (in this case XML Schema datatypes). That is, you can't create the class of integers who used to be the number of employees of AT&T at the beginning of every month in the last year. My view (and I think that Ian and Deb would agree) is that these classes are not very useful, or at least that they can be avoided. In particular, the second class would much better be modelled as a sequence of integers, not as a class of integers. Even if you really want an unordered collection, an existential set (i.e., not an intensional class) appears to be a suitable choice. > -JH peter
This archive was generated by hypermail 2.1.4 : 04/02/02 EST