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]