Thanks for the detailed and thoughtful comments. I agree with your statements; they seem to be more geared to proper interpretation at the TBox level. So I think these comments might be skewed a bit to my intent.

My intent, probably not stated well, was to look to description logics as a way to provide coherent guidance for how to handle distributed, structured data in a linked data manner. I think we can look to simpler data transfer and instance record structures to achieve this aim, while still providing instance input that can be integrity checked and incorporated for meaningful reasoning in TBox ontologies.

Your elaboration on the daisy example, too, I think helps reinforce my (poorly articulated) argument. At the ABox level we can treat all of these variants as instances with asserted attributes. We then can later hash out what all of that means within a proper reasoning framework at the TBox level.

I hope that helps, and if I still missed some key points, please keep it up!

Mike

My comment touches on the role of named graphs and rules for separating contexts and defining constraints across contexts. I will continue to use your example of daisies.

First, there are different kinds of species that carry the name "Daisy" – for example, there are Gerbera Daisy and Common Daisy. Even for the Common or English daisy there are 15 different species according to Wikipedia (http://en.wikipedia.org/wiki/Bellis). This means there can be a class Daisy whose instances are the actual species of daisy. This class would be a subclass (transitively) of a BotanicalSpecie class. The kind of properties one may want to have for species are the country of origin, average height, the person who discovered the specie, etc. On the other hand, there could be a class Daisy which represents all daisy flowers.

Properties listed above for the species don't make sense for the flowers. A daisy in my backyard did not originate in Africa, it may have grown from a seed or was bought at a nursery. It does not have an average height, it has an actual height. It also has a date it was planted, a condition (is it healthy or damaged), a growth state, etc. These properties of a flower are not appropriate for a specie. A class of daisy flowers may have subclasses whose members are all the daisies growing in North America, available for sale in a given nursery or present in my backyard.

This example shows that there is a need to distinguish between the class Daisy whose members are species and the class Daisy whose members are flowers. In RDF/OWL such differentiation is accomplished through the use of namespaces and named graphs. We can specify a relationship between two "systems of classes" using either a hasValue or allValuesFrom restrictions (depending on how the ontologies are designed). Description Logics don't play a role in distinguishing this contextual nature of concepts or in the ability to modularize ontologies. They don't provide a mechanism for giving a different URI to a class of specie:Daisy and flower:Daisy. This happens at the RDF level.

I wonder why Description Logics played a central role in your post. Was it only about using TBox and ABox terms to talk about schema and data?

Going farther with these examples, it is interesting to consider property values that are "inherited" between the species and the flowers. So far, I have given examples of properties that are unique to each class of individuals. But if a given specie of a daisy has medicinal properties, a daisy in my backyard that is a representative of the specie also has these medicinal properties. If a specie has a certain range of colors, the color of my daisy should fall within the range. In Description Logics describing such constraints can call for very complex class structures and axioms. Some of the constraints can not be addressed in Description Logics. How, for example, can I specify that the height of my daisy will not exceed the upper bound of the height of its species? The way to address this is through rules.

To address in a practical manner, the kinds of requirements this thread identifies, a rule system needs to be associated with resources, typically classes. With this motivation we have created SPIN (SPARQL Inferencing Notation) http://www.spinrdf.org/ which uses SPARQL CONSTRACT statements to specify rules. Additional information and demos are available at this blog http://composing-the-semantic-web.blogspot.com/2009/01/object-oriented-semantic-web-with-spin.html.