Merrilee
---------- Forwarded message ----------
Date: Mon, 30 Nov 1998 18:28:42 -0800
From: John Hassan <jhassan@library.berkeley.edu>
To: Merrilee Proffitt <mproffit@library.berkeley.edu>,
MOA2 Workgroup <moa2wg@library.berkeley.edu>
Subject: Re: Re[4]: Scriptorium (fwd)
Thanks for the comments. I have inserted my reponses after each question.
At 11:20 AM 11/30/1998 -0800, Merrilee Proffitt wrote:
>
>Yeay!
>
>--m
>
>---------- Forwarded message ----------
>Date: Mon, 30 Nov 1998 10:51:16 -0500
>From: rdecandido <rdecandido@nypl.org>
>To: Merrilee Proffitt <mproffit@library.berkeley.edu>
>Cc: pellis <pellis@nypl.org>, atroncale <atroncale@nypl.org>,
> hkordish <hkordish@nypl.org>, jgatewood <jgatewood@nypl.org>
>Subject: Re[4]: Scriptorium
>
> Merrilee,
> Attached is a copy of the database with one of the objects entered.
> It's the Jackson Mammoth prints of Colorado and Wyoming. Object 67.
> There are 14 subojects. We also have a bunch of questions and
> comments. But first let me say that all of you have done a terrific
> job making a complex and difficult process relatively easy. What
> follows is meant consturctively and not as whiny and complaining as it
> may sound.
>
> 1. Is there a way of making two different sets of defaults for the
> same object type? It seems likely that there would be more than one
> type of album or one type of diary that would require different
> defaults. Is there a way of doing that or would we have to make
> differently named object types like "photoalbum", "clippingalbum",
> etc.
Response: Sure, just define a different object type for each set of
defaults, as you propose. You could even do something generic like album1,
album2, ..., but more mnemonic names are better.
>
> 2. Master NetLoc is a mandatory field but we will not be putting the
> masters online. We put in a phony URL to work around but this needs a
> better resolution.
Response: I suspect that most people won't have their masters on line, but
we didn't want to preclude it for those who do, so we are applying the same
standard to them as we do to transcripts and derivatives. Besides the DTD
calls for it. As you can see we have gone to some lengths to insure that
the addresses of files are rigorously managed, so that the corresponding
links in the resulting XML documents are well-formed and more reliable. The
data in the links may not be accurate ( there may not be a file at such an
address), but it won't be accidentally inaccurate (as from miskeying), and
the extraction and tools programs won't blow up for lack of valid data. A
dummy URL is how we do it.
>
> 3. Filenames assigned by the program are nothing like what we are
> using. This brings up a major difficulty in workflow. We will almost
> certainly be doing the capture before the database creation. One of
> our capture systems automatically names files--a great time saver.
> Though it is somewhat flexible I don't believe we can make turn out
> the kind of filenames the database is creating. We wouldn't even if it
> could since we have created a filenaming convention that is quite
> different from the one you've built into the db. Can the db be
> modified to create the kind of filenames we want?
Response: This is something that we can probably do, if there is demand
enough , but not until after the new year. Can you (all of you) describe to
us your naming conventions, so we know how broadly we have to think about
this? Of course, this is primarily an issue in batch mode. Right now you
can still key your own file names over those that the system generates for
you.
>
> 4. I don't understand how to make the database create more than one
> derivative with different defaults. We generally create at least 2,
> sometimes 3 or 4 derivatives for use online and in-house. I assume
> others do also. I think I just haven't figured out how to do this.
Response: Derivative Version code is the answer. By changing the Version
code in defaults or in the forms, you change the file name by one or more
characters. The version code is injected into the filename after the
SObjID, and before the suffix. So you might have a group of derivatives for
subobject 12345 like
nypl00012345a.gif --thumbnail
nypl00012345b.jpg --low res
nypl00012345c.jpg --med res
nypl00012345d.jpg --high res
|
<version> .
This insures that a group of derivatives can be correlated with a given
subobject, while each derivative has a unique file name.
That said, there are a couple of real big best practices problems here. How
do you name them, so that the program that packs all this stuff up in an
XML document knows what to do with them, and what standard is required to
insure that our tools can view your images, and vice versa? I suspect that
Jerry and Rick may want to add more here, and that these will be issues
that will have to be sorted out by the community down the road.
>
> 5. Batch adding children is great. We need a similar function to batch
> add images. I don't doubt you guys can cook up a way to do that.
Response: This has been done since the release you were looking at.
>
> 6. PPI on images taken with a camera requires a calculation which we
> don't bother to do. Leaving it empty gives a zero ppi which is
> incorrect.
Response: True, but i don't see a way around it. We took it out as a
required field because we knew that it couldn't always be counted on to be
available. It should be up to the code that displays or uses this data in
the tools to do something smart if the field is zero.
>
> 7. I found the Subobject Form rather confusing. At the top of the form
> the OwnersItemID refers to the object but the Source, right next to it
> refers to the Subobject. I wasn't sure what was being referred to
> where. In the subform the value in the Level box refers not to the
> contents of the subform but to the Object/Subobject above the rest of
> the subform. It took me a while to figure that one out. The fact that
> all the child subobjects appeared but none of their derivatives also
> confused me. It took me a while to figure out that I had to descend a
> level to see them. The pop up notes that are on most buttons are very
> helpful and they would be very helpful on the tabs for these subforms.
Response: Thanks for this. It's been a struggle to make it clear what's
happening in this form.
Everything you see there is from the point of view of one subobject. That
is true of the OwnersItemID too.
This field should contain the archivist's identifier for a particular item
(subobject) within an object, as for a photograph on a page, or an article
on a page. The ObjectIdentier on the Object Form refers to the whole object.
Re the Level Box, i wasn't sure whether that would enlighten or confuse.
Looks like the verdict is in. It was useful to me during testing, but now
it looks like it should go.
re the child subobjects, derivatives, etc., i understand and hope that with
some familiarity you will be comfortable with the notion that everything is
seen from the point of view of a single subobject, as i said above. The
Navigation tab reveals the children of the subobject, and the other 3 tabs
reveal the masters, derivatives, and transcripts for that same subobject
(not for the children subobjects).
>
>
> We will be working on the Stanton Field notes next--we've already
> created the object for it in the db I'm sending you.
>
> bob
>
>
>______________________________ Reply Separator
_________________________________
>Subject: Re: Re[2]: Scriptorium
>Author: Merrilee Proffitt <mproffit@library.berkeley.edu> at Internet
>Date: 11/24/98 2:57 PM
>
>
>Bob and Tony,
>
>Anything to report? We'd like to have a look at your database as well.
>
>Merrilee
>
>On Mon, 23 Nov 1998, rdecandido wrote:
>
>> Merrilee,
>> We'll try for tomorrow.
>>
>> bob
>>
>>
>> ______________________________ Reply Separator
>_________________________________
>> Subject: Re: Scriptorium
>> Author: Merrilee Proffitt <mproffit@library.berkeley.edu> at Internet
>> Date: 11/23/98 10:55 AM
>>
>>
>> Bob,
>>
>> If you and Tony could do this by today or tomorrow, that would be
>> fabulous.
>>
>> Merrilee
>>
>> On Mon, 23 Nov 1998, rdecandido wrote:
>>
>> > Merrilee,
>> > We're in the process of inputting some MOA2 records--the ones for
the
>> > Jackson photographs. It shouldn't take long--there are only about
13
>> > of them. Then we'll (Tony Troncale and I) will sit down and
gather our
>> > comments for you.
>> >
>> > bob
>> >
>> >
>> >
>> > ______________________________ Reply Separator
>> _________________________________
>> > Subject: Re: Digital Scriptorium
>> > Author: Merrilee Proffitt <mproffit@library.berkeley.edu> at Internet
>> > Date: 11/23/98 9:32 AM
>> >
>> >
>> > Melanie,
>> >
>> > I will send the database and some documentation later this afternoon.
>> >
>> > In the meantime, can you give me an update as to where NYPL is with the
>> > database analysis?
>> >
>> > Thanks,
>> >
>> > Merrilee
>> >
>> >
>>
>>
>
>
>Attachment Converted: "D:\My Documents\Attachments\moa2b2.mdb"
>