don't nest IntermediateNodes

[VladimirAlexiev]

@jplu: I don't think the extractor supports nesting of intermediate nodes (and I haven't yet seen a need for such).

You use such eg at http://mappings.dbpedia.org/index.php/Mapping_fr:Infobox_Territoire (any other maps?)

https://fr.wikipedia.org/w/index.php?title=Gouvernement_régional_du_Kurdistan&action=edit

 | pib                    = 23,6 Mrd USD (2011 est.)
 | pib_hab                = 4,452 USD (2011 est.)

But in the extracted data http://mappings.dbpedia.org/server/extraction/fr/extract?title=Gouvernement%20régional%20du%20Kurdistan&revid=&format=turtle-triples&extractors=custom

<http://fr.dbpedia.org/resource/Gouvernement_régional_du_Kurdistan>
 <http://dbpedia.org/ontology/grossDomesticProduct>
   <http://fr.dbpedia.org/resource/Gouvernement_régional_du_Kurdistan__3> .
<http://fr.dbpedia.org/resource/Gouvernement_régional_du_Kurdistan__3>
  a <http://dbpedia.org/ontology/GrossDomesticProduct> ;
  <http://dbpedia.org/ontology/value>
   "24"^^<http://www.w3.org/2001/XMLSchema#nonNegativeInteger> .

there's only PIB and not PIB_hab.

Also, as you can see, the PIB data is very poor. If you'd like, make a separate issue for that and I'll try to help

[Nono314]

Both grossDomesticProduct and grossDomesticProductNominalPerCapita being properties of PopulatedPlace, I'm not even totally sure the nesting was on purpose...

But there are a lot of problems here... Namely:

• the property chosen by Julien is value of type xsd:nonNegativeInteger, that's why the amount is truncated to an int
• he also changed the original data property typed as currency amount to an object property with a new GrossDomesticProduct type this is breaking a lot of mappings in a number of languages.
• those other languages used the property grossDomesticProductAsOf to record the corresponding date, so again no consistency.

[jplu]

Thanks for having fixed this!

[Nono314]

I fixed the 2 properties in the ontology so that mappings in other languages work again. I also fixed Territoire and Pays (the latter also had intermediate nodes for names in other languages). There are still Ancienne entité territoriale and Ville de Chine not yet addressed.

I also did some additions in https://github.com/dbpedia/extraction-framework/pull/363 that should help us get the right order of magnitude for the GDP values.

[VladimirAlexiev]

Thanks for catching this!

@Nono314, @jimkont : We need a best practice on mapping Measurements (also https://github.com/dbpedia/mappings-tracker/issues/42). Proposal:

• If there's already a simple way being used (eg grossDomesticProduct, grossDomesticProductAsOf), use that
• Else use a new common class Measurement (this matches CRM classes E54_Dimension or E56 Measurement): with fields type, value, unit, year (or date); and whatever else may be needed, eg
  • subtype, eg area metro, area total; elevation bottom, elevation top, elevation gain (difference)
  • method, eg census vs estimation
• Thus all specific classes like Area, GrossDomesticProduct, etc etc are suspect and subject to deletion
• I dislike the "specific properties" eg "Person/height" because they are sparql-unfriendly (no slash can be used in prefixed name) and need to discover the existence and the unit.
• Above all, follow already established mappings and don't make new patterns unnecessarily.

Do you agree?

[Nono314]

I was also considering a more generic class instead of all the specialized ones created by Julien but:

• UnitValueParser heavily relies on the property being form a UnitDataType and checks that dimensions match
• it's handy to have values converted to a standard unit so as to be able to query them globally

I think almost all cases also exist in other languages and are mapped using simple properties. So I would keep with your 1st proposal: stay consistent with what already exists. In the longer term, it would indeed be nice to be able attach a year or a qualifier to the value.

As a side note, this current bug https://github.com/dbpedia/extraction-framework/issues/364 is also a good reason not to use so frequently intermediate nodes with many properties that may not be filled.

[VladimirAlexiev]

@Nono314 I can't grasp your two bullets above, please elaborate

• with a generic class Measurement/Dimension, we could still use specific "unit" (corresponding to the specified "type")
• what "standard unit" do you mean? My argument is that "Person/height" (cm) is worse than just "height" (m) for the 2 reasons provided

[Nono314]

Maybe I was too much sticking to the current implementation...

My assumption was that the value property would be xsd:float with the actual unit stored in the unit property, basically as they appear in the wiki content.

Currently:

• SimplePropertyMapping instantiates the UnitValueParser based on the target property being a UnitDataType (though you can then override this type by explicitly setting a unit on the mapping).
• If you have a template property that can contain things like 1.2m, 120cm or 3 feet 11¼ inches, everything currently ends converted into standard SI units (here meter). This is all done by the framework based on the property's datatype and would not be possible with a bare float.
• You also have some specific bahaviours, such as looking for unit at beginning when type is a currency.

For all this you would have to rely on each mapping explicitly setting at least a dimension, in which case, the conversion could actually still happen.

I totally agree with your second point.