Library talk:Circle/File Naming Conventions
- [View source↑]
- [History↑]
Contents
Thread title | Replies | Last modified |
---|---|---|
Examples | 5 | 19:05, 18 January 2023 |
Non/unique Title | 3 | 19:05, 18 January 2023 |
Guiding principles | 7 | 18:14, 9 January 2023 |
File Naming Significance - Draft Section | 3 | 18:13, 9 January 2023 |
I believe these may be all real examples. Consider including links to actual items in OC. Sometimes folks like a visual http://hdl.handle.net/2429/32487
Yes that would be good! I can look up each example in OC. Regarding where/how to link - would it just be best/least messy to hyperlink the example file names?
I think the Lorenz Yeung example is currently linked to the pdf file itself - should I replace that with the OC link for consistency or leave as is?
Can we just add "See example http://hdl.handle.net/2429/32487" underneath each example?
I attempted to add a couple but I'm actually not sure now that it adds much. Feel free to remove if you don't lik eit.
I'm not sure I understand the non/unique title. Is this new? It uses the same example twice. My preference would be to remove the distinction between non/unique and just have one example for this section.
No this section has always been here, though I might have reformatted as I did some reformatting across the whole page for consistency in headings.
Since non-unique titles is only under "Agency and Organizations as Authors" my assumption was that it serves a purpose - maybe agencies submit a lot of generically named reports to cIRcle?
But I agree that at the very least, the use of the same example is confusing.
I'll see if I can find any use cases for this. But if not, then this section could be removed.
So, I re-read the examples a couple of times and then I finally understood what it was getting at. In some cases, they may be giving us chapters or newsletters or something with the exact same title (ie. non-unique) so I think the person who wrote this was trying to explain what to do to differentiate. To simplify, I merged these two which I'm hoping brings more clarity. I'm happy to take direction from you if you disagree or have other suggestions.
Do we want to link to a good reference for these principles here? Also, would we consider using this image at the top of the page for visual interest https://xkcd.com/1459/ I use it in my presentations and feel it resonates:)
I will play around with the layout of the image to add it.
I can also look up a reference for the guiding principles. The only potential hesitation with this is that all the references I've come across so far have stated that special characters should never be used - while the principles on this wiki are cIRcle-specific, would it cause confusion if our linked reference is in conflict with our guide?
I feel like I might be misunderstanding our meeting about this. If all the guidelines are saying do not use special characters, why are we saying you can?
Ok, I was getting confused by what we are trying to say so I looked it up and I think we could adapt this example from https://instr.iastate.libguides.com/datashare/filenames
Avoid special characters Just because you can use something doesn't mean you should. There are two reasons to avoid special characters, punctuation marks, and symbols in filenames:
Special characters and punctuation marks are often reserved characters for computer operating systems. This means that the character is used in a very specififc way by the operating system and using it in a file name will cause errors. Not all operating systems and programs support the same characters. A common example is how the modern Mac OS (9 and after) support a number of special characters (/ \ : * ? < > |) that are not supported by Windows. Also: Never Use Emojis in file names! It's a very bad idea at this time.
They also have a good reference https://blog.josephscott.org/2007/02/12/things-that-shouldnt-be-in-file-names-for-1000-alex/
Significance (draft)[wikitext]
Consistently using a file naming convention is an essential component of the long term preservation of digital records. File names should be both human-readable and machine-readable, meaning that the people and computer software interacting with cIRcle files are able to recognize and understand these files' names. If a file name is not human-readable (e.g., lacks a descriptive name), content may be lost or accidentally overwritten. If a file name is not machine-readable (e.g., contains spaces or unsupported special characters), computer software may fail to open the file rendering it unusable.
The naming guidelines that follow are designed to provide files with concise yet descriptive names that help ensure content can be found, opened, and maintained for as long as possible.
I like how the OER Accessibility Toolkit uses the header "Key Concepts". Consider renaming "Significance" heading to "Key Concepts: File Names Should Be Readable" or something to that effect. Consider doing the same for the File Format Guidelines "Significance" heading.