Springer have pushed back the publication date of ‘Collecting in the Icon Age’ a number of times since my last post. I’m not sure why this has happened, but I’m now wary of citing a particular date. The latest information can be found on Springer’s web site.
Addenda to ‘Organising Family Photos’
For the last ten years or so, I have been diligent in including the photos we receive from our family through social media and messaging, into our Photo collection. This endeavour has required me to request, a) more often than not, a higher res version than the one that has come via social media, and/or b) further information about the contents of the photo i.e. the people, places, or events that are being portrayed. Often, I would need to request the dates of the photos as well because that information seems to get lost when a photo is downloaded into the social media systems we use most – WhatsApp and FaceBook. Inevitably this has been a rather painful process – particularly when there were more than four or five photos involved. Responses were sometimes slow in coming, and replies sometimes hinted at an undercurrent of annoyance at the work that would have to be done.
My requesting of additional information had gone on since photos started coming through social media, and it was typically a tortuous process. It wasn’t that my offspring were unwilling to help, but it was time-consuming for them – and they didn’t fully buy-in to the idea that their photos needed to be an integral part of our photo collection. it reached a head just before Xmas last year when I was doing my regular yearly-or-so intake of new photos. At that point I concluded the buy-in was just not there, and that I was just imposing my own requirements on other people. I decided to be more selective about what I saved from social media and to be satisfied with the resolution delivered and the information that came with it. So, for example, if a photo of my grandchildren with someone else at an unspecified event arrived with a cursory description and sized at 125kb, I would include that version in the collection with a title which didn’t identify the specific event or unknown person, and with whatever date was provided in the social media message.
I recount these experiences because they relate to some general assumptions I had made when assembling the family photo collection as recounted in the ‘Organising Family Photos’ journey. To recap, the collection was assembled by gathering, indexing and scanning all the photos belonging to different elements of the family – my parents and their ancestors; my own before I met my wife; my wife before she met me together with her parent’s photos; and my wife and I’s photos after we married. Each of these four sets of physical photos were placed into sets of four differently coloured photo albums; and I reasoned that my offspring, and their offspring down the generations, would value these collections and would find them helpful in understanding where they came from and who they were.
In assembling these collections, I encountered photos that other people had sent, in addition to the photos the owners had taken themselves. These were often, but not always, photos of grandchildren and other branches of the family. I had assumed that collection owners would see such donated photos to be part of their photo collections, and consequently I had included them in the assembly, indexing, and scanning work. This was the background to my subsequent attempts to collect and catalogue photos provided to me and my wife through social media and messaging systems; and indeed, it has produced a subset of organised and indexed photos, all with information-rich and accurately-dated titles, which provide a rich historical record through a period of about thirty years when our offspring were leaving home, finding partners, and having children. I have no doubt they will enjoy looking at this record sometime in future years, but that is not the point. They will see it is a bonus, not a necessity fulfilled.
Another assumption I made when I was assembling the collection, was that if I provided a flexible structure for the indexing and albums, then other members of the family might maintain their own indexes and albums within the overall structure. However, not only has there been no interest in employing the flexible structure, family members do not seem to undertake any detailed cataloguing of their photos at all – so far as I know. One of the reasons for this is undoubtedly that a) these days people take and receive hugely greater numbers of photos than they ever did before, and therefore the workload in cataloguing is now very much greater than previously, and b) the facilities for retaining, organising, and searching for photos, both in mobile phones and in photo-sharing systems, are now very much better than ever before. In the face of these two changes, it is unsurprising that the workload-heavy approach I have been using to maintain our family photo collection, has not been taken up by family members, despite the fact that a template framework for the activity has been fully worked out and documented, and is easily accessible.
Having said all that, what of our Family Photo Collection, that I envisaged would be passed on down the family generations? Well, at present the physical collection consists of some 76 albums and is increasing by roughly one album every year (only a subset of each new crop of photos goes into the physical albums). This is now a HEFTY collection of physical volumes requiring a bookcase of its own. I haven’t asked any of my offspring how they feel about having to take it on when we die, but I suspect they might find it inconvenient, if not an imposition. Furthermore, the fact that a more comprehensive digital equivalent is available may make the eventual disposal of the physical volumes more likely. However, these too are simply my assumptions which, as we have already seen, have often proved to be incorrect.
The collection as it stands, provides a history of the family from the 1870s – some 150 years. In principle this would be of interest to family members of the future: it would enable them to get a sense of where they came from and to have a picture in their minds of what their ancestors were like. My assumption has always been that people instinctively want to know these things – though I do also believe, that, once people know the information is available, they have less interest in finding it out and examining it. This line of reasoning suggests that having a family photo collection going back 150 years will satisfy the instincts, but will not inspire any detailed inspection of its contents nor any particular regard for its worth; but, again, these are only my assumptions.
The fact that the complete collection is in digital form does provide a number of downstream opportunities that are not afforded by the physical album collection. In particular, a copy of the digital collection can be given to each offspring down the generations. It will take up relatively little digital space, will be easy to access, and will provide rich information in the file titles. As such, it ought to be a desirable asset, worth having and preserving and passing on. It may only contain the photos from a particular 150 year era; but it may inspire future owners to selectively add photos from subsequent times. However, future digital capabilities may bring more far-reaching opportunities. In particular, AI would seem to have all the capabilities to add additional material to the collection automatically. The cataloguing format – an Index Entry (Ref No, Description, and Date) and File Title (Ref No, Description, and Date) – is clear and simple and well within the capabilities of a Large Language Model (LLM) AI, let alone a future more all-singing, all-dancing version. There would, of course, be the danger of an LLM AI producing hallucinated index entries and titles, and even actual photos, so owners would ideally need to be checking what is produced, and that may not be done as diligently as it should. Nevertheless, it seems quite feasible that a collection could be grown in that way.
Unfortunately, the larger the collection grows, I can foresee that future generations will have less desire to fully explore its contents. However, that perhaps is immaterial: the contents will always be there to answer a query or to satisfy a general desire to explore the family’s past. It doesn’t have to be thoroughly explored to be useful. Interestingly, there are probably some comprehensive family photo collections that do already extend through the generations and which could be used to explore what the current downstream offspring think about them. The example that immediately comes to mind is the British Royal Family, and no doubt there are other Royal or Wealthy families which have similar extensive collections assembled and maintained by paid curators. The views of the offspring would be atypical because of their circumstances, but might, at least, throw a little light on the matter. Perhaps such research already exists – I haven’t investigated that question myself.
I have been able to muse about the future of our photo collection because it does actually exist as a whole family collection which can be easily passed on through the generations. This is not so true of photo collections that exist on people’s phones or in some cloud system. It is not clear what will happen to such collections in the decades to come. No doubt some will get passed on, and perhaps some AI in the future may organise and research them in some way; but they will, initially anyway, be less coherent and will represent only a narrow subset of the family. Having said that, there are now so many photos being produced and stored in the world that it is difficult to foresee what will happen to them all in the centuries to come.
This post has been all about the assumptions I have made – and continue to make – while organising and adding to our family photo collection. Here’s a summary of them – with some notes about their validity.
One final point: my acknowledgements must go to all the members of my family who are unknowingly providing the observations upon which I am basing my thoughts and opinions. I have only once explicitly sought their views (that was when I was assembling our photo collection back in 2015). Other than that, I may be misrepresenting them. If so, I apologise.
This Journey contains afterthoughts on Journeys already completed. The musings have not been added to the original Journeys because those Journeys are completed and closed, and are not being reproduced in subsequent Journey hardcopy books. The Addenda Journey, however, will stay open as long as the pwofc.com website is open and I am still alive and able. Each Addenda post will be specifically related to another existing Journey in pwofc.com.
We received the schedule from Springer yesterday. It’s planned to send the book page proofs to us in the week commencing 5th May, and we have 12 days to review them and provide corrections. The Springer web site is now specifying a publication date of 2nd June. In the meantime, we’re working on some supplementary material that we plan to publish elsewhere in pwofc.com also on 2nd June – the analysis we undertook to identify the practice hierarchy, an overall practice hierarchy diagram, and an expanded overall set of references.
I started looking for a replacement for my uGrokit app with a search for ‘simple database apps for the iphone’. The first hit that came back was iDatabase on the app store, and when I looked at that, the app store also suggested Collections Database, easyAsPieDB Database, Formbook, HanDBase Database Manager, and Memento Database. After doing a bit of netsurfing to find out as much as I could about them, I decided that Memento Database would be worth a try, so I downloaded it and imported the first 5 records, then the next 5 and then the next 20. At that point I decided this was probably going to work for me, and loaded up the other 120 or so records. This wasn’t a particularly scientific process, but I suspect its fairly typical of the way apps are selected from the huge number that are available. I had no desire to do detailed analyses for days and days: I just wanted something that works.
The key characteristics that made me decide to go with Memento Database (MD) were the ability to:
Interestingly, the one thing I’ve found really difficult about MD is trying to ascertain if I can really use it for free, or if at some moment my iPhone/mobile account is going to get charged. The problem is that the current ‘Free’ plan I’m on is limited to 100Mb storage, but it’s not clear if that 100Mb is for cloud storage or not. For now, I’m assuming it must be for cloud storage because the iPhone says that this app is taking up 4.67 Gb of which 4.63 Gb is being taken up by Documents and Data. I don’t understand this sizing as it works out at over 29Mb for each of the 155 records – very strange. Anyway, I shall continue to use the app locally and will keep my fingers crossed that it doesn’t lock me out at some point in the future. If that should happen, I’d have to decide whether to tie myself to the £35 a year charge, or whether to look for a replacement.
The process of getting the data from my uGrokit app into the MD app was particularly tortuous, and demonstrated how important it is to retain collection data in a transferable format. The uGrokit app would, on request, send a list of all the data in the body of an email as in the example shown below:
I had to put this material into a spreadsheet and save it in csv format in order to import it to the MD app. I made several different attempts to do so including using Excel’s ‘Get data’ function which I couldn’t understand; and copying and pasting chunks and deleting unwanted material. I ended up just copying and pasting the description and then manually filling in the necessary fields (the ones underlined in the example above). I did this on my laptop in tranches with a small number of records in a spreadsheet to start with and then, as I grew in confidence with the app and the process, I increased the number of records until all 155 had been dealt with. As I did each spreadsheet, I emailed it to myself, picked it up on my iPhone, saved the file to the iPhone’s file system, and imported it from there into the MD app. As I did each import, I discovered foibles of the import process which I was able to address in subsequent csv spreadsheets. For example, apostrophes in the description text (such as “from Paul’s study”) resulted in the text following it being placed into a new record; so, once I figured that out, I eliminated apostrophes from subsequent spreadsheets.
As I compiled the spreadsheets, I was also able to eliminate items that had been removed from the loft: when I designed the uGrokit database I had included a ‘Date removed from loft’ field rather than opting to simply delete the item concerned, because I wanted to have certainty about what had been there and when it was removed. However, with this new app my priority was to keep the number of records down in case I should surpass a charging threshold, so I elected to eliminate items that were no longer in the loft. For the same reason, I did not include the records (including photos) for each of the 32 Positions in the loft (which had been included in the uGrokit database).
Once all the records in the last uGrokit email had been included, I then had to manually create entries in a final csv spreadsheet for the 24 new items that had been added after the last uGrokit email had been sent in January 2023.
Finally, all the spreadsheets were finished and the information imported into the MD app. However, the records from Ugrokit had come with only image file names and not the images themselves, so I then had to go into the loft and take a photo of each of the 155 items. Despite being a laborious exercise, it actually doubled as a useful stock check as well as enabling me to rectify errors in the Position information.
The loft database is now complete and fully operational as a Local ‘Library’ in the MD app. So far, I haven’t been charged anything or been asked to upgrade. The app seems to do everything I need it to – though, of course, time will tell. It has just three flaws that I can see at the moment:
These issues – particularly the first one – are a little disconcerting; but having gone to all the effort to populate my loft database in the MD app, I’m not inclined to do further investigations right now and to potentially have to go through it all again with another app. Instead, I’ll wait and see how things go – and in the meantime export a copy of the MD Loft database, as well as saving a copy of every photo to my iPhone photo library: I’ve learnt my lesson about retaining data in a transferable format. I have retained my old uGrokit loft database on my iPhone: there seems no particular reason to delete it until I have to. However, all additions and changes will be made in the MD app going forward. I’ll report back on how things work out with the new app in a year so.
It’s been over 8 years since I wrote the last entry for this particular journey and started using the uGrokit iPhone app. Since then, the app has worked reliably for me across at least two different iphones and provided easy to access information about the 180 or so objects in our loft. However, a year or so ago, the facility to have a backup email sent listing the contents of the database, stopped; and soon afterwards my local version stopped synching with the remote cloud copy. Investigations revealed that the uGrokit company had been acquired by Turck (a German international supplier of factory and process automation technology) in April 2017, and that the uGrokit app was now EOL (End of Life). I had truly taken my eye off the ball. Turck continues to sell the U Grok smartphone readers but, instead of a ready built app, it provides a software development kit for users to build their own databases.
This is a classic digital preservation problem for collectors using technology to support their activities: you have to keep abreast of the technology or risk losing access to your digital content. It’s demanding enough to have to do this in a commercial enterprise; but for a private individual it is an unwanted responsibility easily brushed under the carpet.
Anyway, I realised that I needed to get on and do something because, although the uGrokit app continued to work OK on my iphone, there is no guarantee that it will stay that way, or that it will work when I upgrade my iPhone; and there is no longer any support operation that I can call on for help. Furthermore, any new entries I make in the app will be locked in the app and not downloadable to another format which can be reused in another system. For all these reasons I decided it was time to find another iPhone app.
A key starting point was the question about RFID. As can be seen from my previous post in 2016, it had been my intention to try to acquire a uGrokit Reader and to try fitting RFID tags to all my loft objects. Well, I did try to do that but nothing came of it. I couldn’t acquire a reader on loan or second hand, and I couldn’t really justify the full price spend of £395 + VAT. Meanwhile, my uGrokit app was working very nicely. I lost momentum and abandoned the idea. Now, however, I needed to be clear if RFID was going to be on the requirements list for the new system I was going to look for. Interestingly, the answer was quite clear: No!
Over the last 8 years I have come to realise that adding an RFID capability would not improve my loft system for the following reason: the position of each loft item is specified in the database; and each position is about three feet wide and 5 feet deep. Most objects are either fairly large in their own right, or else in a container like a case which is also fairly large: so, it is relatively easy to find an object when you know its position. When I want to find an object, I find its position by looking at the app, and then go into the loft armed with that knowledge. Having an RFID reader to point at the object once I get to the Position wouldn’t really make it any easier.
On top of this fundamental fact that I don’t actually need RFID to control my loft objects, there would be a whole lot of extra work to do to implement an RFID system. RFID tags would have to be bought and attached to each object. The tags can be either active with a power source such as a battery, or passive which reflect energy from the reader. I wouldn’t want to have to supply and keep replacing batteries so I would be using passive tags – UHF (high Frequency) passive tags (which can operate up to about 20 feet) as opposed to HF (Low Frequency) passive tags which only operate up to about 3 feet. The tags come in all shapes, sizes, prices, data storage capacities and ways of attaching them to their objects; so, I would have to undertake a selection exercise or be tied to the tags provided by the card reader supplier. The tags would also have to be programmed to identify the objects they are attached to. Special tags may be required for metal objects; and apparently metal objects (such as the TV arial in my loft) can affect the RFID signal.
Given all these complexities, I’m glad I don’t need to go down the RFID route. My tags are white Strung Tie-On Tags which cost about £3 for 100, and I already know how to tie the knot when I attach them to an object. I programme them by writing the Item Serial No on both sides of the tags with a black felt tip pen.
Back to the list of requirements for my replacement Loft app. These are the things that immediately spring to mind:
With these points in mind, I set about looking for a suitable app. The following post documents how I got on.
Springer are now advertising that our book – Collecting in the Icon Age – will be published on 16th May 2025. A write up of the book, its contents, authors, and the formats it will appear in, is on the Springer website. Various booksellers such as Waterstones are also advertising the book and enabling customers to pre-order it. The price of the hardback version is rather high….
We have had no communications from Springer about the detailed contents of the book as yet, but have been advised that we will be sent a schedule which will include the expected date the proofs will be sent to us.
Sometime last December I watched some astronauts talking about their experiences of seeing the earth from afar. Some pictures like these accompanied their remarks. The earth is surrounded by its atmosphere which provides both the Oxygen fuel that we all need to live (in the Troposphere layer that is about 6 miles deep), and other layers which absorb high-energy X-rays and UV radiation from the Sun. The approximate boundary between our atmosphere and outer space is known as the Kármán Line and is about 62 miles up (100km). Seeing our little earth against the vastness, blackness, and relative emptyness of space (a truly appropriate name), started me thinking about that 62-mile fuel store and shield around mankind’s ship in the universe. Not a unique idea I know, but wouldn’t the effective maintenance of those precious 62 miles be the absolute top priority of the ship’s passengers?
It’s been just over a year since Peter Tolmie and I signed a contract with Springer for a book on collecting – a year in which we’ve put a lot of work in. But at last, this morning we downloaded ‘Collecting in the Icon Age: IT’s impact on collecting practices’ to the publisher’s portal. It has ten chapters:
I’m just hoping that it’ll still have 10 chapters and most of the contents when it emerges from the publisher’s editing machine…. Publication should be sometime in 2025.
The final consequence of reorganising my PC collections was that it made me review my Will. Being over 10 years old, it was out of date; and, furthermore, I thought it important to reflect the new PC structure in the bequests relating to digital collections.
The general advice that I’ve read about writing a Will is that all bequests should be included in full detail in the document itself. It is feasible to refer out to another document but this must be in existence at the time, and must be the same version at the time the will is executed. Amendments can be made to a Will using a so-called Codicil, and this mechanism would presumably enable a new version of an exterior document to be specified. However, Codicils must be witnessed in the same way that a Will itself is witnessed, so this is not a quick and easy process. [I should make it clear at this point, that I have not taken professional advice on this, and my interpretation of any of these points could be wrong.]
When I drew up my first Will ten years ago, I realised that, while the bequests relating to items in my collections could be relatively specific, an Executor might still have trouble identifying them in my study. So, I elected to provide an Additional Document and referred to it in the following very general terms, “My Executor may be guided in the location and distribution of these items by the document “Paul’s Stuff” stored as an Excel electronic file in the “XXX” folder in my laptop.”
Having looked again at the guidance, and considered the bequests I had made previously, I decided that I would take the same approach again – mainly because the collections are not particularly valuable, and because I think such a document would be helpful to the Executor. This time, I already had the format and contents of the previous version of the Additional Document to work from; as well as the newly reorganised PC structure. So, first I revamped the Additional Document by considering all the collections in the order that they appear in my laptop files; then, from this updated spreadsheet, I derived the actual bequest statements that would go into the will itself.
My Additional Document has the following fields:
Ref No: a reference number in two parts – a main category number and sub numbers for each of the elements it contains, for example, 14.3
Type: This field provides the owner’s suggestion of how the items might be valued by those who are inheriting them, and can be any one of the following:
Description: This is either the name of the general Category of an item (for example, ‘Photos’); or a description of the item concerned (for example, ‘The family photo collection which contains photos and family videos from the 1870s to the present day’)
Location: This contains clear details of the location of BOTH the Physical objects concerned AND the digital objects concerned even if some of the digital objects simply replicate the physical objects or vice-versa.
Preferred Destination: The person (or organisation) to whom this item is being bequeathed.
Alternative destination: A suggested alternative person (or organisation) who could be given the opportunity to have the item IF the Preferred Destination person (or organisation) says they don’t want it.
Note that I parcel together both the Physical and Digital versions of a particular object; this has the practical implication that a bequest always includes both versions unless explicitly specified otherwise. I believe that without such an approach there could be complications in unravelling what happens to digital equivalents.
While the use of an Additional Document has undoubtedly helped me update my Will, there is no guarantee that it will help if my collections change. It will accommodate small changes in the contents of collections which are referred to in more general terms such as ‘stamp collection’. However, if the bequests in the Will itself become in any way inaccurate, either the Will has to be rewritten or a Codicil produced. A new version of the Additional Document will not be sufficient to officially change a bequest. However, if there is no dispute among the recipients (and I expect that to be the case for these collection items, most of which have relatively little value and which family members have expressed no interest in) such an Additional Document might be all an Executor needs to distribute the deceased’s belongings. All such considerations need to be taken into account when creating a Will’s bequest texts.
Wills are not the only circumstance in which some documentation of collection contents is required. If you want to take out insurance you may need to provide details of the items concerned; and likewise, if you need to make an insurance claim. If you are burgled, the police will require a full description of what has been taken. In both cases, the indexes I have set up will be a good start: information can be extracted from index documents, or from screenshots of folder or file names. For the latter, the information itself can be copied from folder or file names by using the Windows ‘Copy as Path’ function, and then edited in a text document or spreadsheet. The digital photos or scans of physical objects in the collection are even better descriptors. In fact, in this reorganisation of my collections, I find that it is these two things – indexes and digital versions of the objects – that have been driving the structure: in the folder for each collection, I have tried to provide an index of some sort and a sub-folder containing the digital objects. In this way, it is either clear that one or both of those things is available, or that one or both are missing; and in the latter case it begs the question ‘why not provide the missing material’. All this is helpful to the cause of having information available for insurance company or police, should you require it.