[Data-modeling] relationship type explanations... diagrams?

[Tim Kientzle]

Yes, keep in mind that a non-existent property takes up no space, so  
there's no harm (in terms of our storage, at least) in having  
properties that only get used on some specific topics of that type.   
As Jeff indicated, a common pattern is to break up a complex type into  
a collection of simpler types that can be combined in different ways.

Also, keep in mind that among our key goals are to store data in a way  
that's useful to a variety of people, especially people that are  
building applications.  So having things that are straightforward to  
query is important.  Breaking things into collections of types helps  
here, too.  Rather than having 'conductance', for example, on  
"Material", having it as a property of a separate "Conductor" type  
allows people to query for "materials that are conductors."

Good luck,

Tim Kientzle



On Jun 3, 2008, at 4:19 PM, Jeff Prucher wrote:

> Sometimes, having a seemingly absurd number of properties might  
> really be the right answer. If all the properties are distinct and  
> of value to someone, I don't see a reason not to use them. The type  
> "chemical compound" has a lot of properties on it currently, and I  
> doubt it's anything like exhaustive. (There may be some crossover  
> with the types you're thinking about.) Another type that is going to  
> have a huge number of properties eventually is "statistical region",  
> which is essentially a place to stick various types of statistical  
> measures about places; I think there are less than a dozen now, but  
> it will keep going up as people add new kinds of data.
>
> It might also be possible (and I say this knowing nothing about  
> materials science) that you could create several types. For example,  
> if there are some properties that nearly all materials have in  
> common, you could put those on a "Material" type; and if there are  
> some properties that only a certain class of materials have, you  
> could put them on a type "Material Class 1", which could have  
> "Material" as an included type, and so get those properties as well.
>
> Jeff
>
> From: data-modeling-bounces at freebase.com [mailto:data-modeling-bounces at freebase.com 
> ] On Behalf Of jerritt collord
> Sent: Tuesday, June 03, 2008 3:57 PM
> To: data-modeling at freebase.com
> Subject: [Data-modeling] relationship type explanations... diagrams?
>
> I'm new here and not sure how normalized I need to think--or what  
> I'm missing--or if I'm just having a bad day and need to re-read.
>
> Quick explanation of problem: I'm not an engineer but an area I'm  
> interested in tangentially is materials science. There are tons and  
> tons of possible properties as one might imagine and I don't think  
> the right solution is to create a Material type with ~100 properties  
> slots. Or maybe it is?
>
> Obviously the physical properties have to integrate with the fairly  
> complete system of basic Units in freebase... but e.g. there will be  
> a lot of mechanical properties all with Units that now carry Units  
> of Pressure designation.
>
> I know this isn't fruitful, but this is what I tried to do:
> -------
> type: MaterialPropertyClass
> display is Enumeration
> example instances: Mechanical property, Magnetic property, Chemical  
> property, Health property
>
> type: MaterialProperty
> display is Standard
> properties:
> * base SI Unit (single value: reference to appropriate instances of  
> system Unit type)
> * alternative units (multiple values: reference appropriate  
> instances of system Unit types)
> * MaterialPropertyClass (single value: reference to instance of  
> MaterialPropertyClass, display as disambiguator)
> example instances: Density, Magnetic Susceptibility (many of these  
> topics already exist, unstructured, in freebase probably via  
> wikipedia)
>
> type: MaterialPropertyMeasure
> display is Compound (?)
> properties:
> * Material
> * MaterialProperty (single value: references MaterialProperty)
> * MaterialPropretyValue (single value: floating point number)
> * MaterialPropertyUnits (reference to sytem Unit type)
> * MaterialPropretyDesc (single value: text) -- used for non-numeric  
> Properties, or descriptions of measurements
> example instances: Density of Stainless Steel
>
> type: Material
> properties:
> * etc.
> * MaterialsPropertyMeasure (multiple values) ? Here's where I fail  
> to understand... it seems that what I'd want to do is have all the  
> instances of MaterialPropertyMeasure that reference this material  
> show up.
> ----------
> Probably too complicated and all but encourages users to stray from  
> standard units--and unqueryable to boot.
>
> Any guidance for examples of domains/problems that resolve  
> relationships like these? Basic reading I need to do more of?
>
> Thanks,
>
> Jerritt
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling