1. George Anadiotis, Spyros Kotoulas and Ronny Siebes VU University Amsterdam

2. Why do we need distribution… Why do we need anytime behavior… Why is should be (very) scalable… Why should we drop consistency and completeness… Why do we need trust/ontology ranking… etc 2

3. What is P2P? (1 slide) Relationship between P2P and SW(3 slides) Our Goal (1 slide) Distributed SW stores(1 slide) Structured P2P stores (3 slides) Federated stores (2 slides) Our approach (6 slides) Future work (1 slide) 3

4. Class of distributed systems Most important characteristics Same functionality across peers Peer autonomy Formation of overlay networks Common interface They respect some agreed-upon way to organize File-sharing networks are NOT the only Peer- to-Peer systems. 4

5. 5

6. Source of semantic information to self- organize Interoperability 6

7. Scalable infrastructure for Storage Reasoning Collaboration Self-organization Autonomy – control of data Privacy Scalable algorithms Robustness No censorship No preferential treatment of information 7 Common misconception: All Peer-to-Peer systems can offer the above

8. Global-scale semantic web storage and reasoning Scalability Computation Administration 8

9. Structured peer-to-peer Use DHTs One global distributed store Peers do not maintain their own data Federated stores Each peer maintains its own store Stores are interconnected Either global schema or mappings between schemata 9

10. The mathematical abstraction for hashtables is a Map Functionality: put(key,value) get(key) Similar to normal hash-tables with the difference that each bucket now is a peer Accessing different buckets involves network traffic Routing to a bucket is done bothering approx. log(N) peers, N is network size 10

11. Values are stored in the peer with ID starting with the first letter of the key 11 adcbef gjihkl mponqr suvtwx

12. Peer 1 Peer 2 12 adcbef gjihkl mponqr suvtwx

13. 13 adcbef gjihkl mponqr suvtwx RDFS class axioms (1), (2),

14. 14 adcbef gjihkl mponqr suvtwx RDFS class axioms (1) FORALL O,V O[rdfs:subClassOf->V] W] AND W[rdfs:subClassOf->V]). (2) FORALL O,T O[rdf:type->T] T] AND O[rdf:type->S]).

15. As shown, the transitive closure has to be calculated – backwards chaining would require many DHT messages But it does not scale to large number of ontologies. E.g. a animal hierarchy: Adding the triple means that for all triples with animal, we need to insert an additional triple. Control over ontologies Provenance of information Ontologies and instance data are made public Publishers are not in control of their ontologies/data One super-user inserts all data 15

16. Each peer maintains its ontology and instance data Mappings are (manually) defined between ontologies Thus, a semantic topology is created Queries are posted according to such a schema and forwarded following these mappings Semantic Web counterpart of Federated Databases 16

17. Bootstrapping New peers have to manually map their ontologies to the ontology of a peer already in the network Finding relevant ontologies requires flooding Routing The overlay is created according to the ontologies understood by peers, not the data they contain. Possible scalability problem. Searching for instances requires flooding 17

18. Effort to combine both approaches Use a DHT to efficiently find ontologies and instance data Exploit semantic locality by keeping ontologies local to the publisher Whenever possible, perform reasoning peer-to- peer 18

19. 19 Peer 1 Peer 2 19 adcbef gjihkl mponqr suvtwx animal:P1 rabbit:P1 monk_seal:P2 mseal1:P2 habitat:P1lives_in:P1 seal:P1,P2 subClassOf:P1, P2

20. 20 Peer 1 Peer 2 20 adcbef gjihkl mponqr suvtwx animal:P1 rabbit:P1 seal:P1,P2 subClassOf:P1, P2 monk_seal:P2 mseal1:P2 habitat:P1 Query seal? P1, P2 lives_in:P1 Peer 3

21. 21 Peer 1 Peer 2 21 adcbef gjihkl mponqr suvtwx animal:P1 rabbit:P1 seal:P1,P2 subClassOf:P1, P2 monk_seal:P2 mseal1:P2 habitat:P1 Query monk_seal? P2 lives_in:P1 Peer 3 seal? P1

22. Control Access Control Select which data is published on the index Trust – ban spammers, remember good peers Privacy It is possible to obfuscate descriptors stored in the DHT Responsibility Publisher has the responsibility to maintain own data Scalability DHTs can scale to millions of nodes Data is up-to-date 22

23. Based on the data of swoogle, there is currently small overlap between ontologies The distribution of ontology popularity follows a power-law pattern If most answers reside on the same peer, our approach outperforms those that rely on triple distribution on top of a DHT 23

24. Simulations using SWD from Swoogle and Watson (around 25.000) Integration of privacy in the index Selecting the right ontologies/peers 24

25. ? 25