1) Why can't we get the default settings to "stick"? We changed the name
from U.C. Berkeley to Penn State but every time we reopen the default or
open the objects screen, it defaults to U.C. Berkeley.
Response: See question 2.
2) When we fill in all the blanks in the default, they don't carry over to
the objects. Only the three required fields carry over.
Response: A bug was responsible for the problems cited in questions 1 & 2,
and has been fixed.
3) We tried two different approaches with the minutebooks: for sequences
1-5 we assumed when there was only one page for each date entry that it
stands alone; multiple pages became children (thus you'll see some entries
with page1 and page2 which are actually page 2 and 3 for that date. For
sequences 6-12, we assumed that every date would have a child page so each
child has a grandchild (page1, page2, page3 are really page 1, 2, and 3).
Less confusing for the scanning person, but much more work in typing.
Which procedure would others prefer?
Response: This sounds like a "best practices" issue. We'll be looking
closer at this next week, but input from the community would also be good.
4) We found that we need to enter data in sequence--very carefully. If we
need to go back and insert a child in #4 after entering data in #5, it
doesn't display following #4 when sorting by the path when we tried sorting
by the subobject ID number. Is there any way to go back and insert data
out of sequence and still have it sort correctly?
Response: There is a thorny little cluster of problems surrounding the path
string, sibling sequence, and sort sequences. As you know, the path
string for a given subobject is the concatenation of it's parent's path
string and it's own subobject type and sibling sequence number. Originally,
it was intended only as a descriptor of the location of that subobject in a
hierarchy of subobjects. It was not intended to be a sortkey, though for
small sets of siblings at a given level(fewer than 10) it looked like one,
and in some cases we tended to think of it as one. Then we complicated
things even more by allowing users to insert subobjects between other
subobjects by assigning fractional sibling sequence numbers. In the end it
turns out that there isn't a way create a path statement that can act as a
sortkey in this case, and still be a legible and easy to interpret
subobject descriptor. So we have improved on the version of the database
you have look at, but what we have come up with is a compromise of
legibility and space efficiency. And we don't sort on it by itself
anymore, as we did with some queries in the earlier version.
5) When we sort by the path, the numbering sequence is off--1, 11, 12, 13,
2, 21, 22, 3, etc.
Response: See above response.
6) Why doesn't the program know that at each level Source and Object ID are
inherited from the previous level and defaults?
Response: I'm not sure what you are getting at here. ObjectID in a
subobject is always inherited from its parent, and Source should not be,
since it it likely to differ between parent and child subobjects. Unlike
the version of the database you saw, the current version allows defaulting
the Source, though it's been renamed MatFmt (material format).
7) Do we really need to scan the back (verso) of a photo if it is blank?
Response: It's pretty much up to you, though in this case I don't think
there's much point. The only reasons for adding subobjects are a) to
define the structure of the object, and b) to identify elements that are
candidates for some kind of processing. You might create pages that are not
candidates for any kind of processing, but which are essential for laying
out the structure of the object, in that they act as parents (like pages)
of items that are candidates for processing (like photos). You could
define a photo as the parent of 2 sides, if you are going to process recto
and verso separately, or if not, you could skip defining 2 sides and just
process the photo subobject. There really isn't much point in creating a
subobject at the tip of a branch in the object hierarchy, if it isn't going
to get some kind of processing resulting in a digital file. Maybe there's a
best practices dimension to this question too.
8) If all the information is in the EAD finding aid, how much needs to
carry over into the database Title and description fields? Should it only
be enough for the scanning person to identify the object?
Response: Following the White Paper, we are assuming that the lion's share
of descriptive metadata is to be found in some source like an EAD finding
aid. The data recorded in the database is primarily concerned with defining
the structure of the objects, and describing the digital processing their
elements have gone through. However, as your question suggests, some
descriptive metadata is required to identify the objects and shepard their
parts though all this processing. Other data is required to allow the
database simply to function. And still other data is required to allow us
to bundle all the information up in well-formed moa2 XML documents. For
instance it's essential to have the location of the EAD finding aid that
contains all that descriptive metadata. This is why it's vital to establish
at least a minimal set of required fields, so that the database users will
know what to put in, in order to get something useable out the other end.
So the short answer is, if a field label in the database indicates that
data is required, put something in the field that makes sense. And as it
stands right now, it's only our notion of what's required, since we haven't
heard back from anyone on this topic.
9) There wasn't enough room in the object type field for a new default for
Minute books (we had to make it one word or settle for Minute boo).
Response: The field has been lengthened.
10) For diaries and minute books, where you have multiple pages for a
single date, or multiple dates on a single page, how are you setting up the
hierarchy?
Response: This is probably a best practices issue to be decided on by the
community. We've talked a lot about whether the hierarchies can or should
be physical, or logical. I think we agree that they can be either, but you
are flirting with trouble if you try to mix them. How you do this would
probably depend on the kind of processing you are doing. That said, here's
one possibility. You could define page subobjects, and then below them,
define the subobjects for the entries that start on those pages. Process
each entry separately, and do entry pagination in markup.