[Ndn-interest] efficient lookup method

[Arunkumar Dhananjayan]

I don't want to hijack this thread to discuss about SDRs, but can you
enlighten me on how semantic similarity is ensured?

I think to have semantic similarity that everyone agree upon, we need a
common encoding that will be used by everyone.

I listened through the talk and it was really interesting. I find SDRs
quite similar to Bloom Filters and there is considerable literature on
using bloom filters to implement content based routing, where a common hash
function is used, but the hashes themselves do not represent any semantic
meaning. I am finding it intriguing that each bit in an SDR has a semantic
meaning. It is probably true within a single brain, because of the
coordinated learning it did, but I am pretty sure, the semantic meaning of
the bits in the SDR are different in each of our brains.

Probably to achieve a common semantic meaning for each bit, the entire
network should act as a single brain and keep learning continuously. Or
probably retrieving semantically close data is out of the scope of NDN and
should probably be left to a totally different 'Google' layer.

The future looks interesting :-)

regards,
arun

On Sun, Jul 5, 2015 at 5:09 PM, stewart mackenzie <setori88 at gmail.com>
wrote:

> Okay,
>
> Problems possibly solved using SDRs:
>
> * determining if content is on that node or not in constant time
> * get content which is semantically similar
>
> One names content not using hierarchical naming mechanisms but tags of
> semantic meanings.
>
> Please be aware, creating a SDRs is not hashing, indeed it's the opposite
> of hashing.
>
> If you really want to push the boundaries, try tying up nupic into NDN. Ie
> nupic predicts when you need data and pulls it down ahead of time...
>
> Problems possibly solved tying in CLAs (Cortical Learning Algorithms ie
> Nupic) into NDN:
>
> * learning about data patterns and initiating calls for that data AOT
> * just like a post office can forward packages if you're able to come up
> with some mapping technique to teach the CLAs you might be able to do
> something about NDNs forwarding issues.
>
> BTW is there a sane person on this list dropping the C++ implementation in
> favour of a Rust implementation?
>
> /sjm
>
>  On 5 Jul 2015 18:57, "Tai-Lin Chu" <tailinchu at gmail.com> wrote:
>
>> I am working on a different problem but it also involves converting an
>> NDN name to one specific bit pattern.
>>
>> But here is the common problem: NDN name space is essentially
>> infinitely large, so the conversion process is lossy (we want these
>> bit patterns to be more concise than names).
>>
>> If I understand the video correctly,
>>
>> (NDN name) >> (hashing 2^N) >> (SDR)
>>
>> >> means that the space is significantly larger.
>>
>> How does SDR solve any existing problem for NDN that comes from
>> properties of any hashing function?
>>
>> Thanks.
>>
>>
>> On Sun, Jul 5, 2015 at 6:00 PM, stewart mackenzie <setori88 at gmail.com>
>> wrote:
>> >
>> > On 5 Jul 2015 16:28, "Arunkumar Dhananjayan" <arunkd13 at gmail.com>
>> wrote:
>> >
>> >> 1. Tackle the fundamental problem of efficient name lookup especially
>> >> longest prefix matching on which NDN is based on, by coming up with a
>> novel
>> >> data structure or algorithm
>> >
>> > please take a look at how numenta's nupic uses sparse distributed
>> > representation.
>> >
>> >
>> https://m.youtube.com/watch?list=PLyh828DIg4wdSck2_H5A_KruczVscZXv6&v=LbZtc_zWBS4
>> >
>> > When naming content one could convert the name into 2k bit SDR (only the
>> > index is transmitted to save bandwidth).
>> > Now when you add the content into your store the SDR is binary OR'ed
>> into
>> > the content store. Thus future Interests just check PIT by binary
>> AND'ing
>> > against the content.
>> >
>> > Now this is a constant nime operation, so you can efficiently determine
>> if
>> > the content is there or not.
>> >
>> > Essentially I propose the naming mechanism for NDN should be SDR.
>> >
>> > /sjm
>> >
>> >
>> > _______________________________________________
>> > Ndn-interest mailing list
>> > Ndn-interest at lists.cs.ucla.edu
>> > http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20150705/448d48aa/attachment.html>