53 | | A profile is a function that maps a bid to a real number in [0,1]. The higher the value, the more preferred is that bid. |
| 53 | A profile is a function that can tell if a bid is preferred over another bid. |
| 54 | There are a number of ways to do this: |
| 55 | * FullyOrderedSpace: this provides a function isPreferredOrEqual() that can tell if a bid is preferred over another |
| 56 | * PartiallyOrderedSpace: as FullyOrderedSpace, but may not know the answer for part of the bids |
| 57 | * UtilitySpace: as FullyOrderedSpace, but additionally this provides a function getUtility(bid) that maps the bid into a real in [0,1]. The higher the value, the more preferred is that bid. |
| 58 | |
| 59 | == Party |
| 60 | The party module contains basic interfaces for implementing your negotiation party. |
| 61 | The main class is Party, which defines the basic functionality required for every negotiation party. The heart of the party is that your Party implements Connectable<Inform,Action>. Connectable contains 2 main functions: connect and disconnect. When connect is called, your party receives a Connection over which it receives Inform objects and can send Action objects. What exactly is sent and received is determined by the protocol (see the protocol section below). For example if the SAOP protocol is used, your party will receive a YourTurn message, after which it decides on its action and sends it into the Connection. See also the example agent discussed below. |
| 62 | |
| 63 | The Inform objects are all available inside the inform package inside the party module. |
| 64 | |
| 65 | == Timeline |
| 66 | The timeline contains a deadline and a progress object. |
| 67 | The deadline indicates how much time a negotiation session can take. |
| 68 | The progress indicates where currently running session is towards the deadline. |
| 69 | |
| 70 | == References |
| 71 | Parties, domains, profiles and protocols are stored and used on remote machines. |
| 72 | We use IRI's (internationalized resource identifier, which looks similar to the well known URLs you use in your web browser) to refer to them. These IRI's are packed inside objects like the PartyRef, ProtocolRef, ProfileRef, DomainRef so that it is clear what type of object the IRI is referring to. |
| 73 | For example, when your party is initialized, it usually receives a Settings object that contains a ProfileRef. The intention is that the party fetches the actual profile from the web, using the IRI in the ProtocolRef. See the example agent below for an example. |
| 74 | |
| 75 | == BidSpace |
| 76 | The bidspace module contains functionality to support building a negotiation party. We currently have |
| 77 | * OpponentModel: this is a category of classes that can estimate the opponent's profile from the bids that he places. |
| 78 | * Pareto: this is a category of classes that can compute the pareto frontier from a set of profiles. Pareto optimality is an important mechanism to place optimal bids. |
| 79 | * AllBidsList: this can be used to craete a list containing all possible bids in a domain. This list is created in a lazy way, and competely avoids storing the whole list in memory (which might not even fit) |
| 80 | |
| 81 | |
| 82 | |
| 83 | |
| 84 | == Protocol |