There are general two meanings when mentioning graph in database community.
In the first category, the data is graph. That is, the graph database deals with how to store the data that is conceptually organized as a graph. Specific queries like subgraph isomorphism is required, and such database can find its use in some scientific computing/applications(?).
In the second category, graph is intended to integrate heterogeneous data; Graph is a general symbolic that can represent structured, semi-structured, and unstructured data in a unified way. For structured data, each tuple is treated as a vertex (actually, a small graph with each attribute being a vertex) in a graph that is connected by foreign keys (or tuple join). For unstructured data, say webpages, each page is a vertex and each link is an edge.
Let's talk a bit more on the second category. To synthesize structured and unstructured data (or merging IR and DB community) is quite a meaningful task. On one hand, conventional database lacks data access method like keyword-based queries, which are quite common in IR. Such queries can provide users richer search facility[1]. On the other hand, today's IR systems only support pure keyword search, that is, they treats all keyword as dead query entries, unaware of any semantics behind them. The keyword search is unable when one want results with semantics like "find all professors' phone numbers in CS dept., Wisc."[2]
[1] Guoliang Li, et al " EASE: Efficient and Adaptive Keyword Search on Unstructured, Semi-structured and Structured Data."
[2] Entity search. http://wisdm.cs.uiuc.edu/
订阅:
博文评论 (Atom)
没有评论:
发表评论