[tcs-lc] New Version of TCS announced

[Richard Pyle]

> There are no doubt many ways of marking up taxonomic data. The TCS is
> 'a' way of doing it not 'the only' way of doing it. I think it is fair
> to assume that it is not the 'best' way of doing it. Somewhere out there
> in the spaces between peoples heads there is surely a better way of
> doing it waiting to be discovered, written down, documented, tested and
> deployed.

No argument!  But given the somewhat fundamental differences between v095
and v0952, it doesn't seem unreasonable to advocate an approach that is
half-way in-between -- even in the context of a need to get a product to
market soon.

> Bearing this in mind what we really need is feedback along the lines of:
>
>  "TCS 0.95.2 is no good because I can't express X with it"

Is 0.95.2 "presumed superior until proven inferior"?  Or is it vice-versa?
After a quick glance last night, my gut feeling is to stick with v0.95 -- if
for no other reson than more people have spent more time thinking it
through, and because it seems to accomodate all data situations ('though
perhaps not optimally, from a nomenclatural perspective).

On the other hand, v0.95.2 might be a better starting point to lead
something more closely reflecting my own personal preference...

> This can be answered with:
>
> 1) "Yes you can - this is how you do it (and we have added it to the
> documentation)"
>
> 2) "Oops! - we better change the schema to accommodate it"
>
> 3) "Hmm - after thought and discussion we think this is beyond the scope
> of the schema and is better dealt with somewhere else (ABCD, TaXMLit etc)"
>
> So you don't need to come up with a competing schema you just need to
> come up with real world examples of what can't be expressed using 0.95.2
> and we will do one of the three things above. If there are enough of
> number 2 then we may end up creating the schema you have in mind anyhow!

My concern is less that v0.95.2 might "break", than it is that it will take
time to think through the ramifications/implications of such a substantial
restructring.  But I agree - the most important thing now would be to build
instance documents.  Before I can do that, I have to first get my head
around the new version, and how it would work.

Also, we still haven't seemed to nailed down what a unique "name" object is
(i.e., sensu botany or sensu zoology).  I've been thinking a lot lately
about a completely different approach to identifying a "name object", which
may or may not dovetail well with LC/TCS 0.95 or 0.95.2. I *think* both can
be seamlessly accomodated simultaneously, but I'll need to spend some more
time thinking it through.

I do have a set of related questions that might help serve as a springboard
for instantiating v0.95.2.  Specifically, which of the following would
represent unique "name objects"?

 1. Aiidae Smith
 2. Xiidae Jones
 3. Aus Smith
 4. Xus Jones
 5. Aus Brown [heterotypic junior homonym of Aus Smith]
 5. Aus bea Smith [incorrect gender of species epithet]
 6. Aus bus Smith [correct gender of species epithet]
 7. Aus buus Smith [lapsus of species epithet]
 8. Auus bus Smith [lapsus of genus name]
 9. Aus fus Smith
10. Xus bus (Smith) Jones
11. Xus bus subsp. bus (Smith) Jones
12. Xus bus subsp. fus (Smith) Jones
13. Xus bus var. bus (Smith) Jones
14. Xus bus var. fus (Smith) Jones
15. Xus fus subs. bus (Smith) Jones* [inappropriate prioritisation of fus
and bus]

*I'm not sure how botany would handle the authorship on this one, assuming
someone other than Smith or Brown first combined the set of three names in
this way)


I could go on, but this is a good start.  The point is to illustrate which
of these would be name objects, and if not all of them, then how the
non-objects (e.g., alternate orthographies) would be captured (if at all).

In any case, if I haven't expressed it adequately before, let me express it
now:  THANK YOU to you, Jessie, Robert, and everyone else who have so
willingly responded to the discussions on this list, to have taken the time
to generate a new version of TCS.

Aloha,
Rich