[PEAK] fact orientation
Phillip J. Eby
pje at telecommunity.com
Sat Oct 15 21:32:20 EDT 2005
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
More information about the PEAK