Rearrange Data.Frames to reflect the different object types in the package
Closed this issue · 2 comments
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?
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.