<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>An Ontology for Formalising Agreement Patterns in Auction Markets</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Jose J. Duran</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Carlos A. Iglesias</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Centro para las Tecnolog as Inteligentes de la Informacion y sus Aplicaciones (CETINIA), Universidad Rey Juan Carlos</institution>
          ,
          <country country="ES">Spain</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Depto. Ingenier a de Sistemas Telematicos, Universidad Politecnica de Madrid</institution>
          ,
          <country country="ES">Spain</country>
        </aff>
      </contrib-group>
      <fpage>53</fpage>
      <lpage>64</lpage>
      <abstract>
        <p>Knowledge and best practices on auction systems are currently disseminated across the research literature, which limits its access, reuse, evaluation and feedback by practitioners. This article presents a systematic approach to collect this knowledge as design patterns, in order to provide assistance to software developers. An ontology has been dened for formalising design patterns in auction systems, with the aim of improving its searchability by software developers. Finally, a case study illustrates how the proposed pattern ontology provides assistance in the development of a dynamic pricing model for an e-commerce service.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Introduction</title>
      <p>
        Auctions provide a market system model that enable the exchange of resources
on the basis of supply and demand. They have proved to be an e ective model
for dynamic pricing of resources in di erent scenarios such as electronic
commerce [
        <xref ref-type="bibr" rid="ref1">1</xref>
        ], resource allocation [
        <xref ref-type="bibr" rid="ref2">2</xref>
        ], service pricing [
        <xref ref-type="bibr" rid="ref3">3</xref>
        ] or sponsored search
pricing [
        <xref ref-type="bibr" rid="ref4">4</xref>
        ].
      </p>
      <p>
        Nevertheless, software engineers have few available resources that provide
them support in the design of auction mechanisms and automatic bidders, since
current knowledge and best practices on auctions are disseminated across
research publications. It is a good practice to identify the elements of good and
reusable designs in auctions, and provide a systematic framework for formalising
the experience with these designs. This is precisely the role of design patterns [
        <xref ref-type="bibr" rid="ref5">5</xref>
        ],
which describe general reusable solutions to commonly recurring problems in
software design. The notion of design patterns was originated in the
objectoriented software engineering community and has been widely accepted by this
community, having a strong impact on how object-oriented software is designed,
implemented and communicated nowadays.
      </p>
      <p>The purpose of this article is to provide a structured and formalised schema
for describing design patterns in the eld of agreement technologies and validate
it through its application in the domain of auctions.</p>
      <p>The rest of the article is organised as follows. Section 2 presents an
ontology for describing agreement patterns, in order to provide standard facilities
for retrieving patterns based on the user requirements. This agreement patterns
ontology has been linked with an auction domain ontology for describing the
main concepts of the auction domain, in order to provide a common language
for describing the auction patterns. In order to show the applicability of our
approach, a case study is developed within section 3. Finally, section 4 summarises
the main contributions of this paper and the future research activities.
2</p>
      <p>
        Modeling an Ontology for Auction Patterns
Even though design patterns are usually expressed in natural language, several
works have proposed its formalisation in order to provide tool support for
consulting a pattern catalogue and guide developers in its application. Ontologies [
        <xref ref-type="bibr" rid="ref6">6</xref>
        ]
have been considered as a natural formalisation technique that enables an
infrastructure for sharing and interconnecting semantically pattern languages in the
web. Several works have used ontologies [
        <xref ref-type="bibr" rid="ref7">7</xref>
        ] for formalising both the structure of
the patterns [
        <xref ref-type="bibr" rid="ref8 ref9">8,9</xref>
        ] (how to apply the pattern) as well as its intention (when to
apply the pattern) [
        <xref ref-type="bibr" rid="ref10 ref7">7,10</xref>
        ].
      </p>
      <p>
        This article presents an ontology for formalising the intention of agreement
patterns in order to improve its ndability. The ontology is organised into three
levels as shown in g. 1 which are detailed below. The rst level de nes an
ontology (APO) for agreement patterns (section 2.1), with the aim of
facilitating the searchability of the patterns by software developers. A domain ontology
(AUTERMS) for the auction domain (section 2.2) provides the common
terminology for describing auction patterns. Finally, an ontology (AUPA) has been
de ned for describing the auction patterns (section 2.3) . This ontology extends
the APO ontology and is described using the AUTERMS ontology.
Agreement patterns [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ] provide a way to collect best practices for reaching
agreements in a structured way. In this section, the Agreement Patterns Ontology
(APO) is introduced in order to catalogue agreement patterns. This catalogue
should support developers in choosing a pattern for a given problem.
      </p>
      <p>
        In order to determine the scope of the ontology, the ontology should be able
to answer the following competency questions [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ]:
{ Which design patterns can solve a given problem?
{ Which design patterns can solve a given problem and are applicable in a
given context?
{ Which design patterns are related to a given domain concept?
{ Which design patterns are available for a given task?
      </p>
      <p>
        The proposed ontology is based on the structure of the DPIO ontology[
        <xref ref-type="bibr" rid="ref7">7</xref>
        ].
That ontology describes the relationship between patterns and problem types,
which are described by problem constraints. We have extended DPIO by focusing
on pattern constraints, instead of problem type constraints.
      </p>
      <p>apo:relatedPattern apo:hasConstraint
apo:ProblemType
apo:solves
apo:Pattern
apo:relatedConcept
isA
isA
isA
apo:Concept
apo:Constraint
apo:ArchitecturalPattern
apo:OrganisationalPattern</p>
      <p>apo:BehavioralPattern</p>
      <p>
        The structure of the APO ontology is depicted in g. 2. The main
relationships of the core ontology are described below. A Pattern can solve one or more
ProblemTypes and is applicable only if some Constraints are ful lled. A Pattern
can be related with other Patterns. Domain Concepts can be related with one or
more ProblemTypes and one or more Patterns. Patterns are organised according
to the task they solve into:
{ Organisational Patterns. These patterns collect social structure patterns
which de ne the norms, social and interaction model [
        <xref ref-type="bibr" rid="ref13">13</xref>
        ] which form the
society as a whole, and which determine, to some varying degree, the
actions of the individuals socialised into that structure.
{ Behavioural Patterns. These patterns collect individual behaviours of the
participants in the agreement in order to satisfy a goal.
{ Architectural Patterns. These patterns describe architectural patterns
describing the software architecture of the participants in the agreement.
2.2
      </p>
      <sec id="sec-1-1">
        <title>The Auction terms Ontology (AUTERMS)</title>
        <p>
          The objective of the Auction Terms Ontology (AUTERMS) is modelling the
auction domain in order to provide a common vocabulary for describing
auction patterns. Previous work have also proposed ontologies in the negotiation
domain [
          <xref ref-type="bibr" rid="ref14 ref15 ref16">14,15,16</xref>
          ], and have been extended to the auction domain, but we have
not found a speci c ontology in the auction domain. We have modelled a basic
ontology based mainly on the auction patterns proposed by Re [
          <xref ref-type="bibr" rid="ref17">17</xref>
          ], the research
survey on auctions by Parsons et al. [
          <xref ref-type="bibr" rid="ref1">1</xref>
          ] and the ontology for the agent
trading competition developed by Wellman [
          <xref ref-type="bibr" rid="ref18">18</xref>
          ]. The core structure of the proposed
ontology AUPA is shown in g. 3.
        </p>
        <p>aupa:AuctionHouse
aupa:manages</p>
        <p>aupa:Auction
aupa:registeredUsers aupa:hasBids
aupa:auctionType
aupa:Bid
aupa:offers</p>
        <p>aupa:AuctionProtocol
aupa:madeBy aupa:offers
hasProperty
aupa:Participant
aupa:Resource</p>
        <p>aupa:AuctionProperty</p>
        <p>
          The main concepts of this ontology are AuctionHouse, Auction, Participant,
AuctionProtocol and AuctionProperty. Auctions are a negotiation process in
which di erent Participants exchange information in the form of O ers in
order to obtain a Resource. Those Auctions are placed in di erent AuctionHouses
which represents the auctioneer of an Auction. An AuctionHouse has the
responsibility of sharing Auction information between di erent Participants following
the rules of a speci c AuctionProtocol. An AuctionProtocol represents which
AuctionProperties must be meet in a speci c Auction. An AuctionProperty helps to
classify an AuctionProtocol in order to nd the most suitable based on the
problem constraints.
Previous works have also proposed the usage of design patterns in agreement
technologies and auctions. Iglesias et al. [
          <xref ref-type="bibr" rid="ref11">11</xref>
          ] propose Agreement Patterns for
formalising recurring solutions to agreement problems. Re et. al. [
          <xref ref-type="bibr" rid="ref17">17</xref>
          ] propose
auction patterns from an object oriented perspective. In the eld of multiagent
systms, Oluyomi [
          <xref ref-type="bibr" rid="ref19">19</xref>
          ] proposes a classi cation scheme for agent oriented patterns
which is applied to a relevant number of agent patterns. Jureta et al. [
          <xref ref-type="bibr" rid="ref20">20</xref>
          ] describe
three agent oriented patterns in the auction domain.
        </p>
        <p>
          This article extends the work developed by Iglesias et al. [
          <xref ref-type="bibr" rid="ref11">11</xref>
          ] in order to
organise, identify and describe semantically auction patterns as a speci c family
of agreement patterns. In order to validate our approach, several patterns have
been formalised within this ontology. Fig. 4 shows these patterns grouped by
the related Concept in the domain on AUTERMS ontology. In addition, the
auction patterns are classi ed in Architectural, Organisational and Behavioural
according to the APO Ontology.
        </p>
        <p>The pattern catalogue includes the following patterns:
{ Organisational: AuctionPattern, English Auction, Dutch Auction, Vickrey</p>
        <p>
          Auction, First Price Sealed Auction
{ Architectural: Lying Agent [
          <xref ref-type="bibr" rid="ref21">21</xref>
          ], AA Agent [
          <xref ref-type="bibr" rid="ref22">22</xref>
          ], Basic Negotiation Agent [
          <xref ref-type="bibr" rid="ref19">19</xref>
          ]
{ Behavioural: Proxy Bidding [
          <xref ref-type="bibr" rid="ref20">20</xref>
          ], Sniping, Dispute Resolution [
          <xref ref-type="bibr" rid="ref20">20</xref>
          ],
Payment [
          <xref ref-type="bibr" rid="ref20">20</xref>
          ], Fraud Detection [
          <xref ref-type="bibr" rid="ref20">20</xref>
          ], Colussion, Estimate Market Value.
        </p>
        <p>
          In order to illustrate how auction patterns are described, the pattern Vickrey
Auction is described in natural language in table 1, while its semantic description
is depicted in g. 5 and g. 6. The ontology has been de ned using the ontology
editor Protege [
          <xref ref-type="bibr" rid="ref23">23</xref>
          ]. Thanks to the semantic description, the catalogue can be
consulted and ltered according to the user constraints, as described in section 3.
        </p>
      </sec>
      <sec id="sec-1-2">
        <title>Name</title>
      </sec>
      <sec id="sec-1-3">
        <title>Alias</title>
      </sec>
      <sec id="sec-1-4">
        <title>Keywords</title>
      </sec>
      <sec id="sec-1-5">
        <title>Problem Type</title>
      </sec>
      <sec id="sec-1-6">
        <title>Problem</title>
      </sec>
      <sec id="sec-1-7">
        <title>Context</title>
      </sec>
      <sec id="sec-1-8">
        <title>Solution</title>
        <p>Vickrey auction
Second-price sealed-bid auction.</p>
        <p>Auction, service pricing.</p>
        <p>Resource assignation.</p>
        <p>Auction of multiple similar resources, or items, in which
participants should be encouraged to share their true
valuation using incentives.</p>
        <p>There are di erent consumers willing to get the resources,
and the real value of the resource is not known.</p>
        <p>This auction is de ned by the next properties, as seen on
g. 5 :
{ One round: Bids are received in a unique round, which
last until all participants have made their o er, or until
a speci c time.
{ Sealed: O ers are not visible, in any mean, to
partici</p>
        <p>
          pants, until the auction has nished.
{ Multiple items per bid: O ers should be for more
than a resource, and associated with a price. Only an
unique bid per participant.
{ Second pricing: the highest n bids are awarded the
resource and pay a price equal to the n+1 highest amount
bid.
{ Incentive compatibility: Each participant
maximizes its expected utility, by revealing their true
valuation, as nal price is not dependant on the o er made,
but in the last highest o er. Also, in scenarios with
different auctioned resources, a preference assignation of
resources, will be an incentive to bid as high as
possible [
          <xref ref-type="bibr" rid="ref24">24</xref>
          ].
        </p>
        <p>The most important advantage of this auction, is that
sellers don't require to have knowledge about buyers
willingness to pay. Because of that, this auction is highly suitable
in scenarios without that information.</p>
        <p>
          Examples Mobile spectrum assignment[
          <xref ref-type="bibr" rid="ref1">1</xref>
          ], Internet advertising[
          <xref ref-type="bibr" rid="ref25">25</xref>
          ].
Related patterns Sealed auction, Fake bidding.
        </p>
        <p>Table 1: Vickrey Organisational Pattern in Natural Language
3</p>
      </sec>
    </sec>
    <sec id="sec-2">
      <title>Case study</title>
      <p>In order to illustrate the practical application of agreement patterns, this section
describes a case study consisting of the development of an opera ticket selling
service.
// similar restrictions for # FixedProtocol , # SealedNegotiation ,
// and # UnidirectinalInformationExchange</p>
      <p>An opera thether desires to maximize its bene t from sold tickets, which are
sold by di erent online enterntainment ticket selling services. Several strategies
for o ering this service are available, such as de ning a xed pricing policy based
on position of the seat or dynamic pricing based on an auction protocol. The
opera theather desires to explore this second alternative.</p>
      <p>In order to evaluate the ontology, we are going to review the competency
questions enumerated in section 2.1, translate these consults into formal
questions in SPARQL, and evaluate the result set of the queries.</p>
      <p>Which design patterns can solve a given problem?. In our case, we are
interested in consulting all the organisational patterns that solve the problem
Resource Allocation. Fig. 7 shows the corresponding SPARQL query. The result
set contains all the Organisational Auction Patterns of the ontology. In a full
version of the ontology we could obtain other patterns not related with auctions,
such as bargaining.</p>
      <sec id="sec-2-1">
        <title>SELECT DISTINCT ? pattern</title>
        <p>WHERE {
? pattern rdfs : s u b C l a s s O f apo : O r g a n i s a t i o n a l P a t t e r n .
? pattern rdfs : s u b C l a s s O f apo : Pattern .
? pattern rdfs : s u b C l a s s O f [
rdf : type owl : R e s t r i c t i o n ;
owl : s o m e V a l u e s F r o m apo : R e s o u r c e A l l o c a t i o n ;
owl : o n P r o p e r t y apo : solves
}</p>
        <p>Which design patterns can solve a given problem and are applicable in a given
context?. The results of the previous query can be ltered specifying constraints.
In our domain, opera seats are auctioned. We can decide whether opera seats
are divisible or indivisible. In our case, we can sell all the seats for each opera
performances, but each seat can be sold at a di erent price, so we add the
constraint DivisibleResource. Fig. 8 shows the corresponding SPARQL query,
which would return the Vickrey Auction Pattern.</p>
        <p>Which design patterns are related to a given domain concept?. In our domain,
we could be interested in which design patterns are related with the Auction
House concept as shown in Figre 9.</p>
        <p>Which design patterns are available for a given task?. In case we desire to
de ne the architecture of a bidder, we can query the Architectural Patterns
related with the concept Participant (Fig. 10).</p>
      </sec>
      <sec id="sec-2-2">
        <title>SELECT DISTINCT ? pattern</title>
        <p>WHERE {
? pattern rdfs : subClassOf apo : Pattern .
? pattern rdfs : subClassOf apo : OrganisationalPattern .
? pattern rdfs : subClassOf [
rdf : type owl : Restriction ;
owl : someValuesFrom apo : ResourceAllocation ;
owl : onProperty apo : solves
].
? pattern rdfs : subClassOf [
rdf : type owl : Restriction ;
owl : hasValue apo : DivisibleResources ;
owl : onProperty apo : hasConstraint
}</p>
      </sec>
    </sec>
    <sec id="sec-3">
      <title>Conclusions and future work</title>
      <p>Design patterns can contribute to promote knowledge reuse and advance in the
eld of agreement technologies, since the expertise of practices is formalised and
can be easily shared among practitioners, allowing them to share their
experiences and understand better the advantages. limitations and applicability of
these patterns.</p>
      <p>In this paper, several auction patterns have been identi ed in the research
literature and described and classi ed according to a pattern form. In addition,
a domain ontology for auctions has been de ned in order to provide automated
reasoning on the application of patterns.</p>
      <p>
        Current work is focused on several directions. First, our aim is progressing on
the formalisation of the patterns themselves in order to provide and
ontologybased design pattern repository as [
        <xref ref-type="bibr" rid="ref26 ref7">26,27,7</xref>
        ]. Second, since the targeted users
of this research are software developers, our goal is providing at hand support
during their development tasks, through the integration of this tool in a
standard IDE such as Eclipse or Netbeans. In addition, this paper has presented
an initial set of identi ed patterns, and our aim is enlarging this set, analysing
available systems and documented practices as well as with the cooperation of
other researchers and users.
      </p>
    </sec>
    <sec id="sec-4">
      <title>Acknowledgements</title>
      <p>This research has been partly funded by the Spanish Ministry of Science and
Innovation through the projects Ingenio Consolider2010 AT Agreement
Technologies (CSD2007-0022)), OVAMAH (TIN2009-13839-C03-02) and T2C2
(TIN200806739-C04-03/TSI) as well as the Spanish Ministry of Industry, Tourism and
Trade through the project RESULTA (TSI-020301-2009-31).
Volume 5421 of Lecture Notes in Computer Science. Springer Berlin / Heidelberg
(2009) 318{331
27. Pavlic, L., Hericko, M., Podgorelec, V.: Improving design pattern adoption with
Ontology-Based Design Pattern Repository. IEEE (June 2008)</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <surname>Parsons</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Rodr</surname>
            guez-Aguilar,
            <given-names>J.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Klein</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Auctions and bidding: A guide for computer scientists</article-title>
          .
          <volume>24</volume>
          (
          <issue>2</issue>
          ) (
          <year>August 2004</year>
          )
          <volume>271</volume>
          {
          <fpage>287</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <surname>Lin</surname>
            ,
            <given-names>W.Y.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lin</surname>
            ,
            <given-names>G.Y.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wei</surname>
          </string-name>
          , H.Y.:
          <article-title>Dynamic Auction Mechanism for Cloud Resource Allocation</article-title>
          . IEEE (May
          <year>2010</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <surname>Szymanski</surname>
            ,
            <given-names>B.: A Novel</given-names>
          </string-name>
          <string-name>
            <surname>Auction Mechanism for Selling Time-Sensitive</surname>
            <given-names>E</given-names>
          </string-name>
          -Services. IEEE
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4.
          <string-name>
            <surname>Asdemir</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          :
          <article-title>Bidding patterns in search engine auctions (</article-title>
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <surname>Gamma</surname>
            ,
            <given-names>E.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Helm</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          , Johnson, R.,
          <string-name>
            <surname>Vlissides</surname>
          </string-name>
          , J.: Design Patterns:
          <article-title>Elements of Resusable Object-Oriented Software</article-title>
          .
          <string-name>
            <surname>Addison-Wesley Professional</surname>
          </string-name>
          (
          <year>1995</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <surname>Henninger</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          , Corr^ea, V.:
          <article-title>Software pattern communities Current practices and challenges</article-title>
          .
          <source>In: Proceedings of the 14th Conference on Pattern Languages of Programs (PLoP)</source>
          .
          <source>(September</source>
          <year>2007</year>
          )
          <fpage>2007</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7. Kamp meyer, H.,
          <string-name>
            <surname>Zschaler</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          :
          <article-title>Finding the pattern you need: The design pattern intent ontology</article-title>
          .
          <source>Lecture Notes in Computer Science</source>
          <volume>4735</volume>
          (
          <year>2007</year>
          )
          <fpage>211</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8.
          <string-name>
            <surname>Henninger</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ashokkumar</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          :
          <article-title>An Ontology-Based Metamodel for Software Patterns</article-title>
          .
          <source>at 18th Int. Conf. on Software Engineering</source>
          . . . (
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9.
          <string-name>
            <surname>Montero</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          , D az, P.,
          <string-name>
            <surname>Aedo</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          :
          <article-title>Formalization of web design patterns using ontologies</article-title>
          .
          <source>Lecture Notes In Computer Science</source>
          (
          <year>2003</year>
          )
          <volume>179</volume>
          {
          <fpage>188</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <surname>Harb</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bouhours</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Leblanc</surname>
          </string-name>
          , H.:
          <article-title>Using an Ontology to Suggest Software Design Patterns Integration</article-title>
          . Lecture Notes In Computer Science (
          <year>2009</year>
          )
          <fpage>318</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <surname>Iglesias</surname>
            ,
            <given-names>C.A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Garijo</surname>
            , Fernandez-Villamor,
            <given-names>J.I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Duran</surname>
            ,
            <given-names>J.J.:</given-names>
          </string-name>
          <article-title>Agreement patterns</article-title>
          .
          <source>In: Proceedings of the CAEPIA09 Workshop on Agreement Technologies(WAT</source>
          <year>2009</year>
          ), Sevilla,
          <fpage>WAT09</fpage>
          -
          <lpage>CAEPIA09</lpage>
          (November)
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <surname>Noy</surname>
            ,
            <given-names>N.F.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>McGuinness</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          :
          <article-title>Ontology Development 101: A Guide to Creating your First Ontology</article-title>
          .
          <source>Technical Report SMI-2001-0880</source>
          , Stanford Medical Informatics,
          <string-name>
            <surname>Stanford</surname>
          </string-name>
          (
          <year>2001</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <surname>Dignum</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Vazquez-Salceda</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dignum</surname>
            ,
            <given-names>F.</given-names>
          </string-name>
          <article-title>In: Omni: Introducing social structure, norms and ontologies into agent organizations</article-title>
          . Springer-Verlag, New York (
          <year>2005</year>
          )
          <volume>181</volume>
          {
          <fpage>198</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <surname>Tamma</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wooldridge</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dickinson</surname>
            ,
            <given-names>I.:</given-names>
          </string-name>
          <article-title>An ontology based approach to automated negotiation</article-title>
          . In Padget,
          <string-name>
            <given-names>J.A.</given-names>
            ,
            <surname>Shehory</surname>
          </string-name>
          ,
          <string-name>
            <surname>O.</surname>
          </string-name>
          ,
          <string-name>
            <given-names>C.</given-names>
            <surname>Parkes</surname>
          </string-name>
          ,
          <string-name>
            <given-names>D.</given-names>
            ,
            <surname>Sadeh</surname>
          </string-name>
          ,
          <string-name>
            <given-names>N.M.</given-names>
            ,
            <surname>Walsh</surname>
          </string-name>
          , W.E., eds.: Agent Mediated Electronic IV.
          <article-title>Designing Mechanisms and Systems</article-title>
          . AAMAS 2002 Workshop
          <article-title>on agent mediated electronic commerce (AMEC IV), held at the AAMAS 02 conference</article-title>
          , Bologna, Springer Verlag (
          <year>2002</year>
          )
          <volume>219</volume>
          {
          <fpage>237</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref15">
        <mixed-citation>
          15.
          <string-name>
            <surname>Tamma</surname>
            ,
            <given-names>V.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Phelps</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Dickinson</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wooldridge</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Ontologies for supporting negotiation in e-commerce</article-title>
          .
          <source>Engineering Applications of Arti cial Intelligence</source>
          <volume>18</volume>
          (
          <issue>2</issue>
          ) (
          <year>March 2005</year>
          )
          <volume>223</volume>
          {
          <fpage>236</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref16">
        <mixed-citation>
          16.
          <string-name>
            <surname>Paschke</surname>
            ,
            <given-names>A.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kiss</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Al-Hunaty</surname>
            ,
            <given-names>S.:</given-names>
          </string-name>
          <article-title>NPL: Negotiation Pattern Language. economics and management (</article-title>
          <year>2005</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref17">
        <mixed-citation>
          17.
          <string-name>
            <surname>Re</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Braga</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Masiero</surname>
            ,
            <given-names>P.:</given-names>
          </string-name>
          <article-title>A pattern language for online auctions management</article-title>
          .
          <source>Proceedings of PLoP</source>
          (
          <year>2001</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref18">
        <mixed-citation>
          18.
          <string-name>
            <surname>Wellman</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Wurman</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>O'Malley</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bangera</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Lin</surname>
            ,
            <given-names>S.d.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Reeves</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Walsh</surname>
            ,
            <given-names>W.</given-names>
          </string-name>
          :
          <article-title>Designing the market game for a trading agent competition</article-title>
          .
          <source>IEEE Internet Computing</source>
          <volume>5</volume>
          (
          <issue>2</issue>
          ) (
          <year>2001</year>
          )
          <volume>43</volume>
          {
          <fpage>51</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref19">
        <mixed-citation>
          19.
          <string-name>
            <surname>Oluyomi</surname>
            ,
            <given-names>A.O.</given-names>
          </string-name>
          :
          <article-title>Patterns and Protocols for Agent-Oriented Software Development</article-title>
          .
          <source>PhD thesis</source>
          , Faculty of Engineering. University of Melbourne, Australia.
          <source>(November 01</source>
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref20">
        <mixed-citation>
          20.
          <string-name>
            <surname>Jureta</surname>
            ,
            <given-names>I.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Kolp</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Faulkner</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Do</surname>
          </string-name>
          , T.T.:
          <article-title>Patterns for Agent Oriented e-Bidding Practices</article-title>
          .
          <source>In: Proceedigns of 9th International Conference on Knowledge-Based Intelligent Information and Engineering Systems (KES</source>
          <year>2005</year>
          ),
          <source>Part IIKES (2)</source>
          , Melbourne,Australia (
          <year>2005</year>
          )
          <volume>814</volume>
          {
          <fpage>820</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref21">
        <mixed-citation>
          21.
          <string-name>
            <surname>Koolmanojwong</surname>
            ,
            <given-names>S.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Jiamthapthaksin</surname>
            ,
            <given-names>R.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Daengdej</surname>
            ,
            <given-names>J.:</given-names>
          </string-name>
          <article-title>An agent architecture for competitive application environment</article-title>
          .
          <source>Aerospace Conference</source>
          ,
          <year>2004</year>
          . Proceedings.
          <source>2004 IEEE 3079{3089</source>
        </mixed-citation>
      </ref>
      <ref id="ref22">
        <mixed-citation>
          22.
          <string-name>
            <surname>Vytelingum</surname>
            ,
            <given-names>P.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Cli</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Jennings</surname>
            ,
            <given-names>N.R.</given-names>
          </string-name>
          :
          <article-title>Strategic bidding in continuous double auctions</article-title>
          .
          <source>Arti cial Intelligence</source>
          <volume>172</volume>
          (
          <issue>14</issue>
          ) (
          <year>2008</year>
          )
          <volume>1700</volume>
          {
          <fpage>1729</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref23">
        <mixed-citation>
          23. Stanford Center for Biomedical Informatics Research:
          <article-title>Protege ontology editor and knowledge acquisition system</article-title>
          . http://protege.stanford.edu/ (
          <year>2006</year>
          )
        </mixed-citation>
      </ref>
      <ref id="ref24">
        <mixed-citation>
          24.
          <string-name>
            <surname>Nishino</surname>
            ,
            <given-names>N.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Fukuya</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ueda</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          :
          <article-title>Service Design in Movie Theaters Using Auction Mechanism with Seat Reservations</article-title>
        </mixed-citation>
      </ref>
      <ref id="ref25">
        <mixed-citation>
          25.
          <string-name>
            <surname>Edelman</surname>
            ,
            <given-names>B.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Ostrovsky</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          :
          <article-title>Strategic bidder behavior in sponsored search auctions</article-title>
          .
          <source>Decision Support Systems</source>
          <volume>43</volume>
          (
          <issue>1</issue>
          ) (
          <year>2007</year>
          )
          <volume>192</volume>
          {
          <fpage>198</fpage>
        </mixed-citation>
      </ref>
      <ref id="ref26">
        <mixed-citation>
          26.
          <string-name>
            <surname>Harb</surname>
            ,
            <given-names>D.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Bouhours</surname>
            ,
            <given-names>C.</given-names>
          </string-name>
          ,
          <string-name>
            <surname>Leblanc</surname>
          </string-name>
          , H.:
          <article-title>Using an ontology to suggest software design patterns integration</article-title>
          . In Chaudron, M., ed.: Models in Software Engineering.
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>