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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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


Subject: Re: [regrep] Users and Organizations


Nikola,

I think you're definitely onto something here.  To verify my
interpretation, I've expanded your thoughts below with bullet points and
rough diagrams, and placed recommendations at end:

MAIN CONCEPTS:
-------------
- Resource � has �owner� attribute

- It is the ID attribute of the User instance within the registry that
represents the owner of the resource

So we have:

      owns
User ------> Resource

- A user may have an Organization attribute that references the
Organization instance with which the user is affiliated

- So we have (using term �employs� very loosely, just for illustrative
purposes):

            employs        owns
Organization ------> User ------> Resource

There are also 2 pre-defined assocationTypes:

- SubmitterOf � defines that the source Organization is the submitter of
the target RegistryObject [Submitting Organization, or SO]

- ResponsibleFor � defines that the source Organization is responsible
for the ongoing maintenance of the target RegistryObject [Responsible
Organization, or RO]

QUESTIONS WERE:
--------------
Questions were (see "CRUX OF ISSUE" for bottom line):

- It is possible to submit a registry object that has an owner that is
affiliated with an organization that is different then the one(s) which
is (are) the source object in "SubmitterOf" association?

For example:

- User XYZ is employed by Organization 1 (SO)
- User XYZ submits a Registry Object ABC
- Along with the submit is included a �SubmitterOf� association that
defines that Organization 1 is the submitter of (SO) Registry Object ABC

- So we have relations:

              submits
Organization 1 ------> Registry Object ABC

AND
               employs          owns
Organization 1 ------> User XYZ------> Registry Object ABC

CRUX OF ISSUE:

At this point, should User XYZ �own� registry object ABC? 

My opinion: Perhaps not, because User XYZ is employed by the Submitting
Organization (SO), not the Responsible Organization (RO)

Suppose the above example were instead (note added �ResponsibleFor�
association in bullet 4):

- User XYZ is employed by Organization 1 (SO)
- User XYZ submits a Registry Object ABC
- Along with the submit is included a �SubmitterOf� association that
defines that Organization 1 is the submitter of Registry Object ABC
- Along with the submit is also included a �ResponsibleFor� association
that defines that Organization 1 is responsible for (RO) Registry Object
ABC

So we have relations:

              submits
Organization 1 ------> Registry Object ABC

AND
          responsible for
Organization 1 ------> Registry Object ABC

AND
              employs           owns
Organization 1 ------> User XYZ------> Registry Object ABC

At this point, User XYZ should (in my opinion) �own� registry object ABC
because User XYZ is employed by the Responsible Organization (RO) (and
additionally by the Submitting Organization (SO), as they are one and
the same)

RECOMMENDATIONS:
---------------
So to your question of �Do users need to be able to affiliate themselves
with more then 1 organization?� � I think the issue is perhaps not with
user/organization affiliation, but rather with what �type� of
organization is allowed to own a registry object, through a User
instance.  In other words, I believe we may want to consider
�tightening� this functionality to ensure that only a Responsible
Organization may own a registry object (through a user), not a
Submitting Organization. We could require that a registry object have a
Responsible Organization (i.e. ResponsibleFor association) when it is
submitted, ensuring that the registry object is not �Ownerless�.  

Or, we could leave this to a �registry policy� [plug for v4 feature]
that is configurable by registry administrators.  I think we should
consider introducing registry policies (i.e. additional to access
control policies) in V4.

I think we should allow users to be affiliated with more than one
organization.  Example is a user that works for a government contractor
(Organization A), and is submitting objects on behalf of a government
agency (Organization B) as part of a contract with that agency. 
Organization A would be the Submitting Organization, while Organization
B would be the Responsible Organization.  In this case, the user would
�own� the resource because they are �representing� the Responsible
Organization (Organization B).

That's all! Please let me know if I've misunderstood anything.

Joe

Nikola wrote:
> 
> Currently (ebRIM 2.34) "The owner attribute of a Resource carries the value
> of id attribute of the User instance within the registry that represents the
> owner of the resource". At the same time a user "may have an organization
> attribute that references the Organization instance with which the user is
> affiliated". There are also two pre-defined association types "SubmitterOf -
> Defines that the source Organization is the submitter of the target
> RegistryObject." and "ResponsibleFor - Defines that the source Organization
> is responsible for the ongoing maintainence of the target RegistryObject.".
> 
> It is possible to submit a registry object that has an owner that is
> affiliated with an organization that is different then the one(s) which is
> (are) the source object in "SubmitterOf" association. Same applies to
> "ResponsibleFor".
> 
> Do users need to be able to affiliate themselves with more then 1
> organization? Do we need to clarify semantics of affiliation, ownership,
> maintenance, ... of registry objects somewhere in the specs or what is in
> there now is enough? Are above aspects covered by "Access Control" mechanism
> and if yes do we need them as such.
> 
> Regards,
> Nikola
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

Attachment: Chiusano_Joseph.vcf
Description: Card for Joseph Chiusano



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