PRONOM’s dustiest records

Tyler’s recent blog post for the PRONOM Hack-a-thon Week 2024 (my previous for this week), brought up an interesting point about two of PRONOM’s oldest outline records, Real Video Clip (fmt/204) and Real Video (x-fmt/277). How did they end up in PRONOM?

NB. because of the complexity of this post, it may be easier to read in original blog form, than on Mastodon here: https://exponentialdecay.co.uk/blog/pronoms-dustiest-records/

Tyler suggests:

I assume PRONOM originally added these based on MIME types available.

I thought I knew the answer, and so it prompted a forensic look at the records to see if what I thought I knew aligned with reality!

As a PRONOM maintainer at The National Archives, UK from 2009-2012 I knew a little bit of the history of the system, we see some of that history impact us today, for example, when we look at the number of records that don’t have descriptions or file format signatures, 156 of those records are so-called x-PUIDs. A mechanism in PRONOM that was never meant to make it into the wild for working on file formats internally without polluting the public record. There are 455 x-PUIDs in total. They made it into the wild anyway (before my time) and so they exist as a symbol of PRONOM’s dustiest oldest records.

Even by the time I had started, PRONOM still had a lot of what we started to call outline records. One of the more positive changes we made to the process back in the day was that we would stop creating outline records; instead, we would focus on records that could be tied to signatures. This didn’t necessarily make the records more correctly aligned with reality, but it meant records had utility and file formats identified by DROID could be tied back to something that PRONOM “knew about”. I believe the process is a bit more flexible these days, allowing individuals to contribute information to records that tie them back to information like MIMEtypes and specifications. It’s clearer the format is “real” even if a signature is yet to be developed (and of course there are a large number of data formats that are hard to even represent in traditional PRONOM signatures any more and so they need a record, even if there isn’t a neat concept of a signature for them).

Okay old-man, but what about Tyler’s thesis?

Stellent and PRONOM

I learned sometime in my tenure at The National Archives that PRONOM had been seeded with a lot of the formats listed in a technology called OutsideIn previously owned by Stellent and now owned by Oracle.

Oracle OutsideInhttps://docs.oracle.com/outsidein/853/oit/OutsideIn (2010)https://web.archive.org/web/20101016164937/http://www.oracle.com/technetwork/middleware/content-management/oit-all-085236.htmlData sheet – Formats (2011)https://web.archive.org/web/20110125024733/http://www.oracle.com/technetwork/middleware/content-management/ds-oitfiles-133032.pdfCOPTR entryhttps://coptr.digipres.org/index.php/Oracle_Outside_In_Technology

I had always had a feeling that that the scope of this list was largely exaggerated by the company selling the software as it is a marketing tool; and if not exaggerated, perhaps, just not as clearly delineated by format than PRONOM, and rather, by Software, regardless of the properties of a given “format”, e.g. WinZip, and PKZip.

Back to the story though, I was also reasonably sure I would find Tyler’s RealVideo formats in the format listing but, I did not!

I downloaded a CSV summarizing the PRONOM records from api.pronom.ffdev.info with:

curl -X 'GET' \
 'https://api.pronom.ffdev.info/pronom_summary_csv' \
 -H 'accept: application/csv'

I filtered on outline entries and those without signatures only. I went through the entries still remaining and looked for name matches. I did find some name-for-name matches and some that were close, but no RealVideo or RealVideo Clip.

The matches:

7-bit ANSI Textyes7-bit ASCII Textyes8-bit ANSI Textyes8-bit ASCII TextyesEBCDIC-USyesFramework Database IIIyesIBM DisplayWrite Document 2yesIBM DisplayWrite Document 3yesMicrografx Designer 3.1yesNota Bene Text FileyesUnicode Text Fileyes

The maybes:

Cascading Style SheetmaybeFreelance File 1.0-2.1maybeMacPaint GraphicsmaybeMicrosoft Office Binder File for Windows 95maybeMicrosoft Works DatabasemaybeMicrosoft Works Database for DOS 2.0maybeMicrosoft Works Database for Windows 3.0maybeMicrosoft Works Database for Windows 4.0maybeProfessional Write Text FilemaybeWordPerfect for Windows Document 5.2maybeXYWrite DocumentmaybeXYWrite Document IIImaybeXYWrite Document III+maybe

11 exact matches! It’s hardly a headline!

I had hoped that if I found more exact matches it would provide some clues to where some of the older PRONOM entries came from. I expected most of the outline records to come from this list, alas, it isn’t nearly as many as anticipated.

I hoped too that going through the list I might get more clues as to formats that could potentially be deprecated in PRONOM.

As it stands, from the OutsideIn list, the only records I would personally recommend for deprecation are:

7-bit ANSI Text7-bit ASCII Text8-bit ANSI Text8-bit ASCII TextEBCDIC-USUnicode Text File

We know enough now to be almost certain that if something that looks like these files arrives in the archive it will present as a standard text file, and that we will need to rely on determining the character encoding using tools such as Richard Lehane’s characterize (see characterize’s README for more background). It is unlikely we will be able to attach a signature to these records, and we know there are a great deal more encodings in the world than need be represented as PRONOM identifiers.

NB. this might be something to formalize in a PRONOM decision making rubric, connected also, to formalizing approaches for XML based signatures.

A bit of a let down, or is it?

Still uncomfortable with so many outline records and little provenance for them, I wanted to find more information about the source of PRONOM data and so I decided to take a different path — I surfed the internet for answers!

Out of the list of outline records I found a few to be overly specific, or slightly weird, i.e. not really things we hear much about day-to-day, some examples:

ACBM GraphicsApple SoundAutoCAD Plot Configuration File 1.0-R13AutoCAD Plot Configuration File R14AutoSketch DrawingBtrieve Database 5.1CorelDraw PatternDEC Data Exchange FileDEC WPS Plus DocumentDr Halo BitmapGeneric Library FileHTML Extension FileHewlett Packard AdvanceWrite Text FileInkwriter/Notetaker TemplateInset Systems BitmapInstalit ScriptInterleaf DocumentMicrosoft Excel Add-InMicrosoft Excel ODBC QueryMicrosoft Excel ToolbarMicrosoft Powerpoint Design TemplateMicrosoft Print FileMicrostation CAD Drawing 95NAP MetafileNota Bene Text FileOS/2 Change Control FileRevit External GroupSAP DocumentSAS Data FileScanstudio 16-Colour BitmapSchedule+ ContactsSpeller Custom DictionaryUnisys (Sperry) System Data FileWordperfect Secondary File 5.0Wordperfect Secondary File 5.1/5.2form*Z Project File

ACBM graphics? Dr Halo Bitmap? Btrieve database, “5.1”? where are the other five?!!

It gave me pause. I didn’t believe these were all formats well-known to folks who created PRONOM, and I know we didn’t have such an advanced digital transfer program at the time that meant agencies were submitting huge variations of formats to PRONOM for future preservation.

I felt they had to come from somewhere, but where?

Enter Filext.com

Because these formats were very specific I found listings on the internet that I knew had to be part of the story. I had immediate luck just looking for combinations of these names, e.g. ACBM Graphics + NAP Metafile.

In particular I found listings on different websites from hobbyists or universities that all looked the same or similar, e.g.

• https://www.oocities.org/iannaccif/extention.htm
• https://tecfa.unige.ch/guides/fileextensions.htm

There were definite matches with PRONOM which we will get to, but I started to wonder about the provenance of these extensions.

I kept looking and I found one clue, a header and footer of a file that looked like those above and read as follows:

Copyright © 2002 Computer KnowledgeAll Rights ReservedThis download for personal use only. Do NOT distributeit to others either alone or incorporated into anysoftware without prior permission from Computer Knowledge.Developers who wish to incorporate portions of the listplease see the comments at the end of this file.

Developer permissions....This total file may not be included in any other software orproject which presents the data to the public or portions ofthe public. Any developer who wishes to include up to (butnot more than) 2,000 individual entries from this file is freeto do so provided certain conditions are met. These are:.  1) Credit must be given to FILExt. If links are available  in the developed product then one must also be provided to  FILExt as http://filext.com..  Suggested text: "File extension list courtesy of FILExt.  For a more extensive list visit http://filext.com.".  2) Once the extensions are chosen for one product by any  developer then these same extensions must continue to be  used by that developer for any other projects (i.e., you  cannot take one set of 2,000 for one project and a different  set of 2,000 for another project; it's a total of 2,000)..  3) If links are available in the developed product then any  links appearing associated with any of the 2,000 picked  extensions must be included in the product. (This covers  future plans to include such links in this list.).When the project is complete please notify FILExt with thespecifics at feedback@filext.com. We're always interestedin how the list is being used. Thank you.

Filext.com!

And so I asked myself, how long had filext been around?

As it turns out, quite a while! It was forked from a site called cknow around 2002. cknow.com was registered around 1996 and filext.com registered in 2001.

The first appearance of cknow in the internet archive is late 1996: https://web.archive.org/web/19961219035827/http://www.cknow.com/ and Filext early 2001: https://web.archive.org/web/20010522235126/http://www.filext.com/

The sites were founded by Tom Simondi. It looks like he has been responsible for a lot of the 90s and 00s work around demystifying extensions and getting more information to folk about what to do with them.

Could it be the source of the first PRONOM records?

Comparing some of the many other text-based lists I had found with cknow and filext gave me some confidence that there was some shared heritage with the them, and so I asked, could the cknow and filext lists have also seeded PRONOM?

I picked a list close to 2002 (cknow Extensions: 2000) when PRONOM was first started and began to compare entries for exact matches.

ACBM GraphicsyesAutoCAD Compiled MenuyesAutoSketch DrawingyesBtrieve Database 5.1yesDataFlex Query Tag NameyesDeluxe Paint bitmapyesDesignCAD DrawingyesDigital VideoyesDr Halo BitmapyesFrame Vector MetafileyesFramework Database IIyesFramework Database IIIyesFramework Database IVyesInformation or Setup FileyesInset Systems BitmapyesInterBase DatabaseyesLotus Approach View FileyesMathematica NotebookyesMicrosoft Excel Add-InyesMicrosoft Excel ODBC QueryyesMicrosoft Excel OLAP QueryyesMicrosoft Excel OLE DB QueryyesMicrosoft Excel Web QueryyesMicrosoft FoxPro LibraryyesMicrosoft Outlook Address BookyesMicrosoft PowerPoint Graphics FileyesMicrosoft Powerpoint Add-InyesMicrosoft Visual FoxPro TableyesMicrosoft Works DatabaseyesMicrosoft Works DocumentyesMicrostation CAD Drawing 95yesNAP MetafileyesNota Bene Text FileyesOS/2 Change Control FileyesPICS AnimationyesPageMaker Document 3.0yesPageMaker Time Stamp File 4.0yesProfessional Write Text FileyesQuicken Data FileyesRealVideo Clip <– cc. Tyler!yesSchedule+ ContactsyesStatGraphics Data FileyesStructured Query Language DatayesVentura Publisher Vector GraphicsyesXYWrite Document IIIyesXYWrite Document IVyes

46 matches!

Apple SoundmaybeAutoCAD Device-Independent Binary Plotter FilemaybeAutoCAD Drawing TemplatemaybeCascading Style SheetmaybeDEC Data Exchange FilemaybeDEC WPS Plus DocumentmaybeFreelance File 1.0-2.1maybeJava Servlet PagemaybeMicrografx Designer 3.1maybeMicrosoft Office Binder File for Windows 95maybeMicrosoft Office Binder Template for Windows 95maybeMicrosoft Office Binder Template for Windows 97-2003maybeMicrosoft Office Binder Wizard for Windows 95maybeMicrosoft Office Binder Wizard for Windows 97-2003maybeVentura PublishermaybeXYWrite DocumentmaybeXYWrite Document III+maybe

17 maybes!

What did we answer?

Okay, 46 exact matches does not the full listing make (although many (now) full-entries may still have been made from these early listings). Filext may have been an important resource for the first PRONOM records, but it’s also likely that PRONOM had other sources of information. For example, for a number of the Microsoft formats with outline records read like export or save-as listings in previous versions of Microsoft software. E.g. Excel:

NB. I wasn’t actively researching this side of things writing this blog, but I can already see some commonalities, especially Unicode Text!

I know we also had a copy of the Dr Dobb’s Essential Books on File Formats CD-ROM in the archive, and so that may also have been an important resource when PRONOM was creating its first records.

I count only two overlaps with the Stellent list, Framework Database III and Nota Bene Text File.

We did, however, find the RealVideo Clip! And I think we found some decent correlation with a resource that looks likely to have been used partially to populate the PRONOM database.

The era of file extensions

• Throughout my research, I found a lot of similar websites. Filext seems to go furthest back and has the greater pedigree, but in the noughties a lot of other sites seemed to appear to try and provide similar information to internet users, a few of note that seemed comprehensive and particularly well presented:

• Endungen.de (Internet Archive circa. 2002) https://web.archive.org/web/20020603193356/http://www.endungen.de/index.php?changelanguage=049
• Dotwhat.net (Internet Archive circa. 2005): https://web.archive.org/web/20050615021635/http://www.dotwhat.net/
• File-extension.net (Internet Archive circa. 2007): https://web.archive.org/web/20070521093707/https://file-extension.net/
• Filesuffix.com (Internet Archive circa. 2006): https://web.archive.org/web/20060615083930/http://www.filesuffix.com/browse/browse-1.html
• Filext backup: https://www.fileext.com/

I am sure we looked at these sites during my time on PRONOM, although with less frequency given the need to reduce outline records and increase the number with actionable information.

NB. I also  learned that TrID has been around since 2003! https://web.archive.org/web/20030612031252/http://mark0.ngi.it:80/

Provenance and prior art

It’s not entirely productive to say I wish we had better provenance for PRONOM records back in the day – but I do!

It makes me reflect on the importance of looking outside of our own walls in digital preservation instead of the constant redundancy of reinvention or ownership.

Often as academics, or those with archival views of the world, we can provide a polish and precision to technology as it exists to make it more usable in an archival context.

But cknow has been around so long, and the Unix utility File was created in 1986.

There’s a parallel history here that we should be recognizing and sharing for our next colleagues.

I arrived at TNA in 2009 and learned about File maybe two years later. As a Windows guy at the time, that might not be uncommon, but I do feel it is on me to have known more. I also think it should have been trivial to access the provenance around some of the records in the database at the time, but more than that – as a field, shouldn’t we all know Tom Simondi? What if the same academic rigour of PRONOM and DROID could have been applied to existing tools like File? What if we had expanded our bubble and recognized digital preservation (or the tools for it) is something people have been doing in all but name for the longest time? What if the people working in parallel on these projects and websites were part of the digital preservation inner-circle community today?

I don’t have answers, but I feel there are lessons there for the future. Not reinventing or rebuilding without good reason is important, but even if we build something new and we have been inspired by something else, continuing to recognize and acknowledge prior art is important.

What do you think?

Also, how do we get these people into a room and celebrate their work, and learn more!

What next?

I don’t think I got very far here but I found it interesting, and I hope other readers may as well.

This is meant to be a PRONOM hack-a-thon blog and I don’t know if I have pushed the sticks forward that much but maybe there’s a bit more to reason about in the outline records, for example, around the plain-text formats mentioned above and a few more identified along the way.

7-bit ANSI Textx-fmt/21Recommend deprecation7-bit ASCII Textx-fmt/22Recommend deprecation8-bit ANSI Textx-fmt/282Recommend deprecation8-bit ASCII Textx-fmt/283Recommend deprecationUnicode Text Filex-fmt/16Recommend deprecationEBCDIC-USfmt/159Recommend deprecationMS-DOS Text File with line breaksx-fmt/130Recommend deprecation

I noticed in the outline entries some low-hanging fruit that I might focus on next opportunity if someone else doesn’t get there first, these would be:

Cascading Style Sheetx-fmt/224Consider adding CSS to the record nameA signature should be feasibleDocument Type Definitionx-fmt/315Consider adding DTD to the record nameA signature should be feasibleExtensible Stylesheet Languagex-fmt/281Consider adding XSL to the record nameA signature should be feasibleHTML Extension Filex-fmt/417Related to Microsoft’s ISS serverA signature may be possibleStandard Generalized Markup Languagex-fmt/195Consider adding SGML to the record nameA signature may be possibleStill Picture Interchange File Format 2.0fmt/113Related to JPEGA signature should be possibleStructured Query Language Datafmt/206Consider adding SQL to the record nameA signature may be possibleDreamweaver Lock Filefmt/335A system file, there may be an entry in the NSRL databaseA signature may be possible

A little more on the history of extensions websites

The complete filext text file (allext.zip)

It took a few jumps, but I found the complete downloadable text file from Filext.com. I don’t think it exists any more and I don’t think the internet archive managed to grab a copy. Apparently it was quite a chunk of data to download on the web once upon a time, but they eventually found a way to release a zipped text file:

Via one jump we get to the “whole list” page:

https://web.archive.org/web/20020605164206/http://filext.com/wholelist.htm

And then to confirm our absolute interest in downloading it, we get to the a2z file:

https://web.archive.org/web/20020606071418/http://filext.com/a2z.htm

Which would have taken us to the zip file, alas, never captured on the Internet Archive anyway, maybe it is on other Memento compatible servers:

https://web.archive.org/web/20060117000000*/http://www.filext.com:80/allext.zip

Keeping filext up to date

Filext still asks for registry data to help keep it up to date. That’s pretty cool!

https://filext.com/faq/gather_data_for_filext.html

1 │ Echo OFF
2 │ CLS
3 │ assoc > filext_submission_output.txt
4 │ Echo ---------- >> filext_submission_output.txt
5 │ ftype >> filext_submission_output.txt
6 │ Echo Thank you. The output file has been created and
7 │ Echo named filext_submission_output.txt and it should
8 │ Echo be in the same place where you saved this batch
9 │ Echo file. All that is left now is to send that file
10 │ Echo to FILExt. Attach it to an E-mail sent to the
11 │ Echo address: filetype@filext.com
12 │ Echo The E-mail subject should be: Submission
13 │ Echo Thank you.
14 │ Pause
15 │ Exit

Filext as a source of learning

The filext faqs and community seemed particularly helpful and interesting back in the day:

https://web.archive.org/web/20090322040812/http://filext.com/faq/

File extension aggregator

The file-extension.net website started an aggregator project around 2007 and it’s still running today!

http://file-extension.net/seeker/

Some bonus images…

As I was working on this, I found irony in Google Sheets glitching, I managed to grab some screenshots along the way. Thanks for reading everyone!

Wikidata is a good service, Wikibase (on which Wikidata is built) is a better platform.

I have spoken before about its potential to be added into the file-format registry ecosystem in a federated model.

If we are to use it as a registry that can perhaps complement the pipelines going into PRONOM, e.g. in vendor’s digital preservation platforms such as the Rosetta Format Library, a Wikidata should be able to output different serializations of signature file for tools such as Siegfried, DROID or FIDO.

• Siegfried : https://github.com/richardlehane/siegfried/wiki/Wikidata-identifier
• Fido : I’ll need to revisit this!

And what about DROID?

Conversion to DROID

It’s not straightforward to say to a Wikibase/Wikidata Query Service, “output XML in the shape of a DROID signature file”, but it is straightforward to write a converter script.

I had this very thought last week while presenting with colleagues at a File Format Workshop at iPRES in Ghent.

It dawned on me that the conversion script would actually be simple thanks to a change in format to DROID whereby it can process all its own signatures, where previously it required DROID to pre-process them. It’s a long story, a more simple rendition is that DROID no longer requires DROID byte-code to record information about an identification pattern, and can instead store signatures in the attribute of a byte sequence element as-is, i.e. a PRONOM formatted regular expression from PRONOM itself, or Wikidata.

This realization resulted in my writing a conversion script (it took just over a half-day) during some down-time on the train home this past weekend.

The script is called wddroidy (after WD-40 ) and can be found here.

Results

We can see using the skeleton suite from Richard Lehane’s Builder that we can positively identify files using the new signature file.

Links can also be made to work with Wikidata identifiers by modifying the PUID URL pattern in the DROID configuration, e.g. to:

http://wikidata.org/entity/%s

The screenshot below shows where in the dialog that setting is:

Reference signature file

A reference signature file can be found in the wddroidy repository here. There are approximately 8119 file formats listed and 8195 file format signatures for those.

NB. We know there are different issues with Wikidata including how to identify a “format” and the quality of the signatures. We capture some of these in a global repository: https://github.com/ffdev-info/wikidp-issues/issues

DROID simplified format

The real headline here might be how easy it was to create the output using the DROID simplified format.

I have spoken about it briefly before but not in any detail.

In-short DROID no longer uses its own byte-code encoding that included strange terms such as DefaultShift, Shift Byte, and SubSequence (instructions to DROID about how to perform Boyer Moore Horspool search). See below and note especially how the bytes are split in Shift Byte attributes and elements:

<?xml version="1.0" encoding="UTF-8"?><FFSignatureFile xmlns="http://www.nationalarchives.gov.uk/pronom/SignatureFile" Version="1" DateCreated="2024-09-23T18:16:09+00:00">  <InternalSignatureCollection>    <InternalSignature ID="1" Specificity="Specific">      <ByteSequence Reference="BOFoffset">        <SubSequence MinFragLength="0" Position="1" SubSeqMaxOffset="0" SubSeqMinOffset="0">          <Sequence>255044462D312E34</Sequence>          <DefaultShift>9</DefaultShift>          <Shift Byte="25">8</Shift>          <Shift Byte="50">7</Shift>          <Shift Byte="44">6</Shift>          <Shift Byte="46">5</Shift>          <Shift Byte="2D">4</Shift>          <Shift Byte="31">3</Shift>          <Shift Byte="2E">2</Shift>          <Shift Byte="34">1</Shift>        </SubSequence>      </ByteSequence>    </InternalSignature>  </InternalSignatureCollection>  <FileFormatCollection>    <FileFormat ID="1" Name="Development Signature" PUID="dev/1" Version="1.0" MIMEType="application/octet-stream">      <InternalSignatureID>1</InternalSignatureID>      <Extension>ext</Extension>    </FileFormat>  </FileFormatCollection></FFSignatureFile>

The updated format was made possible via Matt Palmer via his ByteSeek work, and can now except a regularly encoded PRONOM formatted regular expression (regex) in an attribute in the ByteSequence element. See here for a signature file equivalent to the above:

<?xml version="1.0" encoding="UTF-8"?><FFSignatureFile      xmlns="http://www.nationalarchives.gov.uk/pronom/SignatureFile" Version="1" DateCreated="2024-09-23T18:16:09+00:00">  <InternalSignatureCollection>    <InternalSignature ID="1" Specificity="Specific">      <ByteSequence Reference="BOFoffset" Sequence="255044462D312E34" Offset="0" />    </InternalSignature>  </InternalSignatureCollection>  <FileFormatCollection>    <FileFormat ID="1" Name="Development Signature" PUID="dev/1" Version="1.0" MIMEType="application/octet-stream">      <InternalSignatureID>1</InternalSignatureID>      <Extension>ext</Extension>    </FileFormat>  </FileFormatCollection></FFSignatureFile>

The format is much easier to read, and after a bit of time sitting with the DROID signature file format you realize it is fairly easy to output as well. I use some very rudimentary templates in wddroidy using  Python’s f-strings.

It means other sources of PRONOM encoded signatures can output much simpler signature files and they can be used by DROID. I myself need to add it to the signature development utility – this would allow the utility to run standalone on anyone’s PC.

One next step for this approach might be to confirm that it does work entirely as expected by extracting all of PRONOM’s signatures proper and performing a mapping to the simplified format – if we can match against all the skeleton files in the latest Builder release then we should be looking good!

Priorities

I am always reminded, but always forget about priorities! This is part of how DROID resolves a file format into a single identifier, e.g. where SVG can match XML, we often want the more specific format returned, and so a priority is used to prioritize that one over the other, resulting in a single unambiguous identification for the DROID user. It manifests in the signature file as:

<FileFormat ID="634" MIMEType="image/svg+xml" Name="Scalable Vector Graphics"PUID="fmt/91"Version="1.0">   <InternalSignatureID>24</InternalSignatureID>   <Extension>svg</Extension>   <HasPriorityOverFileFormatID>638</HasPriorityOverFileFormatID> </FileFormat> More work needs to be done with Wikidata to understand if priorities can be properly applied to a DROID signature file. They are not written into the reference signature file above.

Using the results

Using the results can be done for two things:

1. (Probably) There are a greater number of patterns in the Wikidata output than in PRONOM. If you have a file that remains unidentified, you can try the reference file for clues as to what it may be. I’d only use caution and investigate the exact byte sequence used for a match and understand its properties. I’d also check that the mapping also looks accurate, I’ve tried one or two runs using the identifier and it looks good, but there may still be mistakes.
2. For improving the quality of the sources in Wikidata. As you can see from the Skeleton suite there are a lot of gaps. We a) have a rough idea what these are, and b) know the identification doesn’t work via Wikidata. Why is that? Is the signature in Wikidata simply not good enough? Are patterns missing? Is there another error or issue we can help with given our expertise in file format identification?

Hacking wddroidy

You can hack wddroidy. Currently it allows you to limit the number of results returned, and also modify the ISO language code used by the tool. You can see this in the command line arguments:

python wddroidy.py --helpusage: wddroidy [-h] [--definitions DEFINITIONS] [--wdqs] [--lang LANG] [--limit LIMIT] [--output OUTPUT] [--output-date] [--endpoint ENDPOINT]create a DROID compatible signature file from Wikidataoptions: -h, --help show this help message and exit --definitions DEFINITIONS   use a local definitions file, e.g. from Siegfried --wdqs, -w live results from Wikidata --lang LANG, -l LANG change Wikidata language results --limit LIMIT, -n LIMIT   limit the number of resukts --output OUTPUT, -o OUTPUT   filename to output to --output-date, -t output a default file with the current timestamp --endpoint ENDPOINT, -url ENDPOINT   url of the WDQSfor more information visit https://github.com/ross-spencer/wddroidy

The actual SPARQL query used can be manually edited in the src folder. E.g. you can limit the query by format or family or classification. I provide some more inspiration in the Siegfried Wiki.

Let me know if it’s useful!

This is really just a quick hack and it needs a lot more testing to improve the quality of the output. Most can be dealt with on the Wikidata side I am sure, but some might need to be done in the tool. If it’s useful, reach out, and let’s discuss what can be changed or how it can be used in your work.

Data quality

It will quickly become apparent the data quality isn’t what it is with PRONOM and that is why a curated and authoritative service such as PRONOM is always going to be needed. As mentioned in previous talks, this can in theory be complemented with downstream data in federated databases. This might mean curating Wikidata better using some of the tools available, or curating data into a Wikibase (the platfom Wikidata is built upon). Both options bring different benefits and advantages such as creating a bigger tent of signature developers on Wikidata, or, another example, more expressive signatures being made available via federated Wikibases.

And a word on Wikiba.se

A reminder too, that setting up a Wikibase can take some effort (I was once running three at the same time ) but a service called https://wikiba.se/ exists. wikiba.se could form an excellent scratch pad to begin thinking about mapping PRONOM like data to a Wikibase and also begin solving some of the other issues around mapping container signatures and outputting those in a way that is compatible for DROID. Let me know if you give it a whirl, or want to collab on any of that.

Otherwise, thanks in advance! And enjoy wddroidy!

https://exponentialdecay.co.uk/blog/making-droid-work-with-wikidata/