home.social

#file-formats — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #file-formats, aggregated by home.social.

fetched live
  1. Version 125 of the #PRONOM signature file was released earlier today!

    pronom.nationalarchives.gov.uk

    (with a contribution from @tibhannover for the LabVIEW Virtual Instruments 3.0 file format!)

    #digipres #FileFormats

  2. Version 125 of the #PRONOM signature file was released earlier today!

    pronom.nationalarchives.gov.uk

    (with a contribution from @tibhannover for the LabVIEW Virtual Instruments 3.0 file format!)

    #digipres #FileFormats

  3. Version 125 of the #PRONOM signature file was released earlier today!

    pronom.nationalarchives.gov.uk

    (with a contribution from @tibhannover for the LabVIEW Virtual Instruments 3.0 file format!)

    #digipres #FileFormats

  4. Version 125 of the #PRONOM signature file was released earlier today!

    pronom.nationalarchives.gov.uk

    (with a contribution from @tibhannover for the LabVIEW Virtual Instruments 3.0 file format!)

    #digipres #FileFormats

  5. Version 125 of the #PRONOM signature file was released earlier today!

    pronom.nationalarchives.gov.uk

    (with a contribution from @tibhannover for the LabVIEW Virtual Instruments 3.0 file format!)

    #digipres #FileFormats

  6. The more I read about Wav files, the more I realise that they're a bit of a time capsule. An echo of a 1991 IBM & Microsoft (and earlier).

    Behind the scenes they're actually a format called RIFF (Resource Interchange File Format). Basically tagged data chunks. So it can support most (all?) types of data. A container file format.

    What do you think AVI is behind the scenes? (RIFF), WebP, also RIFF (which was a surprise) and a bunch of others.

    The Wikipedia page states that RIFF was extended from IFF (Interchange File Format`). A brainchild of Electronic Arts and Commodore from 1985.

    Now knowing this, I can see how the design of PNG files were influenced from IFF. Same idea on tagged chunks, different ordering of elements and CRC addition. I did learn that it is noted in the 1.2 PNG spec § 12.4 Why-not-use-format-X.

    In parallel to all this, TIFF (Tagged Image File Format) has no relation to IFF.

    #FileFormats #History

  7. The more I read about Wav files, the more I realise that they're a bit of a time capsule. An echo of a 1991 IBM & Microsoft (and earlier).

    Behind the scenes they're actually a format called RIFF (Resource Interchange File Format). Basically tagged data chunks. So it can support most (all?) types of data. A container file format.

    What do you think AVI is behind the scenes? (RIFF), WebP, also RIFF (which was a surprise) and a bunch of others.

    The Wikipedia page states that RIFF was extended from IFF (Interchange File Format`). A brainchild of Electronic Arts and Commodore from 1985.

    Now knowing this, I can see how the design of PNG files were influenced from IFF. Same idea on tagged chunks, different ordering of elements and CRC addition. I did learn that it is noted in the 1.2 PNG spec § 12.4 Why-not-use-format-X.

    In parallel to all this, TIFF (Tagged Image File Format) has no relation to IFF.

    #FileFormats #History

  8. The more I read about Wav files, the more I realise that they're a bit of a time capsule. An echo of a 1991 IBM & Microsoft (and earlier).

    Behind the scenes they're actually a format called RIFF (Resource Interchange File Format). Basically tagged data chunks. So it can support most (all?) types of data. A container file format.

    What do you think AVI is behind the scenes? (RIFF), WebP, also RIFF (which was a surprise) and a bunch of others.

    The Wikipedia page states that RIFF was extended from IFF (Interchange File Format`). A brainchild of Electronic Arts and Commodore from 1985.

    Now knowing this, I can see how the design of PNG files were influenced from IFF. Same idea on tagged chunks, different ordering of elements and CRC addition. I did learn that it is noted in the 1.2 PNG spec § 12.4 Why-not-use-format-X.

    In parallel to all this, TIFF (Tagged Image File Format) has no relation to IFF.

    #FileFormats #History

  9. The more I read about Wav files, the more I realise that they're a bit of a time capsule. An echo of a 1991 IBM & Microsoft (and earlier).

    Behind the scenes they're actually a format called RIFF (Resource Interchange File Format). Basically tagged data chunks. So it can support most (all?) types of data. A container file format.

    What do you think AVI is behind the scenes? (RIFF), WebP, also RIFF (which was a surprise) and a bunch of others.

    The Wikipedia page states that RIFF was extended from IFF (Interchange File Format`). A brainchild of Electronic Arts and Commodore from 1985.

    Now knowing this, I can see how the design of PNG files were influenced from IFF. Same idea on tagged chunks, different ordering of elements and CRC addition. I did learn that it is noted in the 1.2 PNG spec § 12.4 Why-not-use-format-X.

    In parallel to all this, TIFF (Tagged Image File Format) has no relation to IFF.

    #FileFormats #History

  10. The more I read about Wav files, the more I realise that they're a bit of a time capsule. An echo of a 1991 IBM & Microsoft (and earlier).

    Behind the scenes they're actually a format called RIFF (Resource Interchange File Format). Basically tagged data chunks. So it can support most (all?) types of data. A container file format.

    What do you think AVI is behind the scenes? (RIFF), WebP, also RIFF (which was a surprise) and a bunch of others.

    The Wikipedia page states that RIFF was extended from IFF (Interchange File Format`). A brainchild of Electronic Arts and Commodore from 1985.

    Now knowing this, I can see how the design of PNG files were influenced from IFF. Same idea on tagged chunks, different ordering of elements and CRC addition. I did learn that it is noted in the 1.2 PNG spec § 12.4 Why-not-use-format-X.

    In parallel to all this, TIFF (Tagged Image File Format) has no relation to IFF.

    #FileFormats #History

  11. Search Engine Roundtable: Google Search Showing Fewer PDF Files. But Why?. “Google seems to be showing fewer and fewer PDF files, and when it does show PDF files, it seems not to show them from some pretty important sites, like IRS.gov, New York State, and some others. But in some cases we are seeing Google show PDF documents, without you having to explicitly filter for PDF file types.”

    https://rbfirehose.com/2026/08/29/search-engine-roundtable-google-search-showing-fewer-pdf-files-but-why/
  12. Search Engine Roundtable: Google Search Showing Fewer PDF Files. But Why?. “Google seems to be showing fewer and fewer PDF files, and when it does show PDF files, it seems not to show them from some pretty important sites, like IRS.gov, New York State, and some others. But in some cases we are seeing Google show PDF documents, without you having to explicitly filter for PDF file types.”

    https://rbfirehose.com/2026/08/29/search-engine-roundtable-google-search-showing-fewer-pdf-files-but-why/
  13. Search Engine Roundtable: Google Search Showing Fewer PDF Files. But Why?. “Google seems to be showing fewer and fewer PDF files, and when it does show PDF files, it seems not to show them from some pretty important sites, like IRS.gov, New York State, and some others. But in some cases we are seeing Google show PDF documents, without you having to explicitly filter for PDF file types.”

    https://rbfirehose.com/2026/08/29/search-engine-roundtable-google-search-showing-fewer-pdf-files-but-why/
  14. Search Engine Roundtable: Google Search Showing Fewer PDF Files. But Why?. “Google seems to be showing fewer and fewer PDF files, and when it does show PDF files, it seems not to show them from some pretty important sites, like IRS.gov, New York State, and some others. But in some cases we are seeing Google show PDF documents, without you having to explicitly filter for PDF file types.”

    https://rbfirehose.com/2026/08/29/search-engine-roundtable-google-search-showing-fewer-pdf-files-but-why/
  15. Search Engine Roundtable: Google Search Showing Fewer PDF Files. But Why?. “Google seems to be showing fewer and fewer PDF files, and when it does show PDF files, it seems not to show them from some pretty important sites, like IRS.gov, New York State, and some others. But in some cases we are seeing Google show PDF documents, without you having to explicitly filter for PDF file types.”

    https://rbfirehose.com/2026/08/29/search-engine-roundtable-google-search-showing-fewer-pdf-files-but-why/
  16. Tell me you work with obscure #fileformats without telling me you work with obscure unknown formats. #digipres #ai #fullcircle what is it called when AI references your own blog?

  17. Tell me you work with obscure #fileformats without telling me you work with obscure unknown formats. #digipres #ai #fullcircle what is it called when AI references your own blog?

  18. Tell me you work with obscure #fileformats without telling me you work with obscure unknown formats. #digipres #ai #fullcircle what is it called when AI references your own blog?

  19. Tell me you work with obscure #fileformats without telling me you work with obscure unknown formats. #digipres #ai #fullcircle what is it called when AI references your own blog?

  20. Tell me you work with obscure #fileformats without telling me you work with obscure unknown formats. #digipres #ai #fullcircle what is it called when AI references your own blog?

  21. Declarative all the way down: Building PRONOM signatures with JSONID

    by @beet_keeper

    PRONOM signatures are a form of declarative language, you describe the anticipated behavior in PRONOM’s regular expression syntax and tools like DROID, FIDO, and Siegfried will interpret those instructions and attempt to match them against different files to return a file format identification.

    Normally, you will write PRONOM signatures by hand but doing so for file formats based on other file format building blocks can lead to inconsistencies. Bertrand Caron previously also recognized this in the XML formats that are described with PRONOM signatures on Wikidata.

    XML can use single quotes ' (hex: 0x27) and double quotes " (hex: 0x22) for attribute data, and so, do we make a PRONOM signature with multiple sequences anticipating the use of either?

    The answer is more often than not likely to be yes, because the appearance of these values are often helpful for identifying boundaries for strings that we know must exist.

    But the more file formats that we need to add to PRONOM that are based on foundational formats like XML, or JSON, or similar, the more inconsistencies will creep in, such as sequences that are looking specifically for one byte sequence over another.

    The issue extends further if file formats allow data to appear at the beginning of file, or we need to account for a variable amount of white-space, or we want to start thinking about multi-byte character encoding.

    We can, and in the XML issue described by myself and Caron, I think the recommendation is very much to create editorial standards for signatures for file formats based on other baseline, structured data formats like XML, JSON, YAML, and so on.

    And standards are well and good, but what if tooling could help us?

    For JSON this is exactly what I have tried to do in JSONID.

    What does this feature look like? And what does it get us? Let’s take a look.

    Continue reading “Declarative all the way down: Building PRONOM signatures with JSONID”


    #declarativeProgramming #digipres #DigitalPreservation #DROID #FIDO #FileFormatIdentification #FileFormats #JSON #jsonid #JSONL #NTTW #NTTW9 #PRONOM #RDM #ResearchData #siegfried #StructuredData #structuredText #TOML #YAML
  22. Declarative all the way down: Building PRONOM signatures with JSONID

    by @beet_keeper

    PRONOM signatures are a form of declarative language, you describe the anticipated behavior in PRONOM’s regular expression syntax and tools like DROID, FIDO, and Siegfried will interpret those instructions and attempt to match them against different files to return a file format identification.

    Normally, you will write PRONOM signatures by hand but doing so for file formats based on other file format building blocks can lead to inconsistencies. Bertrand Caron previously also recognized this in the XML formats that are described with PRONOM signatures on Wikidata.

    XML can use single quotes ‘ (hex: 0x27) and double quotes ” (hex: 0x22) for attribute data, and so, do we make a PRONOM signature with multiple sequences anticipating the use of either?

    The answer is more often than not likely to be yes, because the appearance of these values are often helpful for identifying boundaries for strings that we know must exist.

    But the more file formats that we need to add to PRONOM that are based on foundational formats like XML, or JSON, or similar, the more inconsistencies will creep in, such as sequences that are looking specifically for one byte sequence over another.

    The issue extends further if file formats allow data to appear at the beginning of file, or we need to account for a variable amount of white-space, or we want to start thinking about multi-byte character encoding.

    We can, and in the XML issue described by myself and Caron, I think the recommendation is very much to create editorial standards for signatures for file formats based on other baseline, structured data formats like XML, JSON, YAML, and so on.

    And standards are well and good, but what if tooling could help us?

    For JSON this is exactly what I have tried to do in JSONID.

    What does this feature look like? And what does it get us? Let’s take a look.


    #declarativeProgramming #digipres #DigitalPreservation #DROID #FIDO #FileFormatIdentification #FileFormats #JSON #jsonid #JSONL #NTTW #NTTW9 #PRONOM #RDM #ResearchData #siegfried #StructuredData #structuredText #TOML #YAML
  23. Declarative all the way down: Building PRONOM signatures with JSONID

    by @beet_keeper

    PRONOM signatures are a form of declarative language, you describe the anticipated behavior in PRONOM’s regular expression syntax and tools like DROID, FIDO, and Siegfried will interpret those instructions and attempt to match them against different files to return a file format identification.

    Normally, you will write PRONOM signatures by hand but doing so for file formats based on other file format building blocks can lead to inconsistencies. Bertrand Caron previously also recognized this in the XML formats that are described with PRONOM signatures on Wikidata.

    XML can use single quotes ‘ (hex: 0x27) and double quotes ” (hex: 0x22) for attribute data, and so, do we make a PRONOM signature with multiple sequences anticipating the use of either?

    The answer is more often than not likely to be yes, because the appearance of these values are often helpful for identifying boundaries for strings that we know must exist.

    But the more file formats that we need to add to PRONOM that are based on foundational formats like XML, or JSON, or similar, the more inconsistencies will creep in, such as sequences that are looking specifically for one byte sequence over another.

    The issue extends further if file formats allow data to appear at the beginning of file, or we need to account for a variable amount of white-space, or we want to start thinking about multi-byte character encoding.

    We can, and in the XML issue described by myself and Caron, I think the recommendation is very much to create editorial standards for signatures for file formats based on other baseline, structured data formats like XML, JSON, YAML, and so on.

    And standards are well and good, but what if tooling could help us?

    For JSON this is exactly what I have tried to do in JSONID.

    What does this feature look like? And what does it get us? Let’s take a look.


    #declarativeProgramming #digipres #DigitalPreservation #DROID #FIDO #FileFormatIdentification #FileFormats #JSON #jsonid #JSONL #NTTW #NTTW9 #PRONOM #RDM #ResearchData #siegfried #StructuredData #structuredText #TOML #YAML
  24. Declarative all the way down: Building PRONOM signatures with JSONID

    by @beet_keeper

    PRONOM signatures are a form of declarative language, you describe the anticipated behavior in PRONOM’s regular expression syntax and tools like DROID, FIDO, and Siegfried will interpret those instructions and attempt to match them against different files to return a file format identification.

    Normally, you will write PRONOM signatures by hand but doing so for file formats based on other file format building blocks can lead to inconsistencies. Bertrand Caron previously also recognized this in the XML formats that are described with PRONOM signatures on Wikidata.

    XML can use single quotes ‘ (hex: 0x27) and double quotes ” (hex: 0x22) for attribute data, and so, do we make a PRONOM signature with multiple sequences anticipating the use of either?

    The answer is more often than not likely to be yes, because the appearance of these values are often helpful for identifying boundaries for strings that we know must exist.

    But the more file formats that we need to add to PRONOM that are based on foundational formats like XML, or JSON, or similar, the more inconsistencies will creep in, such as sequences that are looking specifically for one byte sequence over another.

    The issue extends further if file formats allow data to appear at the beginning of file, or we need to account for a variable amount of white-space, or we want to start thinking about multi-byte character encoding.

    We can, and in the XML issue described by myself and Caron, I think the recommendation is very much to create editorial standards for signatures for file formats based on other baseline, structured data formats like XML, JSON, YAML, and so on.

    And standards are well and good, but what if tooling could help us?

    For JSON this is exactly what I have tried to do in JSONID.

    What does this feature look like? And what does it get us? Let’s take a look.


    #declarativeProgramming #digipres #DigitalPreservation #DROID #FIDO #FileFormatIdentification #FileFormats #JSON #jsonid #JSONL #NTTW #NTTW9 #PRONOM #RDM #ResearchData #siegfried #StructuredData #structuredText #TOML #YAML
  25. Declarative all the way down: Building PRONOM signatures with JSONID

    by @beet_keeper

    PRONOM signatures are a form of declarative language, you describe the anticipated behavior in PRONOM’s regular expression syntax and tools like DROID, FIDO, and Siegfried will interpret those instructions and attempt to match them against different files to return a file format identification.

    Normally, you will write PRONOM signatures by hand but doing so for file formats based on other file format building blocks can lead to inconsistencies. Bertrand Caron previously also recognized this in the XML formats that are described with PRONOM signatures on Wikidata.

    XML can use single quotes ‘ (hex: 0x27) and double quotes ” (hex: 0x22) for attribute data, and so, do we make a PRONOM signature with multiple sequences anticipating the use of either?

    The answer is more often than not likely to be yes, because the appearance of these values are often helpful for identifying boundaries for strings that we know must exist.

    But the more file formats that we need to add to PRONOM that are based on foundational formats like XML, or JSON, or similar, the more inconsistencies will creep in, such as sequences that are looking specifically for one byte sequence over another.

    The issue extends further if file formats allow data to appear at the beginning of file, or we need to account for a variable amount of white-space, or we want to start thinking about multi-byte character encoding.

    We can, and in the XML issue described by myself and Caron, I think the recommendation is very much to create editorial standards for signatures for file formats based on other baseline, structured data formats like XML, JSON, YAML, and so on.

    And standards are well and good, but what if tooling could help us?

    For JSON this is exactly what I have tried to do in JSONID.

    What does this feature look like? And what does it get us? Let’s take a look.


    #declarativeProgramming #digipres #DigitalPreservation #DROID #FIDO #FileFormatIdentification #FileFormats #JSON #jsonid #JSONL #NTTW #NTTW9 #PRONOM #RDM #ResearchData #siegfried #StructuredData #structuredText #TOML #YAML
  26. I almost cancelled my Adobe subscription last year - then realised I couldn't.
    Software like Adobe's isn't just selling tools, it's locking you in. The real cost isn't the subscription. It's that your work - effects, libraries, templates built over years - lives in proprietary formats. Cancel, and you lose access to your own assets.
    It's not about price. It's about owning the way you work.
    Ever been locked out of an old project?
    #todormotion #DreamDesignDeliver #fileformats #Adobe

  27. I almost cancelled my Adobe subscription last year - then realised I couldn't.
    Software like Adobe's isn't just selling tools, it's locking you in. The real cost isn't the subscription. It's that your work - effects, libraries, templates built over years - lives in proprietary formats. Cancel, and you lose access to your own assets.
    It's not about price. It's about owning the way you work.
    Ever been locked out of an old project?
    #todormotion #DreamDesignDeliver #fileformats #Adobe

  28. I almost cancelled my Adobe subscription last year - then realised I couldn't.
    Software like Adobe's isn't just selling tools, it's locking you in. The real cost isn't the subscription. It's that your work - effects, libraries, templates built over years - lives in proprietary formats. Cancel, and you lose access to your own assets.
    It's not about price. It's about owning the way you work.
    Ever been locked out of an old project?
    #todormotion #DreamDesignDeliver #fileformats #Adobe

  29. I almost cancelled my Adobe subscription last year - then realised I couldn't.
    Software like Adobe's isn't just selling tools, it's locking you in. The real cost isn't the subscription. It's that your work - effects, libraries, templates built over years - lives in proprietary formats. Cancel, and you lose access to your own assets.
    It's not about price. It's about owning the way you work.
    Ever been locked out of an old project?
    #todormotion #DreamDesignDeliver #fileformats #Adobe

  30. I almost cancelled my Adobe subscription last year - then realised I couldn't.
    Software like Adobe's isn't just selling tools, it's locking you in. The real cost isn't the subscription. It's that your work - effects, libraries, templates built over years - lives in proprietary formats. Cancel, and you lose access to your own assets.
    It's not about price. It's about owning the way you work.
    Ever been locked out of an old project?
    #todormotion #DreamDesignDeliver #fileformats #Adobe

  31. I'd sell my soul to have bundled html + css + images + assets in a zipped format.

    Basically, modern web - all of javascript. Instead of using PDFs.

    That'd be a banger way to create and distribute documents. Also very versatile and portable, cuz, like, websites lol. Prove me wrong.

    EDIT: I reinvented sophisticated epubs. Wow.

    #pdf #pdfs #html #css #document #fileformatwars #fileformats #fileformat #epub #epubs

  32. I'd sell my soul to have bundled html + css + images + assets in a zipped format.

    Basically, modern web - all of javascript. Instead of using PDFs.

    That'd be a banger way to create and distribute documents. Also very versatile and portable, cuz, like, websites lol. Prove me wrong.

    EDIT: I reinvented sophisticated epubs. Wow.

    #pdf #pdfs #html #css #document #fileformatwars #fileformats #fileformat #epub #epubs

  33. I'd sell my soul to have bundled html + css + images + assets in a zipped format.

    Basically, modern web - all of javascript. Instead of using PDFs.

    That'd be a banger way to create and distribute documents. Also very versatile and portable, cuz, like, websites lol. Prove me wrong.

    EDIT: I reinvented sophisticated epubs. Wow.

    #pdf #pdfs #html #css #document #fileformatwars #fileformats #fileformat #epub #epubs

  34. I'd sell my soul to have bundled html + css + images + assets in a zipped format.

    Basically, modern web - all of javascript. Instead of using PDFs.

    That'd be a banger way to create and distribute documents. Also very versatile and portable, cuz, like, websites lol. Prove me wrong.

    EDIT: I reinvented sophisticated epubs. Wow.

    #pdf #pdfs #html #css #document #fileformatwars #fileformats #fileformat #epub #epubs

  35. Maintenance begins at creation, so why are we not creating better?

    by @beet_keeper

    The beats are the same. You work for government, or academia (lets face it, that’s probably where 90% of the work is) you have a deliverable; you save it; you print to PDF; you store it on an institutional repository with some metadata (or Zenodo, OSF or equivalent) and its done.

    There’s a small chance that it’s FAIR (Findable, Accessible, Interoperable, Reusable) right? It has metadata that can be discovered by an audience looking for it and can be indexed by search engines. The data is potentially accessible if published correctly. They’re not particularly interoperable or easily converted, and PDFs aren’t really designed for reuse, even if tools like Apache Tika help ease the burden of extracting artifacts. It’s just a PDF, why are we even talking about FAIR? There begins a story…

    The beats are the same, yet, we work in digital preservation, our backgrounds are in GLAM or software, why do we want to shoot ourselves in the foot? Why are we not using our skills to create better?

    Continue reading “Maintenance begins at creation, so why are we not creating better?”


    #Archives #BetterPoster #ContinuumModel #createToMaintain #digipres #DigitalArchiving #DigitalContunuity #digitalLiteracy #DigitalPreservation #FAIR #FileFormats #GLAM #informationRecordsMangagement #NationalDigitalStewardshipAlliance #NDSA #OpenAccess #OpenData #PDF #RDM #ResearchDataLifecycle #RIM
  36. Maintenance begins at creation, so why are we not creating better?

    by @beet_keeper

    The beats are the same. You work for government, or academia (lets face it, that’s probably where 90% of the work is) you have a deliverable; you save it; you print to PDF; you store it on an institutional repository with some metadata (or Zenodo, OSF or equivalent) and its done.

    There’s a small chance that it’s FAIR (Findable, Accessible, Interoperable, Reusable) right? It has metadata that can be discovered by an audience looking for it and can be indexed by search engines. The data is potentially accessible if published correctly. They’re not particularly interoperable or easily converted, and PDFs aren’t really designed for reuse, even if tools like Apache Tika help ease the burden of extracting artifacts. It’s just a PDF, why are we even talking about FAIR? There begins a story…

    The beats are the same, yet, we work in digital preservation, our backgrounds are in GLAM or software, why do we want to shoot ourselves in the foot? Why are we not using our skills to create better?


    #Archives #BetterPoster #ContinuumModel #createToMaintain #digipres #DigitalArchiving #DigitalContunuity #digitalLiteracy #DigitalPreservation #FAIR #FileFormats #GLAM #informationRecordsMangagement #NationalDigitalStewardshipAlliance #NDSA #OpenAccess #OpenData #PDF #RDM #ResearchDataLifecycle #RIM
  37. Maintenance begins at creation, so why are we not creating better?

    by @beet_keeper

    The beats are the same. You work for government, or academia (lets face it, that’s probably where 90% of the work is) you have a deliverable; you save it; you print to PDF; you store it on an institutional repository with some metadata (or Zenodo, OSF or equivalent) and its done.

    There’s a small chance that it’s FAIR (Findable, Accessible, Interoperable, Reusable) right? It has metadata that can be discovered by an audience looking for it and can be indexed by search engines. The data is potentially accessible if published correctly. They’re not particularly interoperable or easily converted, and PDFs aren’t really designed for reuse, even if tools like Apache Tika help ease the burden of extracting artifacts. It’s just a PDF, why are we even talking about FAIR? There begins a story…

    The beats are the same, yet, we work in digital preservation, our backgrounds are in GLAM or software, why do we want to shoot ourselves in the foot? Why are we not using our skills to create better?


    #Archives #ContinuumModel #createToMaintain #digipres #DigitalArchiving #DigitalContunuity #digitalLiteracy #DigitalPreservation #FAIR #FileFormats #GLAM #informationRecordsMangagement #NationalDigitalStewardshipAlliance #NDSA #OpenData #PDF #RDM #ResearchDataLifecycle #RIM
  38. Maintenance begins at creation, so why are we not creating better?

    by @beet_keeper

    The beats are the same. You work for government, or academia (lets face it, that’s probably where 90% of the work is) you have a deliverable; you save it; you print to PDF; you store it on an institutional repository with some metadata (or Zenodo, OSF or equivalent) and its done.

    There’s a small chance that it’s FAIR (Findable, Accessible, Interoperable, Reusable) right? It has metadata that can be discovered by an audience looking for it and can be indexed by search engines. The data is potentially accessible if published correctly. They’re not particularly interoperable or easily converted, and PDFs aren’t really designed for reuse, even if tools like Apache Tika help ease the burden of extracting artifacts. It’s just a PDF, why are we even talking about FAIR? There begins a story…

    The beats are the same, yet, we work in digital preservation, our backgrounds are in GLAM or software, why do we want to shoot ourselves in the foot? Why are we not using our skills to create better?


    #Archives #ContinuumModel #createToMaintain #digipres #DigitalArchiving #DigitalContunuity #digitalLiteracy #DigitalPreservation #FAIR #FileFormats #GLAM #informationRecordsMangagement #NationalDigitalStewardshipAlliance #NDSA #OpenData #PDF #RDM #ResearchDataLifecycle #RIM
  39. Maintenance begins at creation, so why are we not creating better?

    by @beet_keeper

    The beats are the same. You work for government, or academia (lets face it, that’s probably where 90% of the work is) you have a deliverable; you save it; you print to PDF; you store it on an institutional repository with some metadata (or Zenodo, OSF or equivalent) and its done.

    There’s a small chance that it’s FAIR (Findable, Accessible, Interoperable, Reusable) right? It has metadata that can be discovered by an audience looking for it and can be indexed by search engines. The data is potentially accessible if published correctly. They’re not particularly interoperable or easily converted, and PDFs aren’t really designed for reuse, even if tools like Apache Tika help ease the burden of extracting artifacts. It’s just a PDF, why are we even talking about FAIR? There begins a story…

    The beats are the same, yet, we work in digital preservation, our backgrounds are in GLAM or software, why do we want to shoot ourselves in the foot? Why are we not using our skills to create better?


    #Archives #BetterPoster #ContinuumModel #createToMaintain #digipres #DigitalArchiving #DigitalContunuity #digitalLiteracy #DigitalPreservation #FAIR #FileFormats #GLAM #informationRecordsMangagement #NationalDigitalStewardshipAlliance #NDSA #OpenAccess #OpenData #PDF #RDM #ResearchDataLifecycle #RIM