Resource classification by inheritance vs association

Question

I am developing an application that will allow employees (users) to classify table and columns in the corporate databases according to a given taxonomy.

Once the database metadata has been imported, it is converted into an RDF graph. Each table and column is an instance of an internally developed RDF class for representing tables and columns. Note that actual table data are NOT imported.

So a particular column may look like this in Turtle format:

ex:emp_id a dbmap:Column ;
     dct:title "emp_id" ;
     dbmap:storageType "integer" ;
     dbmap:storageSize "10" .
# ... there may be more attributes here ...

Now let's say that we want to associate a logical type (sumo:EmployeeIdentifier) from the taxonomy with this column.

Should ex:emp_id be a sub-class of sumo:EmployeeIdentifier:

ex:emp_id a dbmap:Column ;
     rdfs:subClass sumo:EmployeeIdentifier ;
....

Or should the association be made by an attribute:

ex:emp_id a dbmap:Column ;
     dbmap:logicalType sumo:EmployeeIdentifier ;

What are pros/cons of each approach?

Accepted Answer

Here are some considerations:

If you are modeling ex:emp_id to be a subclass of sumo:EmployeeIdentifier, this means that any instance you have of the former will be an instance of the latter as well (instance inheritance). So one question is: are all conceivable instances of ex:emp_id really always sumo:EmployeeIdentifiers? Or could it be that you have instances that are not (one thing that springs to mind is that you might want to cover the case where the database value is null, or an illegal value: such values would be instances of your ex:emp_id column, but they would not be identifiers). I realize you currently do not plan to actually have instances of ex:emp_id, but it never hurts to think ahead - you might want to later (or someone else might).

The flip side of that argument is that if you model it as a property/association, you will not get any automatic inheritance of the sumo:EmployeeIdentifier classification.

Another consideration is that of modeling complexity: making ex:emp_id of type Column means it is an individual instance. Making it a subclass means that you now have a concept that is both a class and an instance. While this is fine in principle, it does have the potential to make your model more confusing. Using subclassing effectively implies you do not consider ex:emp_id the 'lowest level' in your data model.

To make a long story short: if your intent is not to ever have individual instances of ex:emp_id in your model, but consider ex:emp_id the individual, then I would recommend modeling the relation with sumo:EmployeeIdentifier via a property, rather than using subclassing.

Resource classification by inheritance vs association

Follow this question

Upcoming Events

Related questions