ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Content Centric Networking

To: Debmacp <debmacp@xxxxxxxxx>
Cc: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Edward Barkmeyer <edward.barkmeyer@xxxxxxxx>
Date: Wed, 8 Aug 2012 10:57:34 -0400
Message-id: <50227E5E.4080700@xxxxxxxx>
Deb Macpherson wrote:
> Hi Ed - what if the cache is old though - to me that ruins it all. Can't 
>prepackaged groups stay together and still work within a modernized, tiered 
>URI structure? Deborah MacPherson
>       (01)

I only know what I read on the PARC site.  To really understand the 
technology, you need to ask an expert.
My point was only that what I read suggested no relationship to 
knowledge engineering.    (02)

-Ed    (03)

> Sent from my iPhone
>
> On Aug 7, 2012, at 1:30 PM, Ed Barkmeyer <edbark@xxxxxxxx> wrote:
>
>   
>> Juan de Nadie wrote:
>>     
>>> Hi.
>>> Today I saw some articles concerning this subject. I wonder what are 
>>> the implications of this view in our research subjects (ontologies, 
>>> semantic web, etc). How this view changes our views about the semantic 
>>> web and the use of ontologies?
>>>
>>> 
>http://www.xconomy.com/san-francisco/2012/08/07/the-next-internet-inside-parcs-vision-of-content-centric-networking/?single_page=true
> 
>>>
>>>
>>> http://www.parc.com/services/focus-area/content-centric-networking/
>>>
>>> Best regards.
>>>       
>> If I understand the PARC writeup correctly, this is an implementation 
>> trick.  The idea is that when you fetch a 'web page' that is a 5MB 
>> document, something like 1000 packets transit the internet to deliver 
>> that document to you.  Your browser may "cache" the whole document under 
>> the id URI xxxxx and if you subsequently click on a link to URI xxxxx, 
>> it won't bother to get it over the Internet, it will just display it 
>> from its cache.  Now, if each of those thousand packets actually says:  
>> I am packet #nnn from URI xxxxx, then the servers along the route can do 
>> the same thing -- cache the packet under its name.  If 50 people on your 
>> ISP ask for the same document as URI xxxxx, and the server has cached 
>> all of the packets, it can just send those packets to all the 
>> requestors.  And even if it only has a subset of them, it can send the 
>> first request to the server that actually has the document and cache the 
>> missing packets as they arrive.  Yes, you get 50 copies of 1000 packets 
>> on the server's lines, but you don't busy the rest of the Internet 
>> intermediaries who would otherwise be involved in moving those 50,000 
>> packets.  That is the potential value.  There are some security issues 
>> involved -- the server that owns URI xxxxx may not be willing to send 
>> the document to arbitrary clients, and in that case, the relay servers 
>> need to know that they can't cache it, or they might have to do some 
>> authorization dance with the primary server.
>>
>> But the net effect is that this is a behind-the-scenes protocol for 
>> minimizing the communication loads on Internet components, while 
>> creating the burden of caching on cooperating servers.  It has nothing 
>> whatsoever to do with the nature of the cached information; it is just 
>> about labeling the standard transmission blocks of arbitrary named bit 
>> streams.  Its impact on things like "Big Data" is just performance.  It 
>> works the same for downloading one of the Stanford biomedical ontologies 
>> and for downloading the latest episode of Wipeout.  I don't see any 
>> direct relationship to knowledge engineering.
>>
>> -Ed
>>
>> -- 
>> Edward J. Barkmeyer                        Email: edbark@xxxxxxxx
>> National Institute of Standards & Technology
>> Manufacturing Systems Integration Division
>> 100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
>> Gaithersburg, MD 20899-8263                Cel: +1 240-672-5800
>>
>> "The opinions expressed above do not reflect consensus of NIST, 
>> and have not been reviewed by any Government authority."
>>
>>
>> _________________________________________________________________
>> Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
>> Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
>> Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
>> Shared Files: http://ontolog.cim3.net/file/
>> Community Wiki: http://ontolog.cim3.net/wiki/ 
>> To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
>>
>>         (04)


-- 
Edward J. Barkmeyer                        Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                Cel: +1 240-672-5800    (05)

"The opinions expressed above do not reflect consensus of NIST, 
 and have not been reviewed by any Government authority."    (06)


_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J    (07)

<Prev in Thread] Current Thread [Next in Thread>