1.Registration block send request of registration to super peer via PRP. Process re-registration will be done at specific period to info availability of provider peer, and when the export schema or common ontology are modified to info about the last update of the information. 2.PRP provider peer will communicate with PRP super peer, result of the communicate provider peer will get ID, and access to book keeping and common ontology. 3.Agreement process is carried out between the super peer common ontology and provider peer export schema. Result of agreement save at the provider peer. 4.Result of agreement will consider which part of metadata will put to super peer. This process through PAP 1.Local Data has three parts: local data, develop export schema tool, and handling query to local data from query respond manager. Export schema will based on export schema unit model. Handling query will need a wrapper/mapping from XML to local data model. 2.Registration block has function and interface to register to a super peer. The first time of registration to a supervisor will be done manually by administrator of provider peer. Re-registration will process in background and automatically based on specific period from super peer, and when there is changing of export schema or common ontology. 3.Agreement management process will based on Agreement Unit, which represent the 'transformation' between concept in export schema and common ontology. Result of agreement will be saved at provider peer and utilize for query processing. 4.Query respond manager, there are two steps in query, first step is to evaluate the query to agreement. There are three possibility, can answer, can not answer, maybe respond but consider differences of concept. The differences will solve through negotiation. Second step, query will send to local data with appropriate query language and database model. PRP PAP P2P Communication Infrastructure Provider Peer Super Peer Local Data Query Respond Management Agreement Management Registration PRPPAP P2P Communication Infrastructure Book Keeping Common Ontology Registration b 4a 3 3 2

1.The first process is request peer will adjust his concept to super peer common ontology. The purpose is to have the same reference as provider peer, so common ontology will be as 'pivot' point. The process 1a). Asking to super peer to get the common ontology, and 1b). super peer sending the common ontology to request peer. In this process request peer need 'register' to super peer. Performance of communication does not yet consider. 2.Base on the concept adjustment request peer in Query Sending Management will sent query to some provider peers through PQP. Selection of provider peer based on active provider peer and update content refer to super peer book keeping. The initial process is query writing based on concept adjustment, then follow by: 2a). looking for appropriate provider peer based on availability, current common ontology and metadata sending via PIP; 2b). send a query to PQP before sending to provider peer; 2c). submit query directly to appropriate provider peers via PQP; 2d). query will be processed at Query Respond Management 3.Provider peer will respond the query follow to steps: evaluate the concept and send query to local data. In first step 3a). there are three possibility respond: can respond, can not respond, or maybe respond. 3b). send query to local data through the local 'wrapper'. 4.In 'maybe respond', negotiation is needed to re-write the query. If the query possible to re-write, back to second step, if the query is not possible to re-write, query will be drooped. This follow negotiation feedback in two ways communication. 5.Assume the query can be responded, result of query to local data will send back to request peer via PAP. Request peer can receive from some provider peers with same the query. In this condition, process integration of respond is needed to get better result of the query. The process: 5a). Result send tu request via ParP; 5b). communication between peer; 5c). collect respond via ParP at request peer, integration respond will be done at this block. PQP PNPPArP P2P Communication Infrastructure Provider Peer Request Peer Local Data Query Respond Management Agreement Management Registration PQP PNP PIP PArP P2P Communication Infrastructure Query Management Respond Management Concept Adjustment 1b 2b 4 5a Common Ontology Book Keeping Super Peer 2a 3a 4 5c 4 5b 1a 3b 2d 2c 2a

● Peer Registration Protocol (PRP) is the mechanism by which a peer can send a register to one or more super peers, and receive a response (or multiple responses) of the ID. The PRP implements register and re-register to inform the availability and content. Result of PRP will be saved at super peer book keeping, which content of some information as provided by super and provider peer as follow: ● ID of peer (ID) ● address of peer based on IP (IP) ● time stamp or register (Tr) ● status of joint in the network based on Tr. ● time stamp of export schema (Te) ● version of common ontology used ● basic metadata (organization, contact person, date of first produced, date of last update, name of information, period of information, area of information, standard which used, small description of information) ● Peer Advertising Protocol (PAP) is the mechanism by which a provider peer can advertise its own resources, and discover the resources from other peers. Every peer resource is described and published using an advertisement. Advertisements are programming language-neutral metadata structures that describe network resources. Advertisements are represented as XML documents. The PAP works together with PRP. ● Peer Information Protocol (PIP) is the mechanism by a which a peer may obtain status information about other peers from super peer book keeping as result of PRP. In the future, it can be developed to include state, uptime, traffic load, capabilities, and other information. ● Peer Query Protocol (PQP) is the mechanism by which a request peer can send a query to some provider peers based on result of PIP. ● Peer Negotiation Protocol (PNP) is the mechanism by which a peer can establish a virtual communication channel or pipe between one or more peers. The PBP is used by a peer to bind two or more ends of the connection (pipe endpoints). Pipes provide the foundation communication mechanism between peers. The purpose of the pipe to negotiate between request peer and provider peer to get better respond of the query. ● Peer Answer Protocol (PArP) is the mechanism by which provider peers send a respond of the query from request peer. The result are represented as XML documents. Peer Registration Protocol (PRP) Peer Advertising Protocol (PAP) Peer Information Protocol (PIP) Peer Answer Protocol (PArP) Peer Negotiation Protocol (PNP) Peer Query Protocol (PQP) P2P COMMUNICATION INFRASTRUCTURE

● Registration has function to interface between PRP and book keeping, and has role to consider active provider peer based on re-register time stamp and update content based on re-register time stamp and common ontology version. Will write using Erlang/Java. ● Book Keeping maintenance information about member of provider peers at a community. The information represents at XML document/RDBMS database. ● Ontology Engineering Tool is to develop and maintenance common ontology. It utilize Protege and write with RDFS & OWL. ● Common Ontology is as reference ontology at the community which has common interest. Every update common ontology, a mechanism to write the version and broadcast to provider peer will be available in future. ● Main step of process in super peer: 1). Ontology Engineering Tool develop/maintenance common ontology; 2). Request from PP via PRP will handle via Registration; 3). Result of registration will be saved to Book Keeping; 4). There is possibility a request information from provider or request peer to common ontology via PIP; 5). There is possibility a request status of provider peer from request peer by looking Book Keeping. ● Local data is available local data at provider peer which accessible by public. Type of data can be in RDBMS or native XML. ● XML Bridge or wrapper is a bridge for RDBMS to/from XML, because at other block will talk in XML format. To convert can based on Table Based Mapping or Object Relation Mapping ● Export Schema Tool is a tool to help administrator or expert in developing export schema refer to share local databases. Export schema based on Export Schema Unit and represents in RDFS. Tool use is based on Protege-like??? ● Agreement Management has two steps: matching node element based on WordNet and semantic matching based on Agreement Unit. The tool will based on Protoge-like????? ● Query Respond Management is to answer the question from request peer. There are two steps: evaluate with Agreement result and send to query map to get real answer from share local databases. This block will based on Erlang/Java. ● Query Map is to handle query based on concept level (RDFQL) to local database. There are three approaches: Template Based Query, SQL-Based Query Language, and XML Query Language. Tool/language will be implemented Erlang. ● Main step of process inprovider peer: 1). Local Data to XML Bride; 2). XML Bridge to help Export Schema Tool; 3). Register to super peer via PRP; 4). Asking super peer common ontology for agreement; 5). Process agreement based on WordNet and export schema; 6). Result of agreement save at provider peer, and some meta data send to super peer to save at Book Keeping; 7). Query from request peer via PQP send to Query Respond Management; 8). Query Respond Management evaluates query to concept refer to Agreement; 9). Negotiation to request peer to re-write query base on step 8 via PNP; 10). Full fill query will send to local data through Query Map; 11) Result of query from local data will be sent to request peer via PArP. ● Concept Adjustment has similarity of Export Schema Tool, but more simple. The purpose to make same perception in the concept by using super peer common ontology. Tool will be implemented is Protege-like?? ● Query Sending Management has three main task: to write query based on concept adjustment, to send query to appropriate provider peers based on super peer book keeping, and to negotiate with provider peer in different view of concept. Language is RDF QL/ OWL QL ● Respond Management is a mechanism to integrated respond of the query from some provider peers. This facility will be available at future. ● Main step of process in request peer: 1). Refer to super peer common ontology via PIP for concept adjustment; 2). Result of concept adjustment will be used to write a query; 3). Before sending query, look at active provider peers refer to super peer book keeping; 4). Sending a query to appropriate provider peers; 5). Negotiation with provider peer to re-write query; 6). Receive result of the query from provider peers, integration resulsts will be done at this block. Query Management Respond Management Concept Adjustment PRPPQPPNPPIPPArP P2P Communication Infrastructure Request Peer Provider Peer Local Data Query Respond Management Agreement Management Registration PRPPQPPAPPNPPArP P2P Communcation Infrastructure XML Bridge Export Schema Tool Query Map WordNet Super Peer PRP PIP P2P Communication Infrastucture Book Keeping Common Ontology Registration Ontology Engineering Tool 1*

● Is it possible to run more than 25 virtual machine / peers in one physical machine with 2GB RAM, 80GB HD? ● Is it possible every peer has different IP address not just Port number?

Virtual Machine 1 QEMU running SuSE Virtual Network VDE Virtual Machine 2 QEMU running RedHat Virtual Machine n QEMU running Linux n0 Host Computer SuSE eth0 Gateway: DNS: Machine 1 SuSE sshd, sftp, apache Ethernet Switch Machine 2 SuSE sshd, sftp, apache Machine n SuSE n0 sshd, sftp, apache Host Computer SuSE eth0 Gateway: DNS: eth0 Virtual MachineReal Model Run 7 VMs: ● 5 provider peers ● 1 super peer ● 1 request peers

Virtual Web 1 Apache running SuSE /~1 Virtual Web 2 Apache running SuSE /~2 Virtual Web n Apache running SuSE /~n Host Computer SuSE eth0 Machine 1 SuSE sshd, sftp, apache Ethernet Switch Machine 2 SuSE sshd, sftp, apache Machine n SuSE n0 sshd, sftp, apache Host Computer SuSE eth0 Virtual WebReal Model

Common Ontology Super Peer Provider Peer 1 Query Sending Tool Request Peer Query Community Context Part of Common Ontology Provider Peer n Agreement Context Local Context Part of Common Ontology 13a 3b 3c Agreement Local Data/ Information Part of Export Schema 2 Query Respond Management Agreement Local Data/ Information 2 Part of Export Schema Query Respond Management