[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ciq] xPRL Draft Data Model
Hi John, Thanks. I will look into it and get back to you. Yes, a group could be a label (non legal entity) which groups many parties together. For example a group consisting of many parties (person or organisation) has a relationship with another group of many parties. Each party in the group and its relevance/relationship to the group should be listed also. These sorts of groups are very common in many countries and in particular, asian regions. Regards, Ram john.glaubitz@vertexinc.com wrote: > Hi Ram, > > Thanks for the feedback on my alternate approach to the Relationship model. > > If you'll bear with me, I'd like to try this one more time. I'm afraid I > still don't see why a Group can not be a Party. If an example of a group > is a family, then I would consider the Glaubitz Family as unique an entity > as the individual person; John Glaubitz. If the reason you're contending > that a Group is not a Party is that it's not a named thing but simply a > label under which to identify a type of collection of Parties, then I'm not > sure I see how this would be used in any kind of schema instance. It would > help me to see your model used in an example. I've tried to do this with > my model using the Golf Club example you provided (see attached). I've > given the "locality Golf Club" an identity as a Party even though I expect > you intended this to be simply a grouping. > > Thanks again for your indulgence. > > Regards, > John > > (See attached file: RelationshipExample.pdf) > > > > > > Ram Kumar > <ram.kumar@oasis- > open.org> To > john.glaubitz@vertexinc.com > 07/19/2007 04:23 cc > AM ciq@lists.oasis-open.org, > "liz.kolster@ssc.govt.nz" > <liz.kolster@ssc.govt.nz> > Please respond to Subject > ram.kumar@oasis-o Re: [ciq] xPRL Draft Data Model > pen.org > > > > > > > > > > Hi John, > > I investigated closely your suggested draft data model. It is unable to > support different types > of relationships. In CIQ, a party is a unique person or a unique > organisation and not > a group of persons or a group of organisations. Following are the > different relationship > scenarios: > - A person is in relationship with another person > - A group of people (e.g. family, and their relationship with each > other) are related to another group of people > - A group of people are related to a person or more than one person, > - A person is in relationship with an organisation > - A person is in relationship with a group of organisations (not > necessarily legal entity, and this is common in many countries) > - An organisation is in relationship with another organisation > - An organisation is in relationship with amny organisations > - An organisation is in relationship with a group of organisations (not > necessarily legal entity) > - Group of organisations (not necessarily legal entity) is in > relationship with another group of organisations (not necessarily legal > entities) > > If you use the above use cases, and try to map to your draft structure, > you will find gaps because your model tends to treat a > party as either a group or individual. But note that a group by itself > comprises of many parties and these parties might have relationship > between each other, and a common relationship with another group of > parties or individual party. An example is: > A locality golf club has a set of members who have some sort of > relationship with the golf club as seniors, associates, veterans, etc,and > some sort of relationship between members. This gold club as a whole > entity is in relationship with a parent club, e.g. state golf association. > > The model I came up with, covers all the above requirements. I agree > that the audit information should be removed as it could open up > requirements for other data items also. > > Regards, > > Ram > > john.glaubitz@vertexinc.com wrote: > >> Hi Ram, >> >> At least for conversation sake, I have a different model to suggest and a >> few questions to go along with it. >> >> - In the examples you provided for a PartyGroup, it seems to me that the >> Group has it's own identity and therefore could be simply another type of >> party. This party could have PartyRelationships with the other Parties >> that are it's members thereby taking advantage of what we are trying to >> model here (including roles, start and end dates, etc.). >> >> - I'm not sure I see how you're using Audit information here. If we want >> to go down the road of including this level of metadata around data >> changes, why would we limit it to a Relationship? Wouldn't this be just >> > as > >> important to the business as a Party Name change or Address change? Not >> that I'm suggesting adding a similar class to all these areas. >> >> - For the complex structure you suggest below such as an org chart, I >> believe a very deep hierarchy can be built rather simply. If I were to >> create a data model for this, I may have done it as a classic Bill of >> Materials structure which would have multiple associations from Party to >> Relationship rather than having a self-referencing composition >> > association > >> on the Relationship. For an XML model, I would see this as an extension >> > of > >> a Party such that for a given Party, all the Relationships needed for >> > that > >> Party could be associated. Each Relationship is associated to the >> corresponding Party in the Relationship. The Related Party, being just >> another Party type, would have it's associated relationships etc., etc. >> >> Thanks, >> >> John >> >> >> (See attached file: xPRL v3.0 Alternate.JPG) >> >> >> >> > > >> Ram Kumar >> > > >> <ram.kumar@oasis- >> > > >> open.org> >> > To > >> "David RR Webber (XML)" >> > > >> 07/16/2007 04:58 <david@drrw.info> >> > > >> AM >> > cc > >> "liz.kolster@ssc.govt.nz" >> > > >> <liz.kolster@ssc.govt.nz>, >> > > >> Please respond to ciq@lists.oasis-open.org >> > > >> ram.kumar@oasis-o >> > Subject > >> pen.org Re: [ciq] xPRL Draft Data Model >> > > > > > > > > > > > > > > >> >> >> David, >> >> Thanks for your comments. >> The whole purpose of xPRL is to define the relationships between parties. >> It does not go to define the policies, access credentials, or privacy as >> we have clearly stated that this is outside the goal of CIQ. >> If we try to get into this area, we are opening all sorts of issues. >> The purpose of "audit" is to track the relationship status (e.g. when >> was the contact established last - this is >> very important for business purpose). The repetition has to occur >> particularly, if you want to define complex >> relationships such as representing an entire organisation structure. >> e.g. A had a relationship with B, B has a relationship >> with C, C has a relationship with D and E, etc. >> >> All the diagram says is that a party or a group of parties (Primary >> Party/Party Group)and their relationships >> with party(ies) or group of party(ies) (Secondary Party/Party Group). >> >> Regards, >> >> Ram >> >> David RR Webber (XML) wrote: >> >> >>> Ram, >>> >>> This seems oddly repetitive. Also not sure what the purpose of >>> "audit" part is? >>> >>> Just seems the diagram is telling you nothing like what your text is >>> hinting at!?! >>> >>> Also - surely the notion of circles and groups comes in hugely here. >>> Therefore there is really TWO models - one for the circle/group notion >>> including privacy and access policies, and access logging - and then >>> person / participant. >>> >>> Then a third diagram that shows how the two parts interact - and how >>> the participants can manage and control access themselves - inspect >>> access tracking - restrict and invite as needed. >>> >>> I'm not getting any of this from the one diagram you have here! >>> >>> Thanks, DW >>> >>> "The way to be is to do" - Confucius (551-472 B.C.) >>> >>> >>> -------- Original Message -------- >>> Subject: [ciq] xPRL Draft Data Model >>> From: "Ram Kumar" <kumar.sydney@gmail.com> >>> Date: Sat, July 14, 2007 3:17 am >>> To: ciq@lists.oasis-open.org >>> Cc: "liz.kolster@ssc.govt.nz" <liz.kolster@ssc.govt.nz> >>> >>> TC Members, >>> >>> Please find enclosed a draft data model of extensible Party >>> Relationships Language (xPRL) v3.0. >>> PartyGroup refers to more than one party or organisation as a >>> group (e.g. football team, a group >>> of organisations together bidding for a project, family) and the >>> party group could be a legal or a >>> non legal entity for organisation group. >>> >>> xPRL covers only the following types of relationships: >>> >>> - Person(s) to Person(s) relationship(s) >>> - Organisation(s) to Organisation(s) relationship(s), and >>> - Person(s) to Organisation(s) relationships and vice versa, >>> >>> Let me know your views. >>> >>> Regards, >>> >>> Ram >>> >>> >>> >> -- >> Ram Kumar >> Manager - Technical Committee Development >> OASIS >> Post Office Box 455 >> Billerica,MA 0821 >> USA >> +61 412 758 025 (Direct) >> + 1 978 667 5115 (OASIS HQ) >> + 1 978 667 5114 (Fax) >> ram.kumar@oasis-open.org >> http://www.oasis-open.org >> "Advancing e-Business Standards Since 1993" >> >> >> >> ------------------------------------------------------------------------ >> >> > > -- > Ram Kumar > Manager - Technical Committee Development > OASIS > Post Office Box 455 > Billerica,MA 0821 > USA > +61 412 758 025 (Direct) > + 1 978 667 5115 (OASIS HQ) > + 1 978 667 5114 (Fax) > ram.kumar@oasis-open.org > http://www.oasis-open.org > "Advancing e-Business Standards Since 1993" > > -- Ram Kumar Manager - Technical Committee Development OASIS Post Office Box 455 Billerica,MA 0821 USA +61 412 758 025 (Direct) + 1 978 667 5115 (OASIS HQ) + 1 978 667 5114 (Fax) ram.kumar@oasis-open.org http://www.oasis-open.org "Advancing e-Business Standards Since 1993"
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]