Additional data dictionary changes

[weiweishi]

Hi Metadata team
Per some discussions happened during the implementation of the data dictionary in the Rails application, the dev team has identified some additional properties/attributes that may make the implementation of some of the functions easier or more future approved, and wonder if the metadata team thinks those are reasonable:

• add bibo:owner for collection and community - Internally in the rails application, we have already set an owner property for collection and community, and we wonder if it makes sense to also apply bibo:owner predicate for these two models in the dictionary? as they are serving the same purpose, and by using bibo:owner, we can reduce use of the internal placeholder (Jupiter_core).
• add ual:private as one of the accepted values of dcterms:accessRights, with the understanding that this value that will not be used in any form in the UI, or under normal circumstances. But it will be there to handle any edge cases that our new "drafted" model won't be able to handle.
• add embargo_history to generic item profile

We've also identified, during the implementation of the model that

• owner should be a single value field to simplify the implementation logic. (Tiered role management could be added during enhancement to handle more complex access rights use cases, instead of using multiple owners). This will also affect how the migration data for this field should be constructed, related to #172.

[sfarnel]

@weiweishi @leahvanderjagt

• if we add bibo:owner to community and collection will it default to admin?
• can we agree on what characteristics differentiate private from draft, particularly with respect to visibility?

[weiweishi]

@sfarnel

• yes, community and collection's bibo:owner will default to a generic era admin user (eraadmi@ualberta.ca)
• in terms of visibility between draft and private, there won't be any difference. The difference is basically coming from the implementation of "drafted" objects, as these objects will not be in Fedora, and can be discarded. This is more about the potential edge cases, where an object needs to be kept in Fedora, but can't be visible, we might not need this at all, depending on decisions made in these circumstances. And we can choose to not expose this in UI in any context, even in the admin interface to avoid confusion. It is just that it may be more complicated to add it back in down the road. And we can review in the future (after migration etc) to decide if we can get rid of ual:private completely. I hope this clarifies the requirement, but if it's not, we can chat about this.

[zschoenb]

we are going to default to "eraadmi@ualberta.ca" for owners of community and collection, but we are going to use numeric ids for all other users? Even if I migrate "eraadmi@ualberta.ca" and you coerce it to a numeric user id, the data dictionary should tell us that a) we should expect it to be a numeric id and b) once that id is produced, what it is. @sfarnel @weiweishi @leahvanderjagt

[zschoenb]

Also, does the last comment on private vs. draft reflect the official and final decision?

[sfarnel]

Thanks @zschoenb
Second item in original ticket (re: ual:private) no longer relevant. Decision on private items:
"- We will not have any preservation obligation towards draft objects. So they are disposable and don't need to be saved in Fedora. Current ActiveRecord approach suffices the need.

• ERA team will review any outstanding private objects, and will either remove them from the migration (the abandoned or test objects) or migrate them as "draft" objects (following the draft item creation process in the application instead of using ual: draft).
• We suspect the actual number of real private object is very small, and can be dealt individually.
• We will not have a ual:private value in the dcterms:accessRights property, as we plan to not migrate any object into this category. "

[sfarnel]

Re: owner as single or multi-value: report on items with multiple owners being reviewed; final decision pending.

[sfarnel]

@weiweishi Is it correct to assume that admin will be like any user in that it will be included in the user database and have a numeric id that is associated with an email address (i.e., "eraadmi@ualberta.ca"). If so then we can update the data dictionary to indicate that bibo:owner is also a property on community and collection. If it is going to be different we will need another property. Thanks!

[zschoenb]

The question of how to reduce multi-owner objects to single owner objects still remains: i.e. who becomes the owner?

[zschoenb]

Multi-owner objects are being triaged at the point of Rails ingest. One user is selected as the owner, either because they have been singled out, or based on alphabetical selection. The remaining owners are will be preserved in the ingest package, to be ingested at a later date when multi-owner is supported.