Apologies, but I may have missed some pertinent information:  the PDF file is issued a PURL, and by using that PURL the PDF is retrieved.  The metadata for the ETDs is loaded into the library catalog, and catalog users use a variety of browsers to access the catalog and the ETD metadata.  Once the link to the PDF is clicked the Adobe Reader is able to interpret the relative links in the PDF to retrieve and render the supplemental files.  It's quite an elegant solution, or was, as long as the Adobe Reader is used by the user's browser.

Has anyone in the community also used this mechanism for rendering files, where an absolute URL is given for a PDF, but then related files in the same directory are pulled up by browsers based on relative links embedded in the PDF?

I agree that absolute URLs would be most unambiguous, and a DOI is interesting, although I'm not sure that use of a separate DOI for supplemental files is appropriate.  It's probably worth thinking through.

I suppose that my ideal solution would be some format of relative link that all current browsers would recognize (we're finding that certain formats of relative links can be interpreted by Chrome and others not, which gives me some hope). 

Lydia

-----Original Message-----
From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Brian Sheppard
Sent: Wednesday, November 8, 2017 7:17 PM
To: [log in to unmask]
Subject: Re: [CODE4LIB] Question about handling/rendering of supplemental files in Electronic Theses and Dissertations

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