Changes

Jump to: navigation, search

Meaningful filenames

2,256 bytes added, 08:01, 10 February 2022
m
See also: add reference
This article is Article about naming files in a meaningful way. Naturally files should have unique names so we don't end up with several files with the same or very similar names. This article takes file naming one step further by looking at how the file name itself can carry useful information about the file. This article continues on from the article about [[Portable_Filenames]] where the purpose is looking at what characters (letters, numbers and symbols) we can have in our file names, and other limits on a file naming system.
= Why meaningful filenames =
** HTML, the language of webpages, uses tags like ''<span style="normalText">Example</span>''. Here the meta data describes the style of the text, ie: ''Example'' is ''normalText''
** EXIF ([http://en.wikipedia.org/wiki/Exchangeable_image_file_format Wikipedia's ''EXIF'' entry]) is a way of storing meta data in image files, like when the photo was taken and what type of camera was used.
* Database systems (GRAMPS Gramps is a database system for genealogy) can store a huge amount of data about data. They're are very efficient at this job and very powerful.** Google Search uses a database to remember what web pages are about, and tells you when you ask.
So why not use one of those options?
* EXIF is great, but only for some types of files (not supported in JPEG 2000, PNG, or GIF), there are lots of different systems for different types of files. People are working hard to improve this situation all the time.
* HTML is great if you can store all your information as HTML files, but HTML files cannot contain other files, they just point to them. So we'd basically end up making a website about our files.
* A database, well we already use this when we use GRAMPSGramps. The GRAMPS Gramps database stores lots of information about the files and records it records. But GRAMPS Gramps does not store the actual file inside the database. If the connection between GRAMPS Gramps and the data it is describing is broken, then the files are just files. They contain no more information than they did when you first ''imported'' them into GRAMPSGramps.
This system of ''meaningful filenames'' has the following aims:
* Preserving enough metadata to give the file's content context without GRAMPSGramps* Creating file names normal people can understand so they can see what the file is about without GRAMPSGramps
* Creating file names which a computer can process easily so files need to be batch processed and metadata can be read directly from the file name without possible confusion
* Creating a system simple enough to use all the time for every file
To be understandable we need to be able to use full words where appropriate.
To be computer readable we need to seperate separate the parts in a way which a script can easily recognise and, more importantly, in a way which would never occur in real language. So it would be no good to mark a ''name'' section with the word ''name'' if we also can use the word name somewhere in the file where it is not meant to be a marker.
To be simple enough to remember the system should not be too complicated, after all GRAMPS Gramps is meant to store the real information, this is just a supplement.
== What's in a name? ==
 
It would be nice if we could have files called
Marriage of Mary Angus Jones and Matthew Williams, 2nd Dec 1923 (William Angus is to Mary's right).jpg
But this meets only one of the criteria above, that of ''understandable filenames''. How can a computer know who got married? what their surnames are? and so on. And anyway because of the limitations of [[Portable_Filenames]] ''Portable Filenames'' we can't have file names like that. We have to drop the reliance on capitalisation, drop the spaces, drop the comma and drop the brackets. To be computer readable we need to separate the sections with a system of markers to indicate where the surname, event name etc are.
So what sections do we want to be able to identify? Here's a basic list that should be enough for most situation, remember that GRAMPS Gramps stores the more complex information, we're just trying to give a useful structure to our files.
* Surname
* Firstname
== Source events ==
The GEDCOM 5.5 standard defines so few events as to be useless. The GRAMPS Gramps XML schema defines no events as these can be made by the user. This all seems fair enough since events are highly culture based. The situations where I think a set of events should be defined are those which will be connected with source records. GEDCOM has a reasonable group of those but they are heavily based in western christian culture. The solution must be language and culture dependent. Here's my list:
'''marriage''' is for an actual marriage event and all the associated documentation, including possible divorce and separation documentation.
EVEN--marriage_SURN--jones_GIVN--mary-jean_SURN--williams_GIVN--matthew_DATE--1923-12-02_NOTE--william_angus_to_right_of_mary.jpg
This could be parsed (by GRAMPSGramps?) as the description:
'''Event:''' Marriage
SOUR--census_PLAC--uk__england__london_DATE--1840-03-21_SURN--jones_GIVN--mary-jean.pdf
This could be parsed (by GRAMPSGramps?) as the description:
'''Source:''' Census
Over at Wikipedia there is a good explanation of a [http://en.wikipedia.org/wiki/SWOT_analysis SWOT analysis].
{| border="1"{{prettytable}}
|-
! Aspect
|}
= GRAMPS Gramps ID based =
{{man note|This is another attempt by [[User:Duncan|Duncan Lithgow]] to find a good system. It is not finshed finished so feel free to add comments and correct any obvious mistakes.}}
Here's the records we'll use as examples. They involve Mary Agnes Williams (daughter of John Williams and Anna Matthews). She married Anders Sørensen (son of Anders Sørensen and Anna ?) and they had a daughter Anna Sorensen, note the spelling change.
== Justification ==
Needs expanding{{stub}}
== Aims ==
== Record types ==
The record types tell us what the record is about. GRAMPS Gramps ID's use the first character to denote the type of item the ID refers to. Sticking to something already thought and taking the most relevant ones to stored records these can be used as the following tags for record types:
* I-- Individual
* family name is their surname before marriage, but including deed pool changes, MacArthur for example
* given name is their official first name
* uid is a unique identity, in this example the (original) GRAMPS Gramps ID of the media file
* source date is the date in ISO 8601 format when the information left the people or organisation responsible for it
* event date is the date in ISO 8601 format when the event occured occurred or started. YYYY-MM-DD, ie. 2008-12-28
* event type is a noun describing the event, chosen from a list of event types, ie: marriage
* title is the name of a document (book, letter, census) or object (gravestone, heirloom), ie. williams__arthur_headstone
* Marriage certificate: ''S--marriage_certificate--jensen__williams--anders__mary_agnes--uk__london--1823-12-02--_--00864.pdf''
* Portrait: ''I--portrait--williams--mary_agnes--uk__london--1823-12-03--wedding_portrait--000967.jpg''
 
= Source based =
 
One possible shortcoming of using an event and/or individual based naming strategy is that it could "clash" with the relation between a filename and the source. This only applies to filenames that are a representation of a specific part of a source.
 
An example: having found the baptism record of Anna in page 51v of the 1843-1850 Baptism book of a certain Church we save the image (which displays pages 50v and 51f, i.e. it is an image of the "open book") and name it something like BAP--Anna--1850.png (just an example, any individual and role based mechanism will yield similar results). This works fine and allows one to easily extrapolate information from the file name.
 
However, we latter find that in the exact same page, but a few paragraphs below, we have the baptism record of another individual, from another part of the family tree. While we can simply use the original file it wouldn't convey the right information. We can duplicate the file, but that doesn't make much sense, especially since when adding the file to the Source gallery we would end up with a duplicate, which makes little sense.
 
One way to deal with this is to use a purely source-based approach in naming the files. The downside is that event and individual information can't be gleaned by looking at the file name - one would have to use Gramps itself to maintain the appropriate relations, which is after all something that is part of the source referencing work that should be done. On the other hand, and when talking about Sources that are books, it allows for easy grouping of content related to the same source, e.g. all the relevant pages on a certain book. An example filename would be "PBL--BAP3--F51-52.png", where PBL is the short name of the source author and BAP3 the short name of the specific source. Longer, more descriptive filenames could be used by using full names instead of codes.
 
Obviously this method is limited in scope to some kinds of sources, and doesn't make sense for naming photos or documents that aren't part of a larger source (e.g. an ID card).
 
A really good article on why and how to implement this kind of naming system is [http://parallax-viewpoint.blogspot.com/2015/01/hierarchical-sources.html Hierarchical Sources] by Tony Proctor.
= See also =
* [[Organise_your_recordsOrganise your records]]* Gramps User maillist thread: [[Portable_Filenames]https://sourceforge.net/p/gramps/mailman/gramps-users/thread/CALr1thXQJp15nhLWDFbUhrWS2Bf_i4HJJSZrSE97btfXiRQYkw%40mail.gmail.com/#msg34093959 Organizing media files]
= External links =
* [http://whatdoiknow.org/archives/000442.shtml File Naming / Organization Methods?] from [http://whatdoiknow.org What do I know?]
[[Category:Documentation|F]][[Category:Developers/General|F]][[Category:Media]]
4,529
edits

Navigation menu