We need an analogy engine.
we should be able to feed it things like this:
sql schema => owl ontology
sql rows => owl instances
which can be expanded by the knowledge that the sql schema can be seen as just a certain set of sql rows.
certain sql rows => owl ontology
which can be then expanded by the knowledge that the owl ontology is just a set of certain instances of owl.
so we can see that we have the following relation :
certain sql rows control other sql rows.
certain owl instances control other sql instances.
I mean by that, there are constraints that are enforced by the database engine. Some of these contraints can enumerated :
there exists a string value in a row , where the name of each available table in the database resides.
there exists an rdf:about attribute for each owl:Class which is the name of each available class resides.
now, this interpretation can be misleading. because we only really want to talk about a subset of owl that is used to represent our subset of sql that we are interested in modelling.
therefore the implications for and about owl classes are only really about the subset of classes that we are generating.