It's more accurate to say that the Infovore software is a bridge between Freebase, DBpedia, and other RDF data sets. It merges data sets in batch job and creates data sets that are normalized. I think also it
:BaseKB is a family of products produced from Freebase and Dbpedia data using the Infovore software. The main product, :BaseKB Now, is a cleaned up version of the Freebase RDF dump that is much easier to work with than the raw dump. :BaseKB is similar to DBpedia and could be used as a substitute in many applications, but Dbpedia has some unique and valuable information that is not in Freebase. As for vocabulary conversion I get asked about that a lot. One reason I haven't done it is that every transformation you do to data risks messing things up and the data quality issues are up in the air enough that a half-baked effort at conversion will cause more problems than it solves. If you keep the vocabulary separate, you can query Freebase's opinion and query Dbpedia's opinion and know things haven't been worse. The mapping process would be done one predicate at a time and would probably be guided by how prevalent the predicates are. Some of the predicates are going to be easy to process (just rewrite them) but other ones might need more work if compound value types are involved or if the types are literal types that have a system and domain dependent meaning that needs to be preserved (is it feet or meters?) It might also be useful to map to some third vocabulary. I know people would like to see DBpedia and Freebase through schema.org eyes and I think that would be a good idea. Common types and properties will get handled quickly but if somebody is interested in some vertical, say boats (20,000 known in Freebase) they probably personally will need to do the work to figure things out. For instance, Freebase is missing a lot of facts about boats that are in DBpedia. A union database will benefit from that, and there ought to be some community process where those fixes can be expressed as rules and added to the system. On Wed, Apr 9, 2014 at 5:25 PM, Kingsley Idehen <kide...@openlinksw.com> wrote: > On 4/9/14 4:53 PM, Paul Houle wrote: >> >> The type assignments in DBpedia are very precise (few false >> statements) but not accurate in the sense that recall is poor; many >> things fall through the cracks. The real problem is that the the >> mappings are the map, not the territory. Wikipedia is an >> encyclopedia for humans, not for machines, so DBpedia has to parse >> whatever unsane markup they give us. >> >> Systems like Wikidata and Freebase can be edited by machines and >> human ontologists and get better recall for types. >> >> http://basekb.com/ >> >> is a conversion from Freebase to industry standard RDF. You could >> use :BaseKB as a substitute for DBpedia, but DBpedia has advantages >> too because in addition to the 4 million things important enough to be >> in DBpedia, there is another 37 million unimportant things in :BaseKB >> that matter only to librarians, video store clerks and professional >> discographers. >> >> These unimportant things will drive you crazy unless you master >> them, and the easiest way to turn down the noise is to restrict >> search to the 4 million things. >> >> I could make you an RDF file that has statements such as >> >> ?dbpediaTopic a ?freebaseType . >> >> you could load that together with the rest of DBpedia. That would >> get you a long way towards good lists. The trouble at this point is >> that you don't have the freebase types connected to the DBpedia types >> so you can't join them against the schema to find properties and such. >> Mapping the types to the DBpedia types would not be that hard either, >> since the two systems are well aligned. Then you get something that >> looks like DBpedia but has more accurate types. >> >> Freebase has more accurate and better populated data for things >> like ticker symbols, geo-coordinates, genders, birth dates and the >> like. It would not be hard to rewrite Freebase statements to >> >> ?dbpediaTopic ?freebasePredicate ?anotherDbpediaTopic . >> >> and that would produce something that would be remarkably user >> friendly. > > > :baseKB could (and maybe should) pitched as a human-and-machine curated > bridge between Freebase, DBpedia, and Wikidata (I think). > > Have you considered mapping the classes and properties across DBpedia, > Freebase, and Wikidata? > > > -- > > Regards, > > Kingsley Idehen > Founder & CEO > OpenLink Software > Company Web: http://www.openlinksw.com > Personal Weblog: http://www.openlinksw.com/blog/~kidehen > Twitter Profile: https://twitter.com/kidehen > Google+ Profile: https://plus.google.com/+KingsleyIdehen/about > LinkedIn Profile: http://www.linkedin.com/in/kidehen > > > > > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Dbpedia-discussion mailing list > Dbpedia-discussion@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion > -- Paul Houle Expert on Freebase, DBpedia, Hadoop and RDF (607) 539 6254 paul.houle on Skype ontolo...@gmail.com ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees _______________________________________________ Dbpedia-discussion mailing list Dbpedia-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dbpedia-discussion
