Comments for mark e. phillips journal http://vphill.com/journal journal featuring photos, talk of work, travel and other things that this digital librarian does. Sun, 06 May 2012 20:50:32 +0000 hourly 1 http://wordpress.org/?v=3.3.2 Comment on Cleaning the pool. added to photodatabase by Carole Fischer http://vphill.com/journal/?p=3349&cpage=1#comment-247770 Carole Fischer Sun, 06 May 2012 20:50:32 +0000 #comment-247770 Hi, Bart and I were in Sedona April 22-29, 2012. I love the red rocks and the crystal blue sky above the high dessert. Hi,
Bart and I were in Sedona April 22-29, 2012. I love the red rocks and the crystal blue sky above the high dessert.

]]> Comment on same thing for unt.edu by Louis Vuitton clothing http://vphill.com/journal/?p=781&cpage=1#comment-247621 Louis Vuitton clothing Thu, 03 May 2012 02:36:03 +0000 http://vphill.com/journal/index.php/archives/2006/01/14/same-thing-for-untedu/#comment-247621 fifty-five series http://fashiononsale.jimdo.com/2012/05/01/these-kinds-of-beautifully-louis-vuitton-bags/Traveling can be enjoyable but also persistant fifty-five series http://fashiononsale.jimdo.com/2012/05/01/these-kinds-of-beautifully-louis-vuitton-bags/Traveling can be enjoyable but also persistant

]]> Comment on Aubrey: Our content delivery/metadata management system. by vphill http://vphill.com/journal/?p=2823&cpage=1#comment-231864 vphill Sat, 20 Nov 2010 23:09:10 +0000 http://vphill.com/journal/?p=2823#comment-231864 I guess when I say move I don't really mean move... I'm thinking more of "convert" especially when you get larger and larger collections of digital content, at some point it makes more sense to leave the content in place and build a delivery system on top of it instead of converting it into another slightly different format. As far as "moving" content we do in fact move content all the time. We have multiple copies of each object in the delivery application so that one storage node can go down and we can continue to serve content from another . This has been helpful in several situations. Sorry for the confusion. I guess when I say move I don’t really mean move…

I’m thinking more of “convert” especially when you get larger and larger collections of digital content, at some point it makes more sense to leave the content in place and build a delivery system on top of it instead of converting it into another slightly different format.

As far as “moving” content we do in fact move content all the time. We have multiple copies of each object in the delivery application so that one storage node can go down and we can continue to serve content from another . This has been helpful in several situations.

Sorry for the confusion.

]]> Comment on Aubrey: Our content delivery/metadata management system. by Natalie http://vphill.com/journal/?p=2823&cpage=1#comment-227092 Natalie Thu, 30 Sep 2010 18:11:48 +0000 http://vphill.com/journal/?p=2823#comment-227092 This looks really interesting. You said that you don't want to 'move' the digital objects. What will you do in case of hardware failure or warranty expiration? If some new repo suite comes out that makes Aubrey's job easier, would you consider moving your stuff? This looks really interesting. You said that you don’t want to ‘move’ the digital objects. What will you do in case of hardware failure or warranty expiration? If some new repo suite comes out that makes Aubrey’s job easier, would you consider moving your stuff?

]]> Comment on Aubrey: Our content delivery/metadata management system. by vphill http://vphill.com/journal/?p=2823&cpage=1#comment-225795 vphill Tue, 09 Mar 2010 17:33:22 +0000 http://vphill.com/journal/?p=2823#comment-225795 From the beginning of the project we knew we weren't going to be releasing the code for this one. Mainly because I know that we don't have the resources to support this sort of thing. I would however be interested in groups interested in hosting collections with our framework in our infrastructure. I haven't figured out much of the issues with that , but that's the model I think we would go for. From the beginning of the project we knew we weren’t going to be releasing the code for this one. Mainly because I know that we don’t have the resources to support this sort of thing. I would however be interested in groups interested in hosting collections with our framework in our infrastructure. I haven’t figured out much of the issues with that , but that’s the model I think we would go for.

]]> Comment on Aubrey: Our content delivery/metadata management system. by Mike G. http://vphill.com/journal/?p=2823&cpage=1#comment-225794 Mike G. Mon, 08 Mar 2010 14:20:09 +0000 http://vphill.com/journal/?p=2823#comment-225794 Great to read more about UNT's work, Mark. Out of curiosity, is Aubrey available under an open source license, or do you plan on making it available? Great to read more about UNT’s work, Mark. Out of curiosity, is Aubrey available under an open source license, or do you plan on making it available?

]]> Comment on How we use BagIt to ingest and store digital objects. by Brian Kennison http://vphill.com/journal/?p=2815&cpage=1#comment-225793 Brian Kennison Fri, 05 Mar 2010 19:06:54 +0000 http://vphill.com/journal/?p=2815#comment-225793 Thanks for the info! I've got some things in place but have a lot to do. I buy into the ideas expressed by the CDL of "permanent objects and disposable systems" and I've been trying to get a outline of what this repository system would look like. Your posts are most helpful. Thanks for the info! I’ve got some things in place but have a lot to do. I buy into the ideas expressed by the CDL of “permanent objects and disposable systems” and I’ve been trying to get a outline of what this repository system would look like. Your posts are most helpful.

]]> Comment on How we use BagIt to ingest and store digital objects. by vphill http://vphill.com/journal/?p=2815&cpage=1#comment-225792 vphill Fri, 05 Mar 2010 18:04:47 +0000 http://vphill.com/journal/?p=2815#comment-225792 Descriptive metadata is handled in our delivery platform, called Aubrey, I'll do a few posts about that in the near future. We version all metadata modifications to both the structure of the object (ordering of fileSets, adding labels to manifestations and fileSets, page numbers and such to a digital objects) as well as version all descriptive metadata edits. This is helpful to be able to roll back changes that shouldn't have been made as well as figuring out what happened if something that wasn't supposed to be shared publicly got shared. As we look at raising the quality of our metadata I think the ability to version all of it is one of the measures that plays into it. new ACPs can be run at anytime (for example if we decide to encode at a higher bitrate for video or audio, change sizes or just screw up on the delivery formats) by placing an AIP in the 3.ToACP folder in the desired dropbox and running the makeACP.py script again, it would then just overwrite the copy in aubrey (taking care not to write over the descriptive metadata , filenaming conventions help with this) Descriptive metadata is handled in our delivery platform, called Aubrey, I’ll do a few posts about that in the near future.

We version all metadata modifications to both the structure of the object (ordering of fileSets, adding labels to manifestations and fileSets, page numbers and such to a digital objects) as well as version all descriptive metadata edits. This is helpful to be able to roll back changes that shouldn’t have been made as well as figuring out what happened if something that wasn’t supposed to be shared publicly got shared. As we look at raising the quality of our metadata I think the ability to version all of it is one of the measures that plays into it.

new ACPs can be run at anytime (for example if we decide to encode at a higher bitrate for video or audio, change sizes or just screw up on the delivery formats) by placing an AIP in the 3.ToACP folder in the desired dropbox and running the makeACP.py script again, it would then just overwrite the copy in aubrey (taking care not to write over the descriptive metadata , filenaming conventions help with this)

]]> Comment on How we use BagIt to ingest and store digital objects. by Brian Kennison http://vphill.com/journal/?p=2815&cpage=1#comment-225791 Brian Kennison Fri, 05 Mar 2010 17:45:21 +0000 http://vphill.com/journal/?p=2815#comment-225791 Yes that helps. It expalains how the archive handles versions, essentially another manifestation). When a new version is ingested, I guess a new ACP is generated and overwrites the old ACP. Do you keep versions of the descriptive metadata if it changes? How/When are the different namespaces used? Yes that helps. It expalains how the archive handles versions, essentially another manifestation). When a new version is ingested, I guess a new ACP is generated and overwrites the old ACP. Do you keep versions of the descriptive metadata if it changes? How/When are the different namespaces used?

]]> Comment on How we use BagIt to ingest and store digital objects. by vphill http://vphill.com/journal/?p=2815&cpage=1#comment-225790 vphill Fri, 05 Mar 2010 16:45:57 +0000 http://vphill.com/journal/?p=2815#comment-225790 Yes the Trac wiki isn't very clear. We view coda (our digital archive thingy) as a write once system. If there are changes that need to happen to an object, it really depends on what the change is. Here are some changes that don't require re-ingest * descriptive metadata editing * re-ordering of fileSets (page in a book out of order) If there is a change to a file (someone misspelled their name on an ETD) or a missing page from a book, then the process is to grab the AIP from coda (it becomes a DIP at that point but the structure is the same), change what is needed and then load it back into the ingest system. We have one more dropbox which is a dropbox that doesn't assign a new identifier and is used for both legacy content ingest as well as adding new versions into the system. coda will just maintain two "versions" of this object if it is re-ingested. Does that help? Yes the Trac wiki isn’t very clear.

We view coda (our digital archive thingy) as a write once system. If there are changes that need to happen to an object, it really depends on what the change is. Here are some changes that don’t require re-ingest

* descriptive metadata editing
* re-ordering of fileSets (page in a book out of order)

If there is a change to a file (someone misspelled their name on an ETD) or a missing page from a book, then the process is to grab the AIP from coda (it becomes a DIP at that point but the structure is the same), change what is needed and then load it back into the ingest system. We have one more dropbox which is a dropbox that doesn’t assign a new identifier and is used for both legacy content ingest as well as adding new versions into the system. coda will just maintain two “versions” of this object if it is re-ingested.

Does that help?

]]>