[tdwg-ncd] RE: NCD status summary

[Neil Thomson]

 Hi Markus,

Sorry for the delay in responding to this. I have interspersed comments below and Cc:'d in the RAVNS since there are some changes here that are potential workshop agenda items.

Thanks for your help with this ...

-----Original Message-----
From: Markus Döring [mailto:m.doering at BGBM.org] 
Sent: 01 June 2007 14:51
To: Neil Thomson
Cc: Ruud Altenburg
Subject: NCD status summary

Neil,
I have been working on the schema and the ontology lately. They don't  
match a 100%. In my opinion it would be best to focus on one  
specification only instead of trying to maintain and keep in sync 2  
specifications for different target platforms (XML+RDF). If we need  
to do that, I strongly suggest to do the real modelling in an  
abstract form with UML and derive a schema and ontology from that!  
You can also create a suitable database schema from UML automatically  
if you want. Im not sure how to go about this decision. Maybe its  
best to discuss this during the workshop?

## NT: We should complete the schema v1.0 at least before transferring to another technology. Maybe you could cover the reasons for moving and how it will affect future developments in your session at the workshop?
-----------------------

In regard to the php toolkit I think this decision doesnt have a very  
strong impact as long as the toolkit doesn't implement im/export via  
xml or rdf yet. I suggest to work with the schema for now cause this  
is 99% complete. On the other hand I believe the RDF version is the  
preferred tdwg format, so we should use this ontology as the  
reference. And as I said its not exactly the same as the ncd schema,  
as it is part of the tdwg ontology and uses external ontologies too  
(like vcard).

## NT: ok, that's good in that it should not hold Ruud up too much.
---------

Detailed issues that still need to be resolved are:

*** SCHEMA ***
- what IDs should exist? 1 NCD guid (lsid or whatever) + many others  
with source. Is this correct?

##NT: Only the NCDID needs to be generated, probably as an LSID. All other identifiers are taken from elsewhere (i.e.the "source")
------------------

- are multiple parent collections & parent institutions allowed?  
currently this is not

##NT: Yes, they should be allowed
------------------

- person roles not fixed or at least core suggested? I think we need  
this

##NT: Yes, we do need this
------------------

- what is "richRecordSearchString" in contrast to  
"collectionDatabaseURL"? what about "objectAccessService" and simply  
"furtherInformation" ?

##NT: The "collectionDatabaseURL" is the URL of the database that holds item-level data for the collection being described in this NCD record. The "richRecordSearchString" is what should be used in that database to get directly to the relevant record. To take an example, there will be an NCD record describing a herbarium. The "collectionDatabaseURL" will be to the Index Herbariorum WebDatabase and the "richRecordSearchString" will contain the coden for the herbarium so that the full description of the herbarium can be found by adding the two together. I have no objection to "objectAccessService" for the latter, but the former is more explicit than "furtherInformation".
-------------------

- I have replaced all address information with vcard elements. That  
is vc:N for person names and vc:ADR for addresses. Some existing NCD  
elements do not exist in vcard though. How shall we treat them? Right  
now Ive simply left them as they were before in addition the vcard  
elements. It looks a bit weird, but its ok I believe. In particular  
that is byear and deathyear for persons (full birthday exists in  
vcard) and fax, email, logourl for institutional addresses. Maybe we  
can remove the email and fax and add a website instead? The  
collection have real contacts anyway already, so institutions dont  
really need this, do they?

##NT: Yes, institutions do require contact details too so I would prefer that these elements remain. If they are not present as vc: elements then can they just be ncd: elements?
-------------------

- many elements cover the same ideas that dublin core covers. Should  
we use the explicit dublin core elements for title, description,  
other resources, keyword, rights, modified, created and citation? I  
would be in favor to do so. It would mean that NCD mainly is about  
the extra metadata bits that dublin core doesn't cover!

##NT: We certainly could do this and Doug has produced an NCD <--> DC mapping. Since this would just be a re-labelling exercise we can have this as a discussion item at the workshop. NCD would then be an application profile, re-using elements from mets:, dc: and vc: along with its own.
-------------------

*** ONTOLOGY ***
- collection extent is a pure integer without a unit definition. I  
know this is bad, but having complex data (i.e. with multiple  
elements or attributes) in an ontology means I would have to define a  
new class just for this. And Roger is very keen on keeping the number  
of classes low.

##NT: In this case the single attribute should be a string not an integer. Describing a collection extent as "2" is spectacularly meaningless. If the string is "2 shelves" or "2 cupboards" or "2 rooms" it means a little bit more. Not much, but enough for someone to assess whether it is worth a visit or not.
--------------------
- all keywords lacking strength flag cause I have created a single  
keyword class that is used by all keyword types. And the strewngth  
flag didnt exist for all keywords. Should it or should we drop it?

##NT: I would like to keep the strength flag if possible fot those elements where it makes sense - it would be good to indicate where the collection owner believe's the collection to be particularly strong.
--------------------

- a persons role in regard to a specific collection is missing. I  
think we need it, but then again we need at least a basic controlled  
vocabulary

##NT: Yesm we do need this. Example terms would be owner, adminstrator, collector, preparator etc.
-------------------

I think thats all there is. It looks like a lot, but most issues are  
of a cosmetic nature and do not change the abstract standard. Some  
like multiple parents do of cause.

I would be glad if you could reply to these questions as soon as  
possible, even if its only partly, cause I hope to find some time  
over the weekend to settle some of them.

##NT: Thanks again for looking at these details. It was always known that changes would be needed for the toolkit to work and others may well come to light during testing. We can also talk that through at the workshop, since I think that some of the RAVNS are keen to help with the testing.

Is everyone in agreement with the changes proposed above? We need to quickly move to v1.0 so that Ruud can strut his stuff. Apologies again for the unintended out-time recently.

All best wishes,
Neil
-----------

best wishes
--
Markus

http://rs.tdwg.org/ontology/voc/
http://rs.tdwg.org/ncd/dev/schema/ncd.xsd