[Data-modeling] deceased organism cause of death

Warren Harris warren at metaweb.com
Wed Jul 23 02:03:20 UTC 2008


Would this be a case for delegated properties? We could have a  
general /biology/deceased_organism/cause_of_death, and a delegated / 
people/cause_of_death. Overkill -- probably, and would allow lumping  
and splitting. (Plus throw in a deceased_person with included type  
deceased_organism for good measure.)

Warren


On Jul 22, 2008, at 6:37 PM, John Giannandrea wrote:

>
> The cause_of_death could be moved to /biology if we wanted to conflate
> them.
>
> But then you would be saying that the  reciprocal property 'People Who
> Died This Way' should be generalized to 'organisms who died this way'
> and that seems too general to be as useful.
>
> The question boils down to whether its more valuable to know in
> general that some people and some horses died of a heart attack, or
> keep these in two separate semantic buckets and if you want to know
> that you have to look in two places.    Lumping vs. splitting.
>
> In this case Id propose splitting, keeping the distinction between
> deceased_organism and deceased_person.   This will also have the nice
> property that when looking at a cause of death you will see two
> classes of the afflicted.
>
> -jg
>
> Alexander Marks wrote:
>> Apart from it being strange to expect something in the /person
>> domain, is there a good reason why /biology/deceased_organism/
>> cause_of_death shouldn't expect /people/cause_of_death? In other
>> words, is it important to distinguish between human and non-human
>> causes of death?
>
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3739 bytes
Desc: not available
Url : http://lists.freebase.com/pipermail/data-modeling/attachments/20080722/84bc428e/attachment-0001.bin 


More information about the Data-modeling mailing list