Closed mjordan closed 10 years ago
Wouldn't that duplicate the efforts that Islandora FITS already does with the technical metadata tab?
Or, are you suggesting that we use the FITS to PREMIS xsl that ships in extras.zip, and include that in the xml and html renders we provide?
It would duplicate the display produced by Islandora FITS within the context of Islandora, but I'm thinking about the usefulness of having FITS data in PREMIS for applications outside of Islandora, such as downstream digital preservation platforms like Archivematica. Other applications that might consume our PREMIS (e.g., target migration platforms, digital preservation stacks like Archivematica, submission to TDRs, etc.) won't likely know anything about the FITS datastream as a separate file.
We don't need to render it as HTML just because it's in the PREMIS XML.
Using fits_to_premis_object.xsl seems a bit complicated if it is valid it just stuff the entire FITS XML into an extension. However, it is written in XSLT version 1 so at least it is possible for standard PHP to process it, if we choose to use it. Since it's released under the LGPL it's also compatible with the license on our module.
but I'm thinking about the usefulness of having FITS data in PREMIS for applications outside of Islandora, such as downstream digital preservation platforms like Archivematica.
:+1:
But! FITS is an actual datastream for a given object if it is enabled. So, I would presume it would go along with any object we export from Islandora for consumption to another platform. Or, maybe I'm just confused. Are we not supposed to have FITS as a separate datastream? Is it supposed to be wrapped up in PREMIS?
We don't need to render it as HTML just because it's in the PREMIS XML.
:+1:
I'll need to take a closer look at fits_to_premis_object.xsl
. Hopefully in the next day or so. I still owe @dmoses feedback on our preservation documentation work :wink:
Does the BagIt module include derived datastreams like PREMIS ? If so then embedding the TECHMD in PREMIS would work. Otherwise how do we feed a 'virtual' PREMIS ds into the object on export ? If we aren't displaying it, then I'm not sure what we're gaining? Additional mapping to PREMIS from the TECHMD do would be good.
But! FITS is an actual datastream for a given object if it is enabled. So, I would presume it would go along with any object we export from Islandora for consumption to another platform.
Whether or not the FITS datastream would go along with the object it describes depends on how the object and its datastreams are exported. Assuming the FITS datastream is exported, the consuming application needs to know where to look for it. The benefit of including it in premis:objectCharacteristicsExtension is that it will be easier for a wider range of consuming applications to know where to look for FITS data without doing any extra work.
Are we not supposed to have FITS as a separate datastream? Is it supposed to be wrapped up in PREMIS?
There's no reason we can't have both as long as we don't bombard end users with all the raw data. Whether we wrap it in PREMIS is up to us is up to us!
Does the BagIt module include derived datastreams like PREMIS?
For the BagIt module, PREMIS is not considered a datastream, but it does include a plugin to generate the PREMIS XML to include in the Bag. This plugin calls the same function in the PREMIS module that is used to generate PREMIS on demand for display and download.
If we aren't displaying it, then I'm not sure what we're gaining?
Other applications may want to use it. They should only care about the XML, not how it's displayed to an end user of Islandora.
@dmoses further to what @mjordan's comments his BagIt module, this is what a given object looks for me in the data directory of a bag:
yul_74960
├── DC.xml
├── foxml.xml
├── JP2.jp2
├── JPG.jpg
├── MODS.xml
├── OBJ.tif
├── premis.xml
├── RELS-EXT.rdf
├── TECHMD_FITS.xml
└── TN.jpg
There's no reason we can't have both as long as we don't bombard end users with all the raw data. Whether we wrap it in PREMIS is up to us is up to us!
nods in agreement
The more I think about it, you're totally right. I was wrapped up in just Islandora and not thinking about pure export for just this module, I guess I really need to read up more on premis:objectCharacteristicsExtension
,
And! I finally talked to @sbmarks about our work here, and say's he'd be more than happy to review some of our issue queue questions and provide feedback where he can.
Awesome to getting @sbmarks perspective.
Also, we can write more plugins for Islandora BagIt if we're not happy with what it generates now.
@mjordan I'm really happy with what your module is generating now :smile:
:kiss:
You guys want me to cut a new branch and try to implement this? Basically if there is a FITS datastream (which is identified in variable_get('islandora_fits_techmd_dsid', 'TECHMD')
), slurp the whole thing into premis:objectCharacteristicsExtension?
If you're up for it, do it!
I've got this working in branch 'fits'. If there is FITS metadata, it now appears in a <objectCharacteristicsExtension>
element in the OBJ datastreams' <objectCharacteristics>
. FOXML and PREMIS both validate, and there is no effect on the human-readable HTML output as far as I can see.
Had to do some XML foo because of https://bugs.php.net/bug.php?id=64137 but it was a learning opportunity.
Nice! Do you have a sample you can share?
Also, your update pretty much coincided with the announcement of FITS 0.8!
https://gist.github.com/mjordan/8672407, see line 126.
Nice! Do we need to declare the FITS namespace in line 2 now?
I don't know, let me try not doing that and I'll report back.
Sorry, line 2 of what? I can't find a duplicate namespace declaration for FITS.
Oh, of your example file.
I meant, shouldn't we have a declaration there?
... actually, never mind. It is a valid xml file. @ruebot--
I think I misunderstood your question. We don't need to declare it at the top of the PREMIS file because it is declared with the first instance of the <fits>
element. I ran this PREMIS though xmllint and it validates.
Yep :-)
I did the same exact thing as I was typing out the comment.
Closed with commit b237433ac8d8a53135e70e14ad39d53d8ea2634a.
Should we include the FITS datastream, if it is available for an object, in a premis:objectCharacteristicsExtension wrapper (semantic unit 1.5.7)? If I recall correctly, the FITS datastream described the OBJ datastream.