Are these concepts fixed to a particular phylogenetic hypothesis i.e. a particular genus?
I think my main point here was the fact that in most schemas we (TDWG, et al) have created, we have not really provided an ID field for (2). As you said (2) is the "concept definition" but there is no ID field (that I have come across), for referring to it explicitly.
My thought would be to have something like:
http://zoobank.org/taxonconcept/12345-ABCDE
that returns data for the "whole" taxon concept (ie 2), not just the Name + Reference
I think it is really a data/technical issue - ie the way the schemas/models are defined, a Taxon Concept ID includes, and only includes, a Name ID and a Reference ID. This is based on my understanding of TCS - perhaps DwC is different??
Kevin
-----Original Message-----
From: Richard Pyle [mailto:deepreef@bishopmuseum.org]
Sent: Friday, 11 June 2010 9:03 a.m.
To: Kevin Richards; 'Peter DeVries'
Cc: tdwg-content@lists.tdwg.org; Jerry Cooper
Subject: RE: [tdwg-content] Name is species concept thinking
> This is something that has been slightly confused over the years, ie there
seems to be 2 ways of defining a "taxon concept":
> 1. A Taxon Name (nomenclatural data) + Literature Reference - ie Name X as
defined in article Y
> 2. As you have said a grouping of data that define a taxon concept (Name +
Reference + Synonyms + Type Specimen + Protologue, .)
I don't think of these as two different ways of defining a concept. I see
#1 as a way of *pointing to* a taxon concept definition, and #2 as the
concept definition itself. Basically, #1 (usage instance) is effectively a
container or an identifier for the taxon concept definition.
However, there is somewhat of a dichotmy in the way that taxon concepts are
defined - one is by included members (i.e., specimens, presumably including
at least one name-bearing type specimen, from which a name-label is
derived), the other is by properties (i.e. characters -- morphologic,
genetic, or otherwise). In practice, most concept definitions include both.
But I think the "definition" of the concept (i.e., the circumscription
boundaries) is the same for both -- it's just that those boundaries can be
articulated in different ways (i.e., by examplar members, and by purported
properties).
> 1 has been covered quite well with the various schemas we have come up
> with over the years, but I think these schemas have failed to capture
> 2 very well (the data fields are there, but the encompassing ID is not),
ie
Agreed -- sort of. I think the schemas are there, but have not been
organized appropriately (yet). See below.
> TaxonName ID = N1, FullName = "Aus bus"
> Reference ID = R1, Citation = "Richards, how to define a taxon concept"
> TaxonConcept ID = C1, NameID = N1, ReferenceID = R1
> BUT, the taxon concept C1 does not encompass all related data that defines
that concept (synonyms etc)
No, but it could, through a network of linkages, as I tried to describe in
one of my recent posts.
> To do that we need more Concept Ids and relationships between these
concepts, eg
Exactly! And we need a schema-based process to capture the relevant
information (diagnoses, etc.), anchored to the Concept Ids. At a basic
level, Plazi/TaxonX does this. However, it usually only goes as far as the
text-blob. To parse the text blob, we need to either look towards SDD (for
character-based concept definition stuff) or DwC/Occurrence (for
specimen-based concept definition stuff).
> ConceptRelationship ID=CR1 ConceptFromID=C2, ConceptToID =C1,
RelationshipType='has preferred name'
Yes, I agree we need this as well! But again, I see this as a way of
networking pointers to taxon concept defintions, not describing the
definitions themselves.
Man, these conversations really hurt my brain.... :-)
Aloha,
Rich
Please consider the environment before printing this email
Warning: This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails.
The views expressed in this email may not be those of Landcare Research New Zealand Limited. http://www.landcareresearch.co.nz