task #2342: Open issues for DwC-A export - EDIT - EDIT Project Management

Actions

Copy link

task #2342

open

Open issues for DwC-A export

Added by Andreas Müller over 12 years ago. Updated over 3 years ago.

Status:

New

Priority:

Priority14

Assignee:

Andreas Müller

Category:

cdmadapter

Target version:

DwC-A to CDM Import

Start date:

Due date:

% Done:

Estimated time:

Severity:

major

Tags:

export dwca

Description

wiki:DarwinCoreArchive

Open issues:

check that all best practices from http://code.google.com/p/gbif-ecat/wiki/BestPractices are included
investigate why relatedResources do not get into metaData.xml for cichorieae export
include used vocabularies in metadata.xml
fix eml.xml (it currently doesn't validate)
allow more configuration/filtering -> partly handled in #6754
Check all parameters again
document problems and configuration
document/implement missing parameters
allow higher classification handling -> first implementation: d2f7f487
remove always empty fields
~~~refine progress monitoring~~~ -> #6799
implement logging that can be used by an Editor user -> first version #6754
~~~large exports (split in parts)~~~ -> #6754
refactor such that metadata is created in the beginning
during export of cichoriea sometimes a "data too complex for specimen facade" error occurred (strange as we edit and import all data via the facade)
originalNameUsageId should link to the according concept (if it exists)
data needs to be consistent: if exporting while data are edited the set of core data needs to be fixed at the beginning
implement default fields such as the source field in core
correct handling of references (#7211)

<field default="http://wp6-cichorieae.e-taxonomy.eu/portal/?q=cdm_dataportal/taxon/{ID}" term="http://purl.org/dc/terms/source"/>

test if apache commons compress could be useful (http://commons.apache.org/compress/download_compress.cgi)

Updated by Andreas Müller over 12 years ago

Priority changed from Highest to Priority14
Severity changed from critical to major
Tracker changed from feature request to bug

Actions

Copy link

Updated by Andreas Müller over 12 years ago

Wir wollten einen standard haben in dem der record den "join" von konzept/taxon und name darstellt.

Ein usage, ein Gebrauch eines Namens, ist daher recht unterschiedlich. Wenn ein taxonomicStatus oder parent/acceptedUsage(ID) gegeben ist, ist es definitiv ein taxon. Aber der name alleine mit nomenclaturalStatus und publishedIn kann auch rein nomenklatorisch genutzt werden.

Wie ist denn dann die BestPractice für die CoreIDs beim Export von Daten, die wie das CDM Identifier für beides hat, Konzepte und Namen. Ich habe jetzt erstmal idR die Identifier der Konzepte verwendet und alle Informationen, also nomenklatorische und konzeptbezogene in einen Record zu bekommen, bekomme dabei aber die genannten Probleme. Gleichzeitig hat das natürlich auch eine Reihe Vorteilen beim verarbeiten der Daten durch Applikationen, die keine Trennung zwischen Namen und Konzepten implementieren.

Alternativ wäre es natürlich denkbar, jeweils einen Datensatz für das Konzept und einen für den Namen (als das Nominalkonzept) zu verwenden.

Ideal wäre immer to konzekt id zu benutzen wenn vorhanden. Falls es nur einen namen gibt könnten man evtl ein Nominalkonzept on the fly erzeugen?

Also auf jeden Fall keine 2 Records, richtig? Nominalkonzept wäre kein Problem, ein Name, an dem bereits eine nomRef steht ist ja quasi schon ein Konzept. Ich nehme dann einfach die ID des Namens und fertig.

Markus

Actions

Copy link