BoW partitioning

The OntoGraphs in Figure pc0, pc1 and pc2 represent the modeling of partioning classes for ^BoW (Body of Water) by the data properties .LocationType, .NatureType and .FloatingType using the partitioning classes ^Location_by_LocationType, ^Artifact_by_NatureType and ^Liquid_by_FloatingType. Compared to the modeling with Thing_by PCs the difference is that the properties are specific to the base classes ^Location, ^Artifact and ^Liquid and not generally relevant for other things.

The connection between knowledge subjects and their activity (Figure pc2) is established via the ObjectPropert ◊iao (◊is_Action_of). E.g. (°Floating, ◊iao, ^Liquid_by_FloatingType-floating) means that all particulars of ^Liquid_by_FloatingType-floating are floating.

The OntoGraph in Figure pc3 shows, that the four classes ^BoW-Stream, ^BoW-Wadi, ^BoW-Creek and ^BoW-TidalCreek inherit the values for the properties FloatingType, LocationType and NatureType by the superclasses of ^BoW_natural_aboveground_floating. The consequence is that the values floating, aboveground and natural do not have to be explicitely stored neither in the three classes nor in any particular thereof. For the particulars this can be achieved by assertions like (>RIV-Rhine, iof, ^BoW-Stream), or (>RIV-Amazonas, iof, BoW-Stream). Compared to the representation in Figure pc4 instead of three triples only one triple is needed to have access to the values floating, aboveground and natural for any of the four classes. If n is the number of properties combined in a concept (n=3 for ^BoW_natural_aboveground_floating) then n-1 triples can be saved for every class and every particular thereof.

The OntoGraph in Figure pc5 takes ◊Outlet as an example for creating partitioning classes with object properties (OP). With ◊Outlet the property chain (^BoW-Small_River ◊Outlet BoW-River, ^BoW-River ◊Outlet ^BoW-big_River, ^BoW-big_River ◊Outlet BoW_Stream, ^BoW_Stream ◊Outlet ^BoW_Sea) models that smaller rivers have outlets in bigger rivers or an endlake or a sea.

If you consistently work with partitioning classes, then the height of the class hierarchy is fixed:

• (Level 0) Under the base class - here BoW (Body of Water) - come as the next levels:
• (Level 1) the top classes of the partitioning, here, among others, bodies of BoW_by_Location, BoW_by_NutrientContent, BoW_by_WaterType, etc.
• (Level 2) then has exactly one subclass for each value (Value) from the ValueSet of the DataProperty, e.g.
• (Level 3) then has the base classes, which has the appropriate value for the Data Property of the Level2 class. The reference is made via hasBroader, e.g. (Sea hasBroader BoW_by_WaterType-Saltwater)

A necessity for further levels of classification according to only one Data Property. Thus, such a thoroughly normalized class hierarchy would have exactly four levels.

In Germany alone there are approx. 200 rivers of lenght > 200 km and approx. 15,000 watercourses (streams etc.). In the case of classes that have such a high number of individuals, the introduction of further subclasses makes sense. That's why we introduce here:

• surface_BoW with (hasBroader BoW_by_Location-aboveground) and (hasBroader flowing_waters)
  with .Location = aboveground and .StreamType = flowing
• Underground_flowing_Water with (hasBroader BoW_by_Location-underground) and (hasBroader Flowing_Waters)
  with .Location = underground and .StreamType = flowing
• Aboveground_Stillwaters with (hasBroader BoW_by_Location-aboveground) and (hasBroader StillWaters) with .BoW_Location = aboveground and .BoW_FlowType = flow-free
• Underground_Still_Waters with (hasBroader BoW_by_Location-underground) and (hasBroader Still_Waters)
  with .BoW_by_Location = underground and .BoW_FlowType=flow-free

This results into

• (Level 4) contains the derived classes resulting from the combination of two Data Properties.

Advantages:

• you can find the particulars directly via (<>iof aboveground_river)
• for particulars such as the Rhine, Elbe, Ruhr, etc., you can save the triples for the data property value pairs (.GewaesserLage=aboveground) and (.Flow type=flowing), since they can be derived from the classes as virtual data properties. In the case of German surface BoWs, that would be 2 x 15,000 = 30,000 triples that could be saved.

The principle of deriving subclasses can then be continued accordingly. e.g. you could add and define the width of the water

• Shallow_Surface_River with (hasBroader Surface_River) and (hasBroader BoW_by_DepthType-shallow) and .BoW_Level = above ground and .current type=flowing and .BoW_DepthType = shallow

This results into:

• (Level 5) contains the derived classes resulting from the combination of three Data Properties.

In the case of the particulars, one would in turn be able to save the corresponding number of triples for the pairs of values ​​(depth type=flat). As a consequence, this means: The more derived subclasses you introduce, the more triples you can save in the particulars. For example, with 3 Data Properties and 100,000 particulars, there would be a total of 300,000 triples that could be saved. Another advantage is that the subclass names are very "descriptive". Everyone would immediately understand what is meant by "shallow_aboveground_river".