W3C home > Mailing lists > Public > public-sws-ig@w3.org > December 2003

Re: Cross-ontologies reasoning

From: Adrian Walker <adrianw@snet.net>
Date: Sun, 28 Dec 2003 19:59:35 -0500
Message-Id: <5.0.2.1.2.20031228193847.02cd51f0@pop.snet.net>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 16 March 2008 00:10:53 GMT