Hi Stefan, I'm not sure this is possible, as the SWORD protocol itself defines the structure of SWORD service documents. Service Documents only really list locations that SWORD is able to deposit into. They really aren't designed to display hierarchy.
Here's more on the service document format from the SWORD protocol documentation itself: * SWORDv1: http://www.ukoln.ac.uk/repositories/digirep/index/SWORD_APP_Profile_1.2#8._Service_Documents * SWORDv2: http://swordapp.github.io/SWORDv2-Profile/SWORDProfile.html#protocoloperations_retreivingservicedocument I guess it *might* be possible to tweak the DSpace SWORD implementation code to stuff the hierarchy into the Collection "title" in SWORD -- e.g. "Top Community > Sub Community > Collection". But, we don't have a way to support that in out-of-the-box DSpace, so you'd have to change the code. If this seems like a reasonable solution, I think you'd basically need to update the CollectionCollectionGenerator (for either SWORDv1 or v2) to determine the full hierarchy of names, and then save those as the "title" here: https://github.com/DSpace/DSpace/blob/dspace-6_x/dspace-sword/src/main/java/org/dspace/sword/CollectionCollectionGenerator.java#L73 - Tim On Wed, Oct 24, 2018 at 8:17 AM Stefan Kombrink <[email protected]> wrote: > Okay, I will update this question by myself: > > it seems possible to configure SWORD to deliver communities instead of > collections: > > swordv2-server.expose-communities = true [local.cfg] > > Then, I am able to retrieve a list of service documents for their > collections. > > This way it should be possible to build a community-collection > hierarchy. It just remains unclear what will happen for repositories > that make use of sub-communities and have a deeper hierarchy level e.g. > bibliography-community-subcommunity-collection. > > Could anyone please elaborate on that? > Would be amazing if I could cover all functionality with SWORD-only! > > Regards Stefan > > On 10/24/18 2:20 PM, Stefan Kombrink wrote: > > Dear community, > > > > after the latest success in our SWORD-related DSpace Quests :D there > > remains one last challenge: > > > > Obtaining a community/subcommunity/collection hierarchy within the > > service document. > > > > To us this seems impossible. Actually the only thing missing is a > > definable unique path for each collection of the service document since > > names are often similar, e.g. "Research Data", "Publications", ... > > > > Currently we retrieve this hierarchy using REST but some institutions > > seem reluctant enabling it. Is there a way to bootleg this data through > > the service document? > > > > Any suggestions / ideas? > > > > Thanks in advance & appreciation > > Stefan > > > > -- > Stefan Kombrink > Universität Ulm > Kommunikations- und Informationszentrum (kiz) > Abteilung Informationsmedien > +49-731-50-31482 <+49%20731%205031482> > > -- > All messages to this mailing list should adhere to the DuraSpace Code of > Conduct: https://duraspace.org/about/policies/code-of-conduct/ > --- > 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 [email protected]. > To post to this group, send email to [email protected]. > 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 -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
