- From: Adrian Walker <adrianw@snet.net>
- Date: Sun, 28 Dec 2003 19:59:35 -0500
- To: pat hayes <phayes@ihmc.us>
- Cc: public-sws-ig@w3.org
Hi Pat -- [Pat] ...state-dependent operations (which include nonmonotonic reasoning...) ... [Adrian] Hmm. Nonmonotonic reasoning is surely only state-dependent if you insist on asserting the results ? One can deduce at time T that Tweety can fly, and fail to deduce it at time T+2, because at time T+1 someone added to the open network the fact that Tweety is a penguin. That's nonmonotonic, but no more state-dependent than monotonic reasoning. [Pat] 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. [Adrian] So, suppose we ship some rules and facts around the net in a suitable RDF form. Then, they can be merged with other sets of rules and facts -- that's an advantage of RDF. But in order for machines to do anything productive with them, each site will have to have to have an inference engine. And for this to be useful, each site had better have the same engine (or at least one that behaves the same.) So, beyond the work getting under way on a rules language for the SW, there is surely a need for something like a model-theoretic semantics of the future rules language. Then, folks can compete on finding efficient engines that implement the model theory. Cheers, -- Adrian INTERNET BUSINESS LOGIC www.reengineeringllc.com Dr. Adrian Walker Reengineering LLC PO Box 1412 Bristol CT 06011-1412 USA Phone: USA 860 583 9677 Cell: USA 860 830 2085 Fax: USA 860 314 1029 At 01:20 PM 12/24/03 -0800, you wrote: >>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 Sunday, 28 December 2003 19:59:38 UTC