OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

humanmarkup-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: HM.applications-Translations


The Hendler article is good for a first read as he fits it into the services
model as well.  Here is a 
condensed version from my notes:

Jim Hendler:  http://www.cs.umd.edu/users/hendler/AgentWeb.html

service class has three properties: 
a pointer to the service advertisement
a pointer to a service description, 
a declarative service logic.

An ontology language such as DAML+OIL used to define an ontology, not of
services, 
but of the terms needed to describe the invocation of services

ontology: start with classes such as State and Link and have special
subclasses 
such as StartState and EndState. Constraints and properties would be
described to 
give links a head and tail, to give states a list of the links that lead out
from 
them, and to give states a name, URI, and/or other identifying property.
This 
would provide a "base" ontology which specific types of service providers
could extend. 

agents coming to a page containing a service description could analyze the
FSM 
found there and would be able to determine the particular information needs
for 
invoking the service (and reaching an EndState). Thus an agent that had
access 
to a set of information about a user could analyze the FSM and determine if
that 
information would be sufficient for using this service. If not, the user
could 
be informed as to what additional information would be or some other action
could 
be taken. 

procedural invocation could be done by the agents letting them actually run
the 
services (without user intervention) thus allowing a very general form of
agent 
interaction with off-web resources.

The service class contains a pointer to a URI containing associated service 
logic used to express information that is beyond that found in 
the service description.  A rule such as

TransferOccurs(#cost,Service) := Reached(ServState11), ServiceCost(#cost)

might be used to represent the information that the actual transfer of funds
will 
occur upon reaching a particular site in the service invocation (ServState71
in this case). 

web agents that can use proof checking to confirm transactions. An agent
sends an 
annotated proof to another, where the annotations may be pointers to where
on the 
web a particular fact could be found or pointers to an ontology where a
particular 
rule resides. The agent receiving this proof can analyze it, check the
pointers 
(or decide they are trusted by some previous agreements) and check that the
ontology 
is one it can read and agree with. This allows the agent to recognize that a
valid 
transaction has occurred and to allow the funds to be transferred. 

Subrahmanian et al., 2000: discusses the use of deontic logics and agent
programs 
for multiagent systems. These logics, tied to the appropriate service
descriptions, 
can represent what an agent can do and when it may (or may not) do so.
Logical 
descriptions of services could also be used for automated matchmaking and
brokering, 
for the planning of a set of services that together achieve a user's goal,
and for 
other capabilities currently discussed, but not yet implemented "in the
wild," for 
multi-agent systems.

Assuming agents are communicating with each other (using the terms in these
ontologies 
for the content terms), then it is clear that if they point at the same set
of terms, 
then it is relatively straightforward for them to communicate. By linking to
these 
ontologies the agents commit to using the terms consistently with the usage
mandated 
in that ontology. Thus, if the ontology specifies that a particular class
has a 
particular property and that there is some restriction on that property,
then each 
agent can assume that the other has legal values for that property
maintaining that 
restriction, etc.

Two agents that are simply sending a single message (such as the invocation
of an 
online service as described above) may simply want some sort of quick, "on
the fly" 
translation limited just to the terms in a particular message. Another
approach may 
be to use very large ontologies, such as CYC (Lenat and Guha, 1990) to
actually infer 
mapping terms between agents in other ontologies. 


Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Sean B. Palmer [mailto:sean@mysterylights.com]

Has anyone read the Semantic Web roadmap [2]? I suggest people sit down
with a cup/glass/mug/tin/bucket of their favourite bevarage, and go through
it a few hundered times. The other Design Issues are quite good too,
although don't believe everything that you read (/Axioms especially).

[1] http://www.w3.org/2000/01/sw/
[2] http://www.w3.org/DesignIssues/Semantic


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC