Fri, 18 Oct 2013 18:19:29 +0200
Cédric Krier <[email protected]>:
>On 18/10/13 17:08 +0200, Udo Spallek wrote:
>> Fri, 18 Oct 2013 15:15:15 +0200
>> Cédric Krier <[email protected]>:
>> >On 18/10/13 14:01 +0200, Udo Spallek wrote:
>> >> Wed, 9 Oct 2013 19:15:29 +0200
>> >> Albert Cervera i Areny <[email protected]>:
>[...]
>> >> Len's model is able to handle the traditional
>> >> customer relationships like (see table 1 for the data):
>> >> "In a Customer-Relationship, Party ACME Company takes the
>> >> role as a Customer of DEF firm an Internal Organization"
>> >Yes.
>> >> but also to collect information about a competitor:
>> >> "In a Customer-Relationship, Party Eric is a Customer
>> >> of Party UVW an (external) Competitor"
>> >And why can't we store it with current design?
>> >The relation type will be "is customer of".
>> >The fact that UVW is a competitor is outside the relation because
>> >it is the relation the current company has with UVW.
>> no, that's unfortunately too simple. A 'relation' or 'relationship'
>> is a _relational_ link or connection, not a functional. E.g. in
>> another relationships UVW can be also play the role as a 'partner'
>> of the enterprise, when they sponsoring a convention.
>I don't agree with you. The proof is that the word "Customer" is in
>your example in the name of the relation and also in the role.
>There are here a duplication of information.
Yes, you are right, duplication of information is bad. And I think
we can store the same information with the proposed model:
1. Party ACME Company 'is customer of' DEF firm (internal company)
2. Party Eric 'is customer of' Party UVW
3. Party UVW 'is competitor' of DEF firm (internal company)
I begin to like the proposed model, because it is simple and beautiful:
Parties are nodes and relationships are edges between nodes.
>> >> It can be used to describe hierarchical relationships like company
>> >> roll-ups your blueprint also provides,
>> >> "In a Organization-Rollup-Relationship, Party XYZ is a
>> >> Subsidiary of Party ABC the Parent Organization"
>> >> "In a Organization-Rollup-Relationship, Party DEF is a
>> >> Subsidiary of Party ABC the Parent Organization"
>> >Same here.
>> >> or handle information with different opinions
>> >> "In Sales-Lead-Relationship, Party Thomas is a Hot-Lead
>> >> of Party Victor an internal employee"
>> >> "In Sales-Lead-Relationship, Party Thomas is a Cold-Lead
>> >> of Party Jack an internal employee"
>> >> "In a Sale-Chance-Relationship, Party Thomas is a 90%-Chance
>> >> of Party Victor an internal employee"
>> >> "In a Sale-Chance-Relationship, Party Thomas is a 10%-Chance
>> >> of Party Jack an internal employee"
>> >I would prefer to have a percentage field on the relation for such
>> >case instead of predefined value in the relation/role.
>> Here my point is: ability to collect different opinions about one and
>> the same thing. Here are two employees having different opinions
>> about one and the same interest. Again, as the name 'Relationship'
>> suggests, it is about relational connections, not functional.
>I don't think such data design could be re-used/exploit in anywhere.
>I think also that it is not a relation because it is not a fact.
Beside my not-so-good-example, I think it is good to be able to handle
different relations and take them all as facts. And Alberts proposed
model seems not to restrict this.
Maybe think about a 'weight'-attribute of a relation, which is heavy
when many users reconfirm the relation, or which is light when only one
user allege the relation. In a painted picture of the graph, the heavy
relations are big lines and the light ones are thin. Evidently, such an
attribute should not be part of the base model.
>For your example, I will just store this information on the
>sale_opportunity not on the party.
Maybe my example fails, because we have already a sufficient model
with sale_opportunity.
>> >> The basic idea of Silverston's conception is to collect
>> >> semantic information the company is interested in separated by
>> >> relationship types. It is using the "roles" (and role types) the
>> >> parties *take* or *play* in the relationship as the "relators".
>> >I think the error is here. It is only about the point of view of the
>> >company.
>> Wrong. The collected data is about the point of view of everyone
>> (usually Tryton users) who fills the database with
>> opinions/meanings/facts. These facts can unfortunately change over
>> time.
>Not for me, relationship must be filled with fact and fact doesn't
>change over time.
In this point I am sure these facts will and should change.
We already put many things which not change over time into the party
model. But relationships are IMHO more relative.
One day ABC cooperation is a competitor of ACME, another day ABC
becomes its dependance. One day Peter works for department A, another
day he changes to B and some weeks later he quits, finally.
A coming joint venture will always start with a hearsay:
"Did you hear about A and B want to fusion?"
Depending on your business it can be nice to collect such vague
information and let it getting stronger when other people 'hear' the
same from different sources. The whole stock market is built on this
kind of information...
Anyway, the proposed model does not restrict this use cases.
>> >I think it is more powerful to remove this point of view and
>> >be generic. And later with customization adding the point of view if
>> >needed.
>> There is no 'point of view of the company', because the company is
>> not a person/user, which can encode the information/opinions. And be
>> sure facts can be 'wrong' or getting 'wrong' over time.
>Of course if you collect mood but not if you collect fact.
:-) I guess you meant 'mud'; and hopefully I was finally able to explain
that collecting different opinions about 'facts' _can_ be useful.
>> >> So for me, either the name 'Relationship' or 'Relation' is much
>> >> too general for the structure-only approach of the blueprint, or
>> >> the functionality misses all the needed parts to build real
>> >> *semantic* relationships.
>> >I think it is excatly the power of this design.
>> Why?
>Because it constraints to collect fact on which you can build stuffs.
>Also it is completly free about which facts you collect.
You convinced me that the proposed model is sufficient enough to
achieve my expectations.
>> >I don't see any advantage about the role because the role is
>> >contained in the relation.
>> ... so in the end, someone who really needs a relationship management
>> will have a table with many many different relations. Without having
>> some *aspects* to look on the data like roles and relation_types, it
>> is nearly the same PITA as searching a bunch of free text fields
>> filled with data ...
>I don't get you because in your example you'll get the same amount of
>relation. So of course if you store a lot of relations, you will have
>a lot of relations.
>If later you want to filter them, as I said, a group of relation type
>could be added.
Yes, in this point I see no difference between Silverstons model and
Alberts.
>> Roles instead are declarative: The user 'defines' if a party is
>> a 'customer',
>I though we agree that such declarations were useless.
>Someone is a customer because he buys something, not because someone
>put a flag (idem for supplier).
When you are a wholesale in Germany, you must ensure a customer is a
valid business and it is good to be able to 'declare' someone is a
(valid) customer ... but declarative roles are off topic and I see
really no necessity to combine them with a relationship model, like
Silverston do.
>> 'employee'
>Already exist.
>> or 'doctor'.
>Could be added but it doesn't involve a relation.
>But of course to a doctor will create new relations like
>"doctor of"/"patient of"
Doctor and notary are just 'roles'.
>> You can say when someone started
>> to be a 'customer', 'employee' or 'doctor'. And you can say when
>> someone stops playing a role.
>Roles are managed by creating a Model for it like:
>
> - Employee
> - Company
> - Carrier
> - Bank
> etc.
Interesting idea! But are we really able to link relationships between
Employees and the Companies with Alberts provides model?
>[...]
>> And parties with roles take part in a relationship.
>Here is our divergence. The definition of the relation contains the
>roles.
>Example:
> "Employee of" -> there is a employee and a company
> "Customer of" -> there is a customer and a supplier
> "Subsidiary of" -> there are two companies
> "Salemen of" -> there is a party and a company
Yes, but AFAIS the relation is always between records of model
party.party. Maybe it is an idea to have relations between two
fields.Reference. So the employee-of-relation is a relation between
a record of model Employee and a record of model Company...
But we will have problems with the views, not?
>[...]
>> Or is the approach in the blueprint for rolling-up parties?
>I don't understand the question nor the "rolling-up parties".
Silverston uses the term 'roll-up' for building companies made of
departments, dependences, headquarters, employees...
And the question is already answered, as the proposed model is not
restricted to structural relationships like party 'roll-up'
Thanks for clarification.
Regards
Udo
--
_____________________________
virtual things
Preisler & Spallek GbR
München - Aachen
Windeckstr. 77
81375 München
Tel: +49 (89) 710 481 55
Fax: +49 (89) 710 481 56
[email protected]
http://www.virtual-things.biz
