[tdwg-ncd] RE: More questions and remarks on NCD

Neil Thomson N.Thomson at nhm.ac.uk
Fri Apr 20 12:54:32 CEST 2007

 Hi again Ruud,

Answers below, which I hope will help ...

With thanks,

-----Original Message-----
From: Ruud Altenburg [mailto:ruud at 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
  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
  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.
  could enter this as an Alexandria Digital Library Gazetteer (ADLG)
  as Source=ADLG IDinSOurce=adlgaz-1-3081051-64. Anyone could then later
  out which Amsterdam (plus lots of details) from the ADLG by entering
  that number into the "identification code" box at:

  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,



More information about the tdwg-content mailing list