A straightforward handling of differing granularity requirements in different parts of an ontology can make it more difficult to repurpose or extend the ontology, or to use it in an ontology-driven data integration setting. The reason is that because one is often faced with a situation where (s)he has to decide whether to represent a notion as a literal value (e.g., a string) or an ontology entity such as a class. Choosing one over the other introduces a commitment that one may regret later on.

For example, when modeling a location, one could use the location name as a string or model it as a possibly full-blown pattern for the notion of Place. Choosing the former may prevent future use case of data enrichment, e.g., for expressing co-location (as one cannot use owl:sameAs relation between two strings). Choosing the latter means committing to a particular way of modeling Place, which may not necessarily be desirable in the future.

This pattern provides a way to solve this problem is to essentially keep both in the model, i.e., by including the literal value in the model, while employing a very minimalistic pattern for the notion. The latter is realized only as a single class.

- Replace the variable class <ClassName> with the class Place

- Replace the variable object property hasAssociated<ClassName> with hasAssociatedPlace

- Replace the variable data property <ClassName>KnownAs with PlaceKnownAs

- If desired, the properties may be renamed to something more appropriate with the problem at hand, e.g., rename PlaceKnownAs into placeKnownAs if CamelCase naming convention is used.