Part A

1)  We want to concentrate on the uses of data / information / knowledge in this situation, but first some examples of each.  Recall we're considering a hospital computer network with such things as patient montioring devices, medical records, and physicians' workstations.  That is, we're concentrating on the medical work of the hospital (rather than, say, financial activites, or supply chain, or publicity).  Recall also that there aren't sharp boundaries between data, information, and knowledge, so don't obsess over pigeonholing into these categories.

Raw data would include the streams of measurements being collected by automated patient monitoring equipment, measurements and observations made by nurses,  test results, etc.  There would be personnel records for physicians, nurses, aides, including their work schedules and on-call schedules.  If the hospital is so equipped, there might be location data for medical personnel when they're on the premises.

Under the heading of information one might include specific inferences from data, e.g. diagnoses or conclusions drawn from the raw medical data, warnings that a patient's vital signs were not normal, awareness that some times and locations were under-staffed.

A bit higher up the information hierarchy, we might find such things as case notes, instructions and training for new personnel.

Knowledge tends to include the sorts of things formerly trapped inside people's heads, textbooks, and medical journal review articles, but now externalized and organized so it's useful to others and useful to automated systems.  We can potentially include, here, the entire body of medical knowledge, recorded in textbooks and journals, especially as many are available online.  Experienced specialists might have helped construct expert systems for assisting with diagnosis and selecting treatment.

• Moving up the information hierarchy -- generating more information out of data, and more knowledge out of information.  But merely with this, we haven't gotten any use out of what we "know".
• Drawing conclusions that lead to the need for action, and then constructing plans of action to meet the goals that were identified.

• From general medical knowledge and specific information on each patient, we could derive the limits of what should be considered normal for the data coming in from monitoring equipment.  The software processing the monitoring data could send alerts to the nearest nurses' station, or page the patient's physician, or call for emergency help.
• Image data collected before surgical procedures could be analyzed to produce 3D visualizations, so the surgical staff would know what they were (ahem) getting into.
• During diagnosis, an expert system could be given any currently available patient data, including test results and observations, and could suggest which further tests would be most useful to help decide between possible diagnoses.
• From knowledge of what information is most immediately useful to physicians and nurses for each sort of patient condition and diagnosis, a system for displaying patient data could adjust its display to put the most important information where it would be most accessible.
• Tracking the movement of personnel could help get information to them with less delay.  For instance, when a patient's physician walks in a room, a bedside display might bring up the patient's online chart, without requiring the physician to waste time logging in.  When the physician left, the chart would be hidden, for confidentiality.  Alternatively, physicians could carry handheld or tablet computers, and the appropriate chart could be brought up depending on what patient room they were in.
• Information about patient meal, medication, test, appointment, procedure schedules could be automatically organized into "day-planner" displays for the nurses' stations, bedside displays, and handhelds.
• Physician orders (e.g. for medication or tests) could be dispatched automatically.
• And many more...

2)  A production system has three parts:  a driver or interpreter, a collection of production rules, and state information.  How could we represent the content of each of these parts?  Let's work backwards from state to rules to interpreter -- that's also from easier to harder:

 

State information	The state of the system will consist mainly of values of parameters, so we could say that our state is represented by a collection of pairs:  parameter name and its value.  (In a program, we might represent these as variables, or key / value pairs, or records in a database.)
Production rules	An individual rule has the form of a condition to test and something that should be done if that condition is true.  So we could represent our rules as a collection of pairs:  predicate and action.  The action could, itself be compound -- it could be a collection of actions or a sequence (and ordered collection) of actions, if some actions had to be performed before others.  For efficiency, we might want to have a hierarchy -- a tree -- of predicates, so we don't have to repeat some test over and over in lots of pairs.  In this case, our actions could be attached to any node of the tree, or they might all be at the leaves.  Note that the predicates might include tests not only on information that the system gets from the outside world, but also from the state.  And the actions might not just produce results -- they might update the state information.
Interpreter	The interpreter has to collect information from the world, examine the production rules for true predicates, execute the actions, and return results.  The main point at which its overall behavior might differ from one system to the next is in how the rules are structured (sequence, tree,...).  To describe the operation of the interpreter, we could use the same sort of description as we'd use for a formal machine (e.g. state machine, finite automaton, Turing machine).  This machine would be very simple, because it would store its state in its collection of state information, not in named states of the system.  (Of the three machines mentioned, the Turing machine is closest, as it, too, has its "program" and "state" stored apart from the machine driver.)

 

(a)	Fido is a dog.	Fido is an element of the set of all dogs.  (Note we're assuming that "Fido" is the name of one particular dog.  Had we meant the set of all dogs named Fido, we probably would have said something a bit different.)
(b)	A parrot is a bird.	The category parrot is an element of the set of bird categories.  That is, a parrot is a type of bird.
		The set of all (individual) parrots is a subset of the set of all (individual) birds.
(c)	Polly is a parrot.	Polly is an element of the set of all parrots.  (As for Fido, if we'd meant all Pollies, we would have phrased the sentence differently.
(d)	David Jones is a Jones.	David Jones (the individual person) is an element of (the family of) Joneses or all people named Jones.
(e)	"George Washington" is a great name.	We are heading away from containment here, and toward features or qualities.  We could say we're talking about a category of "great names", but we probably couldn't get any two people to agree on the elements!  I we did have a collection of "great names", "George Washington" would be an element not a subset.  This seems a bit awkward, though -- it would be simpler to say that the name "George Washington" had "great" as a quality.  Regarding "great" (or other modifiers) as qualities has another advantage:  We can apply them to anything without having to insert some artificial intermediate class of things with that quality between a more naturally associated parent and child class.
(f)	Artificial intelligence is a state of mind.	This isn't containment, although perhaps it should be contained, lest it spread.  The whole statement falls into the category of "jokes that deserve groans rather than laughs".

 

Reflexive	For all x in S:  x R x.  That is, (x,x) is in R for every x in S.
Symmetric	For all x, y in S:  x R y  ->  y R x.  That is, whenever (x,y) is in R, so is (y,x).
Transitive	For all x, y, z in S:  x R y  and  y R z  ->  x R z.  If (x,y) and (y,z) are in R, so is (x,z).
Antisymmetric	For all x, y in S:  x R y  and  y R x  ->  x = y.  If (x,y) is in R, where x != y, then (y,x) won't be.
Partial order	R is a partial order if it is reflexive, transitive, and antisymmetric.  (Think of <= as a model.)

Note the problem says that, for each example, S is the set of all elements mentioned in that example.  So S isn't the same for all.

There's no trick to doing these -- just step through all the "for all" elements and see if the statement that defines the property holds.  If it's ever violated, R doesn't have that property.  Most of the statements have a precondition that asks about some elements of R.  That is, they say "if <something> is in R, then...".  ("Symmetric" is the only one that doesn't.)  If there are no elements of R that satisfy the precondition, then there are no cases where the statement is violated.  (This is the same as the definition of "implies", where "false" implies anything because it gives us no information that we could use to decide if the thing on the other side of the implication is true or not.)
 

	S	R	Reflexive	Symmetric	Transitive	Antisymmetric	Partial order
(a)	{a}	{(a,a)}	yes	yes	yes	yes	yes
(b)	{a,b,c}	{(a,b),(a,c),(b,c)}			yes	yes
(c)	{a,b,c}	{(a,a),(a,b),(b,b),(b,c),(a,c),(c,c)}	yes		yes	yes	yes
(d)	{a,b,c}	{(a,b),(b,c)}				yes
(e)	{}	{}	yes	yes	yes	yes	yes

14)  Let:

H = "The home team wins."
V = "The picnic will be in Victory Gardens."
C = "The picnic will be at Consolation Springs."
R = "There is rain."
B = "The sheltered barbeque will be used.
J = "The Joneses stay home."
S = "The Smiths attend."

 

H -> V	If the home team wins then the picnic will be in Victory Gardens...
(~H) -> C	...otherwise (i.e. if the home team does not win) it (the picnic) wil be at Consolation Springs.
R -> B	If it rains (if there is rain), the sheltered barbeque will be used.
R -> J	Whenever (i.e. if) it rains the Joneses stay home.
(~R) -> (~S)	The Smiths only attend if it rains (i.e. if it isn't raining, the Smiths won't attend).  Caution!  This does not mean that the Smiths will always attend if it rains -- it just means that if it's not raining, the Smiths won't show up...

a)  The rules for Has, and their predicate calculus form, are the following.  The last was given in the problem.  (Caution:  The letters used to represent the parts of this statement were not the same on p.152 as in the problem.)  Recall we're saying Has(S,T) means S has a T and Isa(S,T) means S is a T.  I'm writing these in a way that will be helpful in part b.

 

Has is transitive:  If X has Z and Z has Y then X has Y.	Has(X,Z) ^ Has(Z,Y) -> Has(X,Y)
Generalizing  the thing that's "had":  If Z is a Y and X has a Z, then X has a Y.	Has(X,Z) ^ Isa(Z,Y) -> Has(X,Y)
Inheriting a "had" thing from a parent class:  If X is a Z and Z has a Y, then X has a Y.	Isa(X,Z) ^ Has(Z,Y) -> Has(X,Y)

Drawing these can be a bit confusing because we've put the more general item in the second argument to Isa, and we put that higher in the path diagram, but we'd more naturally want to put the first argument of Has above the second.  So forget about drawing a chart -- let's instead write a rule for a path that yields Has(X,Y).

We can chain together path fragments like Has(z1,z2) ^ Has(z2,z3) then Has(z2,z3) ^ Isa(z3,z4) then Isa(z3,z4) ^ Has(z4,z5) and more of any like those.  We don't need to repeat any term -- if it's true once, it's true again...  That sequence becomes Has(z1,z2) ^ Has(z2,z3) ^ Isa(z3,z4) ^ Has(z4,z5).  If we apply the above rules, this collapses to Has(z1,z5).

What about the Isa transitive rule?  Could we include that by collapsing two Isa terms into one?  Try it:  Say we have Isa(z1,z2) and Isa(z2,z3).  We conclude Isa(z1,z3).  Then if we also had Has(z3,z4) we could use the third rule above to conclude Has(z1,z4).  Similarly, if we had Has(z0,z1), we could use the second rule to conclude Has(z0,z3).  We should do a sanity check -- do these make sense?  We just said z1 is a z2 and z2 is a z3 and z3s have z4s, so z2s and z1s also have z4s -- sounds good.  Then we said a z0 has a z1, and a z1 is a z2 and a z2 is a z3, so a z0 has a z3 -- also ok.

So we can have any sequence of Has and Isa, where the second argument of one is the same as the first argument of the next...except that we need to have at least one Has.  We could write the rule as:

{ R_i ( z_i, z_i+1 ) }_{i = 1..n}  and there exists j in 1..n such that Rj = Has    ->    Has(z₁, z_n+1)

c)  Modifications to LINNEUS:

• Add a new hashtable for the "has" relationship and accessor functions to service it, similar to those for "is a".
• Add a function handle-has-assertion to test for and process sentences of the form:

( <article> <thing> has <article> <thing> )
This is similar to the function for "is a".
• Add a function handle-has-question, and its helper hastest, to test for and process sentences of the form:

( has <article> <thing> <article> <thing> )
Hastest is significantly different from the corresponding isa-test.  Justification for its design is in parts a and b.  Details are in comments included with the function in the code.

10)  Here, you will need to:

• Remove facts from the "is a" and "includes" tables if the user gives you a new statement that lets you infer the old facts using the new statement and other facts.
• Refuse to add statements that are facts in your tables already, or that you can infer from your current facts.
• Make snooty remarks if the user tries to do these things.

11)  Changes to LINNEUS are:

• Sentences to LINNEUS that express the "element of" relationship don't have an article in front of the element.
• A hash table and accessor functions are needed for the "element of" relationship -- like the "is a" table and functions except in input sentences and what you print out, leave out the article in front of whichever item is the element.  The "element of" table will have the name of an element as a key, and a list of the classes it belongs to as the value.
• A hash table and accessor functions are needed for the "owns" relationship.
• You'll need functions that look for input sentences like those shown in 11a.  Be sure to look up the thing without the article in the "element of" table, e.g. (what is <thing>) should report
• The problem implies that only an "element" can "own" something, i.e. a class can't.  So you'd need a function to answer ( owns <thing1> <article> <thing2> ).  (It's ok if you allowed classes to own things, too, but this is harder.  You could also have ( owns <thing1> <thing2> ) which asks if one specific thing owns another specific thing -- not a problem if you don't.)
• You'll need an OWNSTEST function.  First you'll need to clarify how "owns" works.  In ( owns <thing1> <article> <thing2> ):
• <thing1>, the owner, must be an element.  <thing2> should (probably) not be an element (but you can allow this if you want).
• The owned thing can chain through "is a" relationships:  If Z is a Y and X owns a Z, then X owns a Y.  You can use ISA-TEST to check for this:  Get all the things that <thing1> owns, then see whether any owned thing "is a" <thing2>.