- tdwg-content - lists.tdwg.org

[taxon-model] Re: Owl polymorphism
by Markus Döring 11 May '07

11 May '07

Roger, this was not targeted directly at TDM. I was mainly exploring OWL and definitely not suggesting multiple inheritance! But in regards to TDM I was thinking about the consequences of allowing any defined term as a "controlled" value for InfoItems.hasValue. Is this desired? Having individual classes for the InfoItem categories now would allow us to define a specific controlled vocabulary for each category - or None if we dont think this is a good idea. These vocabularies, like CyclicityTerm, can easily be extended by anyone who really needs to. And all InfoItems are allowed to contain uncontrolled values via the hasContent property in any case. -- Markus On 11.05.2007, at 11:30, Roger Hyam wrote: > > Hi Markus, > > Sounds like interesting and complex stuff and exactly what I am > trying to avoid ;) > > If this is for exchange standards we want to keep things as simple > as possible. We also need our ontology to entail as little as > possible so people can understand it and (if they are up on the > technology) import it into their own business ontologies. > > The role of the exchange ontology is to denote the meaning of > simple fields it is not to enable connotations but to avoid them. > > This is why I was sticking to simple properties with domains and > ranges. Really just one up from RDFS. If it is important for a > consumer to assert a hierarchy of properties then they can do that > in their own ontology and import it. Who is to say that all > consumers will have the same notion of that hierarchy and what is > the business case for trying to impose one at this point? > > If there were polymorphism of properties (overriding them in sub > classes) then it would get confusing because of the multiple > inheritance. I am not sure what would happen to meaning with the > diamond problem - where the same property is inherited via several > routes but has it's meaning changed differently on each route. It > is always possible to subclass the property though and it may be > possible to forbid the use of the parent property in a class - > perhaps - but this is getting beyond my reading level. > > Not sure if this helps, > > All the best, > > Roger > > > > > On 11 May 2007, at 09:54, Markus Döring wrote: > >> Roger, >> is it possible with OWL to have polymorph class properties? >> As properties are global and only bound to classes via range/ >> domain it doesnt seem to be possible to me, but maybe Im wrong. >> Can I redefine a propertys range depending upon the class it >> belongs to, so its domain? Well, that would mean to declare the >> same property twice with different domains and ranges. Probably >> impossible. It is different from classic OO thinking... >> -- >> Markus >> >> >> >

1 0

[taxon-model] Taxon Data Model wiki updated
by Eamonn O Tuama 09 May '07

09 May '07

I have updated the Taxon Data Model wiki at http://wiki.tdwg.org/TaxonModel. The species model workshop presentations and report are now available there. Feel free to edit and add your own content. Best regards, Éamonn

1 0

[Biogeosdi] itineraries in openmodeller
by Meganck Bart 03 May '07

03 May '07

Hi Tim, I have been thinking about how to make the "itinerary" project a use-case for our GeoAppInter workflow. It's clear that until now I've been working a bit too enclosed - so the Campinas workshop was an eye-opener. In fact the itinerary implementation would not be that different from the demo we did. It's just another way of looking at the modeling part. For that I have some questions about OpenModeler : * how easy or how difficult is it to make your own algorithms for OM ? In what language do they have to be implemented ? * could OM take in data layers other than environmental data ? best regards, Bart. -- Bart Meganck, ICT & GIS engineer, African Zoology Department. Royal Museum for Central Africa, Leuvensesteenweg 13, B-3080 Tervuren, Belgium. Tel : +32(0)2 769 56 92 Fax : +32(0)2 767 02 42 Email : bart.meganck(a)africamuseum.be Website : www.africamuseum.be ########################################### This message has been scanned by ICT - Africa Museum ________________________________________ 3/5/2007 - Filtered through antispam by ICT

2 1

[tdwg-ncd] Preview NLBIF metadatabase
by Ruud Altenburg 01 May '07

01 May '07

Hallo all, at ETI there have been (or still are) problems with the mail server, so some email to or from me may have bounced last week. I would like to announce that a demonstration of the metadatabase developed for NLBIF is available for preview. I had already put up a version last week but that suffered from migration problems. The preview now should work as advertised. If not, please let me know and I'll look at it ASAP. Please note that not all fields catered for in the NCD standard are included. In fact quite many are missing, as they were considered not necessary for this specific project. The interface still is rudimentary. http://www.nlbif.nl/ncd-preview/ Best regards, Ruud Altenburg

1 0

[Biogeosdi] Re: question WFS/WMS layer occurrences search
by Javier de la Torre 28 Apr '07

28 Apr '07

Hi Bart, Lets start using our mailing list to talk about these topics ok? > Now, I think that the occurence service stores a WFS layer (e.g. the > Cocos_nucif_28977530 layer) the moment you do the search, so I just > need > to know : > > * is this done automatically for each and every search ? In GBIF, > in WFS > and in TAPIR ? Yes they are. > > * how do I get the name of this layer in OccurencesDisplay.php - short > of doing a GetCapabilities and parsing the whole XML ? > Uhmmm...no, in the XML report you get after fetching the data it is included the name of the layer that has been registered in the WFS server. Look at the contents of a report to grab it. Cheers.

1 0

[tdwg-ncd] NCD - new version v0.51
by Neil Thomson 24 Apr '07

24 Apr '07

Dear All, A new version of NCD is attached and will be placed on the wiki and in rs.tdwg.org/ncd/dev There are no major changes, but some much-needed tidying up. I am grateful to Markus for making the following changes: - all attribute names start with lower character - all xs:anySimpleType data types have been replaced with xs:string, xs:positiveInteger or xs:language where appropriate - missing types have been added - version="0.51" because all attribute names have changes to lower case In addition, I have amended the header to reflect the new version and date and altered <CollectionExtent> from being a container element (in error) to being a string element. There may be additional changes required to harmonise the schema with the NCD Toolit requirements. For those of you unable to work with .xsd files, I also enclose a cribsheet in Excel that provides a straight listing of the elements and their attrbutes. The names of elements currently deemed to be required are shaded pale blue All best wishes, Neil ------- Neil Thomson Head of Data & Digital Systems The Natural History Museum, Cromwell Road, London SW7 5BD Tel: +44 (0)20 7942 5294, Fax: +44 (0)20 7942 5559, Email: n.thomson(a)nhm.ac.uk http://www.nhm.ac.uk <<NCDv0pt51.xsd>> <<NCDv0pt51.xls>>

1 0

[tdwg-ncd] NCD preview site
by Ruud Altenburg 24 Apr '07

24 Apr '07

Hallo, I must confess that I have been too optimistic about the "NCD preview" database working properly after a server migration. The system was developed in the MySQL 4/PHP 4 tandem and appears not to work flawlessly in MySQL 5/PHP 5. In fact it appears a lot of minor modifications are necessary... So for the time being please consider that link not sent. I will send a message when I get the system working without problems on the new server. Best regards, Ruud Altenburg

1 0

[tdwg-ncd] RE: NCD toolkit
by Neil Thomson 23 Apr '07

23 Apr '07

Hi Ruud, Many thanks for providing the URL to the test site - don't worry about its looks, we are all aware that the functionality needs to be in place first. For your questions below: - We decided to drop <PercentageDatabased> as being an unhelpful element. It is one that would need constant updating, which we thought would not happen. The URLs in the Related Materials Group could alert a user to the fact that a database exists and could then go direct to it. As to EAD, Barabara Mathé at the AMNH has prepared a mapping between EAD and NCD which you may find helpful once it reaches its final form. - Yes, this approach sounds good. I did try to put some dummy data into the test site, but I got thrown out with an SQL error. No matter, having an organisation and a person as a precursor to a collection description sounds perfectly reasonable and is similar to the approach taken by NoDIT. - Yes, the lists will be in English, but we could may get other European language equivalents from GEMET? One for use to discuss with Roger. - There may be more than one agent per site that will be creating and editing records. At my own place there may be a dozen or more authors. Perhaps we should have an "open issues" page on the TDWG wiki, otherwise it is going to become difficult to keep track of queries, responses and decisions on emails? All best wishes, Neil -----Original Message----- From: Ruud Altenburg [mailto:ruud@eti.uva.nl] Sent: 20 April 2007 15:19 To: Neil Thomson Cc: tdwg-ncd(a)lists.tdwg.org Subject: Re: NCD toolkit Hallo Neil, I don't think I'm on the list your cc'ed, so if this bounces could you please forward my reply? I have combined both of your answers of today into one mail. But before I get to that I have an important announcement: I have made our NLBIF metadatabase maintenance site available on a public server, so you and other NCD participants can have a look. Please note that my first concern has been the functionality, not its looks! This should easily be improved with style sheets but frankly I never heard complaints from our ETI people about its 'Spartan look' ; ) The system is available at http://www.nlbif.nl/ncd-preview/ It currently contains no data, but anyone can have a try at adding/ updating/deleting records. The login is test/test. A final note: I would not play too much with the "Send mailing" option, as this may seriously annoy people you have entered as test persons! :) Then the Q&A revisited. I only reply to issues that have remained open or that I feel need some more discussion. > ----------- > 3. The contract mentions import from NoDIT databases as a requirement > (plus the EAD standard which I'm not familiar with). To cater for > this we have added several fields to the metadatabase, otherwise we > would not have been able to migrate all data. However, strictly > speaking the metadatabase therefore does not match the NCD standard > one-on-one. How do we deal with this? > > ## NHT: Would you be able to let me have a list of the elements that > do not match, please? Then we can evaluate whether they should be > added to NCD or whether it does not matter. Since NCD was derived > from the schema that underlies NoDIT they should be very similar. > Markus may be able to advise on this, since he built NoDIT for > BioCASE. These are elements such as PercentageDatabased. We could maintain them in the database (so they are not lost) but omit them from the web service. > ------------ > 4. Which fields in the NCD standard are required and which are not? I > assume ones which have a closed box in XML Spy, but this may be too > loose for a database setup. In the NLBIF metadatabase, a collection > must be connected to either a person or an organisation, otherwise it > would be orphaned. If I interpret the NCD schema well, information > about a collection can be entered without providing information about > the organisation or person to which/whom it belongs. > > ## NHT: Your are right in your interpretation of the schema. We have > tried to keep the number of required elements to a minimum to > encourage data entry - there are currently only 8 required elements > and 5 of these are about who created the entry and when. The > <FamilyName> of a person is required if a person is entered. It > would > be easy enough (and makes sense) to make an institution required and > should not be any hardship for data entry folk since for a > session, at > least, the instutition details will be the same and so entered just > once. This IMO needs further discussion. A collection can also be related to a person, not exclusively to an organisation (private collections!). Also, please keep in mind that information on collections by themselves may be virtually useless if there is no information stored about where the collection is stored (for access) and whom to address for further information. The virtue of a database is that you can search for information, but if only an extremely limited set of data is required, this will seriously impede its use. Please have a look at the setup of the metadatabase maintenance site. It's easy to add collections to existing organisations or persons, which only have to be created once. > ----------- > 5. We have copied some value lists from the NoDIT database to our > database, e.g. keywords describing collections. However, the NCD > standard has a broader scope than the NoDIT database and the NLBIF > metadatabase. In the interface, I assume that many values too should > be selected from popups menus, to guarantee a uniform database -- > e.g. AgentRole, CollectionPurpose, UnitOfMeasure, DigitalFileFormats > to name but a few. To create such lists, we need to have these values > stored in the database, so somehow these lists should be compiled. If > multiple languages should be supported, we may need to have these > values in other languages but English as well. > > ## NHT: These terminology lists and their association with the TDWG > ontology > are the subject of a separate development being undertaken at the > Smithsonian Institution by Carol Butler in association with Roger > Hyam and Markus. They will result in sets of terms that can be used > as pick-lists for those elements that should have just a few > terms or > for which consistency is important. > We should see the first draft of these at the NCD Workshop, if not > before. It would be good for anyone interested to make > suggestions for > such terms and their definition through this list to help Carol to > compile them. This is good news! I could start with the basic set we have compiled for NLBIF and replace these with the NCD entries once these have been determined. I assume these lists will be in English and will not be translated to other languages? > ---------- > 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. Thanks for the explanation. The system tracks which records (organisations, collections and persons) have been updated by whom (by Users). The Agent information e.g. is fixed for each site proving a web service on their local database. This could be entered once when setting up the database. Correct me if I'm wrong! > ---------- > 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? Well, normally both towns are the same, but not always. From a database point of view, it not desirable to enter data that ideally should be stored in separate fields into one field. E.g. it would probably make Google Maps queries much more complicated if not impossible, as addresses can be entered in various forms. Best regards, Ruud

1 0

[tdwg-ncd] FW: NCD toolkit
by Neil Thomson 23 Apr '07

23 Apr '07

Hi Ruud, I'm forwarding this message to the list to maintain the sequence, otherwise my response will be meaningless to the others. It would be great if you would join the list at the URL provided by Ricardo, then we can all share in these exciting developments. With thanks, Neil -----Original Message----- From: Ruud Altenburg [mailto:ruud@eti.uva.nl] Sent: 20 April 2007 15:19 To: Neil Thomson Cc: tdwg-ncd(a)lists.tdwg.org Subject: Re: NCD toolkit Hallo Neil, I don't think I'm on the list your cc'ed, so if this bounces could you please forward my reply? I have combined both of your answers of today into one mail. But before I get to that I have an important announcement: I have made our NLBIF metadatabase maintenance site available on a public server, so you and other NCD participants can have a look. Please note that my first concern has been the functionality, not its looks! This should easily be improved with style sheets but frankly I never heard complaints from our ETI people about its 'Spartan look' ; ) The system is available at http://www.nlbif.nl/ncd-preview/ It currently contains no data, but anyone can have a try at adding/ updating/deleting records. The login is test/test. A final note: I would not play too much with the "Send mailing" option, as this may seriously annoy people you have entered as test persons! :) Then the Q&A revisited. I only reply to issues that have remained open or that I feel need some more discussion. > ----------- > 3. The contract mentions import from NoDIT databases as a requirement > (plus the EAD standard which I'm not familiar with). To cater for > this we have added several fields to the metadatabase, otherwise we > would not have been able to migrate all data. However, strictly > speaking the metadatabase therefore does not match the NCD standard > one-on-one. How do we deal with this? > > ## NHT: Would you be able to let me have a list of the elements that > do not match, please? Then we can evaluate whether they should be > added to NCD or whether it does not matter. Since NCD was derived > from the schema that underlies NoDIT they should be very similar. > Markus may be able to advise on this, since he built NoDIT for > BioCASE. These are elements such as PercentageDatabased. We could maintain them in the database (so they are not lost) but omit them from the web service. > ------------ > 4. Which fields in the NCD standard are required and which are not? I > assume ones which have a closed box in XML Spy, but this may be too > loose for a database setup. In the NLBIF metadatabase, a collection > must be connected to either a person or an organisation, otherwise it > would be orphaned. If I interpret the NCD schema well, information > about a collection can be entered without providing information about > the organisation or person to which/whom it belongs. > > ## NHT: Your are right in your interpretation of the schema. We have > tried to keep the number of required elements to a minimum to > encourage data entry - there are currently only 8 required elements > and 5 of these are about who created the entry and when. The > <FamilyName> of a person is required if a person is entered. It > would > be easy enough (and makes sense) to make an institution required and > should not be any hardship for data entry folk since for a > session, at > least, the instutition details will be the same and so entered just > once. This IMO needs further discussion. A collection can also be related to a person, not exclusively to an organisation (private collections!). Also, please keep in mind that information on collections by themselves may be virtually useless if there is no information stored about where the collection is stored (for access) and whom to address for further information. The virtue of a database is that you can search for information, but if only an extremely limited set of data is required, this will seriously impede its use. Please have a look at the setup of the metadatabase maintenance site. It's easy to add collections to existing organisations or persons, which only have to be created once. > ----------- > 5. We have copied some value lists from the NoDIT database to our > database, e.g. keywords describing collections. However, the NCD > standard has a broader scope than the NoDIT database and the NLBIF > metadatabase. In the interface, I assume that many values too should > be selected from popups menus, to guarantee a uniform database -- > e.g. AgentRole, CollectionPurpose, UnitOfMeasure, DigitalFileFormats > to name but a few. To create such lists, we need to have these values > stored in the database, so somehow these lists should be compiled. If > multiple languages should be supported, we may need to have these > values in other languages but English as well. > > ## NHT: These terminology lists and their association with the TDWG > ontology > are the subject of a separate development being undertaken at the > Smithsonian Institution by Carol Butler in association with Roger > Hyam and Markus. They will result in sets of terms that can be used > as pick-lists for those elements that should have just a few > terms or > for which consistency is important. > We should see the first draft of these at the NCD Workshop, if not > before. It would be good for anyone interested to make > suggestions for > such terms and their definition through this list to help Carol to > compile them. This is good news! I could start with the basic set we have compiled for NLBIF and replace these with the NCD entries once these have been determined. I assume these lists will be in English and will not be translated to other languages? > ---------- > 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. Thanks for the explanation. The system tracks which records (organisations, collections and persons) have been updated by whom (by Users). The Agent information e.g. is fixed for each site proving a web service on their local database. This could be entered once when setting up the database. Correct me if I'm wrong! > ---------- > 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? Well, normally both towns are the same, but not always. From a database point of view, it not desirable to enter data that ideally should be stored in separate fields into one field. E.g. it would probably make Google Maps queries much more complicated if not impossible, as addresses can be entered in various forms. Best regards, Ruud

1 0

[tdwg-ncd] RE: NCD toolkit
by Neil Thomson 20 Apr '07

20 Apr '07

Hi Ruud, Thank you for your mailing - I have interspersed my responses to your questions below. As mentioned, I am also copying this out to the NCD mail-list so that folk can be informed of developments and can offer additional advice, or correct my responses where I am talking nonsense. The toolkit is highly anticipated, with several institutions already looking to make use of it - including my own - so it is important that we get things right as early as possible. The first step is to agree on a stable version of NCD that we can all work with. A new version is required anyway, since the current v0.50 has had some of its elements "un-typed" by XMLSpy and I'm grateful to Markus for pointing this out. So, on with the Q&A session, number 1 ... -----Original Message----- From: Ruud Altenburg [mailto:ruud@eti.uva.nl] Sent: 18 April 2007 12:24 To: Neil Thomson Subject: NCD toolkit Hallo Neil, this is Ruud Altenburg from ETI. My forthcoming project is to participate in the creation of the NCD toolkit. As you know, ETI has prepared a "metadatabase" for NLBIF which was based on the NCD 0.3 standard and added some fields from the NoDIT database which we considered essential (we had to migrate the data from NoDIT to the new database). I have sent you the scheme of the metadatabase some time ago. According to Wouter (Addink, ETI), the toolkit should be based on v0.5 of the NCD scheme. I have compared that to our metadatabase schema and noticed some changes. This implies that we need to update our database schema, which will boil down to the addition of several new fields. This of course should be fairly easy to implement. However, there are some points we need to address before I can really start with this project. ## NHT: Version v0.50 was developed in response to the schema that you sent to me and the presentation that Wouter gave to TDWG at the end of last year. We will need to bear in mind that there will be differences between the NCD data standard, which is intended as a data aggregation and interchange standard, and the implementation of it as a database. We have noted before that there are database fields that are required to make the database work that are not required for the interchange of data. This should not be a problem, though. ----------- 1. The contract states that the NCD toolkit should be multi-lingual. Does this refer to the web interface (the entry tool), the contents of the database, or both? I propose to have the interface in English and only to store the data in several languages. ## NHT: This refers primarily to the contents of the database. Most, if not all, text-oriented elements are now repeatable and have a language attribute so that entries may be made both in the local language and in a second language, such as english. The exception is the <CollectionUniformName> which is expected to be in english. ----------- 2. About the contents: how many languages should the interface cater for? Currently our metadatabase caters for the entry of two languages (English and Dutch). Data have to be entered in two languages at once. The reason for this is that you need to avoid that all organisations and collections are described in English but only half of them in Dutch. So in our setup, when someone enters new data, he or she is forced to do this in two languages at once. I propose a similar strategy for the NCD toolkit, i.e. to restrict the contents to English plus a native language if the user is not from an English speaking territory. ## NHT: This sounds like a good strategy. I'm not sure that we can enforce english except where it is useful for sorting and searching, but restricting input to two languages should be ok. I would expect (but I may be wrong here) that providing local versions of the interface would only involve re-labelling the input form and report form elements? In which case, provided guidance is given, it would be reasonable to expect that those implementing the toolkit in a different language could do that. ----------- 3. The contract mentions import from NoDIT databases as a requirement (plus the EAD standard which I'm not familiar with). To cater for this we have added several fields to the metadatabase, otherwise we would not have been able to migrate all data. However, strictly speaking the metadatabase therefore does not match the NCD standard one-on-one. How do we deal with this? ## NHT: Would you be able to let me have a list of the elements that do not match, please? Then we can evaluate whether they should be added to NCD or whether it does not matter. Since NCD was derived from the schema that underlies NoDIT they should be very similar. Markus may be able to advise on this, since he built NoDIT for BioCASE. ------------ 4. Which fields in the NCD standard are required and which are not? I assume ones which have a closed box in XML Spy, but this may be too loose for a database setup. In the NLBIF metadatabase, a collection must be connected to either a person or an organisation, otherwise it would be orphaned. If I interpret the NCD schema well, information about a collection can be entered without providing information about the organisation or person to which/whom it belongs. ## NHT: Your are right in your interpretation of the schema. We have tried to keep the number of required elements to a minimum to encourage data entry - there are currently only 8 required elements and 5 of these are about who created the entry and when. The <FamilyName> of a person is required if a person is entered. It would be easy enough (and makes sense) to make an institution required and should not be any hardship for data entry folk since for a session, at least, the instutition details will be the same and so entered just once. ----------- 5. We have copied some value lists from the NoDIT database to our database, e.g. keywords describing collections. However, the NCD standard has a broader scope than the NoDIT database and the NLBIF metadatabase. In the interface, I assume that many values too should be selected from popups menus, to guarantee a uniform database -- e.g. AgentRole, CollectionPurpose, UnitOfMeasure, DigitalFileFormats to name but a few. To create such lists, we need to have these values stored in the database, so somehow these lists should be compiled. If multiple languages should be supported, we may need to have these values in other languages but English as well. ## NHT: These terminology lists and their association with the TDWG ontology are the subject of a separate development being undertaken at the Smithsonian Institution by Carol Butler in association with Roger Hyam and Markus. They will result in sets of terms that can be used as pick-lists for those elements that should have just a few terms or for which consistency is important. We should see the first draft of these at the NCD Workshop, if not before. It would be good for anyone interested to make suggestions for such terms and their definition through this list to help Carol to compile them. ----------- I hope you have the time to discuss these items, and probably a few more that will popup when I dive deeper into the subject! ## NHT: Sure thing - I see that there is another one awaiting attention and will get on to that very soon. Thank you very much for your work on this and please do not hesitate to ask any further questions of me or anyone on what is now the TDWG Collections Description Interest Group. All best wishes, Neil Best regards, Ruud

2 1