[PEAK] fact orientation

[Phillip J. Eby]

At 05:31 PM 10/15/2005 -0700, Jay Parlar wrote:
>Given what you've done there, is it possible for Mary to have
>multiple teachers? So when you do:
>
>    >>> list(Teacher(Mary).certifications)
>
>you would get a list of lists?

Nope.  schema.Annotation just creates an additional namespace for facts 
about a single object; it's not a substitute for creating explicit role 
objects if you want to model her being a teacher at different schools, or 
of different subjects, etc.  If the relationship itself has attributes, 
you'd just create ternary fact types like (teacher - X - subject), where X 
is the thing you're tracking, like "teacher A has X years of experience in 
subject B".  In PEAK's schema library, you'd be able to represent this as a 
mapping attribute on Teacher that maps from subject to other information.

If you prefer to nominalize the subject taught as an object instead, then 
you could create a SubjectTaught class with information that relates to one 
specific teacher's teaching of that subject, and make that a 'Many' 
attribute of 'Teacher'.

Anyway, there are lots of ways to model it relationally, and just as many 
ways to model it from an object perspective, and the plan is that 
peak.schema should let you choose whatever ways you want, and should also 
allow you to change your mind with relatively little impact, since you can 
always create a different interface and declare its mapping.  So, you could 
in principle define a different spelling of the 'Teacher()' data interface 
that accesses the same data in a different way.

Implementing this at the query level is going to be interesting, to say the 
least.  I've been thinking that I may actually need a deductive engine of 
some kind to properly handle unification and such.  I guess we'll just have 
to see.