Good suggestions.

As a start, here are some issues inspired by William Kent's 1979 book "Data & Reality"'s index and examples of when they come up.

• Entities (quantity, change, categories, existence)

  Ex. You're reading a mystery novel (building up knowledge structures in a DKR as you go along) and as the end it says "The butler did it". What happens to those structures? (Kent's example).

• Separating symbols and things

  Ex. When I say "tomato" that isn't everything I know about Tomatoes or everything the DKR knows about them.... Somehow that symbol can access additional information. How is this relationship between symbol and related data maintained? (And of course, we have to acknowledge, you can't eat the symbol "tomato".)

• Naming (uniqueness, scope, qualifiers)

  Ex. You say "tomato" and refer to a vegetable, and enter a reference into the DKR, I say "tomato" and refer to a set of nutrition information and try to enter that refernece in the same DKR. How do we keep these same named references referring to different things? And likewise, if I use the scientific name for Tomato (?) how do we have it point to the same thing as some other reference to "tomato".

• Representing relationships (items, domain, role, issues if computed)

  Ex. You make a link to the Tomato nutritional information from a report in the DKR. How is this relationship maintained? Some of the vegetables you reference have pictures, how do you build this link (relationship) when you didn't plan for it? Some of the nutritional information about a tomato is calculated -- how do you distinguish this from other non-computed information?

• Attributes to objects vs. relationships

  Ex. Tomato's have weight. If you are inventorying your tomato harvest in a DKR, should you have a tomato class which has a weight attribute, or should you model this had a tomato being in a relationship with a weight?

• Why data and its description can't really be separated

  Ex. You want to send someone your tomato nutritional information so they can store it in another DKR. But in order to use it, they need to know about what format you stored it in.

• Handling types and categories and sets

  Ex. (Weak!) What does it mean that nutritional information is about a type of Tomato? Does that then mean nutritional information can't be a type of empirical observation? Can it belong to the set of things your friend Fred entered for you, while ate the same time being in the category of things Jim fact checked? How is all this represented?

  Are categories just relationships in disquise?

• Modeling -- both modeling reality and modeling data

  Ex. Simulating the movement of air over a wing vs. discussing the way you implemented this, and also realizing your simulation is not reality (the map is not the territory -- but it is its own territory).

• Handling elementary data (example: images or integers)

  Ex. Should an image stored in the DKR be made of relationships of bytes (and those relationships of bits?) or should it just be an array of bytes on a hard disk. In either case, how do you know how to interpret those bytes back into an image?

• Data integrity

  Ex. For a DKR on tropical medicine, how do you make sure the weights of tomato plant parts entered do not add up to more than the weight of the entire tomato plant?

• Data processes (triggers, integrity constrains, search)

  Ex. When you enter a record for tomato RDA by weight into your DKR, how can the DKR be set up to automatically send email to Eric to let him know to look it over?

• Handling multiple versions of things or patterns

  Over time, we are going to get better information about tomato nutritional values. How do we keep all these versions of information? Which one do I give you when you ask for nutritional information on the tomato?

• Testing for sameness (equality)

  How do I know that this reference to tomato nutritional information points to the same "thing" that this reference to "red fruit" nutritional information points to?

• Efficiency

  Ex. Same as handling elementary data, also how does how the system looks to a user differ from how it is implemented.

Sincerely,

Paul Fernhout
Kurtz-Fernhout Software