November 2001 - tdwg-content

Re: Taxonomic hierarchy in SDD
by Kevin Thiele 29 Nov '01

29 Nov '01

I agree with all this Eric :-) | While canalization is a risk, there certainly is also merit in trying to | retain the best features of "prior art". The DELTA format has persisted for | over 20 years, which is nearly an eternity in the IT field. It must have | been doing one or two things right. There's no need to follow it too | closely, but certainly we can learn quite a bit from DELTA about what works | well and what doesn't. No-one has suggested ignoring prior art, be it DELTA or any of the other programs. I think we have agreed several times to start with +/- a blank slate, learning as you say quite a bit from DELTA, Lucid etc about what works and what doesn't along the way. | >2. Of all the descriptions in the world, 99.9999999% of them are not in | >DELTA. Probably 99.999% of them are textual (natural language) descriptions. | >Surely this should form the basis of our first challenge, methinks. | | I think that's actually a rather harsh assessment of DELTA's uptake. Let's | say there are about 4x10^6 known species. We'd like descriptions for them | all, along with descriptions of higher taxonomic levels (genera, families). | So the magnitude of total number of descriptions is about 10^7. I'd guess | that the number of taxa with DELTA descriptions is of the magnitude of | 10^5. So that means roughly 1% of all taxa already have a DELTA description. I didn't stop to consider the maths, for which my apologies. My point was simply that a vast minority of decriptions are in any type of standardised format at the present. If your estimations are correct (and I can't judge that) then there are still 99 non-DELTA descriptions for every DELTA one, or any other. | >3. Related to 2 above, many (though by no means all) DELTA datasets are | >already abstractions from the source (a set of natural language | >descriptions). We should start with the source. | | The source? Surely the ultimate source is observations made on individual | specimens. If we wish to start with the source, the first thing that needs | to be done is to make sure that we have a system which can adequately | describe a specimen in hand. Yes, you're right about the ultimate source, but there are chains of sources, of course. The reason why I'm interested in the vast legacy of textual descriptions as source material is that I think that effective semi-automated processing of these descriptions along the lines of Pankhurst and Taylor is not too far off (some processing is here already, if course). We should make this easier rather than harder, if at all possible. Capturing the truly ultimate direct observations is something that any Builder program supporting the new standard will have to be good at, of course. | (Sorry if I get too defensive about DELTA. I just can't help myself...) Please don't think that I'm too dismissive of DELTA. I just think we should be assuming that we can do a fair bit better. Cheers - k

1 0

Document vs. database
by Eric Zurcher 29 Nov '01

29 Nov '01

At 02:15 PM 28-11-01 +1100, Kevin Thiele wrote: >Issues > >I've taken the route of marking up a textual description, using a minimum of >tags. It seems to me that a description comprises a series of features with >values. I've used mixed markup because I wanted to have the mimimum tagging >and make maximum use of the text. That is, in cases like: > ><Feature Name="Life form"><Value>shrub</Value></Feature> > >I've made use of the fact that "shrub" occurs in the text by enclosing it in ><Value> tags. In cases like: > ><Feature><Name>Leaves</Name> > >I'm using a <Name> tag rather than a Name attribute > >This may make processing considerably more difficult, but it seems to me >that there are some advantages. An alternative would be to first process the >description into a DELTA-like structure then mark up that. I chose not to go >that route because I still have the dream that one day we'll have a method >of semi-automatically marking up the content of natural language into >something like the above. The other advantage of this structure I believe is >that it maintains all the complexity and nuance of the original natural >language (which can be retrieved merely by removing all the tags). I prefer >this to the DELTA-process (take a natural-language description -> atomise >it -> reconstruct semi-natural-language by putting the atoms back together >again in some fashion). My position on this is rather different, and I would prefer to see characters defined a bit more rigorously. As an example, suppose that the description of one taxon is given as: <Feature Name="Life form"><Value>shrub</Value></Feature> A second as: <Feature Name="Life form"><Value>bush</Value></Feature> And a third as: <Feature Name="Life form"><Value>small woody plant</Value></Feature> And perhaps a fourth as: <Feature Name="Growth form"><Value>shrub</Value></Feature> Are these equivalent? There's certainly no obvious way to associate them, aside from knowing that "bush" and "shrub" mean pretty much the same thing in some dialects of English. I think the goal of trying to extract meaning by inserting a few tags into existing textual descriptions relies too heavily on a level of artificial intelligence that we're still unlikely to see for a couple of decades. But pondering on this made me think about why Kevin and I often disagree on some of these issues. If I may greatly over-simplify our viewpoints, his view is (I think) that a formal description ought to be a document from which data can be extracted; whereas I tend of view a formal description more as a database from which text can be generated. So what ARE we after: the free-flowing flexibility of a document, or the rigour and precision of a database? Fortunately, there is a fair bit of middle ground. It's worth noting that XML was developed as a markup language for documents, but that it's primary usage to date has been as a sort of portable and relatively light-weight data container. Still I think that finding the right balance between flexibility and rigour is going to be a major challenge in this exercise. >Features are nested: > ><Feature><Name>Leaves</Name> > <Feature><Name>Shape</Name></Feature> ></Feature> > >Is this allowable? In XML-Spy I can create a Schema OK for this document. >It's also well-formed. It's certainly allowable in XML. Is it desirable in a description? Possibly, but I think it relates to my question from yesterday about hierarchies of characters ought to be expressed. Nesting is a very good way to express a single hierarchy, but not for handling alternative hierarchies. Which do people want? Eric Zurcher CSIRO Livestock Industries Canberra, ACT Australia E-mail: Eric.Zurcher(a)pi.csiro.au

1 0

Re: Taxonomic hierarchy in SDD
by Eric Zurcher 29 Nov '01

29 Nov '01

At 12:38 PM 28-11-01 +1100, Kevin Thiele wrote: >Concerning Steve's exemplar drawn from a DELTA butterfly treatment: I've >added a few challenges to the challenge cases (number 9 in the attached) >specifically designed to address representation of DELTA datasets in the new >standard. Personally, I don't think we should start with a DELTA data set as >our first challenge, for several reasons: > >1. We have agreed several times that it's important not to be canalized by >DELTA or any other existing representation, but to keep the existing >representations in mind while working. Starting with XDELTA seems to me to >increase the risk of canalization While canalization is a risk, there certainly is also merit in trying to retain the best features of "prior art". The DELTA format has persisted for over 20 years, which is nearly an eternity in the IT field. It must have been doing one or two things right. There's no need to follow it too closely, but certainly we can learn quite a bit from DELTA about what works well and what doesn't. >2. Of all the descriptions in the world, 99.9999999% of them are not in >DELTA. Probably 99.999% of them are textual (natural language) descriptions. >Surely this should form the basis of our first challenge, methinks. I think that's actually a rather harsh assessment of DELTA's uptake. Let's say there are about 4x10^6 known species. We'd like descriptions for them all, along with descriptions of higher taxonomic levels (genera, families). So the magnitude of total number of descriptions is about 10^7. I'd guess that the number of taxa with DELTA descriptions is of the magnitude of 10^5. So that means roughly 1% of all taxa already have a DELTA description. >3. Related to 2 above, many (though by no means all) DELTA datasets are >already abstractions from the source (a set of natural language >descriptions). We should start with the source. The source? Surely the ultimate source is observations made on individual specimens. If we wish to start with the source, the first thing that needs to be done is to make sure that we have a system which can adequately describe a specimen in hand. (Sorry if I get too defensive about DELTA. I just can't help myself...) Eric Zurcher CSIRO Livestock Industries Canberra, ACT Australia E-mail: Eric.Zurcher(a)pi.csiro.au

1 0

Challenge Case 1
by Barringer, Kerry 28 Nov '01

28 Nov '01

Attached are the files for a partial solution to the first Challenge case. I have deliberately left out the XSLT code that capitalizes the first letter in a sentence and eliminates the comma before the period. The stuff I have written is awkward and embarassing and I will try to come up with a more elegant way that can be used for general formatting of the nodes. This DTD corrects some of the typos in the DTD posted yesterday. The XML file should validate against this DTD. I commented out the DOCTYPE line in the XML because the Xalan parser is fussy about how the file location is cited and I wanted one file to test with all the parsers. The XSLT code runs correctly using Microsoft, Sablotron, Saxon, and Xalan parsers in XMLCooktop. The resulting html file is also attached. I had to do this because the code does not run properly under MS Internet Explorer 5.5. This could be a namespace problem. I will look into it. Unfortunately, I did this coding before I saw Kevin Thiele's Nov 27 posting. That posting contains some good ideas about markup that I want to incorporate in this DTD. I especially like his handling of 'shrub' as a character state, not a name. Like Kevin, I nest characters. There are many small differences in the two approaches. The most notable is the handling of numeric characters and ranges. My approach may be too simple for anything but natural language output. As a side challenge, I would like to try to develop code that would produce a tabular description from this markup. The table should have blank cells for missing data. This will help determine if it is necessary to code missing characters as part of the description, or if we can get by with only coding the character we know. I think the later approach is most practical. This will also help determine if nested characters can be used. Kerry ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Kerry Barringer (Curator of the Herbarium) Herbarium 718-623-7318 (office) Brooklyn Botanic Garden 718-941-4774 (fax) 1000 Washington Avenue 718-623-7312 (herbarium) Brooklyn, NY 11225-1099 U.S.A. kbarringer(a)bbg.org http://www.bbg.org/ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

1 0

Challenge 1
by Kevin Thiele 28 Nov '01

28 Nov '01

Here's my first go at representing Challenge 1. The challenge: Rigid, spreading shrub to c. 1m high and wide; stems glabrous. Leaves soon deciduous (particularly on older plants), +/- oblong, (4-)6-10(-15) mm long, 2-3 mm wide, apex obtuse or minutely mucronate within an apical notch, glabrous or a few hairs present near tip; stipules dark reddish-brown, c. 1 mm long, often shallowly joined around the node; spines stout, 1.5-4 cm long. Discaria nitida Slender shrub, to 5 m high; stems glabrous. Leaves persistent (rarely deciduous), elliptic to obovate, (8-)10-20(-30) mm long, 3-7 mm wide, glabrous, shining; spines not developed at each node, to c. 1 cm long. The representation: <Document> <Description Name="Discaria pubescens"> <Feature Name="Habit">Rigid, spreading <Feature Name="Life form"><Value>shrub</Value></Feature><Feature Name="Height"> to c. <Value MinValue="0"/><MaxValue>1</MaxValue><Units>m</Units> high and wide</Feature></Feature>; <Feature Name="Stem indumentum">stems <Value>glabrous</Value></Feature>. <Feature><Name>Leaves</Name><Feature Name="Longevity">soon <Value>deciduous</Value>(particularly on older plants)</Feature>, <Feature Name="Shape">+/- <Value>oblong</Value></Feature>, <Feature Name="Length">(<OutMinValue>4</OutMinValue>-)<MinValue>6</MinValue>-<MaxValu e>10</MaxValue>(-<OutMaxValue>15</OutMaxValue>)<Units> mm</Units> long</Feature>, <Feature Name="Width"><MinValue>2</MinValue>-<MaxValue>3</MaxValue><Units> mm</Units> wide</Feature>, <Feature Name="Apex shape"><Value>obtuse</Value> or minutely <Value>mucronate within an apical notch</Value></Feature>, <Feature Name="indumentum" Value="hairy">surfaces <Value>glabrous</Value> or a few hairs present near tip</Feature>;<Feature><Name>stipules</Name><Feature Name="Colour"><Value Value="Brown"/><Value Value="Red"/>dark reddish-brown</Feature>, c. 1 mm long, <Feature Name="Arrangement">often shallowly <Value>joined around the node</Value></Feature></Feature></Feature> <Feature><Name> spines</Name><Feature Name="Robustness"><Value>stout</Value></Feature>, <Feature Name="Length"><MinValue>1.5</MinValue>-<MaxValue>4</MaxValue><Units>cm</Unit s> long</Feature></Feature>. </Description> <Description Name="Discaria nitida"> <Feature Name="Habit">Slender <Feature Name="Life form"><Value>shrub</Value></Feature><Feature Name="Height"> to <Value MinValue="0"/><MaxValue>5</MaxValue><Units>m</Units>hig</Feature></Feature>; <Feature Name="Stem indumentum">stems <Value>glabrous</Value></Feature>. <Feature><Name>Leaves</Name><Feature Name="Longevity"><Value>persistent</Value>(rarely<Value Qualifier="rarely">deciduous</Value>)</Feature>, <Feature Name="Shape"><Value>elliptic</Value> to <Value>obovate</Value></Feature>, <Feature Name="Length">(<OutMinValue>8</OutMinValue>-)<MinValue>10</MinValue>-<MaxVal ue>20</MaxValue>(-<OutMaxValue>30</OutMaxValue>)<Units> mm</Units> long</Feature>, <Feature Name="Width"><MinValue>3</MinValue>-<MaxValue>7</MaxValue><Units> mm</Units> wide</Feature>, <Feature Name="indumentum" ><Value>glabrous</Value></Feature> shining; </Feature><Feature><Name>spines</Name>, not developing at each node, <Feature Name="Length" MinValue="0">to c. <MaxValue>1</MaxValue><Units>cm</Units> long</Feature></Feature> </Description> </Document> or, if you prefer <Document> <Description Name="Discaria pubescens"> <Feature Name="Habit">Rigid, spreading <Feature Name="Life form"><Value>shrub</Value></Feature> <Feature Name="Height"> to c. <Value MinValue="0"/><MaxValue>1</MaxValue><Units>m</Units> high and wide</Feature> </Feature>; <Feature Name="Stem indumentum">stems <Value>glabrous</Value></Feature>. <Feature><Name>Leaves</Name> <Feature Name="Longevity">soon <Value>deciduous</Value>(particularly on older plants)</Feature>, <Feature Name="Shape">+/- <Value>oblong</Value></Feature>, <Feature Name="Length">(<OutMinValue>4</OutMinValue>-)<MinValue>6</MinValue>-<MaxValu e>10</MaxValue>(-<OutMaxValue>15</OutMaxValue>)<Units> mm</Units> long</Feature>, <Feature Name="Width"><MinValue>2</MinValue>-<MaxValue>3</MaxValue><Units> mm</Units> wide</Feature>, <Feature Name="Apex shape"><Value>obtuse</Value> or minutely <Value>mucronate within an apical notch</Value></Feature>, <Feature Name="indumentum" Value="hairy">surfaces <Value>glabrous</Value> or a few hairs present near tip</Feature>; <Feature><Name>stipules</Name> <Feature Name="Colour"><Value Value="Brown"/><Value Value="Red"/>dark reddish-brown</Feature>, c. 1 mm long, <Feature Name="Arrangement">often shallowly <Value>joined around the node</Value></Feature> </Feature> </Feature> <Feature><Name> spines</Name> <Feature Name="Robustness"><Value>stout</Value></Feature>, <Feature Name="Length"><MinValue>1.5</MinValue>-<MaxValue>4</MaxValue><Units>cm</Unit s> long</Feature> </Feature>. </Description> <Description Name="Discaria nitida"> <Feature Name="Habit">Slender <Feature Name="Life form"><Value>shrub</Value></Feature> <Feature Name="Height"> to <Value MinValue="0"/><MaxValue>5</MaxValue><Units>m</Units>high</Feature> </Feature>; <Feature Name="Stem indumentum">stems <Value>glabrous</Value></Feature>. <Feature><Name>Leaves</Name> <Feature Name="Longevity"><Value>persistent</Value>(rarely<Value Qualifier="rarely">deciduous</Value>)</Feature>, <Feature Name="Shape"><Value>elliptic</Value> to <Value>obovate</Value></Feature>, <Feature Name="Length">(<OutMinValue>8</OutMinValue>-)<MinValue>10</MinValue>-<MaxVal ue>20</MaxValue>(-<OutMaxValue>30</OutMaxValue>)<Units> mm</Units> long</Feature>, <Feature Name="Width"><MinValue>3</MinValue>-<MaxValue>7</MaxValue><Units> mm</Units> wide</Feature>, <Feature Name="indumentum" ><Value>glabrous</Value></Feature> shining; </Feature> <Feature><Name>spines</Name>, not developing at each node, <Feature Name="Length" MinValue="0">to c. <MaxValue>1</MaxValue><Units>cm</Units> long</Feature> </Feature> </Description> </Document> Issues I've taken the route of marking up a textual description, using a minimum of tags. It seems to me that a description comprises a series of features with values. I've used mixed markup because I wanted to have the mimimum tagging and make maximum use of the text. That is, in cases like: <Feature Name="Life form"><Value>shrub</Value></Feature> I've made use of the fact that "shrub" occurs in the text by enclosing it in <Value> tags. In cases like: <Feature><Name>Leaves</Name> I'm using a <Name> tag rather than a Name attribute This may make processing considerably more difficult, but it seems to me that there are some advantages. An alternative would be to first process the description into a DELTA-like structure then mark up that. I chose not to go that route because I still have the dream that one day we'll have a method of semi-automatically marking up the content of natural language into something like the above. The other advantage of this structure I believe is that it maintains all the complexity and nuance of the original natural language (which can be retrieved merely by removing all the tags). I prefer this to the DELTA-process (take a natural-language description -> atomise it -> reconstruct semi-natural-language by putting the atoms back together again in some fashion). Features are nested: <Feature><Name>Leaves</Name> <Feature><Name>Shape</Name></Feature> </Feature> Is this allowable? In XML-Spy I can create a Schema OK for this document. It's also well-formed. In this example, there is not a 1:1 correspondence between the descriptions - e.g. the description for D. pubescens has <Feature Name="Apex shape"> while that for D. nitida does not. This is anathema to most of us, but is a real world case. We'll have to deal with it. In this example there is no character list against which character names etc can be validated (to e.g. pick up the above problem). This is something we need to deal with. Be gentle with me. Your mission, should you choose to accept it, is to show that I'm crazy and do better than this. This email will self-destruct in 5 seconds Cheers - k

1 0

Re: Morphological Data Representation
by Guillaume Rousse 28 Nov '01

28 Nov '01

Ainsi parlait Steve Shattuck : [..] > Guillaume commented that he's "always surprised seeing people recommend > using proprietary stuff" in response to my suggestion of using Microsoft's > XML Notepad (which, by the way, is actually free). The point I was trying > to make was that XML can get complicated very quickly and using an XML view > (of any sort) is better than using a text editor. Nothing more. 'Free' in free software refers to freedom, not price (think free speech, not free beer). XML Notepad is freeware (currently), not free software. I think distinction here is really important. And about the utility of a dedicated xml editor vs a text editor, it is defenitively a question of personal taste. It all depends of the editor, the ease you have with it, etc... As a die-hard vim-user, i never found any specialized xml editor which allowed so many functionalities. -- Guillaume Rousse <rousse(a)ccr.jussieu.fr> GPG key http://lis.snv.jussieu.fr/~rousse/gpgkey.html

1 0

Re: Morphological Data Representation
by Kevin Thiele 28 Nov '01

28 Nov '01

1 0

Re: Taxonomic hierarchy in SDD
by Kevin Thiele 28 Nov '01

28 Nov '01

Can I propose that we note but set aside the Taxonomic Hierarchy thread for the moment. In the challenge cases, Challenge 7 will begin to address this issue (in this challenge we will attempt to represent descriptions from a nested set of descriptions e.g. family (genus (species (specimens)))). When this comes up, we will need to address both hierarchy as a way of handling inheritance, and also alternate hierarchies (differing taxonomic opinions). But surely we need to work out how to represent a single description before we tackle a nested set. Concerning Steve's exemplar drawn from a DELTA butterfly treatment: I've added a few challenges to the challenge cases (number 9 in the attached) specifically designed to address representation of DELTA datasets in the new standard. Personally, I don't think we should start with a DELTA data set as our first challenge, for several reasons: 1. We have agreed several times that it's important not to be canalized by DELTA or any other existing representation, but to keep the existing representations in mind while working. Starting with XDELTA seems to me to increase the risk of canalization 2. Of all the descriptions in the world, 99.9999999% of them are not in DELTA. Probably 99.999% of them are textual (natural language) descriptions. Surely this should form the basis of our first challenge, methinks. 3. Related to 2 above, many (though by no means all) DELTA datasets are already abstractions from the source (a set of natural language descriptions). We should start with the source. This time I've attached the attachment. Sometime soon we'll put this up on the web instead of flying it around as an attachment. Cheers - k

1 0

Re: Taxonomic hierarchy in SDD
by Eric Zurcher 28 Nov '01

28 Nov '01

One additional point to consider is that hierarchies arise not only in the classification of items (taxa or specimens), but also in the classification of the characters used to describe those item. And along both the item and character "axes", there will often be multiple, alternative hierarchies which reflect different purposes or philosophies. For example, in assembling an interactive key to plants, one might well want to group characters dealing with leaves separately from characters dealing with the infloresence. And perhaps a trickier "hierarchy" of characters is one that might be used to describe the rules for "natural language" generation, aggregating characters into phrases, sentences and paragraphs. Does anyone see a good generalized mechanism for handling the creation and maintenance of hierarchies (or other groupings)? Here are a few thoughts off the top of my head: Because of the need for handling alternative hierarchies for different purposes, it would seem logical to keep the "classification" separate from the "core" data (going back to DELTA, this was one reason why "directives" files were used - it provided a mechanism for changing groupings without touching the core data). But this approach comes at a significant cost: if the "core" data is changed, it will probably require synchronized changes in the various hierarchy descriptions which reference that data. Maintaining consistency becomes a problem. Perhaps the way out is to make use of unique global identifiers (GUIDs), as Steve Shattuck has suggested. At 10:43 PM 26-11-01 -0500, Bob Morris wrote: >We may not be arguing here. I don't dispute the need for this, only >argue that there should not be a standard for taxonomy, but rather a >standard for how to specify taxonomy. Or any other hierarchy for that >matter. > >Doing this would allow you to get the hiearchy from /any/ suitable >source, including but not limited to the data source itself. To me it >seems that the least brittle thing for data inheritance is to use the >same model as for datatype inheritance, i.e. a separate "schema" to >which reference is made, as Tim Jones argued. Eric Zurcher CSIRO Livestock Industries Canberra, ACT Australia E-mail: Eric.Zurcher(a)pi.csiro.au

1 0

Re: Taxonomic hierarchy in SDD
by Robert A. (Bob) Morris 27 Nov '01

27 Nov '01

Here's another need for Use Cases. Oops. I mean data challenges. I suspect it is not profitable to approach this problem without detailed examples. Those examples might illuminate whether the problems of hierarchy rearangement can simply be handled by XSLT, as probably can the examples you give. Bob Morris Eric Zurcher writes: > Date: Wed, 28 Nov 2001 09:54:06 +1100 > From: Eric Zurcher <Eric.Zurcher(a)pi.csiro.au> > To: TDWG-SDD(a)usobi.org > Subject: Re: Taxonomic hierarchy in SDD > > One additional point to consider is that hierarchies arise not only in the > classification of items (taxa or specimens), but also in the classification > of the characters used to describe those item. And along both the item and > character "axes", there will often be multiple, alternative hierarchies > which reflect different purposes or philosophies. > > For example, in assembling an interactive key to plants, one might well > want to group characters dealing with leaves separately from characters > dealing with the infloresence. And perhaps a trickier "hierarchy" of > characters is one that might be used to describe the rules for "natural > language" generation, aggregating characters into phrases, sentences and > paragraphs. > > Does anyone see a good generalized mechanism for handling the creation and > maintenance of hierarchies (or other groupings)? > > Here are a few thoughts off the top of my head: Because of the need for > handling alternative hierarchies for different purposes, it would seem > logical to keep the "classification" separate from the "core" data (going > back to DELTA, this was one reason why "directives" files were used - it > provided a mechanism for changing groupings without touching the core > data). But this approach comes at a significant cost: if the "core" data is > changed, it will probably require synchronized changes in the various > hierarchy descriptions which reference that data. Maintaining consistency > becomes a problem. Perhaps the way out is to make use of unique global > identifiers (GUIDs), as Steve Shattuck has suggested. > > At 10:43 PM 26-11-01 -0500, Bob Morris wrote: > >We may not be arguing here. I don't dispute the need for this, only > >argue that there should not be a standard for taxonomy, but rather a > >standard for how to specify taxonomy. Or any other hierarchy for that > >matter. > > > >Doing this would allow you to get the hiearchy from /any/ suitable > >source, including but not limited to the data source itself. To me it > >seems that the least brittle thing for data inheritance is to use the > >same model as for datatype inheritance, i.e. a separate "schema" to > >which reference is made, as Tim Jones argued. > > Eric Zurcher > CSIRO Livestock Industries > Canberra, ACT Australia > E-mail: Eric.Zurcher(a)pi.csiro.au >

1 0