[Data-modeling] Are Influence Nodes necessarily persons?

[Faye Harris]

Ah yes, "Peer" -- I'd second it as a type. I knew I was forgetting 
something.

And yes, breaking James's application on who influenced whom would be a 
concern. It's unfortunate. But I do feel that this would constitute a 
necessary move in the right direction. Data on influence between two 
persons would be an easily query-able subset of data on influence 
between any two topics of arbitrary type.

The resulting ability in the new schema to model influence between any 
two instances would be a clear gain.

-- Faye


Jeff Prucher wrote:
> I think the phylogeny pattern fits this type of data better than a two-type
> system. Because influence is a chain (X influence Y who influenced Z), a
> phylogeny is a lot cleaner; otherwise Y needs to be both an influencee and
> an influencer, which seems unnecessarily complicated.  Influence node also
> has the Peers property, which would presumably have to be handled by another
> type (Peer?), if we get rid of the Influence Node type.
>
> As regards person vs. other influencable thing, I don't have a strong
> opinion, but I do want to note that there are applications that use this
> model which may be affected by changing the usage.
>
> Jeff
>
>   
>> -----Original Message-----
>> From: data-modeling-bounces at freebase.com 
>> [mailto:data-modeling-bounces at freebase.com] On Behalf Of Faye Harris
>> Sent: Thursday, October 30, 2008 4:59 PM
>> To: Freebase data modeling mailing list
>> Subject: Re: [Data-modeling] Are Influence Nodes necessarily persons?
>>
>> I've actually given this some thought recently, hence the 
>> relatively quick response. :)
>>
>> As data models go, "Influence Node" is sort of an odd ball. 
>> It doesn't tell you immediately if an instance is an 
>> "influencer" or "influencee" 
>> (pardon the coinage), just that it has data related to influence. 
>> Normally, types in Freebase model an "Is-A" relationship. San 
>> Francisco "Is-A" location, and we apply the "Location" type 
>> to the topic for San Francisco to represent that relationship.
>>
>> So a comparable schema for influence would ideally have 
>> separate "Influencer" and "Influencee" (or "Influenced", or 
>> whatever name) types, applied to topics where... well, 
>> applicable. As a generalized concept the included type of 
>> "Person" is rather unnecessary. Influence may be between two 
>> things of the same type, or any type, or between things of 
>> different types. A film can influence an author, a philosophy 
>> can influence an art movement, etc.
>>
>> If asked between 1) remodeling the current "Influence Node" 
>> type to two separate types without "Person" as an included 
>> type, and 2) creating a new pair of types to duplicate the 
>> same influence relationship without "Person" as an included 
>> type, I'd choose the former. It'd take a little reshuffling, 
>> but I think it'd be a lot less confusing in the long run, 
>> than having two sets of similar types, one a subset of the other.
>>
>> -- Faye
>>
>>
>> Tadhg O'Higgins wrote:
>>     
>>> Would Influence Node be more useful/interesting if it didn't assume 
>>> personhood for its instances? Books, Films, Games, and 
>>>       
>> Musical Groups 
>>     
>>> are all examples of things that seem like Influence Nodes 
>>>       
>> but are not 
>>     
>>> persons.
>>>
>>> We should consider removing the /people/person included type from 
>>> Influence Node for that reason. The alternatives I can see 
>>>       
>> are to a) 
>>     
>>> create an "Influence <thing>" in each domain that might 
>>>       
>> support one, 
>>     
>>> or
>>> b) create an "Influence Thing" type that's just like Influence Node 
>>> but doesn't include personhood. Neither of those seem as good a 
>>> solution as widening the scope of Influence Node.
>>>
>>> Thoughts?
>>>
>>> Tadhg
>>> _______________________________________________
>>> Data-modeling mailing list
>>> Data-modeling at freebase.com
>>> http://lists.freebase.com/mailman/listinfo/data-modeling
>>>
>>>   
>>>       
>> _______________________________________________
>> Data-modeling mailing list
>> Data-modeling at freebase.com
>> http://lists.freebase.com/mailman/listinfo/data-modeling
>>
>>     
>
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling
>
>