From: Mike Beedle
Subject: L4: Lifestreams, Living Metaphor, Linda on the Web, LISP
Date: 
Message-ID: <SD%s8.255663$702.48760@sccrnsc02>
As I explained in my previous post, I think the "semantic web"
is being designed to be bloated, inefficient, and with low
standards.

Here is what I propose doing:

    Creating a "Killer App" Open Source project that
    competes with the current definition of the "Semantic Web"
    using Lisp and Lisp-friendly technologies as the
    primary backbone.

L4 (Lifestreams, Living Metaphor, Linda, Lisp), would probably
include things like:

     LISP, LISP code/libraries to do AI, CBL,
     LISP app and web servers (CL-HTTP, AllegroServe),
    Linda, LSP, REST, KIF/Ontolingua, Lifestreams,
    LISP Agents, Living Metaphor (aLife things0, KQML,
    FIPA acl, etc.

Here is more or less what I see:

1) Keep ontologies in Ontolingua within the Lisp App Servers.
http://www-ksl.stanford.edu/knowledge-sharing/

That means avoid putting too much intelligence
in "hard coded" web pages ;-)  The "semantic web":
http://www.semanticweb.org/
assumes that things like DAML+OIL will be:

 a) contained within the resource ("embedded"; e.g. in HTML).
 b) external to the resource but supplied by the
 transfer mechanism
 c) retrieved independently from the resource or
 d) may contain the resource ("wrapped"; e.g. RDF itself).

 So something like this:

 <rdf:RDF
    xmlns:rdf ="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
    xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
    xmlns:daml="http://www.daml.org/2000/12/daml+oil#"
    xmlns     ="http://www.daml.org/2000/12/daml+oil-ex#"
 >

 <daml:Ontology rdf:about="">
    <daml:versionInfo>$Id: daml+oil-ex.daml,v 1.4 2001/01/11 20:33:52 mdean
Exp $</daml:versionInfo>
    <rdfs:comment>An example ontology</rdfs:comment>
    <daml:imports rdf:resource="http://www.daml.org/2000/12/daml+oil"/>
 </daml:Ontology>

 <!--  [snip] >
      <rdfs:Class rdf:ID="Person">
        <rdfs:subClassOf rdf:resource="#Animal"/>
          <rdfs:subClassOf>
            <daml:Restriction>
              <daml:onProperty rdf:resource="#hasParent"/>
              <daml:toClass rdf:resource="#Person"/>
           </daml:Restriction>
      </rdfs:subClassOf>
      <rdfs:subClassOf>
        <daml:Restriction daml:cardinality="1">
          <daml:onProperty rdf:resource="#hasFather"/>
        </daml:Restriction>
        </rdfs:subClassOf>
      </rdfs:Class>

 <Person rdf:ID="Adam">
    <rdfs:label>Adam</rdfs:label>
    <rdfs:comment>Adam is a person.</rdfs:comment>
 </Person>
 <!--  [snip] >

 </rdf:RDF>

 may end up included in a web page.  This assumption
 is incorrect because for most companies in any non-trivial
 business, this information:

 a) varies dynamically.  In fact in large companies
 most web pages are now "generated" by app servers
 for a variety of reasons:
  - changing catalogues
  - changing prices
  - personalization
  - NLS issues
  - etc.
 b) it is too large to be included in web pages
 c) it may require stronger security concerns but more
 importantly,
 d) it lacks the _methods_ and _rules_ to do something
 interesting with the exchanges of information like:

  - business process management
  - supply-chain exchanges that are rule-oriented
  - distributed workflows
  - most complex AI tasks
  - intelligent "brokering" i.e. competition,
  cooperation, auctioning, coalitions,
  bidding/awarding, etc.

So, in conclusion, handle Lisp-like semantic requests
within the app servers not within the HTTP servers.

2) Use LISP-like snipplets for exchanges of knowledge i.e.
semantics, data and code, that use predetermined standards like
KIF, FIPA-acl and KQML CBL:
http://www-formal.stanford.edu/jmc/cbcl2/cbcl2.html

to do:
  a) ontological and knowledge requests
  b) data requests
  c) code transfers (exchange logic: classes, functions
  rules, patterns, etc.)
  etc.

  with basic exchanges like:

  (REQUEST-QUOTE (ADJECTIVE (PENCILS #2) YELLOW)
               (GROSS 100))

  have replies like:

  (WE-QUOTE (OUR-STOCK-NUMBER A7305)
      (QUANTITY 100)
           (DELIVERY-DATE 3-10-77)
                (PRICE $1.00))

Again, these "semantic" requests should be directly tunneled
into the app servers where the power to do AI resides -- not
directed to inherently dumb web pages!!!


3) Use Lisp app and web servers (CL-HTTP, AllegroServe):
http://sourceforge.net/projects/portableaserve/
http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html
to host agents and parse the exchanges defined in 2 above, to
take advantage of the _existing_ AI infrastructure/libraries
that already do a good job with:

  a) knowledge representation
  b) reasoning
  c) logical programming
  d) expert systems
  e) genetic programming
  f) game playing (plans, strategies, intentions, actions, etc.)
  g) parsing natural languages
  h) neural nets
  etc.

  because this is important to implement:

  a) voting
  b) auctions
  c) coalitions
  d) negotiation
  e) bidding/awarding
  etc.

Again, AI should be done from _within_ the app server
where the power is, and not from within the HTTP server
and its pages - leave those alone.  Most of them
will tend to be generated _dynamically_ over time anyhow.

4) Use the REST architectural style:
http://internet.conveyor.com/RESTwiki/moin.cgi/FrontPage?action=highlight&va
lue=RestArchitecturalStyle to do Client(browser)-to-App server or for
AppServer-to-AppServer
requests -- with URI opacity or without, whatever suits
your security needs.

5) Use AllegroServe style dynamic web pages, or server pages,
like LSP (Lisp Server Pages) to display HTML on clients
http://sourceforge.net/projects/lsp

6) Render machine-readable exchanges in a similar fashion
as AllegroServe serves dynamic web pages, but instead
format KIF, FIPA-acl and KQML CBL "documents" or
"requests" and enclose that in the HTTP response.

Clients can parse the results with standard Lisp-like parsers :-),
i.e. Lisp itself !!!

7) Use compression and encryption or request/responses
if necessary.

8) Devise a queueing mechanism for non-RPC exhcanges.

9) Use a Lifestreams architecture to store web data

and,

10)  Use Linda-like excahnges that do distributed computing
by offereing content/data pattern-matching over HTTP
(using a RESTful style, with opacity or without).


This is simple, elegant, compact, powerful, and
can be done with high performance, using the
Lisp tools and technologies that are available today:

This will truly deliver a distributed, intelligent and mobile
"Semantic Web".

- Mike
http://www.livingmetaphor.org

From: Mike Beedle
Subject: Re: Lifestreams, Living Metaphor, Linda on the Web, LISP
Date: 
Message-ID: <wZjt8.867$CH1.444@sccrnsc02>
Mike Beedle wrote:
>
>     Creating a "Killer App" Open Source project that
>     competes with the current definition of the "Semantic Web"
>     using Lisp and Lisp-friendly technologies as the
>     primary backbone.
>
> L4 (Lifestreams, Living Metaphor, Linda, Lisp), would probably
> include things like:
>
>      LISP, LISP code/libraries to do AI, CBL,
>      LISP app and web servers (CL-HTTP, AllegroServe),
>     Linda, LSP, REST, KIF/Ontolingua, Lifestreams,
>     LISP Agents, Living Metaphor (aLife things0, KQML,
>     FIPA acl, etc.
>
> Here is more or less what I see:
>
> 1) Keep ontologies in Ontolingua within the Lisp App Servers.
> http://www-ksl.stanford.edu/knowledge-sharing/
> 2) Use LISP-like snipplets for exchanges of knowledge i.e.
> 3) Use Lisp app and web servers (CL-HTTP, AllegroServe):
> 4) Use the REST architectural style:
> 5) Use AllegroServe style dynamic web pages, or server pages,
> 6) Render machine-readable exchanges in a similar fashion
> 7) Use compression and encryption or request/responses
> 8) Devise a queueing mechanism for non-RPC exhcanges.
> 9) Use a Lifestreams architecture to store web data
> 10)  Use Linda-like excahnges that do distributed computing
> by offereing content/data pattern-matching over HTTP
> (using a RESTful style, with opacity or without).

Does anyone have any ideas to implement a "semantic web"
using Lisp and Lisp friendly technologies?

I really like to hear what you have to say.

Mike Beedle wrote:
> This will truly deliver a distributed, intelligent and mobile
> "Semantic Web".

This is perhaps an exaggeration.  I probably should be phrased:

    This will get closer to deliver a distributed, intelligent
    and mobile "Semantic Web".

- Mike
From: Matthew X. Economou
Subject: Re: Lifestreams, Living Metaphor, Linda on the Web, LISP
Date: 
Message-ID: <w4ovgaw1co5.fsf@eco-fs1.irtnog.org>
>>>>> "Mike" == Mike Beedle <·······@e-architects.com> writes:

    Mike> Does anyone have any ideas to implement a "semantic web"
    Mike> using Lisp and Lisp friendly technologies?

I think semantic web technologies will fail because it is impossible
to capture the connotation of an object, as connotations are (a)
context sensitive and (b) client-side.  An object's denotation is at
best half of its complete meaning (syntax, semantics).

-- 
Matthew X. Economou <········@irtnog.org> - Unsafe at any clock speed!
"Genetic engineering lets us fix god's horrible, horrible mistakes...
 like German people." -Mr. Garrison [South Park]
From: Henry Lebowzki
Subject: Re: Lifestreams, Living Metaphor, Linda on the Web, LISP
Date: 
Message-ID: <3cbba08e.2451282@news.cis.dfn.de>
On 12 Apr 2002 23:48:42 -0400, "Matthew X. Economou"
<···············@irtnog.org> wrote:

>>>>>> "Mike" == Mike Beedle <·······@e-architects.com> writes:
>
>    Mike> Does anyone have any ideas to implement a "semantic web"
>    Mike> using Lisp and Lisp friendly technologies?
>
>I think semantic web technologies will fail because it is impossible
>to capture the connotation of an object, as connotations are (a)
>context sensitive and (b) client-side.  An object's denotation is at
>best half of its complete meaning (syntax, semantics).
>
>-- 
>Matthew X. Economou <········@irtnog.org> - Unsafe at any clock speed!

Hi-
	Aren't semantic webs more easily done in Prolog? (honest
question, not intented to start a flame-war).

	Regs
	H
From: Christopher C. Stacy
Subject: Re: Lifestreams, Living Metaphor, Linda on the Web, LISP
Date: 
Message-ID: <un0w4kos0.fsf@grant.org>
>>>>> On Tue, 16 Apr 2002 03:55:57 GMT, Henry Lebowzki ("Henry") writes:
 Henry> Aren't semantic webs more easily done in Prolog? (honest
 Henry> question, not intented to start a flame-war).

PROLOG gives you a calculus for computing certain kinds of 
inferences, but Lisp is a more general purpose language.
On the other hand, Lisp has no built-in logic resolver
of any kind, so you will have to write your own.
From: Brad Miller
Subject: Re: Lifestreams, Living Metaphor, Linda on the Web, LISP
Date: 
Message-ID: <a9igf7$f4j$1@newshost.mot.com>
"Christopher C. Stacy" <······@grant.org> wrote in message
··················@grant.org...
> >>>>> On Tue, 16 Apr 2002 03:55:57 GMT, Henry Lebowzki ("Henry") writes:
>  Henry> Aren't semantic webs more easily done in Prolog? (honest
>  Henry> question, not intented to start a flame-war).
>
> PROLOG gives you a calculus for computing certain kinds of
> inferences, but Lisp is a more general purpose language.
> On the other hand, Lisp has no built-in logic resolver
> of any kind, so you will have to write your own.

I think it's easier to write PROLOG in Lisp than Lisp in PROLOG, though I've
only done the former.

Depending on the particular features you need for your semantic net (which
is not a semantic web), it can be almost trivial in either language.
Constraints are hard in either, in lisp you need a prover, in PROLOG you
need to quote your constraints (since propositions are first order only),
and, effectively, write a prover.

The biggest advantage you'll have in Lisp is you can add syntactic sugar to
make writing your knowledge easier, and still be able to appeal to the Lisp
reader...

Best,
Brad Miller
From: Tomas By
Subject: Re: Lifestreams, Living Metaphor, Linda on the Web, LISP
Date: 
Message-ID: <wkg01vt0ht.fsf@basun.net>
"Brad Miller" <·················@motorola.com> writes:
> [...]
> The biggest advantage you'll have in Lisp is you can add syntactic sugar to
> make writing your knowledge easier, and still be able to appeal to the Lisp
> reader...

That can be done in Prolog too, either by defining operators (easy) or
using term_expansion/2 (little bit more tedious).

/Tomas
From: Jochen Schmidt
Subject: Re: Lifestreams, Living Metaphor, Linda on the Web, LISP
Date: 
Message-ID: <a9gg8i$hib$1@rznews2.rrze.uni-erlangen.de>
Henry Lebowzki wrote:

> Aren't semantic webs more easily done in Prolog? (honest
> question, not intented to start a flame-war).

What you probably mean is "semantic nets" which is a different thing and 
certainly not the same as the "semantic web".

(letting aside the question if or if not semantic nets are easier in Prolog
 compared to Lisp)

ciao,
Jochen

--
http://www.dataheaven.de