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 Ram,

This new model looks good.  I still may have some questions related to how
you're using Relationship Type and Primary and Secondary Party Relationship
Roles, but I'd like to think about it first.

Also, thanks for the examples.  They help a great deal.

Regards,

John



                                                                           
             Ram Kumar                                                     
             <ram.kumar@oasis-                                             
             open.org>                                                  To 
                                       john.glaubitz@vertexinc.com         
             07/20/2007 07:35                                           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 agree with what you say. I re-worked on the model based on your
suggestion and please find enclosed the model. I have also enclosed
a zip file containing the schema (xPRL.xsd) and about 11 examples.

Let me know what you think. I have tried to cover different types of
examples including mapping an organisation structure.

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"

[attachment "schema1.zip" deleted by John Glaubitz/Construction/Vertexinc]
(Embedded image moved to file: pic07376.jpg)

pic07376.jpg



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