OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ciq message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ciq] xPRL Draft Data Model


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"



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]