Concept Discussion: Types and Attributes

Imagine, we have a software that lets you manage a zoo.

The designers of this software are having a “design” discussion:

-They all agree that the system should be capable to assign a type to each animal. The software will ship a hierarchy of out-of-the-box types. Users shall be able to extend this hierarchy to create their own types.

-They also agree that each animal should have a set of related attributes such as the sex, weight, healthiness, tiredness. The value of some of these attributes may change or be changed over time. When the user selects an animal all current values are presented so the user can get an overview about the current state of the animal.

-The current discussion is whether the set of related attributes should directly depend on the type of an animal or whether they should add another concept called Animal Description. The zoo manager could then define several animal descriptions, and assign them to individual animals, independent of their class. The concept of Animal Descriptions came up because they assumed that it would be too much effort to define to the set of relevant attributes for each individual animal.

-Steven is in favour of Animal Descriptions. He has read an interesting book about software concept and has learned to avoid overloaded and redundant concepts. He argues that Animal Type is a concept that mainly serves the purpose to classify animals according to a familiar taxonomy in order to search and filter for certain types.
The Animal Description concept, he argues, serves the purpose of defining the relevant information that should be displayed when user wants to be informed about a certain animal. Degining a set of attributes would overload the concept Animal Type. In many cases not all relevant attributes depend on the Animal Type. For instance a pregnant animal has special attributes of interest - or an animal born in the wild, or an animal that is part of a research project.

-Francis argues that the introduction of Animal Descriptions makes the software hard to understand. The user could always define a new type together with its set of attributes.

-Steven argues that in this case, the users would have to artificially extend the type hierarchy, leading to a degration of the original Animal Type concept.

-Francis also argues that search & filter are more general concepts not directly bound to types. Today, they may use animal types as criteria, but further criteria could be added. He also argues that there are some users for which the relevant attributes always depend on the type - a kind of simple use case.

-now Steven is unsure how to proceed. He still thinks that both should be separate concepts. Maybe the purpose of Animal Types is just to allow users classify animals in their prefered way. The point is that the relevant attributes may not directly depend on this classification. He is also unsure whether these concepts are even concepts in the sense of the book he has read, they do not seem to involve state and behavior but are rather concepts from the domain of conceptual modeling.

It seems like there is a trade off between optimization for simple use cases and optimization for complex use cases. If the use case is simple Animal Descriptions are redundant, if the use case is complex their absence leads to overloading of Animal Types.

Do you have any advise? Do you think that the alternatives are related to software concepts in the narrow sense discussed in this forum?

1 Like

Hi Fabian, Welcome to the forum!

I’m curious to understand better what you have in mind for the AnimalType and AnimalDescription concepts. I think I’m with Steven, who says he is

unsure whether these concepts are even concepts in the sense of the book he has read, they do not seem to involve state and behavior but are rather concepts from the domain of conceptual modeling.

I see potentially three different concepts here:

  • AnimalTaxonomy. The purpose of this concept is to make available (in this system, to the zookeepers and the public) knowledge about different kinds of animals. Its state would be a taxonomy of species, genus, family etc of different animals and their characteristics, and its actions would allow the updating of this catalog as it gets enriched, corrected, etc over time.
  • AnimalIdentification. The purpose of this concept is to identify each of the animals in the zoo, assigning it an identity (including distinguishing markings etc) and a kind from the taxonomy. Its state would be a database of identifiers and types, and its actions would including assigning a kind to a particular animal, and perhaps revising that over time.
  • AnimalCondition. The purpose of this concept is to track the condition of each animal. Its state would be a log of observations, tests and interventions, associated with particular animal ids, and the actions would record those.

Does this make sense?

Thanks. That has helped very much to identify potential concepts in this scenario.

Based on the three concepts you have proposed the discussion would continue like this:

Certain users would be responsible to connect each property that is part of an AnimalCondition to a column in an external database that contains actual values (maybe originating from some smart sensors). For this task, he needs to know which properties are expected for a certain animal and the system should keep track of which properties are already assigned to signals from the database.

The question is whether there should be a list of properties associated with each type of the AnimalTaxonomy or whether there should be another concept AnimalConditionTemplate, whose state would be a set of templates, where each template is a list of property definitions that specify which properties are relevant for an AnimalCondition. Each template could be assigned to one or multiple animals. For example a template for animal born in freedom would have additional properties related to its origin and mode of purchase and could be assigned.

For the sake of the discussion, let us assume a single template is sufficient to describe all relevant properties of an AnimalCondition. Maybe we can consider an extension to combine multiple templates later.

The idea is that it would be way too tedious to reinvent the set of relevant properties for an AnimalCondition for each individual animal. So thr purpose of AnimalConditionTemplate would be to predefine commonly used sets of properties that can be assigned to animal to define details about their AnimalCondition.

Francis is in favor of directly attaching this list of relevant properties to the AnimalTaxonomy concept.
In simple cases the set of relevant properties depends only on the type of the animal, in more complex cases one could just add further types to the taxonomy as required to express a certain AnimalCondition. For instance a type “ZebraBornInFreedom”.

Steven argues that this is overloading the concept leading to unnatural taxonomies, artificially extended by types whose purpose is related to AnimalCondition.

Francis understands that very complex cases would blow up the type hierarchy but says that they will not be very frequent and having a separate concept for AnimalConditionTemplates makes the overall system hard to understand.

Currently, they feel like we might have 4 potential concepts:

AnimalTaxonomy
AnimalIdentity
AnimalCondition
AnimalConditionTemplate

The question seems to be whether the inclusion of the template concepts provides an overall benefit.

I feel that in the discussion between Steven and Francis there is a certain tension between the way we may structure the problem using concepts (as defined by Daniel Jackson) and the way we may structure it using object-oriented classification.

In 1991 Michael Jackson wrote in one of his wonderful papers (Object-Orientation: Classification Considered Harmful) about some of the difficulties that object-oriented classification can introduce into problem analysis.

Here we may see these difficulties when multiple classifications (“ZebraBornInFreedom”) and/or dynamic classifications (“PregnantAnimal”) apply to the same animals.

If instead we only focus on the concepts, those difficulties are no longer here: “multiple classification” is naturally supported, because an individual can participate in multiple concepts (in their states), and “dynamic classification” is naturally supported, because an individual can enter and exit the state of a concept by its corresponding actions.

1 Like

I think the footnote 42 from “The Essence of Software” is relevant in this situation (and in many design discussions I had in the past :slight_smile:) We need to stop thinking in terms of ontologies and ask ourselves instead what domain of actions the software will automate.

As Dr Jackson said above, when managing a zoo, the concept of identity for an animal will likely be relevant. This identity will have a set of attributes, some never changing (e.g. type), some changing rarely, and others changing almost every day. Those attributes and the kinds of actions that the zoo employees do will drive what other concepts/properties are required for each animal. Those do not only depend on the type of animal, they can depend on their sex, on their medical history…

Trying to define categories or even mixins like “ZebraBornInFreedom” is in my opinion a dead end. It is likely impossible to imagine all the situations that would require custom properties/actions. I think it is best to look at what the zoo employees do every day and extract generic abstract concept for it. For example, they probably need to have concepts like “Schedule” to take care of regular care for animals but it is not relevant why this care is needed. The system should support a generic schedule mechanism. That’s what I mean by basing the design on “actions” rather than “taxonomies”.

What do you think?

2 Likes

I agree with your statement that we should stop thinking in terms of ontologies, at least when we are doing concept design. I would add that something similar is true about attributes: they should not drive the concepts; it should be the other way round.

So in the AnimalIdentification concept, I would only include state that is needed to identify an animal. Other attributes (state) would be part of other concepts on an “as needed” basis.

Does this make sense?

1 Like

Great discussion.

I just want to highlight a point that I have probably not made very clear.

The zoo software is supposed to be sold to many zoos. Each zoo manager should be able to organize animals according to his own specific criteria.

The discussion is around which base concepts do we need to provide so that each zoo manager can tailor it to his specific circumstances.

We realized there is one concern related to classification of each animal to a certain type and one concern is associating certain attributes to an animal. The initial discussion was whether both concerns should be addressed together by associating attributes to types or whether types should be unrelated to the attributes. The question was whether thinking in terms of concepts may help as we felt it may have something to do with overloading concepts.

1 Like

You are right, we are not done yet. :slightly_smiling_face:

Before we go into the discussion about the customization, I have a question for @dnj about the AnimalTaxonomy and AnimalIdentification concepts.

It seems that AnimalIdentification is using AnimalTaxonomy directly, as its purpose says (“assigning it […] a kind from the taxonomy”).

In this case it could seem quite natural that AnimalIdentification would be coupled to AnimalTaxonomy (the coupling point being the set “Kind”), but on the other hand we really want concepts to be (completely) independent.

So my question is: Would we define AnimalIdentification with a generic “Kind” (and connect the two concepts later) or would we define it using “Kind” from AnimalTaxonomy directly? (I don’t know if the latter is even possible using the notation of EOS.)

1 Like

The initial discussion was whether both concerns should be addressed together by associating attributes to types or whether types should be unrelated to the attributes.

It depends what the purpose of types are. If types are used to communicate with the public and provide a type-specific data sheet for each animal then it makes sense to attach those attributes to types. This is the “AnimalTaxonomy” concept proposed above.

But I would not represent any other concern using this concept. If the zookeeper need to store information related to the animal condition or care then different concept(s) need to be introduced.

1 Like

What a great discussion with so many interesting observations! A few thoughts:

  • Operationalizing our questions. I’m not averse to taking a philosophical approach particularly when it can help us highlight a contradiction in our thinking, or help us resolve a puzzle. But generally I find it very helpful to try to return all questions to operational ones, asking what the impacts on developers and users are in very concrete terms. This is the point I’m making in Note 42 that @benfle cites (thank you!) which is saying in part that object oriented ontology questions can take us in an unproductive direction, and thinking about what functionality needs to be supported can be more helpful. Also, as @abo notes, attributes are best regarded as derived from functionality rather than someone having to exist for some ontological reason. @benfle points out that in the case of the animal taxonomy attributes, these might follow very directly from what users expect to see about animals.

  • Template for animal conditions. In that spirit, @fabian’s point that some kind of template mechanism would be useful seems spot on to me. There will likely be subsets of the animals that need to be tracked in different ways. and some kind of template concept seems like a reasonable way to capture the commonalities (and avoid having lots of optional fields).

  • Overloading of taxonomy. Addressing @fabian’s particular question, I’d side with Steven who argues that Francis’s proposal to put the template mechanism for animal conditions inside the Taxonomy concept is a bad idea, and that it’s a form of overloading. It’s tempting to put the mechanism there, because the templates seem initially to be aligned with animal taxonomy types. But then as Francis himself notes, to distinguish animals born in freedom from animals born in the zoo you’d find yourself extending the taxonomy with types like ZebraBornInFreedom. And it seems to me there’s no end in that. What about the animals that are in the petting zoo and get more contact? Or the ones that are getting special treatment after an injury (a dynamic category)? These classifications seem neither to align with the natural taxonomy, nor do they seem to have any value for a developer who just wants the taxonomy concept. So both separation of concerns and clarity of purpose are likely to be compromised by doing this.

  • Dynamic and multiple classification. I agree with @abo that structuring with concepts lets you avoid the traditional complications of OO-like classifications. In general, each concept can impose its own classifications on objects, and those classifications can be overlapping and dynamic. There’s no reason you couldn’t use an OO type hierarchy inside concepts (and just never expose them in the interface).

  • Maintaining decoupling. I was sloppy in taking about how AnimalIdentification might assign a type to an animal, while the concept that creates and manages those types is AnimalTaxonomy. @abo caught this and correctly noted that to ensure that the concepts are independent and uncoupled this will require AnimalIdentity to refer to the animal type using a generic type variable (which would be instantiated when the concepts are composed).

  • Decoupling condition templates. Finally, here’s one part of this whole scenario that I don’t have completely resolved in my mind and that you can all help with. The easiest way to deal with the condition templates is to say that they are part of the AnimalCondition concept, which would include both the functionality for defining the templates for animal kinds, assigning the kinds to individual animals, and then maintaining the instantiated templates. But, as I think @fabian is suggesting, it would be nice to separate out the template functionality into its own concept. But we’d like to do that in a way that doesn’t make the AnimalCondition concept actually dependent on the Template concept. This is a pattern that arises in many contexts where templates are used, so it would be great to solve it. Ideas?

1 Like

Thank you very much @dnj for taking the time to write such a nice and helpful answer!

It will be interesting to further discuss the AnimalCondition and Template concepts.

@Fabian, am I understanding the need of the zoo managers correctly that everything they would like to express about animals in the AnimalCondition concept could be done based on template properties?

If that’s the case I wonder if we should make the AnimalCondition and Template concepts completely generic, because they don’t seem to be animal-specific anymore.

What do you think, would it make sense to go into this direction?

Interesting questions.

Yes, I think we could generalize the concepts and just talk about entities instead of animals.

Initially, the assumption was that Templates describe all attributes that are of interest reg. an entity.

However, we found out that users do not always know a-priori which attributes are relevant for a given entity. And, indeed, in some cases the set of relevant properties may change over time.

It appeared that there were at least two different concepts to choose from. First, one where entities and concepts are tightly couples and changes to either must be somehow synchronized. Second, one where templates can be applied as a are mere shortcut to create multiple attributes at once.

At this point we realize that we do not really understand what is needed but rather explore the range of options that appear to us. Maybe there are at least two archetypical concepts here": Aspect (or Facet) and InstanceTemplate.