- tdwg-content - lists.tdwg.org

Re: [Tdwg-lit] Level 2 starting point
by Roger Hyam 15 Feb '06

15 Feb '06

Hi Anna and all, Two points on this: 1. RDF does not stop you building nested structures, quite the opposite. So long as the structure goes node-arc-node (or Object-property-Object-property if you prefer) it can be nested as deep as you like. You can therefore have an XML structure that both vaildates against an XML Schema or DTD and is valid RDF (see http://www.prismstandard.org where they do this). This would be a good way to think about designing XML Schema based documents even if you had no intention of using RDF. 2. RDF is not a panacea. It would be crazy to try and describe documents with it when one should be use XHTML or some other document centric approach. It is good for 'metadata' (depending on what that is) though. There seems to be a rumour going round that everything is going to be RDF starting next week. This is news to me! It seems like a good idea to evaluate RDF as an interoperability mechanism between standards though and the use of LSIDs suggests heading in this direction to describe objects. Whether the objects themselves are encoded in RDF is something else. All the best, Roger On 15/02/06, Anna Weitzman <Weitzman(a)si.edu> wrote: > > Good points. I wonder if TDWG-TAG will be the place for this larger, > conceptual discussion? > > >>> "Gregor Hagedorn" <G.Hagedorn(a)BBA.DE> 15-Feb-2006 7:51:45 AM >>> > > One comment following from the GUID meeting is that I believe we need to > get > > serious about being able to represent our data models in RDF. This means > > that the goal should indeed be for a "flat" (Darwin Core like) standard. > If > > there are elements which hold nested complexity that we wish to > represent, > > we should recognise that these are probably separate data objects which > > should be modeled as separable components (with their own "flat" > standards). > > The top level object can then have a property whose value is the > identifier > > for one of the lower level components. Even if we choose to compose rich > > documents with entire trees of object relationships, the underlying > model > > should make these separations clear. > > I am concerned about this, to me it seems to block the way into a future > for > scientific data exchange. > > Flat list is great for advertising, (see e.g. DublinCore, DarwinCore or > RSS), > but not really for exchanging complex data. > > Completely forbidding any object aggregation would mean that each > measurement > of a specimen has a stand-alone resource... Or each author in a > publication > (because authors have addresses, so they can not be just a list, the list > elements have structure). > > Where can we discuss this issue which goes far beyond the TDWG-LIT? > > Gregor---------------------------------------------------------- > Gregor Hagedorn *(G.Hagedorn(a)bba.de <%28G.Hagedorn(a)bba.de>* ) > Institute for Plant Virology, Microbiology, and Biosafety > Federal Research Center for Agriculture and Forestry (BBA) > Königin-Luise-Str. 19 Tel: +49-30-8304-2220 > 14195 Berlin, Germany Fax: +49-30-8304-2203 > > > _______________________________________________ > TDWG-Lit mailing list > *TDWG-Lit(a)lists.tdwg.org* > *http://lists.tdwg.org/mailman/listinfo/tdwg-lit_lists.tdwg.org* > -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

1 0

Re: [Tdwg-lit] Level 2 starting point
by Anna Weitzman 15 Feb '06

15 Feb '06

Good points. I wonder if TDWG-TAG will be the place for this larger, conceptual discussion? >>> "Gregor Hagedorn" <G.Hagedorn(a)BBA.DE> 15-Feb-2006 7:51:45 AM >>> > One comment following from the GUID meeting is that I believe we need to get > serious about being able to represent our data models in RDF. This means > that the goal should indeed be for a "flat" (Darwin Core like) standard. If > there are elements which hold nested complexity that we wish to represent, > we should recognise that these are probably separate data objects which > should be modeled as separable components (with their own "flat" standards). > The top level object can then have a property whose value is the identifier > for one of the lower level components. Even if we choose to compose rich > documents with entire trees of object relationships, the underlying model > should make these separations clear. I am concerned about this, to me it seems to block the way into a future for scientific data exchange. Flat list is great for advertising, (see e.g. DublinCore, DarwinCore or RSS), but not really for exchanging complex data. Completely forbidding any object aggregation would mean that each measurement of a specimen has a stand-alone resource... Or each author in a publication (because authors have addresses, so they can not be just a list, the list elements have structure). Where can we discuss this issue which goes far beyond the TDWG-LIT? Gregor---------------------------------------------------------- Gregor Hagedorn (G.Hagedorn(a)bba.de ) Institute for Plant Virology, Microbiology, and Biosafety Federal Research Center for Agriculture and Forestry (BBA) Königin-Luise-Str. 19 Tel: +49-30-8304-2220 14195 Berlin, Germany Fax: +49-30-8304-2203 _______________________________________________ TDWG-Lit mailing list TDWG-Lit(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-lit_lists.tdwg.org

1 0

[Tdwg-lit] Level 2 starting point
by Anna Weitzman 15 Feb '06

15 Feb '06

Dear All, Attached is the starting point of the level 2 standard. This is very much an intermediate between the other two standards, but as was discussed in the TDWG meetings, it is very much needed for a number of reasons. It will certainly be vital if we are to accommodate (and drive) the metadata choices that are made for the big literature digitization projects that are in the pipeline. Once again, please review: Requirements (do you have others? are these the right ones?) Content elements. Thanks Anna & Chris

3 2

[Tdwg-lit] Level 1 starting point
by Anna Weitzman 15 Feb '06

15 Feb '06

Dear All, This is the first of several strings that we are sending to the list for consideration and discussion. ++++ Proposed Level 1 Standard Attached is the basic content we discussed at the TDWG meetings, and which we now need to consider. Could you please consider the contents as set out? Are there elements anything missing? Does it meet the need that you envision for this standard? Do any of you who attended the recent TDWG GUID meeting have anything to bring up related to the LSID/GUID portion? Thanks, Anna & Chris

4 3

[Tdwg-obs] Public working draft of NatureServe Species Occurrence Schema, comments invited
by Lynn Kutner 13 Feb '06

13 Feb '06

Please note that the NatureServe species occurrence data is typically at a coarser scale than observation or collection data: A Species Occurrence (SO) is an area of land and/or water in which a species is, or was, present. A SO should have practical conservation value for the species as evidenced by potential continued (or historical) presence and/or regular recurrence at a given location. For species Elements, the SO often corresponds with the local population, but when appropriate may be a portion of a population (e.g., long distance dispersers) or a group of nearby populations (e.g., metapopulation). A SO record has both spatial and tabular components including a mappable feature and its supporting database attributes. Thank you for your time. Instructions for providing comments can be found at the bottom of this email. Lynn Lynn Kutner NatureServe Email: lynn_kutner(a)natureserve.org Phone: (303) 541-0360 www.natureserve.org ________________________________ From: Douglas Sellers Sent: Friday, February 10, 2006 11:39 AM Cc: Bruce Stein; Lori Scott; Leslie Honey Subject: Public working draft of NatureServe Species Occurrence Schema, comments invited NatureServe is pleased to announce the release of a public working draft (version 0.3) of an XML schema to describe species occurrence-level data as reflected in NatureServe's biodiversity data model. We are seeking public review and comments on this version until March 3, 2006. Comments received during the review period will be addressed in the next release, version 1.0. NatureServe is evolving its data delivery strategy to use XML-based, Web services protocols. Last month the NatureServe Species Schema, describing species profile-type information managed by NatureServe, and familiar to many through our NatureServe Explorer website (www.natureserve.org/explorer) was released for public review. The Species Occurrence Schema that is the subject of this announcement is complementary to that schema, and focuses on describing spatially explicit species locality data as managed by the NatureServe network. The data represented by this schema provides a new level of spatial precision not currently available on NatureServe Explorer. Our Web services strategy for sharing data among NatureServe network members and with the broader community is dependent upon the usability of these XML schemas. For this reason, we are seeking as wide a review as possible among our colleagues within the biodiversity informatics community, and especially from those organizations that regularly rely on and interact with NatureServe data. Reviewers are invited to submit comments on either the content or the structure of the XML documents. Content reviewers will want to follow the link for the human-readable documentation. We have also provided a sample document for review, which contains example data in XML format for one species occurrence record of Ardea herodias (Great Blue Heron). Reviewers should also note that this schema incorporates mapped occurrence location information, represented as polygon shapes. In compliance with Open Geospatial Consortium (OGC) standards for web map and web feature services, the spatial elements of the species occurrence schema are represented using Geography Markup Language (GML). In addition to the human readable documentation, technical reviewers will find useful the links to the XSD documents. Technical reviewer comments may cover the names of the XML tags, the nesting of the XML document, the structure of the XML schema, and the organization of the GML components. Technical reviewer comments from organizations that may develop applications to consume NatureServe data as expressed by these XML schema are highly encouraged. The NatureServe Species Occurrence Schema documentation can be found at: http://services.natureserve.org/technical/speciesOccurrenceSchema.htm Please submit comments using the feedback forms found at the same location, or via email to: services(a)natureserve.org The complementary NatureServe Species Schema documentation can be found at: http://services.natureserve.org/technical/speciesSchema.htm Reviewers may find it useful to compare the two documents. While the public comment period for the species schema has closed, we will consider new comments as time permits within the schedule for releasing the next version.

2 1

[Tdwg-obs] Controlled vocabularies are a bad thing!
by Roger Hyam 12 Feb '06

12 Feb '06

Hi, I am splitting this out of the thread on observation definition as it is somewhat off that topic but I am quoting from something Denis said. Denis said: "The main issue here will be to *standardize how people are allowed to use the BasisOfObservation field *(through controlled vocabulary), and to find ways to know whether you are reporting measurements (eg, mass) about the sample only or the full organism." (My emphasis) I am interested in the notion of controlled vocabularies. We don't have them in normal text communication. Although I am picking words from a dictionary as I type I am free to make up my own words at any time. You may be able to understand their meaning from context or you may simply fail to understand what I am talking about. Words are normally added to dictionaries *after *they are in use not before. If we invent controlled vocabularies for communication then we have to guess all the terms that anyone is likely to use ahead of time. A little like compiling a dictionary before we can use a language. This is: * Difficult - we have to have some person or group of people with 100% knowledge of the domain. * Time Consuming - because people don't know everything they have to go away and learn and debate etc etc - possibly for years. * Error Prone - Once a list is settled on it will contain errors (everything does). People will also use the existing terms to mean something different from their official definition because they can't invent their own terms - the purpose of having the controlled vocabulary will be lost. * Unresponsive - once we have a list we have to stick with it till we update the whole thing. * Potentially difficult to manage - if the list is embedded in an XML Schema or imported into such a schema then changing it to add a new kind of animal trace for example will involve updating multiple schemas and possibly software etc etc. I therefore suggest that it is far better to have 'recommended' vocabularies similar to Dublin Core where terms can be added and mixed with those from other vocabularies rather than 'hard-coded' vocabularies as occur in may XML Schema implementations. People should be allowed to put what they like in BasisOfObservation field but should only expect to be understood if they use something from a common vocabulary. (The vocabulary has the chance to be self explaining if it uses URI/GUIDs - but that is another topic.) I appreciate that this may be a sea change for some people in the way we think about transfer standards but believe it is the only way forwards if we want to handle the complexity of our data. Thoughts and observations(!) much appreciated. Roger -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

2 1

Re: [Tdwg-obs] Antw: Re: On observation definition / moving forward
by Denis Lepage 11 Feb '06

11 Feb '06

Hi again, I agree that Sabine's point is really pertinent, and I believe can be covered by a DarwinCore field called BasisOfObservation (or something along those lines). The record can be use to describe an observation, a specimen, or a sample of some sort, which is linked to the presence of an organism. I believe that as long as you can put a taxonomic name to a sample, it can easily be described using the existing core structure, plus some discipline-specific descriptors. The taxonomic name doesn't have to down to the species level (can be family, order, etc.). The main issue here will be to standardize how people are allowed to use the BasisOfObservation field (through controlled vocabulary), and to find ways to know whether you are reporting measurements (eg, mass) about the sample only or the full organism. Where I think this will break down is when you'll try to describe non-living things (rocks, clouds, whatever). You probably still could to some extent, but that'd be a stretch of the primary purpose of a schema used for describing biodiversity monitoring. Good weekend everyone Denis -----Original Message----- From: Tdwg-obs-bounces(a)lists.tdwg.org on behalf of tdwg(a)achapman.org Sent: Fri 2/10/2006 16:55 To: Tdwg-obs(a)lists.tdwg.org Subject: Re: [Tdwg-obs] Antw: Re: On observation definition / moving forward Denis, I agree with your sentiments here, and it is the only way we can handle the vast amount of differences. More than people expect, however, can be generalised for different groups. Allan Allison and myself had an intereting example of this in Indonesia many years ago where we were working with foresters, fisherman, insect people and botanists, and trying to look at the common denominator in as many fields as possible. One that came up was collecting method where virtually every group saw their group as so specialised and wanted fields that would only apply to them (fishermen for example for net type, size etc.) We eventually got them all to see that we could use just "collecting method" with a different set of terms for each group. But I think Sabine has an additional point that needs to be covered. If I read Sabine rightly, she is talking about what the observation may be and not necessarily the aspects of that observation (measurements etc.). I think there are perhaps two aspects to what she is saying. I can see the need for observation of "scat" or "hair" for mammals, "pupa" "lavae" for insects, "fruit" for plants, "nest" for a bird, etc. where these may have been observed separately from the main animal/plant etc. It is an observation, but not an obseration of the whole animal/plant, etc. I am not sure that 'Unit' is the best term, though - worth discussing. Cheers Arthur D. Chapman Toowoomba, Australia >>>From Denis Lepage <dlepage(a)bsc-eoc.org> on 10 Feb 2006: > Hi Sabine, > > What you describe for plants is very much like what we often find in > ver> tebrates. > > At any given sampling event, you may want to characterise differently > un> its that belong to the same taxon. In birds, if you are talking about > ba> nding (ringing) data, you typically want to record the characteristics > o> f each individual (mass, body measurements, sex, band number, etc.). > For> that reason, a schema needs to allow repeating the same taxonomic unit > > multiple times in the same sampling event, each record with its own > char> acteristics. On the other hand, if you have a group of organisms that > al> l share exactly the same characteristics, it makes a lot more sense to > h> ave a field that tell you how many times this unit was repeated, rather > > than have separate records for each. > > For all biodiversity monitoring, there are common fields that will > allow> you to describe what your unit is (taxonomic fields), in addition to > ot> her fields such date, time, location, etc. But each discipline will > also> have its own requirements. Bird banders typically do not care about > soi> l or water pH, and you surely do not need to describe whether your > units> had a brood patch. > > In a schema, the way to handle this is to put everything that is common > > to all disciplines in the core list of fields. DarwinCore already gives > > a number of those fields, but there are more common fields that can be > a> dded (DarwinCore was initially designed for museum specimens). > Everythin> g that is specific to a limited number of disciplines then need to be > pa> rt of a schema extension. In birds monitoring, we think so far that > this> will represent about 4 or 5 different extensions (one for surveys, one > > for bird banding, one for nest records, etc.). The agrobiodiversity > comm> unity will have to work on it's own extensions, as will other > communitie> s (which don't necessarily have to be taxon-based). > > Cheers > Denis > > Denis Lepage, Senior Scientist/Chercheur sénior > National Data Center/Centre national des données > Bird Studies Canada/Études d'Oiseaux Canada > PO Box/B.P. 160, Port Rowan, ON N0E 1M0 > 519-586-3531 ext. 225, fax/téléc. 519-586-3532 > > > > -----Original Message----- > > From: Tdwg-obs-bounces(a)lists.tdwg.org > > [mailto:Tdwg-obs-bounces@lists.tdwg.org]On Behalf Of SABINE ROSCHER > > Sent: 10 February 2006 9:11 AM > > To: Tdwg-obs(a)lists.tdwg.org > > Subject: [Tdwg-obs] Antw: Re: On observation definition / > > moving forward > > > > > > Hello, > > > > We work in the field of agrobiodiversity, e.g. crop wild > > relatives. For us the combination of oberservation data and > > samples is very important. > > > > We consider the unit as central element, which can be a part > > of an organism, an ogranism, or a group of organisms. The > > reason for going under the level of organism is that > > sometimes the plant with all roots etc. can be quite larger > > than the part that is observed and recorded for a certain location. > > > > This describes the line we think along : > > "A unit in our context is uniquely identified by time, > > place(site) and taxonomy. In addition a particular unit could > > be sampled to further assist in characterising it. Such > > samples could be (1) seed samples/planting material > > (classical ex situ accessions), (2) photos or (3) herbarium vouchers." > > > > UNIT {time, site, taxonomy} (+ sample) > > > > (With regard to the prior discussion I agree that we also > > have to handle legacy data with missing entries for time and place.) > > > > Sabine > > > > > > Sabine Roscher > > 513 - Informations- und Koordinationszentrum für Biologische > > Vielfalt (IBV) > > Bundesanstalt für Landwirtschaft und Ernährung > > Deichmanns Aue 29, 53179 Bonn > > Tel.: +49 (0)228 6845-3235 (oder -3237) > > Fax: +49 (0)228 6845-3787 > > E-Mail: sabine.roscher(a)ble.de > > Internet: www.ble.de > > weiterführende Information: www.genres.de > > > > > > >>> Steve Kelling <stk2(a)cornell.edu> 09.02.2006 18:55 >>> > > Hello, > > I really like the improvements made on the definition, and I > > might suggest > > that I put it up on the TDWG-obs website > > http://www.avianknowledge.net/tdwg. > > I think we still need to define occurrence, and I think that Arthur > > Chapman's "species occurrence data" gets us most of the way === message truncated ==

1 0

Re: [Tdwg-obs] Antw: Re: On observation definition / moving forward
by Denis Lepage 10 Feb '06

10 Feb '06

Hi Sabine, What you describe for plants is very much like what we often find in vertebrates. At any given sampling event, you may want to characterise differently units that belong to the same taxon. In birds, if you are talking about banding (ringing) data, you typically want to record the characteristics of each individual (mass, body measurements, sex, band number, etc.). For that reason, a schema needs to allow repeating the same taxonomic unit multiple times in the same sampling event, each record with its own characteristics. On the other hand, if you have a group of organisms that all share exactly the same characteristics, it makes a lot more sense to have a field that tell you how many times this unit was repeated, rather than have separate records for each. For all biodiversity monitoring, there are common fields that will allow you to describe what your unit is (taxonomic fields), in addition to other fields such date, time, location, etc. But each discipline will also have its own requirements. Bird banders typically do not care about soil or water pH, and you surely do not need to describe whether your units had a brood patch. In a schema, the way to handle this is to put everything that is common to all disciplines in the core list of fields. DarwinCore already gives a number of those fields, but there are more common fields that can be added (DarwinCore was initially designed for museum specimens). Everything that is specific to a limited number of disciplines then need to be part of a schema extension. In birds monitoring, we think so far that this will represent about 4 or 5 different extensions (one for surveys, one for bird banding, one for nest records, etc.). The agrobiodiversity community will have to work on it's own extensions, as will other communities (which don't necessarily have to be taxon-based). Cheers Denis Denis Lepage, Senior Scientist/Chercheur sénior National Data Center/Centre national des données Bird Studies Canada/Études d'Oiseaux Canada PO Box/B.P. 160, Port Rowan, ON N0E 1M0 519-586-3531 ext. 225, fax/téléc. 519-586-3532 > -----Original Message----- > From: Tdwg-obs-bounces(a)lists.tdwg.org > [mailto:Tdwg-obs-bounces@lists.tdwg.org]On Behalf Of SABINE ROSCHER > Sent: 10 February 2006 9:11 AM > To: Tdwg-obs(a)lists.tdwg.org > Subject: [Tdwg-obs] Antw: Re: On observation definition / > moving forward > > > Hello, > > We work in the field of agrobiodiversity, e.g. crop wild > relatives. For us the combination of oberservation data and > samples is very important. > > We consider the unit as central element, which can be a part > of an organism, an ogranism, or a group of organisms. The > reason for going under the level of organism is that > sometimes the plant with all roots etc. can be quite larger > than the part that is observed and recorded for a certain location. > > This describes the line we think along : > "A unit in our context is uniquely identified by time, > place(site) and taxonomy. In addition a particular unit could > be sampled to further assist in characterising it. Such > samples could be (1) seed samples/planting material > (classical ex situ accessions), (2) photos or (3) herbarium vouchers." > > UNIT {time, site, taxonomy} (+ sample) > > (With regard to the prior discussion I agree that we also > have to handle legacy data with missing entries for time and place.) > > Sabine > > > Sabine Roscher > 513 - Informations- und Koordinationszentrum für Biologische > Vielfalt (IBV) > Bundesanstalt für Landwirtschaft und Ernährung > Deichmanns Aue 29, 53179 Bonn > Tel.: +49 (0)228 6845-3235 (oder -3237) > Fax: +49 (0)228 6845-3787 > E-Mail: sabine.roscher(a)ble.de > Internet: www.ble.de > weiterführende Information: www.genres.de > > > >>> Steve Kelling <stk2(a)cornell.edu> 09.02.2006 18:55 >>> > Hello, > I really like the improvements made on the definition, and I > might suggest > that I put it up on the TDWG-obs website > http://www.avianknowledge.net/tdwg. > I think we still need to define occurrence, and I think that Arthur > Chapman's "species occurrence data" gets us most of the way > there. My sense > is that the elaborations need to be expanded a bit more. For > example, data > collection event. I suggest that we include in the definition some > information about time, minimum required data, and so forth. These > definitions can be longer and more detailed than the observation > definition. So taking data collection event: An event, > during or after > which at least the minimum required data were recorded. > > Can we identify the minimum required data? For us it is: > who the collector is > where the information was collected (and should refer to occurrence > information and all of the discussion with it) > when the data and time > what was observed (and how many) > effort distance covered, time spent etc. > I'm sure there are other data for the minimum required data > and this is > worth discussion. > > We should also discuss the event. For example, one of ours > and Bird Studies > Canada projects (Project FeederWatch) the event can last 2 days. > > We also need to think about whether we want to include > protocol. In our > definitions no protocol (incidental observation) is also a protocol. > > Anyway, thanks for the improvements on the definition of > observation. I > (like Lynn) look forward to discussing some of these other issues. > > Steve > > > > > At 05:03 PM 2/8/2006 -0500, you wrote: > >With only comments from Bob & Arthur (thanks!), the latest version of > >observation definitions is as follows: > > > >"An observation characterizes the evidence for the presence > or absence > >of an organism or set of organisms through a data collection > event at a > >location. Observations are not necessarily independent and could be > >linked via characteristics such as time, place, protocol, and > >co-occurring organisms." > > > >With the following draft elaborations for various terms > (many thanks to > >Bob Peet for providing most of these draft definitions): > > > >1) occurrence > > > >"Occurrence" has been changed to "evidence for the presence > or absence". > > > >The key idea is that the organism or set of organisms was either > >detected or not. We also need to provide an opportunity for the > >recorder to note the certainty. > > > >As an aside, recall we need to support minimalist protocols (e.g. > >"organism/community (not)seen in field", "organism heard in field", > >"scat seen in field", "tracks seen in field", "museum collection".) > > > >2) data collection event > > > >An event, during or after which at least the minimum > required data were > >recorded. > > > >3) location > > > >Ideally, at least geocoordinates plus an accuracy term. > Since there is a > >considerable amount of historical / legacy data that does > not presently > >have a georeference yet has valuable information that should > be included > >in observation databases and shared, we cannot at this time > require data > >to be in a GIS format. > > > >I (Lynn) suggest: > >(a) Location information be required, preferably geocoordinates and > >mapping precision, but if not available then a text > description and the > >finest level of geolocation using the Darwin Core attributes. > > > >(b) Location data include the representation of observations > as point, > >line, or polygon data (with the necessary spatial metadata). > > > >4) entity > > > >Dropped from the definition of observation. > > > >5) could be linked > > > >Can have a pointer or pointers to other observations, > thereby creating > >aggregate observations. Note that commonality of date, time, place, > >etc. is not sufficient in that the none of the observation authors > >explicitly made the connection > > > > > >Please share your comments / thoughts on all of the above definitions > >with this email list. > > > >If people are generally comfortable with the above as working > >defintions, then I'd like to propose that we move into the > fun part of > >identifying attributes to be developed into a schema. > > > >Thank you - > >Lynn > > > > > >Lynn Kutner > >Data Management Coordinator > >NatureServe > >phone: (303) 541-0360 > >email: lynn_kutner(a)natureserve.org > >http://www.natureserve.org/ > > > > > > > > > > > >_______________________________________________ > >Tdwg-obs mailing list > >Tdwg-obs(a)lists.tdwg.org > >http://lists.tdwg.org/mailman/listinfo/tdwg-obs_lists.tdwg.org > _______________________________________________ > Tdwg-obs mailing list > Tdwg-obs(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-obs_lists.tdwg.org > > > _______________________________________________ > Tdwg-obs mailing list > Tdwg-obs(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-obs_lists.tdwg.org >

2 1

[Tdwg-img] TDWG Technical Architecture Group Meeting Call
by Roger Hyam 10 Feb '06

10 Feb '06

Dear Imaging List Member, As you may be aware the GUID-1 meeting has now taken place. The outcome of this meeting has wide ranging repercussions for all TDWG standards and their future interoperability. I am therefore calling a Technical Architecture Group meeting as soon as possible to discuss the best way to proceed. This meeting will be able to discuss issues, such as shared vocabularies, which are outside the scope of the GUID project. You can read more about the proposed meeting here: http://www.tdwg.hyam.net/twiki/bin/view/TAG/TagMeeting1 I would be grateful if you would consider whether you might attend or nominate some one to attend. If you would like to discuss the meeting further please join the TAG list to save generating traffic on this list (http://www.tdwg.org/mailinglists.htm) Best wishes, Roger (apologies if you have received this multiple times as it is going to several TDWG lists). -- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger(a)tdwg.org +44 1578 722782 -------------------------------------

1 0

[Tdwg-obs] Antw: Re: On observation definition / moving forward
by SABINE ROSCHER 10 Feb '06

10 Feb '06

Hello, We work in the field of agrobiodiversity, e.g. crop wild relatives. For us the combination of oberservation data and samples is very important. We consider the unit as central element, which can be a part of an organism, an ogranism, or a group of organisms. The reason for going under the level of organism is that sometimes the plant with all roots etc. can be quite larger than the part that is observed and recorded for a certain location. This describes the line we think along : "A unit in our context is uniquely identified by time, place(site) and taxonomy. In addition a particular unit could be sampled to further assist in characterising it. Such samples could be (1) seed samples/planting material (classical ex situ accessions), (2) photos or (3) herbarium vouchers." UNIT {time, site, taxonomy} (+ sample) (With regard to the prior discussion I agree that we also have to handle legacy data with missing entries for time and place.) Sabine Sabine Roscher 513 - Informations- und Koordinationszentrum für Biologische Vielfalt (IBV) Bundesanstalt für Landwirtschaft und Ernährung Deichmanns Aue 29, 53179 Bonn Tel.: +49 (0)228 6845-3235 (oder -3237) Fax: +49 (0)228 6845-3787 E-Mail: sabine.roscher(a)ble.de Internet: www.ble.de weiterführende Information: www.genres.de >>> Steve Kelling <stk2(a)cornell.edu> 09.02.2006 18:55 >>> Hello, I really like the improvements made on the definition, and I might suggest that I put it up on the TDWG-obs website http://www.avianknowledge.net/tdwg. I think we still need to define occurrence, and I think that Arthur Chapman's "species occurrence data" gets us most of the way there. My sense is that the elaborations need to be expanded a bit more. For example, data collection event. I suggest that we include in the definition some information about time, minimum required data, and so forth. These definitions can be longer and more detailed than the observation definition. So taking data collection event: An event, during or after which at least the minimum required data were recorded. Can we identify the minimum required data? For us it is: who the collector is where the information was collected (and should refer to occurrence information and all of the discussion with it) when the data and time what was observed (and how many) effort distance covered, time spent etc. I'm sure there are other data for the minimum required data and this is worth discussion. We should also discuss the event. For example, one of ours and Bird Studies Canada projects (Project FeederWatch) the event can last 2 days. We also need to think about whether we want to include protocol. In our definitions no protocol (incidental observation) is also a protocol. Anyway, thanks for the improvements on the definition of observation. I (like Lynn) look forward to discussing some of these other issues. Steve At 05:03 PM 2/8/2006 -0500, you wrote: >With only comments from Bob & Arthur (thanks!), the latest version of >observation definitions is as follows: > >"An observation characterizes the evidence for the presence or absence >of an organism or set of organisms through a data collection event at a >location. Observations are not necessarily independent and could be >linked via characteristics such as time, place, protocol, and >co-occurring organisms." > >With the following draft elaborations for various terms (many thanks to >Bob Peet for providing most of these draft definitions): > >1) occurrence > >"Occurrence" has been changed to "evidence for the presence or absence". > >The key idea is that the organism or set of organisms was either >detected or not. We also need to provide an opportunity for the >recorder to note the certainty. > >As an aside, recall we need to support minimalist protocols (e.g. >"organism/community (not)seen in field", "organism heard in field", >"scat seen in field", "tracks seen in field", "museum collection".) > >2) data collection event > >An event, during or after which at least the minimum required data were >recorded. > >3) location > >Ideally, at least geocoordinates plus an accuracy term. Since there is a >considerable amount of historical / legacy data that does not presently >have a georeference yet has valuable information that should be included >in observation databases and shared, we cannot at this time require data >to be in a GIS format. > >I (Lynn) suggest: >(a) Location information be required, preferably geocoordinates and >mapping precision, but if not available then a text description and the >finest level of geolocation using the Darwin Core attributes. > >(b) Location data include the representation of observations as point, >line, or polygon data (with the necessary spatial metadata). > >4) entity > >Dropped from the definition of observation. > >5) could be linked > >Can have a pointer or pointers to other observations, thereby creating >aggregate observations. Note that commonality of date, time, place, >etc. is not sufficient in that the none of the observation authors >explicitly made the connection > > >Please share your comments / thoughts on all of the above definitions >with this email list. > >If people are generally comfortable with the above as working >defintions, then I'd like to propose that we move into the fun part of >identifying attributes to be developed into a schema. > >Thank you - >Lynn > > >Lynn Kutner >Data Management Coordinator >NatureServe >phone: (303) 541-0360 >email: lynn_kutner(a)natureserve.org >http://www.natureserve.org/ > > > > > >_______________________________________________ >Tdwg-obs mailing list >Tdwg-obs(a)lists.tdwg.org >http://lists.tdwg.org/mailman/listinfo/tdwg-obs_lists.tdwg.org _______________________________________________ Tdwg-obs mailing list Tdwg-obs(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-obs_lists.tdwg.org

1 0