- From: Kingsley Idehen <kidehen@openlinksw.com>
- Date: Sat, 19 May 2012 11:44:32 -0400
- To: public-lod@w3.org
- Message-ID: <4FB7BFE0.6090005@openlinksw.com>
On 5/17/12 11:55 AM, Joseph Montibello wrote: > Hi all, > > Can someone interpret this for me? I took a google search that has an > information box on the side that I think is what Google's referring to as > their knowledge graph. > > http://bit.ly/googlelod > > I started looking at it using a chrome extension, OpenLink Data Explorer. > I threw up a pdf of what I saw at > > http://bit.ly/googlelod2 > > In that document, which lists out the triples found on the page, one of > the triples is as follows: > > subject: > search?hl=en&biw=1823&bih=850&q=jan+kerouac&stick=H4sIAAAAAAAAAONgVuLUz9U3M > CmoSEoHAO-WRMoNAAAA&sa=X&ei=Vhm1T83QD6me6AGgg7DfDw&sqi=2&ved=0CLwBEJsTKAA > predicate: void:sparqlEndpoint > object: sparql > > Does anyone believe / can anyone confirm that this is an actual sparql > endpoint? Sorry if I'm totally crazy here - very new to looking at linked > data in general, so I'm still feeling my way along. That can't be right. At the very best, the triple should imply there is a sparql endpoint that provides access to the data transformed via the sponger linked data middleware. Thus, given a proxy (wrapper) URI, you can obtain its description (via describe or construct) via the sparql endpoint in question. I assume you've looked at the examples at: http://ode.openlinksw.com or the notes at http://uriburner.com etc.. Kingsley > > Thanks, > Joe Montibello, MLIS > Library Systems Manager > Dartmouth College Library > 603.646.9394 > joseph.montibello@dartmouth.edu > > > > > > > On 5/17/12 11:22 AM, "Steve Harris"<steve.harris@garlik.com> wrote: > >> On 2012-05-17, at 00:04, Kingsley Idehen wrote: >> >> >> On 5/16/12 6:55 PM, Bernard Vatant wrote: >> >> Adrian >> >> Don't dream of accessing the Google Knowledge Graph and query it through >> a SPARQL endpoint as you do for DBpedia. As every Google critical >> technological infrastructure, I'm afraid it will be well hidden under the >> hood, and accessible only through the search >> interface. If they ever expose the Graph objects through an API as they >> do for Gmaps, now THAT would be really great news. >> >> Kingsley says they have Freebase, yes but Freebase stores only 22 million >> entities according to their own stats, which makes less than 5% of the >> overall figure, since Google claims 500 million nodes in the Knowledge >> Graph, and growing. So I guess they have >> also DBpedia and VIAF and Geonames and you name it ... whatever open and >> structured they can put their hands on. Linked data stuff whatever the >> format. >> >> Bernard >> >> >> >> And it will be query accessible, this is something that's inevitable and >> unavoidable. This is the Web. >> >> >> >> >> >> I doubt it. Google don't even allow API access to their search engine. I >> can still remember the days when they were a search company ;) >> >> >> For them it's all about staying ahead of the competition so they can get >> more eyeballs on google ads, and more tracking data - interactions with >> humans basically - providing APIs to their graph data doesn't help that >> aim. >> >> >> Doesn't mean they won't do it, but I don't think there's any reason for >> them to. >> >> >> - Steve >> >> >> -- >> Steve Harris, CTO >> Garlik, a part of Experian >> 1-3 Halford Road, Richmond, TW10 6AW, UK >> +44 20 8439 8203 http://www.garlik.com/ >> Registered in England and Wales 653331 VAT # 887 1335 93 >> Registered office: Landmark House, Experian Way, Nottingham, Notts, NG80 >> 1ZZ >> >> >> >> >> >> >> >> >> >> > > > > -- Regards, Kingsley Idehen Founder& CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog: http://www.openlinksw.com/blog/~kidehen Twitter/Identi.ca handle: @kidehen Google+ Profile: https://plus.google.com/112399767740508618350/about LinkedIn Profile: http://www.linkedin.com/in/kidehen
Attachments
- application/pkcs7-signature attachment: S/MIME Cryptographic Signature
Received on Saturday, 19 May 2012 15:44:57 UTC