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

Re: Cross-ontologies reasoning

From: pat hayes <phayes@ihmc.us>
Date: Wed, 24 Dec 2003 13:20:14 -0800
Message-Id: <p06001f45bc0fa9d12493@[]>
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 

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 
>>>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 :))
>>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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:11 UTC