Richard,

I agree that this is a useful (and hopefully not too boring!) dialogue.

Let me hurl a few softballs back, and please, do understand that I agree
fundamentally with what you are saying. As they say, "the devil is in the
details".

I truly believe this is a "crisis" for small archives, as the lack of
funding means that structured metadata gets pushed to the back of the bus
(or worse, OFF the bus).

My further comments below.

--
John Spencer
http://www.bridgemediasolutions.com/

>
> Hello, John,
>
> I think we have a really great dialogue going on here. I will elaborate on
> the points, below.
>
> At 12:40 PM 3/23/2005, John Spencer wrote:
>> Also, we've built these tools for our internal use, it's
>> certainly not that hard.
>
> Right, but I think Scott addressed that and what we're trying to do here.
> Mounting heads and aligning tape machines isn't that hard for me, but lots
> of people don't do it themselves. Writing the software would be harder for me.

Understood and agreed. We have a number of data projects underway where the
archive is doing the "real work" (the actual transfers) and we're helping
out with the IT issues.
>
>>> I think the initial programming project was to provide a manual interface
>>> to the BWF metadata chunk, so that presented with a BWF file, the operator
>>> could read and modify the metadata.
>>
>> How do you control the operator's authority to modify? Should it be
>> controlled? Will certain DAW applications overwrite the existing metadata
>> when the file is opened?
>
> I think these tools are intended for smaller archives and people like me.
> Larger operations will require you to use the rigorous tools that they
> develop internally or purchase with rights management.

Here I must disagree. If I were to share my collection of files with
another institution (small or large), I would have a problem if all present
metadata were modifiable. DRM or not, the core information should not be
easily changeable.
>
>>> It was my suggestion to add the import/export utility and to make it easily
>>> accessible by standard Microsoft/Open Office tools.
>>
>> Agreed. I think that is why you see a large "dose" of XML baked into the
>> latest Office flavors.
>
> That is true--I haven't worked with that part of the latest Office all that
> much.
>
>
>>> I do think that there is a place for this. If entity A provides a bunch of
>>> BWF files to entity B, they could stand on their own w/o having the
>>> separate metadata files.
>>
>> If entity A has 500GB of files and entity B would like to research them,
>> wouldn't a 500K database be an easier start?
>
> That wasn't what I meant. Entity A (me) transfers files for Entity B (Sound
> Archive of Nowhere in Particular). I submit these files with
> author/title/whatever metadata in them. It's all tied together. The SA of
> NiP then ingests the files (essence and metadata) into their digital
> storage system.
>
> The Sound Archive of Nowhere in Particular can also send some of these
> files off to the Aboriginal Cultural Heritage Centre of Nowhere in
> Particular without having to extract pieces of a database, etc.

This is another area of concern for me. How can we assume that SANiP has
their metadata fields laid out in the same manner as ACHCN (Aboriginal
Cultural Heritage Centre of Nowhere in Particular)? Sounds like there might
be some re-keying (or re-mapping, or crosswalks) of data, which is not my
favorite scenario. The more times we re-type the same information, the
greater chance for error. Are we talking about MARC records, DC metadata,
etc.? The use of XML should remove many of these obstacles, but the same
cannot be said for those using Excel 95 to collect metadata!

I do agree that some metadata should reside in the header, as you could
always open the file up in hexadecimal and read it. At our office, we call
this "catastrophic metadata" (or "CYA" metadata). However, I'm somewhat
unsure of your meaning of "tied together". Are you referring to
1) a wrapper that can be opened automatically (like MXF), or
2) the metadata and audio files reside on the same physical carrier, or
3) all of the metadata would be in the BWF header?

Also, I was under the impression that many smaller archives don't have
"digital storage systems", hence the transitional migration to Gold CD-R (as
evidenced by various discussions on this list).
>
>>> Also, putting metadata into the BWF on the data tape or storage system is
>>> the perfect long-term backup to the main data store. I did not see this as
>>> a search tool, but as part of an archive strategy and an interchange
>> strategy.
>>
>> Agreed. I was merely pointing out that if you have many data tapes, it is a
>> logistical nightmare to try and reload those tapes to update (1) common
>> field across all of the audio files.
>
> Totally agreed. I see the type of metadata in the BWF file as more
> static/historic. The dynamic data--which, presumably, would be more
> specialized to your collection would live in your database only and not be
> written to the metadata chunk of the BWF files.
>
>
> Richard L. Hess email: [log in to unmask]
> Vignettes
> Media web: http://www.richardhess.com/tape/
> Aurora, Ontario, Canada (905) 713 6733 1-877-TAPE-FIX
>