Possible use of supporting types
-
-
I expect that the following example would best be modeled as a supporting type and would like to get some feedback. I would like to use Freebase to summarize and store somewhat complex conditional values. For example, I would like to create a topic that holds the following information: In publication 1 there were 5 eggs of species 1 in habitat type 1 but in that same publication there were 4 eggs for species 2 in habitat type 2.
Currently I can model these 2 topics (i.e. pub 1, species 1, eggs 5, habtype 1 vs. pub 1, species 2, eggs 4, habtype 2) through a standard type with little problem. Data entry for relatively redundant topics will be relatively slow going until cloning is available but it is possible. It seems to me that a supporting type should probably be used to maintain these entries. Correct? I sure as heck don't want them coming up in the UI because they are too complex among other reasons.
This brings up the following question: Why should I give it these kinds of topics a name? If the names aren't used in the UI then it is just a system identifier. A time stamp would work just as well. Also, I probably won't know a good name for these topics until I enter their attributes. Maybe a name could automatically be created and then updated as a concatenation of topic properties? Either way, naming the topics for this kind of supporting type will often be pointless and a waste of time. Is it possible for a new feature to allow the checking of a box for automatic generation of names for a supporting type?
-
I don't think supporting types will help you out here, but I could be wrong. If I understand the problem (which I might not), I think it could be solved by using a CVT. I.e., you have a property ("egg information", say) with an expected type that is a CVT. The CVT would have properties for # of eggs, species, and habitat type (all of which should be marked as disambiguators). That way, you can enter both "species 1, eggs 5, habtype 1" and "species 2, eggs 4, habtype 2" as property values on the same topic. This also removes the problem of having to name the topics, since as you point out, there's no sensible name for ones like these.
-
Thanks Jeff. You're probably right about CVT as a more logical approach. I'll try it on and see if it fits.
-