Kumar: - if a property you need is in dbo: use that. But double that for the objects in interest, it is indeed present in most of them - if a property you need is not in dbo: or many of the objects of interest are missing it, use dbp: . As described by Markus, you may need to use several dbp: props, especially across different language DBpedias: each dbp: is named in the local language
> For example, there are three different raw Wikipedia infobox properties for > the birth date of a person. > In the the /ontology/ namespace, they are all mapped onto one relation In addition to the merging of several dbp: into one dbo:, there is another advantage of dbo: - dbp: values of an array of subobjects are not correlated between each other. But if the mapping is properly modeled (e.g. using IntermediateNodeMapping), they can be properly correlated in dbo: > data is of much higher quality than the Raw Infobox Properties in the > /property/ namespace. That is the theory anyway :-) But dbp: come about automatically: each template property is emitted as a corresponding dbo: property In contrast, dbo: only come about, when someone has made an appropriate mapping. There are at least 2 potential problems with dbo: that a consumer needs to be aware of: - dbp:birthDate may be mapped to dbo:birthDate for 100 templates, but missing for the 101st template (or the mapping for that template may be missing altogether). How would a consumer detect this problem? - each dbo: is either an ObjectProperty or DatatypeProperty. This means that each returns only URLs, or only literals, but not both. dbp: doesn't have such restriction. Search for "dichotomy" in http://vladimiralexiev.github.io/pres/20150209-dbpedia/dbpedia-problems-long.html Cheers! Vladimir
