No subject

=20AccordingTo (i.e. a person in a place in a publication) for a name cha=
nge. Or if you do it needs to be modelled elsewhere?=20

>> The nominal concept is there so that someone identifying
>> something later, without saying what meaning they meant, can use
>> the nominal version.
>
>O.K., so why isn't this the *perfect* representation of a=20
>"name object"?  As
>I understand it, we all agree that a Linnaean name, by itself, with no
>reference to specimen objects other than the primary type,=20
>does imply a sort
>of "fuzzy" concept that essentially boils down to the "sum of=20
>all concepts
>that have been attached to this name, or have been attached to=20
>names that
>have been treated as synonyms of this name".  Isn't that exactly what a
>Nominal concept is intended to be used for?
>
Yes but if people are really saying that they want to tag things with nam=
es and not nominal concepts which is what I think Gregor is saying then i=
t wouldn't be perfect for him nor for James(and I have a couple of doubts=
=20lingering but can't quite express them).
The problem for me is the discussion is really limited in terms of views =
of everyone - so trying to see what the general consensus is difficult.

TCS was designed as a compromise to try to take on board all we heard whe=
n we went around discussing with the groups as to what they understood to=
=20be concepts and what they would do with them etc. So we spoke with man=
y people and tried to find a way of looking at the data in a common forma=
t that everyone could map their data to. In Christchurch there was a unan=
imous agreement at the Names/Concepts subgroup meeting on the Saturday (w=
ith quite a lot of people there) that specimens etc. should be tagged wit=
h concepts and not names. Therefore we came up with nominal concepts to a=
llow people to deal with legacy data where all you have is a name but we =
know there is an implied concept that could be any one of the existing co=
ncepts described. (Arguably it might not be any of the concepts previousl=
y but this I would put down to inherent errors in interpretation of conce=
pts when doing identifications).

Now people seem to be saying that they want to use names whether or not i=
t's the right thing to do and so they don't want to have to use concepts.=
=20TCS was never trying to say this is the way you need to do things - th=
at's why the schema has so many optional things in it, so you can represe=
nt a concept however you think it should be done, but we didn't allow nam=
es as top level objects, because we thought you could represent names as =
concepts and it would encourage the world to start solving the concept pr=
oblem. In Christchurch we saw many very nice examples of systems that had=
=20been built which were based on names - but what I heard in I think all=
=20of these presentations even when they didn't want to acknowledge the n=
eed for concepts was that they had got so far but then they were having a=
=20problem with what the names meant.=20

We also were promoting re-use across TDWG schemas and tried to show this =
in Christchurch with our use of ANY to indicate that we would expect to p=
ick up the schema defined by one of the other subgroups for this part of =
the schema and at least we would include a GUID and the primary key field=
s to the objects being described by the other schemas. So for publication=
=20we had an Endnote based suggestion but replaced this with any to say t=
hat if the publication group were looking at this we could replace this w=
ith their standard for citing a reference. Same for Vouchers, Character D=
escription etc. With Names we took the Name element from ABCD which was a=
=20type.

The Name element wasn't seen to be good enough so LC were going to remode=
l this. I haven't seen a suggestion for a new Name type yet just a potent=
ial XSD for LC which may or may not be mappable to TCS - we tried to map =
some of it.

Now we are in the situation that some people want to pass names around - =
by this do we mean bare names or do we mean with all the nomenclatural hi=
story?
what do we mean by a name? Some people say that certain names are just ty=
pos - regardless of where they were published, some names don't need to h=
ave a publication associated with them (so how do we ever find out about =
these new names or suggested corrections to existing names and isn't this=
=20tracked by nomenclaturalists?)

to satisfy everyone to we need a name object that is simply the scientifi=
c name (similar to what Walter wanted for ABCD), a nominal object that re=
fers to the name but includes all the nomenclatural relationships and a c=
oncept object that includes the name object or maybe the nominal object -=
=20not sure what it would really need...

Which is why I kept it together so you only need to view the parts of the=
=20TCS that are relevant to your needs. In any DBMS systems you don't pas=
s around the whole object all the time you do projections or define views=
=20on the relations so you see what you need to. hmmmm...

......>O.K., maybe it would be helpful to refer back to the=20
>PowerPoint file from
>the TCS Wiki:
>http://www.soc.napier.ac.uk/doc/Demo_V2.ppt
>
......
>
>To a nomenclaturalist, there are the following Name objects:
agreed

>(Whether or not Pyle 1990 should be cited for these gender-matching
>corrections is not clear, and needs further discussion.)
>
well I guess that's up to the nomenclaturalists but if you record it they=
=20can ignore it if they don't want it for whatever purpose but the data =
will be there for those interested.

>Note that neither ICZN, nor ICBN would treat 3a or 4a as distinct "name
>objects", but rather as attributes (variants -- corrected, in=20
>this case) of
>the name objects 3 & 4.

modelling semantics - I don't think ICBN or ICZN have name objects but an=
yway if I treat it as a name object (TCS concept) the fact that is has a =
relationship - say orthographic_variant_of to some other name concept sho=
uld be enough information to decide how to treat the data for your purpos=
es.

>
>So here is my question to you:
>
>Given the instance document structured as you have it, how do=20
>I extract just
>the nomenclatural information about these 6 name-objects (two of which
>include one orthographic variant each)?
>
all the original concepts which do not have any is_orthographic_variant_o=
f relationships pointing from it.

>I see 8 "Original" concepts, and 8 "Nominal" concepts.  The=20
>Nominal concepts
>(as they are formatted here) do not help me, because they do=20
>not establish
>unambiguous relationships between a combination and its=20
>basionym, a genus
>and its type species, any link to the original publication, etc.
all of this information is captured in the relationships the concept has =
to other relationships - e.g. has_basionym,  is_nov_comb whatever.....
>
>Most of the nomenclatural information I need can be found=20
>among the set of
>"Original" concepts,=20
yes that's because I see the names as a kind of original concept.

>but the nomenclatural information is=20
>mixed in with the
>concept information. For example:
>
>- only one of the 6 listed vouchers for Aus aus L. is of nomenclatural
>interest to me (same applies to other instances
yes the one that is specified to be the type specimen as opposed to any o=
ther specimen...a query could handle that surely....
>
>- the only way I can find out the original genus placement of=20
>a name like
>"Aus bea Archer 1965" is to parse out the first part of the content of
><NameSimple>, and hope it's not a homonym.
>
no you can follow the relationship which says "Aus bea Archer 1965" is a =
child_of "Aus Linnaeus 1758"
>- the only way I can tell for sure that "cy1" is not a=20
>distinct name object
>itself (from a nomenclatural perspective) is to tunnel down=20
>and discover the
>existence of <Relationship type=3D"is validation of"> --=20
>something I would
>have to specifically filter for in order to transform this=20
>instance into an
>orthographic variant of ca3, rather than a new name object.
>
yes - if you had modelled the data differently in your system (most likel=
y) to that of TCS which is designed for exchange and assumes mappings hav=
e to take place.

>- It would take a bit of processing overhead to examine the various
>Relationships within cp5 to sort out that this instance=20
>represents the first
>combination of the species-group name "Aus bea Archer 1965" with the
>genus-group name "Aus Linnaeus 1758"., rather than a new=20
>species-group name.
>
yes but possible and the computer could do it......

>I have no doubt that we could come up with a set of logic=20
>rules to allow a
>robust software tool to munch through this entire instance=20
>document and pull
>out just the 6 name objects (with their nomenclatural=20
>connections) that are
>of interest to a nomenclator.=20
yes I agree
>But the co-mingling of concept-relevant
>information with name-relevant information, and the need to=20
>cumbersomely
>extract and digest the nomenclaturally important bits out from=20
>the concept
>bits makes this schema very unappealing to the name camp.
>
perhaps but I guess this is what happens if you try to get something that=
=20people with many different perspectives can use - I'm now wondering if=
=20people want that - although it certainly was my initial goal.

>What I am proposing (and hope to do so formally tonight, including a
>re-working of the Demo_v2.xml instance document) is a=20
>compromise that would
>solve a variety of needs simultaneously, without actually=20
>changing much of
>the existing TCS structure (just some of the business rules)

i.e. what I was trying to do in TCS ;-)

>
>> yes that's why we introduced nominal concepts but your nominal
>> concept does have an according to - to the person who made the
>> name change in the publication that name change was proposed.
>
>I think this comes back to my point that "Nomenclatural Act=20
>Credited To..."
>is fundamentally different from "Concept Circumscription=20
>According To..."

yes to some people but at the end of the day if others have to use these =
names to mean something then to them perhaps they are not different so as=
=20long as everyone can see the data the way they need to things are hunk=
y dory ha ha......
>
>> >That's exactly the sort of "concept" we want name-only data to
>> >default to.
>> >
>> yes I agree that name only data used in identification should
>> default to nominal concepts i.e. scientific name AccordingTo NULL
>> rather than just scientific name.
>
>Yes, but then it's a separate step (finding the corresponding Original
>Concept) that is needed to get the nomenclatural details.  When a
>nomenclator passes a name object, the implied concept=20
>circumscription is the
>one you would type as "Nominal".  I think what you are trying=20
>to do here is
>establish "'Linnaeus 1758' as author of name-object 'Aus'", using the
>"AccordingTo" structure that is normally used to mean=20
>"'Linnaeus 1758' as
>definer of a concept circumscription to which he applied the=20
>name 'Aus'".
>

yes

>My point all along is that the label "Aus Linnaeus 1758 SEC.=20
>Linnaeus 1758"
>has two copies of "Linnaeus 1758" for a reason.  The first=20
>"Linnaeus 1758"
>is to disambiguate the genus name "Aus" from homonyms, and to=20
>point to the
>original publication in which the relevant name-object "Aus" was first
>established.  The second "Linnaeus 1758" serves the function=20
>of specifically
>referencing the concept circumscription that Linnaeus intended his name
>"Aus" to apply to.  From what it seems you are saying, you are=20
>trying to
>capture both references to "Linnaeus 1758" in the concept-label "Aus
>Linnaeus 1758 SEC. Linnaeus 1758", using only one=20
>"AccordingTo" pointer.

yes that's what I'm doing

>And I think that is not a wise approach to modeling these two different
>pieces of information.
>
fair enough - I thought it was a good solution as schematically and in te=
rms of physical objects there were lots of similarities.

>> but your nominal concepts would not be simple scientific names
>> according to we don't whom they would have other information
>> about them that the biologist using a name probably had no
>> knowledge of or intention of referring to.
>
>The *only* other information I would propose to include in a=20
>Nominal Concept
>instance would be nomenclatural information (authorship=20
>attributes, pointers
>to original description, pointer to basionym, perhaps a pointer to the
>primary type specimen; etc.).=20
This is what I'd have in the original concept for a name object.

> None of that information would=20
>in any way
>alter the "fuzzy" nature of the Nominal Concept=20
>circumscription.  If the
>biologist provided a Linnaean name as governed by one of the Codes, it
>doesn't matter whether said biologist intended to refer to the=20
>author of the
>name, or the year it was published, or its type species, or=20
>whatever -- but
>the point is, these pieces of information are objectively tied=20
>to the name
>that the biologist used.  It doesn't in any way affect the=20
>"Null"-ness of
>the concept circumscription definition.

if you point at the original description then people could decide that's =
what was meant by the name - that's something Gregor has been fighting ag=
ainst.

>But the point is this:  you now have a bunch=20
>of taxonomists
>(not just me) telling you that "Name" attributes aren't part=20
>of the concept
>definition *either*.  To us, it seems fundamental to=20
>modularize the name
>objects and their corresponding name-name relationships=20
>separately from the
>concept circumscriptions and their concept-concept=20
>relationships.  So, just
>as you have appeased the "other" taxonomists by separating the=20
>"definitive"
>Relationships from the "interpretive" Relationships, several of us are
>asking you (begging you) to find a way to separate the name=20
>attributes and
>name-name relationships from the concept attributes and concept-concept
>relationships.

I'm sure we could do it and by the looks of things might have to but I th=
ink that it will bring the community together in solving the problems we =
have in taxonomic data - maybe I'm being pessimistic here but at the end =
of the day it has to do what everyone needs it to do, so as long as we ca=
n enforce (if we want) the semantics we are trying to get over in TCS and=
=20others can use it for names and ignore concepts then who am I to say w=
hat they should do - I really believe that whatever schema we come up wit=
h people will interpret it the way they want to.
>
>The extreme approach (which some on this list advocate) is the earlier
>"thought-experiment" approach of treating names as separate top-level
>objects.  What I am personally proposing is a more moderated=20
>approach (which
>I am increasingly believing serves both the TCS community and the LC
>community more effectively than either the current TCS, or the
>names-as-top-level-objects approach), is to harness the=20
>intuitive "power" of
>the Nominal concept. More on this later tonight.

I think as soon as name objects become top level we will focus on names a=
nd not concepts and won't be able to create concepts without first having=
=20name objects. So we will have people continuing to duplicate effort in=
=20creating names and correcting them and then trying to decide if their =
names are the same as someone else's names...hey-ho....
but (probably) better that people do something.....


...>I'm talking about a real concept definition (with vouchers,=20
>and character
>diagnoses, and such), that was *NOT* "published in a taxonomic=20
>publication
>such as a monograph or as a result of a name change to satisfy=20
>one of the
>codes and therefore to be intended to be used by people in the future."

where was it recorded then? and if it is deemed to be a *real* concept th=
en why couldn't we record it like any other concept? I used the condition=
s as a guide to decide if things were real concepts but I can't always an=
swer that - that's the role of the taxonomic community I think.

>
>> >- Nomenclaturalists have an unambiguous way to package the=20
>information
>> >they're interested in (i.e., Nominal concepts)
>>
>> then we can't use Nominal concepts for what we meant them to be in
>> the first place - which was to allow biologist who use scientific
>> names in labelling things without saying what meaning they meant.
>
>Why not???  Attaching purely nomenclatural information to a=20
>Nominal concept
>instance does not say anything about what the concept "means"=20
>(other than
>the fact that it includes the primary type specimen of the=20
>name itself).
>Nothing about what I am proposing attaches *any*=20
>circumscriptional "meaning"
>to the Nominal concept -- it still represents a fuzzy "sum of=20
>all concepts
>that might have referred to this name".

you include an original description - but we are to ignore that...

>
>> i.e. Aus bus AccordingTo NULL
>> because your nominal concepts would have an AccordingTo surely? -
>
>No!!!  "AccordingTo" would still be NULL.  Instead, somewhere within
>"NameDetailed", would be something along the lines of=20
>"DescribedIn", which
>would point to the Code-accepted publication instance in which the name
>became nomenclaturally available.  This would unambiguously=20
>NOT be confused
>with "AccordingTo", which involves a concept circumscription.

ok - this is what I thought you'd want - as I mentioned above - but it is=
=20effectively another AccordingTo in my mind.

>
>The problem I have with treating the "Original" concept instance as the
>"bearer of the name", is that it's not clear whether=20
>"AccordingTo" means
>"DescribedIn", or, "in the concept circumscription sense of". =20
>I believe
>that for "Original" Concept instances, it should always mean=20
>the latter.
>The "DescribedIn" information should be berried somewhere among the
>nomenclatural elements of the corresponding "Nominal" Concept.

I think it means the same - because it is in the same publication.....
Jessie
This message is intended for the addressee(s) only and should not be read=
, copied or disclosed to anyone else outwith the University without the p=
ermission of the sender.
It is your responsibility to ensure that this message and any attachments=
=20are scanned for viruses or other defects. Napier University does not a=
ccept liability for any loss
or damage which may result from this email or any attachment, or for erro=
rs or omissions arising after it was sent. Email is not a secure medium. =
Email entering the=20
University's system is subject to routine monitoring and filtering by the=
=20University.=20