[tdwg-ncd] RE: More questions and remarks on NCD
N.Thomson at nhm.ac.uk
Fri Apr 20 12:54:32 CEST 2007
Hi again Ruud,
Answers below, which I hope will help ...
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
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
## 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
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