52 lines
1.6 KiB
Plaintext
52 lines
1.6 KiB
Plaintext
head 1.2;
|
|
access;
|
|
symbols;
|
|
locks; strict;
|
|
comment @# @;
|
|
|
|
|
|
1.2
|
|
date 2007.03.06.17.30.00; author TWikiGuest; state Exp;
|
|
branches;
|
|
next 1.1;
|
|
|
|
1.1
|
|
date 2004.11.08.19.04.00; author GregorHagedorn; state Exp;
|
|
branches;
|
|
next ;
|
|
|
|
|
|
desc
|
|
@none
|
|
@
|
|
|
|
|
|
1.2
|
|
log
|
|
@Added topic name via script
|
|
@
|
|
text
|
|
@---+!! %TOPIC%
|
|
|
|
%META:TOPICINFO{author="GregorHagedorn" date="1099940640" format="1.0" version="1.1"}%
|
|
%META:TOPICPARENT{name="LinneanCoreUseCases"}%
|
|
To create taxonomic/nomenclatural monographs online on the internet some name-atomization standard is desirable.
|
|
|
|
Notable, this standard would have to be able to deal with name usage and not just the definition of a perfect nomenclatural name. In addition to what LC might have to support to be embedded into TCS, it may have to support information about misidentification, loose/fuzzy concept suffixes like "sensu lato", non-author information for competing synonyms in the case of later homonyms, etc. See also LinneanCoreConceptSuffixString.
|
|
|
|
Can someone from the group developing this list a number of their requirements or perhaps give example data they would expect to be treated by LC? I think the checklist people are in a similar situation. Strictly they have name-usage data, but for many groups they may be the primary suppliers of (perhaps regional) synonymy. They also may slightly touch the taxon concept domain, using an occasional "s. stricto" or "sec. author"...
|
|
|
|
It may be possible that we need to structure LC into a number of types so to fulfill the different but largely overlapping needs.
|
|
|
|
-- Main.GregorHagedorn - 08 Nov 2004
|
|
@
|
|
|
|
|
|
1.1
|
|
log
|
|
@none
|
|
@
|
|
text
|
|
@d1 2
|
|
@
|