On 4/10/14 2:37 PM, Paul Houle wrote:
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.
Yep!
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.
No need for the replacement pitch. You have a curation-branded dataset culled from DBpedia, Freebase etc... Once loaded, this dataset can serve many useful purposes in conjunction with existing DBpedia and Freebase data.
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.
Mapping at the definitions level (data dictionary, schema, vocabulary, ontology) has more power and longevity than at the instance data level.
TBox (entity types definitions) & RBox (entity relation type definitions) driven tours are eternally superior to ABox driven tours, across the Linked Open Data cloud :-)
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 TBox, RBox, and ABox relations should always be loosely coupled. Conflation is our worst enemy in the Data Economy.
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.
Yes, there should be many of these, all loosely coupled.
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.
Yes, and there is value here for those who want functional business models in the Data Economy.
Kingsley
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
-- 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
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------------------ 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
