Collection getParentCommunityList()

[Terry Brady]

I am investigating the following ticket: https://jira.duraspace.org/browse/DS-2766

Here are my questions.

1. In the collections endpoint, of the REST api, what is the intended behavior of expand=parentCommunityList?

2. In DSpace, can a collection exist in multiple communities?

Question 1. expand=parentCommunityList

In DSpace5x, the expand=parentCommunityList option returns the full hierarchy of owing communities for a collection (all the way to the top level community).

In DSpace 6x, this option returns the subcommunity that is an immediate parent of the collection.

Assuming that this behavior is incorrect in DSpace 6, the following configuration will need to be updated to follow the community2community hierarchy: https://github.com/DSpace/DSpace/blob/master/dspace-api/src/main/java/org/dspace/content/Collection.java#L81-L86

Question 2: Can a collection exist in multiple communities?

The following method in DSpace 5x could imply that a collection can exist in multiple communities: https://github.com/DSpace/DSpace/blob/dspace-5_x/dspace-api/src/main/java/org/dspace/content/Collection.java#L1402

But, the REST API implies that there is a single "parentCommunity".

https://github.com/DSpace/DSpace/blob/dspace-5_x/dspace-rest/src/main/java/org/dspace/rest/common/Collection.java#L136

and a separate parentCommunityList

https://github.com/DSpace/DSpace/blob/dspace-5_x/dspace-rest/src/main/java/org/dspace/rest/common/Collection.java#L156

What is the intended set of relationships to be supported?

If a collection can exist in multiple communities, how should the REST api respond to "expand=parentCommunityList" option?

If a collection can exist in multiple communities, how can this relationship be created in our UIs?

Terry

--

Terry Brady

Applications Programmer Analyst

Georgetown University Library Information Technology

https://www.library.georgetown.edu/lit/code

425-298-5498 (Seattle, WA)

[Tim Donohue]

Hi Terry,

Some quick answers...

I'm not sure of the correct answer to #1 myself (Peter Dietz, did you create this behavior?). Since it's called a "List" though, it sounds to me like the behavior in DSpace 5.x is more correct (that the intension may be to locate the full location of the collection, similar to breadcrumbs).

As for #2, the API / database has always supported the "idea" of a Collection existing in multiple locations (i.e. a "linked" Collection). However, we've never found a reason to fully build this out with unit tests, etc. So, it's a partially created concept, and it's never really been proven to "work".  In addition, the UIs have never supported this idea...at the UI level, a Collection only ever belongs to a single Community.

So, essentially, #2 would/should be treated as a new feature. The groundwork is there in the API / database layer. But, it has never been fully built out. It'd need a volunteer to dig in and implement this concept so that it's actually usable in the UIs.  It also may require some refactoring at the REST API layer, as you've noted.

- Tim

--
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To post to this group, send email to dspac...@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

-- 
Tim Donohue
Technical Lead for DSpace & DSpaceDirect
DuraSpace.org | DSpace.org | DSpaceDirect.org

[Terry Brady]

Tim,

Thanks for the explanation.

To implement #1, I recommend that we add the necessary hibernate configuration logic to recursively traverse community2community.  Who could advise on that change?

To implement #2, we would probably want to change the method return type to return a list of lists: one list for each immediate community parent.

Terry

[Tim Donohue]

Hi Terry,

On 5/18/2016 11:33 AM, Terry Brady wrote:

Tim,

Thanks for the explanation.

To implement #1, I recommend that we add the necessary hibernate configuration logic to recursively traverse community2community.  Who could advise on that change?

Sounds like we should verify the purpose of this setting first (with whoever added it...it doesn't seem to have documentation?). Maybe Peter Dietz?
Then, maybe get feedback from KevinVdV (or Atmire) on updating Hibernate as needed.

To implement #2, we would probably want to change the method return type to return a list of lists: one list for each immediate community parent.

Yes, that makes sense to me. As long as we validate the assumptions in #1 first.  We'd need to document this change in the REST API docs though, as it might affect anyone using "parentCommunityList" already.

In general here, I think we need more feedback on the intension of this param (maybe even try to track down in the codebase who added it, via GitHub "blame"?) . I'm not sure I even understand it. Until we do, it's hard to figure out how to proceed.

- Tim

[Monika Mevenkamp]

Right now DSpace has a conceptually clean structure, an almost perfect hierarchy, except where items are mapped to multiple collections.  So for example: it is clear what it means to show a collection in the UI. For a mapped item that is not necessarily true. Image styling different collections in different ways in a future flexible UI  - what style should be picked for a mapped item ? In other words - mapping things - means moving away from a hierarchy - means life will be more complicated.

My question here: Mapping Collection to multiple communities  — Is it worth it ?

What is the use case for mapping collections to multiple communities   ?

Can the same be achieved with solr and ‘virtual’ collections which could be defined as whatever matches some kind of query ?

What is the implication in terms of getting rid of the distinction between communities and collections ? 

That is a feature I am looking forward to: we have several communities with a single collection with few items.

Where does that position the DSPACE model in relation to the Portland Data Model ? 

My gut tells me to not to map collections. I don’t have a good overview of the wider DSPace world though.
But it would be  worthwhile discussing before hacking …


Monika

—

Monika Mevenkamp

Digital Repository Infrastructure Developer

Princeton University

Phone: 609-258-4161

Skype: mo-meven

[Tim Donohue]

Hi Monika,

Those are good questions. To clarify, I'm not recommending we add a new "map collections" feature. I was just pointing out to Terry, that *at the Java API level*, DSpace has supported the idea of a Collection having multiple parents for some time.  That is not a change, it's just how the Java API has worked.  However, at the UI level, this feature has never been implemented because we never had a clear use case for it (and I'm not exactly sure myself why the API was built this way to begin with).

When it comes to the REST API, we'd then have a decision. Do we let it act more like the Java API or do we just "hide" this feature of the Java API and make the REST API look more like the current UIs.  I think this is the basics of what Terry is asking in his #2.  I'm not sold on the fact that we need to let the REST API even support this feature (it's definitely not a high priority).

I think the real issue here is just finding a solution to https://jira.duraspace.org/browse/DS-2766, which is more about just figuring out what "parentCommunityList" was meant to do.

- Tim

[Monika Mevenkamp]

Well I guess _ i rephrase - I’d vote for hiding  :-) 

On another note - would it make sense to get away from names like 

parentCommunity 

parentCollection

in favor of parent  / parentList 

again looking ahead to the bright future where collections and communities become the same 

Monika

—

Monika Mevenkamp

Digital Repository Infrastructure Developer

Princeton University

Phone: 609-258-4161

Skype: mo-meven

[Tim Donohue]

After some more thought on this, I agree with Monika.

Since we have no known use cases for having a Collection appear in multiple Communities, let's leave the REST API as-is in 6.0. It doesn't need to surface this "feature" of the underlying Java API, until we actually have a reason to do so.

I also agree that eventually we might want to just simplify these REST API params to "parent" and "parentList". But, that can be a future task (not for 6.0).

So, Terry, that should answer your #2.  Don't bother updating the REST API for this.  As for #1, I think we just need to make "parentCommunityList" act similar to 5.x in the 6.x codebase, which should solve https://jira.duraspace.org/browse/DS-2766

- Tim

[Terry Brady]

This plan makes sense to me.  

I believe we need to update the hibernate definition to recursively crawl community2community.  I am new to hibernate, but I presume that this is possible.

Terry

[Tim Donohue]

Terry,

I'd recommend copying what you've found into the DS-2766 ticket (so that it can be tracked there and found easier). Then, you could ask KevinVdV for his advice on the Hibernate question, or we could find another volunteer to help tackle it.   But, it would be good to enhance DS-2766 with the description of the problem, etc. first.

Thanks,

Tim

[Terry Brady]

Thanks Tim.  I have updated the ticket.

Based on these assumptions, there is no change needed for the hibernate config.  

I will have a PR posted soon.