Owner

[LukasKalbertodt]

This idea has been floating around for ages, and comes up regularly. The main problem and reason why we haven't settled on anything yet is that many people have very different ideas about what it should be. Let me try to list the different use cases I came across:

• Programmatic association with a single user
  • For example, Tobira has a page "My Videos" which currently shows all videos the user has write access to. That's not really "My videos", is it?
  • For this use case, the field needs to be a unique user identifier, i.e. it cannot be a normal person name. Two options: username or user role. It's a bit tricky due to keeping that identifier consistent across many different places (Tobira, Opencast, LMS), i.e. a single actual person needs to have the same identifier regardless of where they log into.
• Pragmatic person to contact
  • This is what Olaf mainly described here. It's basically a person an administrator can contact about the video (e.g. pending deletion).
  • A user-identifier linking the video to a user-account would work, but what if that person leaves the university and the account is deleted? A normal person name and/or mail address might be better?
• Legal owner
  • Some also talked about having an owner mainly as a legal framework, e.g. to make a person responsible for copyrighted content or whatnot.

Open questions:

• A single owner or multiple ones?
• Can owners be changed? Who can do that?
• What about serires and playlists? Can they have owners? Is the video owner inherited by the series?
• ...

What we already decided a long time ago kind of:

• Keep ownership separate from access. ACLs with read/write actions are already evaluated by lots of apps, if we now say the access also depends on the owner, that means adjusting lots of apps and probably breakage in the transition period.

Previous discussions:

• Olaf: Ownership for Tobira and Opencast
• Discuss: Event Metadata #1 (comment)
• Discuss: Event Metadata #1 (comment)

[mtneug]

Keep ownership separate from access. ACLs with read/write actions are already evaluated by lots of apps, if we now say the access also depends on the owner, that means adjusting lots of apps and probably breakage in the transition period.

Ownership is already a concept in the Moodle and ILIAS Opencast plugins. Both use a single rule in the ACL, by default ROLE_OWNER_{username}. Both only allow for a single owner that can be changed. What {username} is can also be configured and hopefully then matches with the username in Opencast. Not a perfect solution, but mostly works in practice.

Using the ACL is for attaching the ownership is not necessarily related to access. The ACLs might still contain ROLE_USER_{username}.

[LukasKalbertodt]

I agree that using the ACL somehow does not necessarily mean we are relating it to access. But the way you describe Moodle and Ilias doing it seems weird and maybe backwards to me. What action is associated with this ROLE_OWNER_* anyway? What I could see is having an ACL entry with the user role and the action own. That is in line with how ACLs are normally used and uses the pre-existing user role, not creating a second username-derived role. Alternatively, I would use a metadata field. But yeah, this ROLE_OWNER_* ACL entry does not seem like a good solution to me, even if it works in practice.

[mtneug]

I think ILIAS always uses read,write. For Moodle, this should be configurable. We use the same as for ROLE_USER_*, i.e. read,write,annotate,annotate-admin.

[snoesberger]

Pragmatic person to contact

• This is what Olaf mainly described here. It's basically a person an administrator can contact about the video (e.g. pending deletion).
• A user-identifier linking the video to a user-account would work, but what if that person leaves the university and the account is deleted? A normal person name and/or mail address might be better?

If the aim is simply to have a point of contact (which would be the main use case for us), I would suggest using an email address. This would also allow you to use a group email address. This could help to solve problems when a person leaves the university. If you only have the user ID, it can be difficult to identify the person behind that ID once they have left the university. Even with a name or email address, it can be difficult to find out which institution the person worked for and who took over their responsibilities.
I'm also not a fan of mapping the owner directly to an opencast user. This would require an opencast account for each owner. This is what we are trying to avoid at the moment.

If the purpose is to provide a point of contact, I wouldn't call it "owner", but rather something like "contact address". Perhaps we should differentiate between these two use cases? The "owner" would be the legal owner of the video, whereas the "contact address" could be used to inform people of things like videos being ready for cutting or being preselected for deletion due to a lifecycle policy.

[LukasKalbertodt]

Perhaps we should differentiate between these two use cases?

I agree. We might want to have different things for all three use cases. The "legal owner" could be served by the dublin core "rightsHolder" field? Which, in the new data model, would live in extraMetadata in the dct namespace.

I'm also not a fan of mapping the owner directly to an opencast user. This would require an opencast account for each owner. This is what we are trying to avoid at the moment.

Well, depends. Lets assume the "contact person" and "legal owner" use cases are covered via different means already. We still need to solve the "programmatic association" part and that only works with a unique user identifier, be it username or uesr role. For one, I never said that the username in the field would be checked against Opencast's user table or anything.

But yes, you would need a global system for assigning usernames/user roles to persons. If you don't have that, or at least not for all users, than those users cannot be owner of anything. Which is not a huge deal in my book. Remember that in order to give read access (for an event) to a single person, you have to have a unique "user role" for that person already. So the requirements for both these things are the same. Tobira also requires the same. In other words: if a person can log into Tobira or can be granted individual access, then they can be an owner. At least that's how I see it.