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

LocalData

Query RespondManagement

AgreementManagement

Registration

PRPPAP

P2P Communication Infrastructure

BookKeeping

CommonOntology

Registration

1

2

34b

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 PNP PArP

P2P Communication Infrastructure

Provider Peer Request Peer

LocalData

Query RespondManagement

AgreementManagement

Registration

PQP PNPPIP PArP

P2P Communication Infrastructure

Query Management

RespondManagement

Concept Adjustment

1b

2b

4

5a

CommonOntology

BookKeeping

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.

QueryManagement

RespondManagement

Concept Adjustment

PRP PQP PNPPIP PArPP2P Communication

Infrastructure

Request Peer

1

23

4

5

6

Provider Peer

LocalData

Query RespondManagement

AgreementManagement

Registration

PRP PQPPAP PNP PArP

P2P Communcation Infrastructure

XMLBridge

Export Schema

Tool

Query Map

1

2

3

4

5

6

7

8

9

10

11

WordNet

Super Peer

PRP PIP

P2P Communication Infrastucture

BookKeeping

CommonOntologyRegistration

Ontology Engineering Tool

1*

2

3

45

● 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?

Erlang/OZ/Java

Protege-like

RDF QL

RDF/OWL Editor

Super Peer

Protege-like

RDF QL

RDF/OWL Editor

Provider Peer-1

Dbase Back

XML Wrap

Query Engine

WordNet

Phyton

Sim Measure

Protege-like

RDF QL

RDF/OWL Editor

Request Peer-1

Merge A

Protege-like

RDF QL

RDF/OWL Editor

Provider Peer-2

Dbase Back

XML Wrap

Query Engine

WordNet

Phyton

Sim Measure

Protege-like

RDF QL

RDF/OWL Editor

Request Peer-2

Merge A

Protege-like

RDF QL

RDF/OWL Editor

Provider Peer-3

Dbase Back

XML Wrap

Query Engine

WordNet

Phyton

Sim Measure

Protege-like

RDF QL

RDF/OWL Editor

Request Peer-n

Merge A

Protege-like

RDF QL

RDF/OWL Editor

Provider Peer-m

Dbase Back

XML Wrap

Query Engine

WordNet

Phyton

Sim Measure

Physical PC will run virtual machine, for example using FAUMachine

Erlang/OZ/Java

Erlang/OZ/JavaErlang/OZ/Java

Erlang/OZ/Java Erlang/OZ/Java

Erlang/OZ/JavaErlang/OZ/Java

Virtual Machine 1QEMUrunning SuSE 9.2192.168.2.110

Virtual Network

VDE

Virtual Machine 2QEMUrunning RedHat 8.0192.168.2.120

Virtual Machine nQEMUrunning Linux192.168.2.1n0

Host ComputerSuSE 9.3193.52.237.157

eth0

Gateway: 192.168.2.2

DNS: 192.168.2.3

Machine 1SuSE 9.2192.168.2.110sshd, sftp, apache

Ethernet Switch

Machine 2SuSE 9.2192.168.2.120sshd, sftp, apache

Machine nSuSE 9.2192.168.2.1n0sshd, sftp, apache

Host ComputerSuSE 9.3193.52.237.157

eth0

Gateway: 192.168.2.2

DNS: 192.168.2.3

eth0

eth0

eth0

Virtual Machine Real Model

Run 7 VMs:● 5 provider peers● 1 super peer● 1 request peers

Virtual Web 1Apacherunning SuSE 9.3193.52.237.157/~1

Virtual Web 2Apacherunning SuSE 9.3193.52.237.157/~2

Virtual Web nApacherunning SuSE 9.3193.52.237.157/~n

Host ComputerSuSE 9.3193.52.237.157

eth0 Machine 1SuSE 9.3192.168.2.110sshd, sftp, apache

Ethernet Switch

Machine 2SuSE 9.3192.168.2.120sshd, sftp, apache

Machine nSuSE 9.3192.168.2.1n0sshd, sftp, apache

Host ComputerSuSE 9.3193.52.237.157

eth0eth0

eth0

eth0

Virtual Web Real Model

Common Ontology

Super Peer

Provider Peer 1

Query Sending Tool

Request Peer

Query

Com

mu

nit

y C

onte

xt

Part of Common Ontology

Provider Peer n

Agr

eem

ent

Con

text

Loc

al C

onte

xt

Part of Common Ontology1 3a

3b

3cAgreement

Local Data/ Information

Part of Export Schema

2

Query Respond Management

Agreement

Local Data/ Information

2

Part of Export Schema

Query Respond Management