Loading ...
Sorry, an error occurred while loading the content.

6032Re: Decentralised Meta-Data Search Strategies

Expand Messages
  • samrhjoseph
    Aug 4 8:26 AM
      Hi Lucas

      --- In decentralization@y..., Lucas Gonze <lgonze@p...> wrote:
      >
      > Useful stuff, Sam. Good as both a survey (found out about a bunch
      of
      > projects that I didn't know, e.g. FASD) and analysis.

      Glad to hear it was of use.

      >
      > A question I had that you didn't address is why decentralized
      metadata
      > search is different in p2p than on the web.

      Right, although I don't know that it is any different. I mean I
      don't know that we can distinguish the web (lots of http servers and
      html browsers) clearly from a p2p system (integrated server and
      browser nodes) since both involve distributing data over many
      machines.

      People browsing the web are basically free to set up their own search
      engines so that their own data can be searched (something NeuroGrid
      will hopefully make easier for them), and as you'll notice in the
      document I mention various web based decentralised search systems in
      the related work section.

      I'm not even sure that we can meaningfully distinguish web from p2p,
      except perhaps with the churn aspect of p2p, and the greater ease
      with which data can be made available by every user.

      Thinking it over, you are right to point this out as an absence. I
      think the ease of publishing data in the p2p environment means that
      the need for decentralized search is even greater than on the web,
      but that the churn makes it all the harder to provide ....

      >
      > Your point about how propagating hashes of keywords vs. intact
      keywords
      > defeats substring matching was useful. It made me wonder about
      pinning
      > down limitations that topology puts on functionality.
      >

      Superfically there would seem to be some kind of relation between the
      kinds of guarantees that the topology can offer in terms of data
      recovery, and the flexibility of search it can provide. It would be
      interesting if we could pin this down more concretely. I'm hoping
      that once I get some distance from writing this review it might be
      possible to think about it a bit more objectively :-)

      > Does it matter whether metadata search is an overlay on the
      network, as
      > with FASD, or the main linking structure, as with Plesh?

      I'm not sure that I see the difference you are pointing to here. I
      mean both FASD and Plesh work as overlays, I think.

      Both FASD and Plesh nodes store meta-data, which in turn can point to
      resources that can be obtained from another system. FASD nodes
      contain documents that contain a list of keywords, their TFIDF values
      and a pointer to a document (which can be a Freenet Key, a Chord Key,
      or a web url). Plesh nodes contain Triples, the resource of which
      may also be a pointer to a document. Looking at it this way, they
      seem to be offering a similar kind of functionality.

      Perhaps I have misunderstood your question.

      CHEERS> SAM

      p.s. thanks for all the excellent feedback BTW
    • Show all 9 messages in this topic