Open Worlds, Distribution, Delegation, Federation, Logic, NILE, etc

This may or may not be obvious: one tremendous benefit of the
triple-set model is that completely transparent distribution and
delegation becomes so much easier that we can probably do them.  

This is what I was trying to do with NILE.  (It stands for
Notation-Independant Logic Engine, a relatively unimportant fact that
I couldn't seem to remember while digesting lunch, for those of you at
the RDF-IG meeting Tuesday).

Putting this as clearly as I can this morning, speaking to this
diverse audience, here's how distribution and delegation can work:

   1. Do all your communication as passing triples of constant terms
      (that is: RDF with some reasonable answers to some items on the
      issues list).  

   2. This means the "RDF API" looks like this:

	    Foo.tell(Term subject, Term predicate, Term object);

   3. You get information back by asking for it to be sent somewhere.
      For instance, you might (somehow) create a Term for your own
      tell() interface (Bar), then present a graph-matching pattern
      along with that "return address" for the query results.
 
   4. This is a universal API.  It works for everything.  You can put
      a triple store below it, obviously, but you can also put any
      kind of software below it.  Two extreme examples:

            You can put a unix kernel below it, using a vocabulary of
            the system call names and a vocabulary of bytes and
            mutable byte-sequences that can point each other.

            You can put UDP+TCP/IP below it, with a vocabulary of
            ports and addresses and byte-sequences, letting you talk
            to anything on The Internet.

      These examples subsume each other, since in theory the unix
      kernel can talk on the internet, and on the net you can make
      connections to unix machines, where you can talk to their
      kernels.

   5. If your query structure works with the "open world" assumption,
      then you can talk to anything below or _above_ the API, without
      even knowing the difference.  Fred poses a query to a generic
      triple store, looking for all Widgets between $20 and $30.  The
      triple store answers the query with what it knows -- perhaps it
      tells Fred about 2 particular.  Meanwhile, some widget sellers
      have meta-queries in the triple store: they presented queries
      about queries about widgets.  That leads the triple store to
      send them Fred's query, and they can tell him about their
      widgets.

   6. Some of these external information providers are self-contained
      and stateless.  All they do is get triples (perhaps responses to
      meta-queries) and offer back triples.  They can be coded as pure
      functions (no side-effects) in any programming language, or as
      the kind of rewrite rules in NILE.  (I'm vague on the theory of
      expressiveness of logics, but that's what I was aiming for.)

      (Where I was eventually trying to go with the Peano arithmetic
      example in NILE was to show this equivalence, where some
      application can use integer relations (ie arithmetic) which
      might be provided in either the rewrite rules I showed OR in
      some bit of C code, and the behavior (aside from performance)
      would be indistinguishable.  The theory is obvious and it seemed
      like a good demonstration.  It opens the door for all sorts of
      compilation-of-logic systems and various solutions to the
      performance problems in an obvious/naive implementation of this
      architecture.)

I suspect I'm not the only one who sees this as an RDF use-case,
particularly when I see the resistance to using negation-as-failure
and closed-world systems, but I haven't heard this talked about.

I don't have a web page about this right now, but when I do (in a few
hours maybe?) I think I'll make it "http://www.w3.org/2001/03/open".
If you see me at the Tech Plenary today & tomorrow, by all means talk
to me about it.

      -- sandro    
         http://www.w3.org/People/Sandro

Received on Thursday, 1 March 2001 10:31:49 UTC