- From: pat hayes <phayes@ihmc.us>
- Date: Wed, 24 Dec 2003 13:20:14 -0800
- To: Adrian Walker <adrianw@snet.net>
- Cc: public-sws-ig@w3.org
>Bijan, Graham -- > >The distinction between code and data is getting ever fuzzier.... Er... There has always been a fuzzy distinction between computation and description. Allow me to draw everyone's attention to a now venerable slogan, first widely publicized by my colleague Bob Kowalski in 1971: "Algorithm = logic + control". There were quite a flurry of papers on this topic in the early 70s; but the idea was probably first implemented in the mid-60s in systems like the Aberdeen ABSYS and the early SIMULA, and in fact can be traced back to the 1940/50s when Post and Church and Turing first noticed that lambda-calculus and its brethren can be viewed either as descriptive languages which describe functions, or as operational languages for manipulating them, and that the two views are almost indistinguishable: and of course it lives amongst us today as logic programming. However, there is a genuine distinction between state-free operations (which include monotonic reasoning and pure functional programming and, arguably, pure scripting) and state-dependent operations (which include nonmonotonic reasoning and most procedural programming such as Java). The point is not the executable/nonexecutable distinction, but whether the 'code' can be moved into a different context and 'executed' there freely, or whether on the other hand it is necessary to also transmit some kind of computational state, tied to a place in the code, to enable the execution to proceed. Is the code itself enough, or do you need to have a continuation for some virtual machine? I think that the hallmark of a being a useful thing to publish for transmission over an open, world-wide network lies in this kind of a distinction rather than the executable/description contrast. Pat Hayes > >See, for a simple example, MergeOntologies1 at www.reengineeringllc.com . > >As its name would suggest, it's a merge of two ontologies. It's >also executable, although not by means of Java, C or such. > >Comments ? Cheers, -- Adrian > > > >At 10:23 AM 12/24/03 -0500, you wrote: > >>On Dec 24, 2003, at 6:00 AM, Graham Klyne wrote: >> >>>At 18:21 20/12/03 -0500, Bijan Parsia wrote: >>>>Interesting, code sharing exactly occurred to me as a relevant >>>>thing to consider. >>> >>>I don't know if this is a useful perspective, but I've noticed >>>that code sharing seems to be much easier when programming in >>>Haskell compared with (say) Java or C. I find I can generally >>>pick up third-party functions and just use them, more easily than >>>with more conventional programming languages. >> >>Yes, the advantages of, oh, referential transparency had occured to me. >> >>>I can imagine two possible contributors to this effect: >>> >>>(a) ultimately, many Haskell expressions are just values, so in >>>some respects they're closer to data than to code. There isn't a >>>procedural aspect to get in the way (e.g. no need to coordinate >>>passage through the "von Neumann bottleneck"? cf. [1]) >>> >>>(b) the type system (being highly polymorphic, having much in >>>common with ML and friends) permits, even encourages, typing >>>details that are not relevant to some function to be left >>>unspecified. >>> >>>I'm not sure if this has anything to say about ontology sharing. >>>Maybe that reducing assumptions made by any given ontology makes >>>it easier to share? (Hmmm... that sounds almost obvious.) >> >>There are two issues (at least) with code sharing: Getting enough >>adoption so there's lots of code to share, and then making it >>relatively painless to share. >> >>There is a lot of *some* kind of code sharing going on . Take Java >>as one example. >> >>OWL like ontologies seem way closer to data sharing. Rules do get >>quite close to code sharing. Whether this is a difference that >>makes a difference is the question. >> >>Interestingly, of course, that expression (or code) as values seems >>to push code sharing toward data sharing. >> >>(Note, lest anyone mistake me: I think the data sharing problem to >>be highly non-trivial :)) >> >>Cheers, >>Bijan Parsia. -- --------------------------------------------------------------------- IHMC (850)434 8903 or (650)494 3973 home 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32501 (850)291 0667 cell phayes@ihmc.us http://www.ihmc.us/users/phayes
Received on Wednesday, 24 December 2003 16:19:36 UTC