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

[Jeff Prucher]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/data-modeling/attachments/20080603/91e2af71/attachment-0001.htm