performatives and trust

Seth Russell wrote:
>From: "Sandro Hawke" <sandro@w3.org>
>
>> The point is that some RDF vocabular terms need to be defined as
>> "operational" or "performative" for particular agents.
>
>I think all we need is just the one term, 'do'.  So the triple would be
>{Agent do Action}.  But the action is never performed unless it is issued
>through a privledged channel ... we wouldn't want an agent to to just read
>some RDF feed somewhere and act upon it.  Once a privledged command channel
>is opened to an agent the command triple might read something like {You do
>Jump17} ... Jump17 being a URI uniquely described by some trusted source.

I agree one term (eg "do") is enough, although I'm not sure if its
better to try to pick one or go ahead and use lots of them.  Another
single term that works is the class RequestedAction, as in
  {someAction rdf:type RequestedAction} 
where your target-agent information (which you might want to omit) is
connected by some predicate to someAction.

I don't see any need for a special channel for performatives.
Security is really orthogonal.  Getting the height of :jump17 right
may be even more important than whether it happens at all.  (It might
be that anyone's allowed to request jumps under 20cm, but above that
is a protected operation.)  The important thing here is for an agent
to be able to distinguish which information came from which sources.  

This can be addressed fairly well outside of RDF, or inside RDF with
the same kind of indirection we're talking about elsewhere in this
thread.  One option:

   // fetch two files and directly incorporate their triples
   kb.include("http://hawke.org/sandro-startup1");
   kb.include("http://hawke.org/sandro-startup2");
   // fetch another file and incorporate a description of
   // the contained triples, along with network security
   // data (presence of validated XML signatures, SSL, etc)
   Symbol r = kb.newSym();
   kb.read(r, "https://robustai.net/seths-claims");

And then you have some logic for figuring out which nodes off "r"
should be turned into assertions.

kb.read need not be primitive of course.  Perhaps it would be more
clear as

   KB kb2;
   SecInfo si;
   kb2.include_with_secinfo("https://robustai.net/seths-claims", si);

and then (perhaps using my programming language here, not RDF logic) I
look at si and kb2, and figure out what to put into kb.

One big advantage of the first form, where the security info and logic are
all in RDF triples, is that multi-stage trust (eg: I trust Eric to tell me
who to trust) is probably a lot simpler.

Has anyone implemented anything like this?   I've thought about it for
years but never gotten the lower layers happy enough to build up to
this.

    -- sandro

Received on Friday, 1 June 2001 15:12:58 UTC