[Data-modeling] "Inheritance"

[Scott Meyer]

Michael,

You may not like this answer, but fundamentally there's no reason
to create an inheritance hierarchy (or hierarchies) in Freebase unless
the intermediate types in the hierarchy actually mean something.

>From your description, the situation looks like this:

/people/person
   SubA

SuperA (defines Prop1 and Prop2)
   SubA
   SubB

Where indentation means "inherits from."

If there's no situation in which you would type an instance of
person as SuperA but not as SubA (ie. SuperA is "abstract") then
there's no reason for SuperA to exist.  There's no code in Freebase,
so abstraction isn't really meaningful.  If you want all instances
having certain properties, just ask for them, if necessary, using
fully qualified property names.

So, concretely:

/people/person
   SubA (defines Prop1 and Prop2)

SubB (delegates Prop1 and Prop2 from SubA)

Could also do the delegation from SubB to SubA.  It really doesn't
matter.

Now, the UI issue:

Clearly, the UI is at least semi-broken wrt. delegated properties
and "inheritance."  Given that we haven't yet defined what "inheritance"
is, this somewhat excusable.  We'll fix it.  Both.

As a practical matter, you can create a table view with any set of
properties.  Here's a view that I created by starting with instances
of people and then adding /government/politician/offices held:

http://www.freebase.com/view/people/person?q=eNp1kE2OgzAMhe_iNYKuZsFVqirKgJlaDXGUmGpQxd0nCRQKna4c_7znzzk_oPrhO3rbo5XKsSGhhrR9qSrHIVbZBnVF00J9fgDFYAdjCiDb4u8zMdSTQP1VAHcdNbhKFXslJAahfhVb3ePzzS4NagO1-AGnY6GAwD56LwsLkNFF7Q7_H-YZeboU0GpBxZ36Ji_Xlb49op_2VFbPECTj4fDt1s9XbJSGm-xUNTxY8WNGCqd67i_GUDlkZzAGH9hCWmJvuS3UYxDdu5x92pJilQ5N41F-12ZY0NK-3Vi2fqvmJLPNv70glmm6XCHK2XjT7rmnyx8O1dPl&filter_view=table

You could add Prop1 or Prop2 this way.  Click on "more" at the bottom
of the add new column panel.  There should be no need to create types
just to drive the UI.

An even simpler data model that you might consider is just:

/people/person

SubB (defines Prop1 and Prop2)

You can then get the original SubA case by

   "p:type" : "/people/person",
   "a:type" : "/user/michael/subb"

If this abstract discussion didn't help, how about unmasking
Prop1 and Prop2 so that the wisdom of the data modeling list can
be brought to bear on the real problem.

-Scott

Michael Callaghan wrote:
> 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.
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling