Hello,
You mention:
Nice but probably not crucial to have object implementations and
queries
all in the same formalism, whether that's Prolog, Lisp, XSLT, etc.
E.g. the ability to query and program web services without a ad-hoc
interpreter running there.
I reply:
There are two formalisms that I propose using: RDF and SPARQL/Update.
RDF is to represent your API, runtime program, and virtual machine
and SPARQL/Update is the protocol for manipulating the network (e.g.
INSERT, DELETE, SELECT, ASK, etc.). There are many benefits to this
model. First I will articulate the benefit as realized by our current
objectives at LANL.
1. We are dealing with a 10 billion triple (edge) semantic network.
Some analysis can be done by harvesting subsets of the network and
performing our network analysis algorithms in main memory. However,
there are some algorithms that are just not possible with a 'main
memory' approach. Thus, we will move the processor and the algorithm
to the data. By embedding the processor in the data, we can rely on
any number of host hardware CPUs to calculate its evolution. As a
devil's advocate, we could write code that will selectively harvest
subsets as needed for the 10 billion edge calculation. However, the
general-purpose processor allows us to do more than just graph
algorithms.
2. When the virtual machine is represented in RDF, then the virtual
machine can be queried like any other aspect of the semantic network.
For instance, it is possible to write code that is interpreted by a
virtual machine that causes the virtual machine to re-write itself at
run-time. To my knowledge, no such mechanism exists in other
programming languages. For instance, the virtual machine of the Java
programming language is hidden to the programmer. One can not
manipulate main memory directory nor manipulate the JVM program at
runtime (the JVM is written in another language). This is not the
case in my proposed model of computing. The virtual machine is an
object much like any other object and can be manipulated as such.
There is much to be said of how this could be used in terms of
evolutionary algorithms.
3. The Semantic Web is a vision of a semantic network overlaid across
servers around the world. With the proposed programming paradigm, the
representation of virtual machines and software is yet another
component of this distributed semantic network. The Semantic Web
becomes a computing infrastructure that does not have a sense of its
underlying hardware support. Because virtual machines are represented
in the network, they can be evolved by any of underlying hardware
CPUs. When a hardware CPU leaves the computation, it does not effect
the state of the virtual machine. The virtual machine simply
'freezes' and awaits another hardware CPU to continue its evolution.
In fact, another RDF virtual machine can compute the evolution of the
'frozen' virtual machine. However, the network will always require a
grounding in the hardware to evolve. Please read section 4.1 of the
arXiv preprint for more on this topic.
4. There already exists a host of technologies to support the
Semantic Web: multi-billion triple triple-store servers, ontology
development environments, reasoners, etc. The model I proposed
requires very little investment by the community to use. The Neno
language that LANL is currently developing looks very similar to
Java. Once that hurdle is climbed, object-oriented programming is
possible on the Semantic Web. ... Again, the Semantic Web
automatically becomes a "[EMAIL PROTECTED]". It becomes a decentralized
computing platform without the standards issues seen by the Grid
computing community. There are RDF virtual machines (RVMs) and there
are RDF programs. If the underlying host machine has the process code
for the RVM architecture, it can execute it---thats it.
5. The programming language proposed by LANL has constructs that are
not possible (realistically) with other programming language. This is
due to the fact that the programming language has an underlying
network representation. There are some neat constructs that emerge
when the data structure is a network (e.g. inverse method invocation,
inverse field referencing, field cardinality, general object query
(automatic JavaSpaces)). Please refer to section 3 of the arXiv pre-
print.
6. Please refer to section 2 of the paper I submitted to arXiv for a
list of other benefits of this model.
7. There are still many issues concerning trust and rouge software
that has not been addressed by my arXiv pre-print. This will be
addressed in a future paper.
8. Please refer to http://www.soe.ucsc.edu/~okram/papers/random-
grammar.pdf for a specialized random walker RVM architecture.
Thanks for your time,
Marko A. Rodriguez
Los Alamos National Laboratory (P362-proto)
Los Alamos, NM 87545
Phone +1 505 606 1691
http://www.soe.ucsc.edu/~okram
============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
lectures, archives, unsubscribe, maps at http://www.friam.org
