Hi again Ruud,
Answers below, which I hope will help ...
With thanks, Neil
-----Original Message----- From: Ruud Altenburg [mailto:ruud@eti.uva.nl] Sent: 19 April 2007 09:43 To: Neil Thomson Subject: More questions and remarks on NCD
Hallo Neil,
here are some remarks on the NCD standard, some with respect to the current NLBIF database:
1. RecordType: this item is non-relevant for a database I assume, as it is always "actual". Possibly it is actual when returning XML from a query on the database through a wrapper. Should this be included in the database?
## NHT: I would say that it should be included in the database, but defaulted to "actual". This allows the possibility that records generated as the result of a database query can be added to the database, but flagged as "derived". This was felt to be important to prevent an over-inflated estimation of the number of collections in an organisation.
---------- 2. More or less the same applies to Agents. My idea is that this is filled in once when setting up the database and that this is returned only when the database is accessed externally. But as apparently more than one agent with one or more roles can be responsible for a single record, so possibly this solution is incomplete. However, many changes have to be made to the current database to implement agents to a record level. E.g. consider that a collection is appended to an organisation that has previously been created by another agent.
## NHT: You are right that someone entering new records should only need to record their details once for the session. The agents section of the NCD Header (which is based on the METS header) is intended to record metadata about the record itself, rather than the collection that the record describes. The date of record creation should default to "today" and be fixed. However, an agent can come along later and amend the record, maybe adding to it or correcting it. In this case the role of the person is "editor". Appending a collection to an existing organisation record should not affect the organisation record, since the relationship is established simply by recording the organisation ID in the collection record. Nothing is added to or changed in the organisation record.
---------- 3. Shouldn't PostalAddressText and PhysicalAddressText each have an independent zipcode and town? In reverse, is it necessary to use language attributes to towns and regions? We have stored this data in a non-language-dependent field.
## NHT: Not sure about this one - are there cases where an organisation has a postal address in a different town from the organisation? This may be solved, as the annotation text suggests, by having the complete address text in the postal element. The ZIP code and town are intended for your wizzy Google Maps link and for folk to determine what collections they may visit in a particular area. So if we are agreed that only one of these is required, the documentation will need to make it clear that the ZIP code and Town refer the to actual organisation, rather than its postbox. While we are on the topic, does anyone have a preference for "organisation" over "institution", or does it not matter?
---------- 4. For the metadatabase I have used a slightly different schema that should be compatible with how things are implemented in the NCD. This is -- if I understand correctly what Source and IDinSource mean. I suppose these are 'links' to a different 'table' in which to look up the keyword? Some keywords can be entered by typing, others will need to be selected from a popup list I assume. We have taken those lists from the NoDIT database and I have translated the terms into Dutch for specific use for the NLBIF metadatabase. This is something to consider when setting up the NCD database. Also what exactly does the Strength attribute for most keywords stand for?
## NHT: These are intended to allow folk to enter terms from a published source, such as a thesaurus and to then be able to find the exact term in that source. So the attributes will point to external resources. An example would be the term "Amsterdam" for geoegraphical coverage. Someone could enter this as an Alexandria Digital Library Gazetteer (ADLG) reference as Source=ADLG IDinSOurce=adlgaz-1-3081051-64. Anyone could then later find out which Amsterdam (plus lots of details) from the ADLG by entering the that number into the "identification code" box at: http://webclient.alexandria.ucsb.edu/client/gaz/adl/index.jsp
The strength attribute is simply a flag that can be attached to a specific keyword (or keywords) to indicate that the collection is particularly strong in that aspect. For example a collection of butterflies from all over "Africa" (no flag), but particularly from Zaire (flag).
----------- 5. The following fields also require a Language attribute I think? CollectionFocus, CollectionPurpose, SubUnitName.
## NHT: Oops, yes - one for the next version.
Hope this helps, Neil
Regards,
Ruud