luckinet/ontologics

Rearrange Data.Frames to reflect the different object types in the package

Closed this issue · 2 comments

rue-a commented

The package is build around 5 types of objects. The central two object type are the harmonised classes and the harmonised concepts. Both the harmonised classes and concepts, can be mapped to external classes and concepts. An external class/concept is a class/concept that is defined in another source; a source can be an ontology, a vocabulary, or generally anything that provides a description of the class/concept. The external classes and concepts are the third and fourth object type. Every external class/concept has to be related with one such source, which leads to the fifths object type, the sources.

Each of these five object types share the three properties id, label and description, which are accompanied by some type-specific properties. The rearranged Data.Frames to model this five types in five Data.Frames would look as follows (the <...>-tags denote what kind of value has to be entered in this column):

1. Harmonised Classes

id label description has_broader has_close_match
<a harmonised class id> <a string> <a string> <another harmonised class id> <an external class id>

2. External Classes

id label description has_source
<an external class id> <a string> <a string> <a source id>

3. Harmonised Concepts

id label description has_broader has_close_match class
<a harmonised concept id> <a string> <a string> <another harmonised concept id> <an external concept id> <a harmonised class id>

4. External Concepts

id label description has_source
<an external concept id> <a string> <a string> <a source id>

5. Sources

id label description homepage license notes
<a source id> <a string> <a string> <a URL> <a license string> <a string>

Something that would happen quite often is that an external concept would have a match that is not a close match, for instance a territory that existed once, but doesn't anymore (some Landkreis). In that case, I'd intuitively handle the previously existing (but not anymore) concepts and new to insert into the ontology via a "has_narrower_match" to the respective Bundesland, in which it has occurred. Or, in case the previous territory was split up into several territories that are now in different Bundesländer, I'd assign it with the narrower match to the Bund. Shouldn't we, in that case, also allow a "has_narrow_match" to the harmonised concepts?

rue-a commented

Something that would happen quite often is that an external concept would have a match that is not a close match, for instance a territory that existed once, but doesn't anymore (some Landkreis). In that case, I'd intuitively handle the previously existing (but not anymore) concepts and new to insert into the ontology via a "has_narrower_match" to the respective Bundesland, in which it has occurred. Or, in case the previous territory was split up into several territories that are now in different Bundesländer, I'd assign it with the narrower match to the Bund. Shouldn't we, in that case, also allow a "has_narrow_match" to the harmonised concepts?

I see, I thought the mappings were restricted to close_match. In this case, I think we should add has_narrower_match, has_broader_match and has_exact_match, to cover all eventualities. The same then for classes, I think. The has_exact_match relation denotes that a concept or class is actually identical to some other concept or class.