From: Michiel Trimpe
Subject: RDF Lispverse
Date: 
Message-ID: <38d78$45ef2791$d55d9cd8$22213@news.chello.nl>
Hey guys,

I'm new to c.l.lisp and new to Lisp, but I've known it's the way to go 
for quite a couple of years now (stuck in J2EE because I wanted 
investors.) I have one idea though that I'd like you guys to give some 
feedback on. What if we create an RDF based Lispverse?

We start storing our Lisp code in RDF and we create a massive collection 
of Lisp code stored in RDF.

For example, say I'm creating a function for extracting all Dutch words 
from a  text. Let's say my program is located on 
http://www.mysite.com/textprocessing. Now I would create an RDF node 
there called 
http://www.mysite.com/textprocessing/Function#extract-dutch-words.

Locally I could simply reference this function using it's namespace as 
regular, but the interesting part is that an entirely different program 
could reference the same RDF node. For example, the function on 
http://www.competitor.com/textanalysis/Function#extract-language-words 
could then reference my function, download it on the fly, and execute it 
locally.

We could even allow for a very simple construct to indicate that the 
program shouldn't even try to download it, but that it should be 
executed remotely. If I see it correctly, it would also be very simple 
to port existing Lisp software.

Doesn't that just feel like an almost instant approach to truly 
ubiquitous, everyware, distributed, ICT 2.3-beta, web 2.8, semantic, 
computing for the future?

Anybody like?

-- michiel trimpe

Victory usually goes to those green enough to underestimate the 
monumental hurdles they are facing - Richard Feynman

From: Alex Mizrahi
Subject: Re: RDF Lispverse
Date: 
Message-ID: <45ef6b1a$0$90266$14726298@news.sunsite.dk>
(message (Hello 'Michiel)
(you :wrote  :on '(Wed, 07 Mar 2007 21:58:42 +0100))
(

 MT> Doesn't that just feel like an almost instant approach to truly
 MT> ubiquitous, everyware, distributed, ICT 2.3-beta, web 2.8, semantic,
 MT> computing for the future?

almost :)

but you'd better better define how it could work, how is this connected with 
RDF (because only RDFish thingie i see in this post is URI reference and 
node terminology), how it will be better than asdf-install etc.

while you're defining this, i'll add my few ideas about uniquitous.. etc 
thing:

1. it would be extremely cool to have a code in a for of triples. actually 
standard RDF vocabulary define thingie like Lisp's CONS, so there's no 
problem (except maybe size, but who cares).
this would allow not only reference not only functions, but each atom of 
source code. this will allow to have source-level semantic code versioning.

2. i think HTTP is not good for RDF. there should be a global database (with 
versioning, access control, etc) -- or distributed database, so RDF 
semantic-level search could be done without guessing first where to get 
document containing RDF statements..

and i'm actually going to implement this. at first in a form of publically 
editable triple store, and a publically editable function definitions, with 
functions able to retrieve data from triple store and format it for user. 
you see, it's somewhat (distantly) related to RDF Lispverse you're 
proposing.

)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"?? ???? ??????? ?????") 
From: Michiel Trimpe
Subject: Re: RDF Lispverse
Date: 
Message-ID: <9388a$45efe724$d55d9cd8$32174@news.chello.nl>
  > but you'd better better define how it could work, how is this 
connected with
> RDF (because only RDFish thingie i see in this post is URI reference and 
> node terminology), how it will be better than asdf-install etc.

OK, got your point. Will do that. It's better than asdf-install b.t.w. 
because you can create code that doesn't actually download any specific 
until the actual invocation of the functions.

> 1. it would be extremely cool to have a code in a for of triples. actually 
> standard RDF vocabulary define thingie like Lisp's CONS, so there's no 
> problem (except maybe size, but who cares).
> this would allow not only reference not only functions, but each atom of 
> source code. this will allow to have source-level semantic code versioning.

Yep, left that out in the original post but that definitely needs to be 
included as well.

> 2. i think HTTP is not good for RDF. there should be a global database (with 
> versioning, access control, etc) -- or distributed database, so RDF 
> semantic-level search could be done without guessing first where to get 
> document containing RDF statements..

Agree, HTTP is irrelevant for this. Only clunky. Actually I would like 
to throw RDFLisp statements at a server and get the same back. The 
database is indeed necessary, but I'm first going to focus on a use-case 
in which the RDF source locations are known.

> and i'm actually going to implement this. at first in a form of publically 
> editable triple store, and a publically editable function definitions, with 
> functions able to retrieve data from triple store and format it for user. 
> you see, it's somewhat (distantly) related to RDF Lispverse you're 
> proposing.

It's related quite closely actually, I'm curious about your 
implementation. Keep me updated when you release an alpha version!
From: ············@gmail.com
Subject: Re: RDF Lispverse
Date: 
Message-ID: <1173387474.717563.68600@j27g2000cwj.googlegroups.com>
That sounds like a really cool idea, though you might want to consider
some security issues -- e.g. you might want some sort of signature
system so that whenever you download the code, you have some assurance
that nobody has intercepted the transmission and replaced it with
arbitrary malware.  (Imagine somebody is downloading your code over an
insecure wireless link, for example.)

mfh
From: ···············@gmail.com
Subject: Re: RDF Lispverse
Date: 
Message-ID: <1173397584.638550.122400@8g2000cwh.googlegroups.com>
On Mar 8, 10:36 am, Michiel Trimpe <·······@trimpe.nl> wrote:

> OK, got your point. Will do that. It's better than asdf-install b.t.w.
> because you can create code that doesn't actually download any specific
> until the actual invocation of the functions.

This sounds like the ultimate in late binding which certainly earns
geek kudos but I was wondering what the practical benefit was? Can I
override this behavior to avoid large downloads during the execution
of my program?

That said, making libraries easier to get hold of and use is one of
those things that greatly adds to the usability of a language or
environment so good luck with your project.

Phil
From: Michiel Trimpe
Subject: Re: RDF Lispverse
Date: 
Message-ID: <d2baf$45f10491$d55d9cd8$11857@news.chello.nl>
> This sounds like the ultimate in late binding which certainly earns
> geek kudos but I was wondering what the practical benefit was? Can I
> override this behavior to avoid large downloads during the execution
> of my program?

I think of it more as dynamic binding. You can lazy bind, eager bind, 
late bind & download define fetch sets.

The most important aspect I believe is when you add remote calling. 
Think of web-services of which you can download certain logic and 
execute it locally if you want it's too slow.