Concept Discussion: Types and Attributes

Cool, I see we have a lot of interesting questions to consider.

I think we could address most of these within the concept we have sketched out.

But there are also things our current concept could not address that might be relevant to your scenario. Two come to my mind right now:

  1. When we assign a template to an entity instance, its properties get instantiated and we can then start to assign values to those instantiated properties. But there are no initial value assignments.
  2. We can do no validation. Users are free to assign any value to any property.

Can you live with that?

Update: I think we could solve the first issue (initial value assignments) within our tentative concept by providing an (optional) default value when we assign properties to templates. And I think we could solve the second problem (validation) with a separate validation concept and use synchronization between the two concepts when setting values.

But I would leave the validation part out for now if that’s OK with you.

Over night, another issue came to my mind, one at a deeper level.

When @fabian and I took the emphasis away from the zoo in the updated problem statement above, I wasn’t aware that by doing this, we implicitly reframed the problem from an information problem to a workpiece problem: data is still important in the new framing, but it is not longer very important (to us as designers), what this data really is about.

Now, the new framing may or may not be adequate, I can’t tell.

But I wanted to give a heads-up that if the new framing is not adequate, I think we will probably end up with the wrong concepts. @dnj, am I making a mistake here?

No chance yet to read through all this in detail and think about it, but I wanted to share a couple of thoughts:

  • Domain specificity. Concepts are all about making functionality generic when possible, so I applaud the way in which @fabian is trying to generalize. But I think that it’s a mistake to move away from a concrete domain. By all means let’s discuss generic concepts to support the Zoo, but once we stop talking about the Zoo we no longer have a grip on what problem we’re trying to solve, and it becomes hard to evaluate any particular design proposal.
  • Excessive generality. There’s also a risk of becoming so general that (a) the design problem actually becomes harder, and (b) you’re no longer attending fully to the specific properties of the problem at hand. Is the AnimalTaxonomy concept really just a generic Taxonomy? I suspect that if you were building a system to support zoo animals, you’d want to build a very animal-specific taxonomy that has hardwired schema notions like genus, species, etc. Also if we make completely generic Template and Aspect concepts, aren’t we just going to find ourselves building a content management system?
  • Tracking animal conditions. If I were working on the Zoo system, I’d want to understand better what functionality is needed here. I’d guess it’d be more than just a generic workpieces problem (as @abo notes it seems to be becoming, referring to Michael Jackson’s problem frames). For example, might the zoo keepers not want to track the conditions over time? And to label some subset of the animals as needing special care and thus more active tracking?
  • YAGNI. Even as I write this, I realize I may be falling afoul of the agile slogan “you aren’t going to need it.” Perhaps the best way to work out a concept design is to first posit that some particular purpose exists, and then figure out which concepts are needed to support it.

I’m pondering the template question and hope to have more to say about it soon. I share @abo’s view that, a priori, the AnimalTaxonomy concept should not include identifications of individual animals. For one thing, the taxonomy is very static and the identification is very dynamic (not to mention, as I noted earlier, the fact that the taxonomy has many legitimate uses without having instances). That said, @fabian seems to be wanting to include the identification there perhaps because each individual animal has some properties (eg a wing span) which are dependent (schema-wise) on the class in the taxonomy that they belong to. In other words, the template problem again :slight_smile:

1 Like

Thank you very much for kindly sharing your very helpful thoughts, insights and guidance!

And thanks to everybody for this interesting discussion. I’m learning a lot here and am looking forward to how it might continue :slightly_smiling_face:

I’ve been thinking a bit about what seems to me the hardest question here, which is the role of the templating concept. In short, @fabian’s idea was to be able to define a template of properties for a group of animals which the zoo keeper is then prompted to give values for when tracking the animal’s condition. The challenge is to design this as a separate concept without dependences between concepts.

Here’s one way to do it. First we define a very basic templating concept, which allows you to create a template consisting of a set of property names. The type parameter (Item) will be bound to the items of whatever type that have templates associated with them.

concept Template [Item]
purpose simplify customization of items
  template: Item -> one Template
  properties: Template -> set String
  createTemplate (ps: set String, out t: Template)
  assignTemplate (i: Item, t: Template)

Now we define a concept for tracking the conditions of the animals. A priori, there’s no reason to make this animal-specific (although my guess is that you might well want to; I just don’t known enough about zoos). So I’m making it generic in the item type again.

concept PropertyTracking [Item]
purpose tracking over time of properties of items
  records: Item -> set Record
  propertyNames:  Item -> set String
  date: Record -> one Date
  properties: Record -> set Property
  name: Property -> one String
  value: Property -> one Univ
  setItemPropertyNames (i: Item, ps: set String)  
  addRecord (i: Item, d: Date, props: String -> Univ)
  // UI presents props as form using i.propertyNames

The interesting part here is that there is one action for setting the property names associated with an item (this will be an individual animal when we instantiate the concept in context), and another for setting the values of the properties. That second action takes a mapping from property names to values as an argument, but the property names will be provided by the UI.

Now we can instantiate our concepts. I’ll assume we have some AnimalTaxonomy concept that introduces a type AnimalTaxonomy.Class representing the particular category an animal falls in. Rather than an AnimalIdentity concept, I thought for now we might assume a standard Profile concept (as all web sites have), which also allows the subjects of the profiles to have categories assigned to them (in this forum, for example, there are 5 or so user categories); I’m assuming that’s a polymorphic reference, and I’m instantiating it with the taxonomy class. Then I instantiate the Template concept, with the items being the animal identifiers (the Id class exported by the Profile concept).

app Zoo
  Profile [AnimalTaxonomy.Class]
  Template [Profile.Id]
  PropertyTracking [Profile.Id]

Most of the actions of the app will be just the lifted actions of the concepts. The magic happens in the action that sets the property names of an individual animal. By using a sync, this is replaced by an action that lets the user select a template that has been previously created, and then uses that template to set the property names implicitly:

sync selectAnimalTemplate (i: Profile.Id, t: Template.Template)
  Template.assignTemplate (i, t)
  PropertyTracking.setItemPropertyNames (i,

This design could be elaborated in various ways:

  • Adding types to the properties (which would allow validation)
  • Allowing templates to be modified and propagating the changes to the tracking records
  • Associating templates with animal classes rather than (as here) letting them be independent.

A few notes on what’s involved in this kind of concept separation:

  • Try to make each concept a plausible unit of functionality in its own right
  • Avoid having any shared types across concepts, except for primitives like Date and String
  • No function calls between concepts, even by registering callbacks
  • Connect concepts using syncs, and try to avoid extending concepts with special actions needed only for syncs that aren’t plausible for the concept in other contexts.


1 Like

I am delighted to see your solution: clean, clear and concise and full of interesting and useful details. I sure learned a lot from this. Thank you very much!

I like the way, in which the two concepts are separated. It brings many advantages. To mention just a few:

  • It embodies a clear separation of concerns: the two concepts have different tempi and (in the case of the zoo) address different user groups.
  • It makes the PropertyTracking concept more reusable: it could be used in an app that doesn’t require templates.
  • Related to the first point, it greatly helps with understanding: if we would have just one concept, it would be harder to understand.

So you quickly convinced me that two concepts are much better than one to solve this problem.

But I still struggle a bit with the question: Is Template truly a concept in its own right?

When we look at the purpose of the Template concept and take a step back, the purpose seems to become “simplify another concept”. This manifests itself at the app level, in that the Template concept depends on the PropertyTracking concept (in the sense of EOS chapter 7). Moreover, I find it hard to imagine any app, where Template would not depend on some concept in this way.

Another way to ask the same question could be: Would we include the Template concept in a concept catalog on its own? I feel that an entry in the catalog would be more like the full answer you gave above: it would contain the Template concept, together with another concept that is extended by it, as well as the crucial sync to connect the two. So the entry in the catalog would seem to be a kind of pattern at the app level.

I would appreciate learning your thoughts about this.

Perhaps PropertyTracking would be better named History, e.g. a vet might say “What’s the history of this animal?” and so the name History would fit nicely with the vocabulary of the domain.

@dnj and everyone, I am curious to know whether you think it is important to choose a good name for concepts? Or if the name doesn’t really matter that much so long as you have the ideas straight?

Hi @winter! Names are incredibly important, but (a) you might not always be able to find one name that everyone likes; @pwilczynski handles this by allowing concept entries to have “alias” names; (b) finding a good name is really hard, and depends on understanding the concept deeply (and what related concepts there are, how people react to the name, etc).

Given all that, I agree that PropertyTracking might not be such a good name. I chose it to suggest that you have some objects with some properties that you are tracking over time. But now that I think about it more, it sounds like something to help you keep track of property that you own! OTOH, History seems too generic to me and could mean almost anything. Other suggestions?

1 Like

Sorry for the slow reply, @abo. Your question is really great. I think you’re absolutely right that Template is not useful by itself, but only makes sense in the context of another concept that provides the elements of the template. But I don’t think that disqualifies it as a concept; it just means that if you constructed a dependence graph (see chapter in EOS) it would never be one of the root concepts that have no dependence on others. Or to put it another way, it would never deliver the key functionality of an app but only play a supporting role.

There are other concepts like this: pretty much all access control and authentication concepts, for example, which likewise don’t provide value in and of themselves but help make other concepts useful.

1 Like