<div dir="ltr"><div><div><div><div><div><div>I don't want to hijack this thread to discuss about SDRs, but can you enlighten me on how semantic similarity is ensured?<br><br></div>I think to have semantic similarity that everyone agree upon, we need a common encoding that will be used by everyone.<br><br></div>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.<br><br></div>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.<br><br></div>The future looks interesting :-)<br><br></div>regards,<br></div>arun<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jul 5, 2015 at 5:09 PM, stewart mackenzie <span dir="ltr"><<a href="mailto:setori88@gmail.com" target="_blank">setori88@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Okay,</p>
<p dir="ltr">Problems possibly solved using SDRs:</p>
<p dir="ltr">* determining if content is on that node or not in constant time<br>
* get content which is semantically similar</p>
<p dir="ltr">One names content not using hierarchical naming mechanisms but tags of semantic meanings.</p>
<p dir="ltr">Please be aware, creating a SDRs is not hashing, indeed it's the opposite of hashing.</p>
<p dir="ltr">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... </p>
<p dir="ltr">Problems possibly solved tying in CLAs (Cortical Learning Algorithms ie Nupic) into NDN:</p>
<p dir="ltr">* learning about data patterns and initiating calls for that data AOT<br>
* 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.</p>
<p dir="ltr">BTW is there a sane person on this list dropping the C++ implementation in favour of a Rust implementation?</p>
<p dir="ltr">/sjm</p><div class="HOEnZb"><div class="h5">
<p dir="ltr"> </p>
<div class="gmail_quote">On 5 Jul 2015 18:57, "Tai-Lin Chu" <<a href="mailto:tailinchu@gmail.com" target="_blank">tailinchu@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I am working on a different problem but it also involves converting an<br>
NDN name to one specific bit pattern.<br>
<br>
But here is the common problem: NDN name space is essentially<br>
infinitely large, so the conversion process is lossy (we want these<br>
bit patterns to be more concise than names).<br>
<br>
If I understand the video correctly,<br>
<br>
(NDN name) >> (hashing 2^N) >> (SDR)<br>
<br>
>> means that the space is significantly larger.<br>
<br>
How does SDR solve any existing problem for NDN that comes from<br>
properties of any hashing function?<br>
<br>
Thanks.<br>
<br>
<br>
On Sun, Jul 5, 2015 at 6:00 PM, stewart mackenzie <<a href="mailto:setori88@gmail.com" target="_blank">setori88@gmail.com</a>> wrote:<br>
><br>
> On 5 Jul 2015 16:28, "Arunkumar Dhananjayan" <<a href="mailto:arunkd13@gmail.com" target="_blank">arunkd13@gmail.com</a>> wrote:<br>
><br>
>> 1. Tackle the fundamental problem of efficient name lookup especially<br>
>> longest prefix matching on which NDN is based on, by coming up with a novel<br>
>> data structure or algorithm<br>
><br>
> please take a look at how numenta's nupic uses sparse distributed<br>
> representation.<br>
><br>
> <a href="https://m.youtube.com/watch?list=PLyh828DIg4wdSck2_H5A_KruczVscZXv6&v=LbZtc_zWBS4" rel="noreferrer" target="_blank">https://m.youtube.com/watch?list=PLyh828DIg4wdSck2_H5A_KruczVscZXv6&v=LbZtc_zWBS4</a><br>
><br>
> When naming content one could convert the name into 2k bit SDR (only the<br>
> index is transmitted to save bandwidth).<br>
> Now when you add the content into your store the SDR is binary OR'ed into<br>
> the content store. Thus future Interests just check PIT by binary AND'ing<br>
> against the content.<br>
><br>
> Now this is a constant nime operation, so you can efficiently determine if<br>
> the content is there or not.<br>
><br>
> Essentially I propose the naming mechanism for NDN should be SDR.<br>
><br>
> /sjm<br>
><br>
><br>
> _______________________________________________<br>
> Ndn-interest mailing list<br>
> <a href="mailto:Ndn-interest@lists.cs.ucla.edu" target="_blank">Ndn-interest@lists.cs.ucla.edu</a><br>
> <a href="http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest" rel="noreferrer" target="_blank">http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest</a><br>
><br>
</blockquote></div>
</div></div></blockquote></div><br></div>