Search Co-Ordination by Semantic Routed Network

Abstract

Specialized search engines have potential to provide superior search precision, relevance and recall. A specialized P2P overlay network called semantic routed network, which forwards search queries based on their meanings, can unify a large number of specialized search engines under a single Internet wide search service. Providing fast and successful routing of search queries is a challenging task due to conflicting tradeoff requirements. We present P2P topology generation and semantic routing table compaction techniques to realize fast and successful query routing. Our simulation shows that a SRN coordinating 800 search engines can achieve a competitive 100% query routing success within 6 messaging delays, and have query delivery response of 1.89 messaging delays.

Full text

Page 1

Search Co-ordination by Semantic Routed Network

Amitava Biswas, Suneil Mohan, Rabi Mahapatra
Department of Computer Science
Texas A&M University,
College Station, TX, USA 77840
amitabi@cs.tamu.edu, suneil@cs.tamu.edu, rabi@cs.tamu.edu


Abstract— Specialized search engines have potential to provide
superior search precision, relevance and recall. A specialized P2P
overlay network called Semantic Routed Network, which
forwards search queries based on their meanings, can unify a
large number of specialized search engines under a single
internet wide search service. Providing fast and successful
routing of search queries is a challenging task due to conflicting
tradeoff requirements. We present P2P topology generation and
semantic routing table compaction techniques to realize fast and
successful query routing. Our simulation shows that a SRN
coordinating 800 search engines can achieve a competitive 100%
query routing success within 6 messaging delays, and have query
delivery response of 1.89 messaging delays.
Keywords- Search engine co-ordination; P2P; semantic routing.
I.
INTRODUCTION
Searching is an important activity on the internet.
Currently the world wide consumption of “web search”
service is around 13 billion search queries per month and
growing by 38% annually [1]. Users prefer a smaller set of
more relevant results gathered from all possible web sources.
They also desire meaning based search. For example, they
expect to find a document containing consumer reviews on
Nissan cars when searching for “advice on choosing Japanese
sedans” even if the returned text and the user’s search
intention do not share any common keywords.
These needs have lead to a boom in specialized (vertical)
search engines like riya.com (visual search), theFind.com
(product search), hydroseek.org (for hydrology data), Pubmed
(for bioscience
www.ncbi.nlm.nih.gov/pubmed/), etc., which propose to offer
better precision, relevance and recall compared to generic
internet search engines like Google and Yahoo. Here the
rationale is that these specialized engines apply custom search
strategies suited to the problem domain, search context, type
of data objects, etc., to yield superior results.
publications at
To carry out specialized searching, currently users have to
manually search for these specialized engines and then try
them out. This requires effort and time due to multiple search
iterations using all possible keywords and their combinations.
Hence there is a definite need for an automated co-ordination
mechanism which can bring all specialized and generic search
engines together and orchestrate their capabilities to provide a
unified web search service. The goal is to provide the best of
the both worlds: generic (single window search for anything
and everything) and specialized searching (smaller set of
relevant results from all available resources). A specialized
P2P overlay network called Semantic Routed Network (SRN)
can co-ordinate, orchestrate and unify services of multiple
search engines. This is a scalable alternative to a centralized
“search engine of search engines” kind of solution.
In this application, the Semantic Routed Network (SRN)
would be a P2P network of semantic routers (grey circles in
Fig. 1, e.g. R1, R2) which would forward/route search queries
(query messages) to other peer routers or search engines
(small boxes in Fig. 1, e.g. E5, E6) that can best handle them.
This routing is done based on the meaning of the message
(query) key.

Figure 1. Co-ordinated searching by SRN
In this proposed system, a user can pose a search query
(arrow “(i)” in Fig. 1) to a mediating user interface (UI). The
UI constructs a suitable search/query key and submits an
‘object search request’ message with this key to any arbitrary
semantic router (arrow “(ii)” to R1). The search key represents
the meaning of the desired object. The query recipient
semantic router will forward the query to another peer router
(e.g. R2) for better servicing (semantic routing) and the query
may undergo multiple hops before reaching a search engine
(E6) which will finally return results, if available, to the UI to
be presented to the user (arrow “(iii)” & “(iv)”). The next hop
destination to forward the query message is decided using a
table lookup mechanism (semantic lookup). Each router has a
semantic routing table with multiple rows comprising of a key
and destination addresses (URI/URL) of the peer routers
(search engines). The key (semantic key or semantic
descriptor) is a data structure that represents the meaning of
the desired object (its description) or specialty of a search
engine or a semantic router. The next destination is read out
from the table row having a key whose meaning is most
similar to the meaning of the search key.
To provide superior search performances (recall, relevance
and precision) it is important that the SRN provides enhanced
query/ message routing performance in terms of: (A) high end-
(i) Intention
D1
D6
D3
D4
D5
Key
R1
R6
R3
E4
E5
Destination
Portion of Query
Routing Table of R2
(iii) Response
User searching
(iv) Results
(ii) Query with key ‘K’
E4

E5
SRN
R3
R2
R1
User Interface
E6
R6

Page 2

to-end routing success (% of messages reaching intended
search engines within limited message time-to-live (TTL));
(B) low response time (number of routing hops required to
reach destination, multiplied by the time needed to carry out
each semantic routing table lookup to decide the next hop
destination); (C) minimum message congestion at semantic
routers; and (D) low messaging overhead (number of
messages generated in the network to carry out a search).
Limited TTL is necessary to limit the messaging overhead.
The choice of topology of the P2P network and the quality of
the routing table content determines these routing and message
overhead performances in addition to the number of semantic
routers required to construct the network. Here the challenges
are: (1) generation of this topology; (2) optimization of
semantic routing table content and minimization of its size
(smaller number of routing table rows will mean smaller
number of key comparisons, leading to faster lookup); and (3)
design of the semantic key data structure that can realistically
represent meanings of the search engine’s specialties and the
search queries in all possible situations. The available file
searching P2P network proposals, like [2-11], including those
referred in [12,13], do not attempt to address these challenges.
In our earlier work we had presented a mechanism to
optimize the content of semantic routing table and provided a
rudimentary design for the semantic key data structure [13].
Subsequently a more advanced design of the semantic key was
provided in [14]. Whereas in this paper we explain how the
proposed search engine co-ordination mechanism using SRN
will actually work on top of the existing IP routing fabric,
existing web and search engine infrastructures. Here we
analyze several alternative topologies for a practical SRN and
rationalize why we chose the small world network topology
[15]. We also present additional algorithms that enable self-
organization of the proposed optimal SRN topology and
compaction of the routing table, which had not been presented
in [13]. Our simulated SRN having 800 specialized search
engines, has an expected end-to-end query routing response
(query delivery time) of less than ~1.89 messaging delays,
100% query routing success and message overhead of 4.8
messages per search query. Even though our meaning oriented
SRN is very different from the existing keyword based file
searching P2P networks to allow a direct comparison.
Nevertheless it is evident that SRN’s smaller message
overhead is superior than the very large overheads (in order of
hundreds and thousands) in those P2P networks that have
search success in order of ~37% [12].
II.
SEARCH ENGINE CO-ORDINATION USING SRN
A. Working Principle, Lookup Algorithm and Messaging Protocol
Semantic Routing: This semantic routing will operate on
top of IP routing. For example, in Fig. 1, semantic router “R2”
receives a message and finds its key “K” to be most similar to
its routing table row key “D3” which has a corresponding URI
address belonging to router “R3”. R2 carries out a DNS look
up with R3’s URI to ascertain R3’s IP addresses to forward
the query message as the TCP/IP payload (e.g., on top of
HTTP). In case of a lack of match, query is broadcasted to all
addresses. Fig. 2 shows the proposed network stack.

Figure 2. SRN network stack
A chosen row can have multiple destination columns
and/or multiple “t” best matching rows can be chosen during
lookup for selective query multi-casting to enable higher
routing success and search recall. The rational for multiple
columns table is explained in section V.
Messaging Protocol: Specialized search engines are
destinations for ‘object search request’ messages. On the other
hand a ‘search engine search request’ message carrying a
similarity threshold value is used to discover search engines
(intended destinations). The search engine verifies whether the
similarity between the query and its own descriptor key is
above the similarity threshold value before presenting its
address to the message originator. The originator may relax
the similarity threshold value and send repeated requests if
sufficient responses are not received.
Object Publication method: To publish an object on the
web, the owner has to put it up in a web server, generate a
semantic key for the object (by a method discussed in [14])
and then submit the key and the object’s URI to any arbitrary
semantic router. Using the SRN’s search capability the
recipient router will identify a suitable search engine which is
interested in hosting the object’s key-address pair in its index.
B. Evaluation of Topology Options and Choice for SRN
We investigated six different network topologies for their
suitability in SRN (2D forms in Fig. 3).

Figure 3. Different classes of network topologies
These are: (1) hierarchical network with nodes having
uniform degree (same number of links or routing table
entries); (2) hierarchical power law network (node degree has
power law distribution) [16]; (3) Random network with
uniform node degree [16]; (4) Random power law network
(2) Hierarchical power law
(3) Random
(4) Random power law
(5) Lattice
(6) Small world
(1) Hierarchical
Network
Paradigm
Semantic
Routed Network
Protocol Layers Address
Key used
Semantic
Descriptor
Mapping
(Performed by)
Semantic Descriptor to URI
(Semantic Routing Table)
SRN Layer

P2P Networking
Application Layer
(HTTP, etc.)
Transport Layer
(TCP)

URI

TCP Port
URI to IP
(DNS Service)
Traditional
Networking
Network Layer
(IP)

IP address
IP to Router Interface
(IP Routing Table)

Page 3

[16]; (5) Lattice network with uniform degree; and (6) Small
world network (SWN) with uniform degree [15].
We compared these six topologies, against four criteria:
(1) probability of congestion at semantic routers; (2)
implementability; (3) number of routers necessary to build the
topology; and (4) expected search path length (message
delivery time); to assess their suitability for SRN.
Implementability is judged based on: (a) the ease of allocating
nodes under routers and subnets as described earlier (i.e. ease
of organizing the network); and (b) whether the topology can
be constructed by modest sized routers with smaller number of
routing table rows. A large routing table size is not desirable
for SRN because a large semantic routing table may not be
feasible given the complexity of key comparison. This
comparison is summarized in Table 1 and explained below.
In Table 1, for each topology, the message routing (or
search) method is also mentioned. Message delivery by
network flooding is avoided due to its large overhead. In
hierarchical networks, messages are routed to the higher level
subnet if no destination match is found in the routing table of
the current subnet router/gateway (i.e. hierarchical routing
similar to IP). Routing in both random networks is by random
walk [17] destination search algorithm or its variants. Routing
in lattice and small world network is by greedy routing and its
variants [15]. The number of expected edge traversals (hops)
needed to reach any node from another (i.e. search path length
or message delivery time) due to routing methods and
topologies are greater than the network diameters.
The intensity of congestion is higher for hierarchical
networks because a large number of messages have to pass
through a very small number of hubs. Worst case congestion is
higher in power law networks than that of their plain variants
because the router with largest number of links (degree) will
be worst hit. For other topologies, the traffic is uniformly
distributed among all routers.
A balanced tree is the optimum hierarchical network
which has smallest tree depth and expected search path length.
To construct a balanced hierarchical tree the address space has
to be partitioned and uniformly allocated among the sub-
networks. This is not possible in SRN, because: (1) maximum
number of nodes that may join the network in future can not
be known beforehand; and (2) the address key that represents
meaning, have infinitely large space, which can not be
partitioned and allocated like IP addresses. Any arbitrary
address space partitioning is likely to result in an unbalanced
tree with large depth. Dynamic balancing is expensive for a
large tree and if attempted the network will remain out of
operation for long time during such balancing. Thus,
hierarchical SRNs, if implemented, will: have large depths;
require large number of routers; and have large message
delivery times. However hierarchical power law networks are
likely to have shorter depths compared to its plain variant.
With random walk search in random power law networks,
the expected search path length scales sub-linearly, having
order O(Nβ), where β is around 0.7 or larger [17] and N =
number of search engines. In case of plain random networks,
the search path lengths will be larger, simply because it takes
longer time to cover the network. The order of search path
length for a lattice is smaller than power law random network
and higher than that of the small world network topology.
These comparisons in Table 1, clearly shows that small world
topology has a good combination of all required properties,
therefore is the best choice for SRN.
III. SEMANTIC DESCRIPTOR AND SIMILARITY COMPARISON
A. Design of the Semantic Key Data Structure
We propose to use the semantic descriptor designs from
[14], after carrying out two modifications. The first one
involves the following modification of the two binder
functions as defined in [14]: (1) [
them efficient (reduce number of basis vectors).
]
,..,••
; and (2) {}
,...,••
, to make
TABLE I.
PERFORMANCE COMPARISON OF NETWORK TOPOLOGIES
Criteria

Topology
Routing
method
Congestion
(probability that message goes
through most congested router)
Highest
*
r
Implementable
(balanced ?,
limited degree ?)
Number of
routers needed
Expected search
path length
(msg. delivery time)
Large,
Ω
Suitable
Hierarchical
Hierarchical
1
) 1
−
(
*) 1
−
N
(
≈
Nr

No (unbalanced)
Can be very large
)(log N
k

No (balanced tree
impossible)
No (balanced tree
impossible, large
router)
No (not routable)
Hierarchical
power law
Hierarchical
Highest,
1
) 1
−
( *
)(
1
max
k
max
N
≈
−
−
kN

No (unbalanced,
large degree)
Can be very large Large, smaller than
above,
(log N
Ω
)
k

Random
Random walk
Very small,
1 ,
) 1
+
N
(
<≈λ
λ
N

Yes
Smaller,
k
N
rk
N
− )
≈
(

Larger
λ
1 ),
βλ>>
(NO

Random
power law
Random walk
High

No (large node
degree)
Larger,
)(NO
≈

Large [17],
)(
β
NO
,
β ~0.7
Large,
D
⋅
No (not routable,
large router)
Lattice
Greedy routing
Small Yes
Smaller,
k
N
rk
N
− )
≈
(


)(
1 D
NO

No (large path
length)
Small world
Indirect greedy
routing
Very small,
N
k
N
rlk
≈
−−
)(

Yes
Smaller,
k
N
rlk
N
−
≈
−
)(

Small [15],
((log
O
))
/ 1
+
1
D
kN

Yes
N = total number of search engines, k = node degree, total number of engines & routers registered by each router in networks with uniform router node degree, kmax = k for the biggest router in power law networks, r =
number of routers registered to each router, l = number of long edges (shortcuts) per router in small world topology, D = dimension of the lattice (i.e. half of number of routing table rows), 1 < l << 2D ≤ r < k << N.

Page 4

For one, two and three and ‘n’ arguments we define the binder
functions as follows (hsh() is a hash function, e.g. MD5):

....(1a).......... ][
aa ≡


) hsh( )hsh( if ],[
abab
>≡
<>

hsh( )hsh( )hsh( if ],,[
abcab
>>≡
M
)hsh( )hsh( if
1b).........(
bababa
>≡
<>

)hsh(
>

,
cb
)hsh(
>
)hsh( if

≡

)hsh( )hsh( )hsh( if
.(1c).......... )
c
bcabca
cbacbacba
>>≡
<>
<>
<>

.....(2) .......... .....],.....[ ....],,[
assscsbsas
cbacba
≡


......(3) ....],[],[....],[],[
A ≡
....)]
+

(....),
+
[(
+++
≡
c
+++
c
+
dbbdaa
dcba

....(4a)
∑
.......... ][
A
∑
i
A

.....(4) ,.....],,.....[ ,....],,[then
....... ,
i
c
,
i
,
i
If
,,
,,,
,,,
∑
ji
∑
i
a
≡
===
k
kji
kcjbia
ic
i
ibia
cbsssCB
sCbsBasA

) .......(5a
][
}{
A
h
Ah
A
A
h
A
=≡
;
....(5b) ..........
][]
h
[],[
},{
BAAB
BAAB
hh
BhA
+
hBA
BA
+
++
≡


]
....(5c)
])[][][],
+
[
h
,[
+
],[],,[(
},,{
CBAAC BCAB ABC
h
CBA AC
+
BC AB ABC
h
hhhhh
ChBhAhCAhCBhBAhCBA
CBA
+++
++++++
≡

The second modification is about storage format of the
semantic descriptor data structure. A two column format of the
coefficient table [14], without the BF indices column, is stored
to save space. However the three column format is used for
comparison computation as in [14]. The BF indices can be
readily generated by fast hashing of the vector id using
specialized hardware. The query descriptor has to also
incorporate additional terms so that it can be matched with the
descriptor of the search engine which can service it.
IV. SHORTEST PATHS IN SEMANTIC ROUTING TABLES
Small world topology can be generated by the node
clustering algorithm described in [13]. However the presence
of shortest route in a small world topology alone does not
ensure that a message will be routed through it during
semantic (greedy) routing (e.g. Fig. 4).

Figure 4. Small world network operations
For example, in the SWN in Fig. 4, though a shortest path via
router number R1?R2?R7?R6 (shown by broken line)
exists but in absence of a mechanism that programs the
shortest path in the semantic routing table, messages will be
routed through a longer path R1?R3?R4?R5?R6 (shown
by heavy lines) by the proposed (greedy) semantic routing
approach. To ensure messages follow the shortest routes these
paths need to be explicitly programmed into semantic routing
tables. To achieve this, routers have to look beyond the
immediate neighbors to note directions (e.g. R1?R2…, Fig.
4) that can lead to a shortest path even though it may
contradict with the plain greedy routing path (R1?R3…, Fig.
4). This aspect had been independently modeled by [15],
whereas here we present an OSPF inspired technique to
program shortest paths in semantic routing tables.
A. Design of Semantic Routing Table & Distance Table
To aid identification of the shortest paths and incorporate
them in the routing table, each router maintains neighboring
router distance table as shown in Fig. 5, in addition to the
semantic routing table described earlier. This distance table
has three columns, the first one for semantic descriptor key,
the second one for hop distance and the third one for the
router’s URI address which is the destination of the next hop.
The hop distance (second) column value gives the shortest
distance, in terms of hops, required to reach the final
destination via the next hop router.

Figure 5. Creation of routing table rows from distance table
Routing Table Update Mechanism: The routing table is
generated based from the information available in the distance
table. Whenever a new row is created in the distance table, a
corresponding row is also created in the routing table using the
same key and URI address as the destination. This is
illustrated with an example in Fig. 5.
Implementation of distance table and routing table: In
actual implementation of these two tables, the search engine
and router node addresses will be maintained in a separate list
and these two tables will contain pointers to those addresses in
the address list instead of the addresses (Fig. 6).

Figure 6. Actual implementation of distance and routing table
This mechanism: avoids duplication of information (URI
addresses) in distance and routing tables; eases the coherence
between both tables; and simplifies simultaneous updation of
both tables. When an address is inserted in any of these tables,
it actually means that the address is inserted in the address list
and pointers to this address list location are inserted in both
Actual Implementation
Distance Table
Key Dest Hop
Dist
1
0
1
D1
D6
D3
R1
R6
R3
D4
D5
E4
E5
1
1
Distance Table
Routing Table
KeyDest
D1
R1
D6 R6
D3
R3
D4,5 E4 E5
Addresses
E4
E5
Key Dest Hop
Dist
1
0
1
D1
D6
D3
R1
R6
R3
D4 P_E4
D5 P_E5,
1
1
Routing Table
Key
D1
D2
D3
D4,5
Dest
R1
R6
P_E4 P_E5,
Abstract Views
R5
R6
R1

R7
R2
R4 R3
Distance table
Key Dest.
Hop
Distance
1
0
1
1
D1
D6
D3
D4
R1
R6
R3
E4
D5
E5
1
Routing table
Key
D1
D6
D3
D4
Dest
R1
R6
R3
E4
D5 E5
New row
got added
Creates
corresponding new
row in routing table

Page 5

tables (Fig. 6). When an address is updated in any of these
tables, it actually means that the address is simply updated in
the address list, without any need to change the pointers.
However for sake of simplicity throughout the rest of this
paper we will show the distance table to contain search engine
and router addresses instead of their addresses pointers.
Entries are deleted from the address list whenever all pointers
to them are dropped from the distance and routing table.
B. Programming shortest paths in routing table
When a row is added or updated in the distance and
routing tables, the router sends a table update message with
information contained in the added/updated row to all other
peer routers whose addresses are in its routing table. For each
row in the update message the recipient router does distance
table lookup using the row key in the message. During
distance table lookup if the key similarity for the closest match
is above a certain threshold then a match is noted (Fig. 7). For
a matching row if the existing distance value is found greater
than the distance value in the updated message by one, then
distance table row is updated by the distance value (after
incrementing by one) and the address in the update message.
By this method gradually the existing shortest paths are
incorporated in the routing tables. To introduce new routers or
search engines in the network, they are bootstrapped with a
small number of router key address pairs in their distance
tables. The new nodes start participating by sending update
messages to the routers they know.

Figure 7. Programming shortest paths in routing tables
V.
SEMANTIC ROUTING TABLE COMPACTION
A. Motivation and Approach
There is a need to limit the routing table lookup response
time by limiting the number comparisons (there is one
comparison for each row) by limiting the number of routing
table rows. On the other hand the routing table has to
accommodate a large number of destination routes to have
superior routing success and response time. This is because
number of routing table rows determines how far each router
can look beyond its immediate neighbors to develop the
topological awareness required for indirect greedy routing
[15]. This tradeoff envelope can be improved by having
multiple destinations in each routing table rows and
minimizing number of rows. Such approach enables smaller
routers with multiple destinations routing table rows to be
more effective than large routers having single destination
rows [13].
During generation of the small world topology, as new
interesting search engines and routers are discovered by a
router, the router adds new routes to them in its routing table.
As new rows get added in the routing table it runs out of row
space. To free up row space (to record newer interesting
outgoing connections), three strategies are applied to reclaim
routing tale space without loosing out too much on routing
performances. As the first strategy, two routing table rows are
merged together into a single row to form rows having
multiple destinations addresses. The second method involves
selectively evicting destination addresses from columns and
entire rows from routing tables and the third one includes
reallocating the evicted routing table entries so that routing
performance do not deteriorate too much. These three
mechanisms are applied as and when the need and opportunity
arises. Here we present the first strategy. The second and third
strategies were presented in [13].
B. Row Merging Policy
This merging is carried out by amalgamating two rows at
a time. The pair of rows whose keys are most similar to each
other are selected first. There are two rules to merge rows
based on two different situations. When the URI addresses of
both the distance table rows are same, then this URI address is
used to populate the single destination column of the merged
row. The distance table row keys are merged together to form
a single merged key and used to populate the key column of
the merged row (Fig. 8). On the other hand when the URI
addresses of the parent rows are different, then the keys are
still merged together and the two different URIs are used to
populate two different destination columns of the merged
rows. This type of row merging creates a situation where
multiple distance table rows have a single shared routing table
row. This creates rows with multiple destination address
columns (Fig. 8).

Figure 8. Two routing table row merging situations
C. Merging of Semantic Keys
When rows are merged or when destination addresses are
relocated corresponding row keys are merged. The single
merged key should contain all the meanings represented by all
the keys that were merged together. This is required so that the
routing table lookup method remains same and simple as
before. This process is similar to grouping nodes and networks
hierarchically into sub-networks and replacing multiple IP
addresses of these groups by the common prefix portion of
their IP addresses.
Key Dest. Hops
D1 E1
D2 E2
D7 E7
1
1
1
E6
R11
R12
R11
R14
R13
Msg 1
Msg 2
E7
E2 E1
E4
E3
E5
Update message Msg 2
Distance Table of R11
Distance table of
R12 after Msg 2
D14
D7
D11
D1
D2
R14
E7
R11
E1
E2
2
2
1
2
2
Key Route Hops
D3 E3
D4 E4
D5 E5
D13 R13
D6 E6
1
1
2
1
3
Distance Table of
R12 after Msg 1,
before Msg2
D14
D7
D11
R14
E7
R11
2
4
1
Key Route Hops
D3 E3
D4 E4
D5 E5
D13 R13
D6 E6
1
1
2
1
3
Before
compaction
Key Dest
Di
After
compaction
Key
merge(Di,Dj)
Situation 1
Situation 2
Dn
Dest
Ri Rk
Dk
Rk
Dn
Ri
Dk

Dn
Ri


Key Dest
Di

Ri

Key
merge(Di,Dj)
Dn
Dest
Ri
Before
compaction
After
compaction