Possible to keep repository unpublished/private? Also: Possible to link to files saved on local server?

[JJ_S]

Hello, Hello!

A few questions about AToM functionality that I haven't been able to answer on my own:

My organization objects to the high cost of web hosting associated with ArchivesSpace, so I am exploring AToM as a good alternative for managing a repository that I've been working on for several years. Just a side note that I am trained in DACS, so translating to ISAD(G) would be necessary for my foray into AToM.

My questions:

1. Is it possible to keep the repository private by not publishing it online? (Only our staff will need to access it)
   
2. Is it possible to link files saved on a local server to their item descriptions in AToM? (We don't need to include thumbnail jpgs of digital documents like press clippings, for example, but it would be very helpful to have a quick pathway to access such documents on our vast server)
3. Has anyone here who is trained primarily in DACS found that shifting to ISAD(G) leads to less detail in description?

Big thanks in advance!

- JJ

[Dan Gillean]

Hi JJ, and welcome to the AtoM community! 

Is it possible to keep the repository private by not publishing it online? (Only our staff will need to access it)

If by repository you mean the entire archival catalog: yes. You could put the entire site under HTTP authentication for example and/or keep it behind a firewall. You can add robots.txt files to ensure that webcrawilers will not index it, etc. 

If by repository you mean an archival institution record in AtoM: not out of the box. Currently only archival descriptions have a "publication status" that allows their visibility to public users to be easily toggled (i.e you can set descriptions to "Draft" and users who are not logged in cannot see them). 

That said, one way of achieving this functionality for other public facing record types that also don't have a publication status (such as authority records, terms, etc) is to use a 2-site deployment method: Essentially, you have 2 AtoM sites installed - one read/write site behind a firewall for staff editing, and another read-only site for public access. You then use a replication script to copy content to the public site whenever you are ready to update what is visible. In addition to adding a sort of workaround publication status for other entities, this also can help with site security and scalability. See the following slide deck for more info: 

• https://www.slideshare.net/accesstomemory/2-sitereplication-with-atom
  

Is it possible to link files saved on a local server to their item descriptions in AToM? (We don't need to include thumbnail jpgs of digital documents like press clippings, for example, but it would be very helpful to have a quick pathway to access such documents on our vast server)

There are potentially two ways to do this. 

First, by bending the existing user-interface supported functionality: 

If you don't need local access derivatives to be visible in AtoM, AND the file paths you want to use would be accessible on your local network, then.... I think yes? But it would be worth setting up a local test instance to confirm this. Note that the functionality here would not be great. 

Essentially, I think you could use AtoM's link via URL option for digital objects: 

• https://www.accesstomemory.org/docs/latest/user-manual/import-export/upload-digital-object/#link-a-single-digital-object-to-an-archival-description
  

Normally, linking by URL has 3 requirements for it to work as intended: 

• The URL must be accessible on the public web - no firewalls, password requirements, etc
• The URL must use HTTP or HTTPS - no local share drives, FTP links, etc
• The URL must end in a file extension - if you try giving a general link  (like a YouTube link) then AtoM doesn't know where to find the target object

However, failing to meet these requirements does not prevent you from saving the link and associating it with the description - it merely prevents AtoM from properly displaying technical metadata about the file and generating a thumbnail and a reference access copy. 

The media type for each object will likely end up as "Other" for every link like this. While you could edit the digital object metadata to manually change this, setting it to audio or video for example will prompt AtoM to load the player.... which won't work, since there is no file to play, and may confuse your users. 

So: probably, but it would be a bit of a hack. 

The second way, if you can get it to work, would require use of a command-line task, but might allow you to have your cake and eat it too (i.e. still have local derivatives). 

There is an option in our Digital Object Load command-line task that we added for an institution with a similar use case - they had a separate internal object server, and didn't want to duplicate all their storage by also uploading files to AtoM as master copies. We added the --link-source option to address exactly this case. From the description in the docs: 

The --link-source option could apply in a use case where an institution might typically store master digital objects in a separate local repository. Rather than maintain multiple copies of every digital object, you could use the --link-source option to load objects via local filepath stored to a source file in the database. Essentially, when you use the --link-source option, the digital object load task will behave like an external digital object being uploaded via URI, and ultimately, the source “master” file(s) are not copied to the uploads directory.

See: https://www.accesstomemory.org/docs/latest/admin-manual/maintenance/cli-import-export/#load-digital-objects-via-the-command-line

For this to work, you will still need to basically meet conditions 1 and 3 for the external digital objects - AtoM would need to have access to their internal location without any barriers like password prompts, etc; and you would still need links that end in the file extension to get derivatives whenever possible. 

Has anyone here who is trained primarily in DACS found that shifting to ISAD(G) leads to less detail in description?

Worth noting that, while it's not a perfect implementation, AtoM does have a DACS template! So for descriptions created in the user interface, the fields and help text would all be very familiar. Additionally, all of AtoM's templates are crosswalked, so you can easily switch between DACS, ISAD(G), and the other supported templates at any time to see how they map. 

Note that we don't have a separate CSV import/export template or EAD XML profile for DACS, so you would use the ISAD(G) ones for this. Fortunately, DACS maps to ISAD(G) rather closely, so the transition would not be that difficult I should imagine. 

Cheers, 

Dan Gillean, MAS, MLIS
AtoM Program Manager
Artefactual Systems, Inc.
604-527-2056

@accesstomemory

he / him

--
You received this message because you are subscribed to the Google Groups "AtoM Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ica-atom-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ica-atom-users/0543e022-fd87-4b90-9503-3535bcd3aad2n%40googlegroups.com.