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. 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.
Having established a new file structure for the 40 collections I wanted to accommodate, I set about making indexes and the digital objects themselves, as visible and accessible as possible. I used three different types of indexes – a document containing a list of the objects, a set of folders with index information in the folder titles, and a set of files with index information in the file titles. In each case, access to the index was provided either by placing the index, or by placing a shortcut to the index, into the relevant collection folder. The table below shows the number of instances of each type that are employed in the overall set of collections.
| Number of collections | Index placed into collection folder | Shortcut placed into collection folder | |
| Index in a separate document | 15 | 11 | 4 |
| Index in folder names | 7 | 3 | 4 |
| Index in file titles | 12 | 8 | 4 |
| No index | 6 | 0 | 0 |
Another way of creating an index is to piggyback one collection’s index on another collection’s index. This is what I’ve done for the ‘Other Display Case Items’ collection which is identified by the term ‘Other Display Case Items’ in the facet column of the Mementos index.
In similar vein, two indexes can simply be combined as I’ve done in two cases. In one, I’ve merged the indexes of two separate Memento collections (my own for before I was married (1366 entries), and the other for myself and my wife (870 entries) into a single spreadsheet making it much easier to manage and to conduct searches. The digital objects still have different Ref Nos prefixes enabling them to be distinguished from each other. In fact, I now have 4 different collections recorded in the Mementos Index, all with different Ref No prefixes, and all with their files kept in separate sub-folders. In the other case, the separate Publications, Significant Work Reports, and Certificates & Trophies indexes (containing 68, 98 and 41 entries respectively) were combined into a single word document and the collection renamed the ‘Trophy Gallery’ collection.
This combination of different indexing approaches and the ability to either locate the actual index, or a shortcut, in a collection folder, provides a great deal of flexibility in the work required to creating and maintaining an index, while enabling very quick access to the index information whichever approach is taken.
The use of shortcuts also provided a very useful aid in the storage of digital objects associated with collections. In three particular cases (Music, Videos and Photos) the collections are located in separate libraries in the Windows File Manager, take up many gigabytes of storage, and, in the case of Music and Photos, comprise hundreds and thousands of files respectively. To be able to leave them where they are, and just to refer to them with a shortcut, was a much easier option than to have to physically relocate them. 
Another very important advantage in leaving them in their separate libraries is that the backup of the Documents library will be much quicker, and will take up considerably less space which means that I will not be so worried about a potential lack of space in the destination of the backup.
Interestingly, shortcuts have played much less of a part in cross referencing between collection objects. This is because you want to spot a cross reference while you are looking at a particular object – you don’t want to have to go looking for a separate shortcut file – indeed you wouldn’t necessarily even be aware that a separate shortcut file exists. Hence, cross references are best defined either in indexes, or as links on some text or images. I have cross references in the indexes for 12 of my collections – though none are in a specific cross-reference field. Instead, I have used fields such as ‘Notes’ or ‘Comments’ or have simply added a cross reference in brackets at the end of a description or a title. For the most part these cross references specify Reference Numbers – it doesn’t work so well with a general description or a lengthy pathname. I am still musing on whether to add a specific Cross-Reference field into some of my indexes.
Regarding links on text or images, I have only employed this technique a couple of times. First, in this Blog in which it is invaluable in referring to other posts and to supporting files; and second, in the Story Boards collection in which the approach was integral to the Story Board concept: the things that an object reminds you of are placed around it on a single page, and then further information about that snippet is available via a link to some back-end material. Its very effective. I may use more of the link approach now that I have an established and comprehensive digital structure for all my collections such that I’m confident that the objects will stay in the same place for quite a while and that the links are unlikely to get broken.
The reorganisation of the digital versions of my collections hasn’t affected the display of collection objects a great deal – though it has prompted me to put additional folders into the Windows Lock Screen function. Previously I had only included the Paintings, Drawings and Collages collection, but I’ve now added the Computer Artefacts, Other Display Case Items, Mementos, and Photo collections, and these four have added well over 26,000 extra objects to be displayed when the PC is inactive. It’s easy to add items into the Lock Screen function since it will accept high level folders and will display the items at the bottom of the folder tree. A final point about displays is that at some point in the near future I’m going to have to rearrange the way all these collections are displayed in my iPad to reflect this newly reorganised master structure in my laptop. A disconnect in the way the two versions are represented would not be helpful…
I’ve just finished taking my own collection-combining medicine – and it’s produced an unexpected set of collections and a massively different PC landscape.
I started by going through the 92 collections I had previously accredited to myself and thinking about what I really wanted to be classed as a collection and how I wanted them to be categorised – dual considerations which influenced one another. The result was a surprise; not that it was different from what I expected (I hadn’t really any preconceived notions) – it was just very new. I’d elected to have 40 separate collections in the following 11 categories:
As you can see, the above list is a screenshot of the second level folders in my laptop, below a top-level folder named ‘APAWCOL’ – the ‘A’ being included to ensure it sits at the top of the folder list. The names in brackets are included to make it easy to know what collections are in each category. Of course, this overall structure only emerged after an extensive process of iterative developments. Some of the more interesting decisions taken on the way include the following:
As the above examples show, decisions about personal collections are flexible and pragmatic; they just need to make sense to the owner.
The process of creating and populating these different collections within the overall APAWCOL folder involved the movement of individual files and folders, and the creation of many folders and shortcuts. It also involved sorting out and rationalising the material that had built up over the years in non-collection folders, and some folders which had mixtures of both non-collection and collection material embedded within layers of sub-folders. I soon realised that this exercise would require a complete revamp of all the files in my PC filing system.
When I started, my laptop had libraries for Music, Photos, and Videos, and the PAWDOC folder (containing thousands of files) in the Documents library. I left all these collections alone, and simply used shortcuts to access them from the relevant collection folders.
Within the laptop’s ‘Documents’ library there were 31 main folders when I started and only 11 when I had finished. 16 of the original 31 were moved into collection folders. Of the remaining 15 main folders, 1 was the PAWDOC folder, 8 were retained as ongoing day-to-day files, and 6 were destroyed. 1 new main folder was created.
The reorganisation took me 16 days and involved the following actions:
I’m very pleased with the result for a number of reasons:
I conclude from this experience that simply having the digital elements of multiple collections together into one place on the PC is beneficial and worthwhile. However, achieving it required much more than the movement of files and folders. There were substantial implications for indexes and cross referencing, and for actually combining some collections together. These are addressed in subsequent posts.