REST-API some fields not returned

[ipso....@gmail.com]

Hi there,

I’m trying to extract data from our AtoM 2.4.1 catalogue, via the RestAPI, using R and a REST-API-Key generated in AtoM. I get JSON back, but only ever these four fields eg.

{

“slug":"police-v-john-rowney-dongara-1870-206",

"title":"Police v John Rowney - Dongara”,

"repository":"State Records Office of Western Australia”,

“level_of_description":"Item"

}

However if I’m reading https://www.accesstomemory.org/en/docs/2.4/dev-manual/api/browse-io/ I should get other fields, including “thumbnail_url” which is the one I wanted.

Grateful for any hints on how to solve this problem.

Kind Regards,

Michael O’Connor

SROWA

[Dan Gillean]

Hi Michael, 

To be honest, I'm not sure what to suggest, but I'll try to offer a few ideas. I tested this on our public demo site, which is still running 2.4.x - if you try it yourself you may need to first navigate to Admin > Settings > Plugins and enable the arRestApiPlugin, since the site resets every hour. In any case, here is part of the response I get when accessing https://demo.accesstomemory.org/api/informationobjects:

{
 "total": 632,
  "results": [
    {
      "reference_code": "ON00120 007-2",
      "slug": "woolworth-building-sudbury-ontario-photo-copyright-rideau-air-photos-ltd-seeley-bay-ont-can",
      "title": "Woolworth Building Sudbury, Ontario",
      "repository": "City of Greater Sudbury Archives",
      "level_of_description": "Item",
      "creation_dates": [
        "1961"
      ],
      "place_access_points": [
        "Ontario",
        "Sudbury, Greater",
        "Sudbury, Greater",
        "Canada"
      ],
      "thumbnail_url": "http://demo.accesstomemory.org/uploads/r/city-of-greater-sudbury-archives/7/1/71478/007-1-1-2_142.jpg"
    },
    {
      "reference_code": "ON00120 007-1",
      "slug": "sudbury-high-school",
      "title": "Sudbury High School",
      "repository": "City of Greater Sudbury Archives",
      "level_of_description": "Item",
      "creation_dates": [
        "[between 1955 and 1965]"
      ],
      "place_access_points": [
        "Ontario",
        "Sudbury, Greater",
        "Sudbury, Greater",
        "Canada"
      ]
    },
    {
      "reference_code": "ON00120 007-11",
      "slug": "28-hockey-arena-sudbury-photo-copyright-rideau-air-photos-ltd-seeleys-bay-ont-can",
      "title": "28. Hockey Arena Sudbury",
      "repository": "City of Greater Sudbury Archives",
      "level_of_description": "Item",
      "creation_dates": [
        "1961"
      ],
      "place_access_points": [
        "Ontario",
        "Sudbury, Greater",
        "Sudbury, Greater",
        "Canada"
      ],
      "thumbnail_url": "http://demo.accesstomemory.org/uploads/r/city-of-greater-sudbury-archives/7/1/71487/007-1-1-11_142.jpg"
    },

...etc.

As you can see, it appears to be working in 2.4.1, so I'm hoping this is a configuration issue, and not a bug. Let's check a few things. 

First, here is where the thumbnail is being added to the browse endpoint response in the code: 

• https://github.com/artefactual/atom/blob/stable/2.4.x/plugins/arRestApiPlugin/modules/api/actions/informationobjectsBrowseAction.class.php#L189  
  

Notice that it is constructing the path by using your Base site URL setting. This is a configurable setting in Admin > Settings > Site information - make sure that you have entered the proper URL for your homepage! The URL should not end with a slash (e.g. enter http://example.com, not http://example.com/), as AtoM will add this as needed when using the base URL setting to prepare links. 

I don't think that failing to set this should prevent the thumbnail_url from showing up in the endpoint response (instead, I would just expect the URL to be incorrect), but as a first step, double-check that you've properly configured this setting. 

One thing you could try is using the read endpoint to see if digital object metadata is showing up in the response that way - for example: 

• http://example.com/api/informationobjects/police-v-john-rowney-dongara-1870-206

Two things I noted in the code for this endpoint: 

• https://github.com/artefactual/atom/blob/stable/2.4.x/plugins/arRestApiPlugin/modules/api/actions/informationobjectsReadAction.class.php#L436-L466  
  

First, on line 436: the digital object URL's availability may depend on your Visible elements settings. If you have disabled the digital object URL visibility, it looks like it may not be included in the response either. See: 

• https://www.accesstomemory.org/docs/2.4/user-manual/administer/visible-elements/#visible-elements-digital-object 

Second,  lines 447 and on reference a unique use case - that is, when you have performed a metadata-only DIP upload from Archivematica. See: 

• https://www.archivematica.org/docs/archivematica-1.11/user-manual/access/access/#upload-metadata-atom  
  

In this case, there is no actual digital object stored in AtoM - only metadata about the digital object. Consequently, if by chance you are using Archivematica and AtoM, and you've followed this workflow, then I would not expect to see a thumbnail URL in the response. 

One more thing to check: It's possible in the group and user permission settings to disable access to the digital object master and derivatives. I would double-check that thumbnail access is set to "Grant" in the Archival description permissions for the anonymous group. If it's set to "Inherit" it should be fine - by default, public users can access thumbnails and reference display copies, but not the digital object master (i.e. the original file upload). See: 

• https://www.accesstomemory.org/docs/2.4/user-manual/administer/manage-user-accounts/ 
• https://www.accesstomemory.org/docs/2.4/user-manual/administer/edit-permissions/   
  

Finally, it does look like Elasticsearch is being used to help generate the response, so you could always try re-indexing your content to see if it helps. From AtoM's root installation directory, run the following to rebuild your search index: 

• php symfony search:populate

See: https://www.accesstomemory.org/docs/2.4/admin-manual/maintenance/populate-search-index/

Hopefully one of these suggestions might help resolve the issue! If not, let us know a bit more about your installation. For example: 

• What is the full version number listed in Admin > Settings > Global? (just want to make sure the database schema version is correct - for 2.4.1 I believe it should be v156)
• Did you follow our recommended installation instructions?
• If yes, are you using Ubuntu 14.04 or 16.04?
• If no, what changes have you made?
• What version of PHP do you have installed?
• Have you made any changes to the default digital object storage locations (for example, are you using a multi-server installation or anything like that)?
• Were the digital objects you're unable to see in the API response uploaded locally, or via URL?
• Anything else that you'd like to share that might help us to recreate the issue locally?

Thanks in advance! 

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/8c4c26f8-a581-4df1-8e28-a2b7b2bc4654%40googlegroups.com.

[Mike O'Connor]

Hi Dan,

Thank you for such a detailed response!  I’m working through the solutions and will report back soon.

Regards,

Michael

You received this message because you are subscribed to a topic in the Google Groups "AtoM Users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ica-atom-users/Xihp5XEf7yc/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAC1FhZJb7xof8YpDNJepeGa9EDHaSOYhdYPyij9ySNKf2ZGkjg%40mail.gmail.com.