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 string literal value 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.

• owl:Thing
• xsd:string
• variable class: <ClassName>
• variable object property: hasAssociated<ClassName>
• variable data property: <ClassName>KnownAs

Axiom patterns (in Manchester Syntax):

• hasAssociated<ClassName> Range <ClassName>
• <ClassName>KnownAs Range xsd:string
• <ClassName>KnownAs some xsd:string SubClassOf: <ClassName>
• <ClassName> SubClassOf: <ClassName>KnownAs some xsd:string

• 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.