This storage structure seems to imply that, to display the PDF and have viable links to supplemental files, one has to download the entire directory. Is that right? 

Otherwise a viewer's local copy of the main PDF wouldn't be able to find the linked files. That, or the Adobe Reader remembers where the PDF was downloaded from, and renders the links accordingly?

To my mind, it's preferrable to have all discrete objects be unambiguously addressable, ideally via some persistent ID like a DOI or similar. That goes for both the primary object of interest (the ETD) and the supplemental files. 

This might be a good time to take a step back and review how you're storing relationships between objects and how that might fit with a standard such as METS. A simple first step might be creating some kind of file manifest (stored in the ETD directory) that expresses the relations between files. ("I am an ETD and these files are my children who bear witness," etc.) And later, you could make use of those manifests to express those relations however you choose.

This isn't a solution, to be sure, but maybe some thoughts to ponder.



> On November 8, at 2:59 PM, Lydia Motyka <[log in to unmask]> wrote:
> 
> This may be somewhat of a tangential topic, but I'm hoping that some of my colleagues work with Electronic Theses and Dissertations (ETDs).
> 
> For many years we've run an ETD hosting service that stores the main PDF and any supplemental files in the same directory, and we've instructed users to insert internal or relative links to those supplemental files into the main PDF.  (For example, an Appendix may be a supplemental file and the appendix would be referenced in the main PDF.  Users viewing the PDF would click on the link to display the Appendix.)
> 
> All of this has relied on browsers using Adobe reader or Adobe plug-ins, which correctly interpret the relative link and display the supplemental files, which are stored in the same directory on our server as the main PDF.  Fewer and fewer browsers now use Adobe, and those that don't generally are not able to correctly interpret relative links in the PDF to render the supplemental files.
> 
> While browsers used Adobe this made submission of ETDs and their supplemental files very easy:  the student packaged the main thesis and all supplemental files into one folder, the links to supplemental files were easily created and tested in Word, and conversion to PDF retained the relative links.  At the other end Adobe would correctly interpret those links and render the files.  Students or library staff did notd have to deal with loading supplemental files separately, and our software did not have to deal with them separately.
> 
> Unfortunately we can no longer assume that Adobe be used to render the ETD PDF, and I'm wondering if any colleagues are facing the same dilemma and how that problem was solved (likely by changing the ETD hosting system).  Our preferred solution would include retaining PDFs and supplemental files in the same directory.
> 
> Thanks in advance,
> 
> Lydia Motyka
> Florida Academic Library Services Cooperative