[Data-modeling] "Inheritance"

[Michael Callaghan]

The answer to my question may be scattered among various posts but I
couldn't see it clearly. As a starter I'll say I'm quite aware that the
Freebase engine models types purely as collections of properties, and has no
concept of inheritance hierarchies in the mainstream OO sense.  This
question is about which combination of Freebase features (both at the
modelling level and the UI level) comes closest to enabling the modelling of
type inheritance.

I have two related types which, in an OO sense, seem good candidates for
subclassing from a common supertype.  Let's call them SubA and SubB, and the
proposed supertype SuperA.  SubA is a particular kind of person, with two
added props, so I'm planning to create "SubA topics" merely by adding SubA
as a type to certain existing /people/person topics.  SubB is just a
particular kind of Topic, with the same two props of its own, and again I
would create "SubB topics" by adding SubB as a type to certain existing
topics.  (Note, SubA and SubB may at some point need one or two extra props
of their own.)  To act as the supertype, SuperA will have these two common
properties Prop1 and Prop2, which I will make available in SubA and SubB
through delegation i.e. I will set up the same two delegated properties in
both SubA and SubB, which really link back to the actual definitions in
SuperA.

Using the basic default Freebase UI views, I'd like to be able to list all
SuperA topics, or just all SubA or SubB topics, and in all cases display the
Prop1 and Prop2 values.  To do this, I believe I have to add SuperA to all
of the existing, matching Topics, as well as adding SubA to some of those
and SubB to the others.  Alternatively,  I can add SuperA as an "included
type" to SubA and SubB; then by adding e.g. SubA as a type to an existing
Topic I am effectively also adding SuperA (at least when done through the
UI).  If I take either of these approaches, then when I view a Topic that's
been tagged as SubA (and SuperA) I get duplicate copies of the values of
Prop1 and Prop2 showing up (not surprisingly).  I can get round this by
"hiding" the Props1 and Props2 properties in the SuperA schema but leaving
the delegated versions of them exposed in SubA and SubB.  Individual
matching Topic pages then display perfectly, showing the Props1 and Props2
values, whether the Topic is a SubA or a SubB, as do lists of SubA or SubB
topics.  However, if I now try to list all "SuperA topics", then the Props1
and Props2 values don't show - because I hid them!

Am I right in thinking that the above covers all accepted patterns for
attempting to emulate inheritance hierarchies in Freebase, and that the
"problem" described in the previous paragraph is just unavoidable.  Or am I
missing something?

Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/data-modeling/attachments/20090519/6592c2ac/attachment.htm