August 2010 - tdwg-content

dwc:associatedOccurrences
by Mark Wilden 07 Sep '10

07 Sep '10

On Tue, Aug 24, 2010 at 6:24 AM, John Wieczorek <tuco(a)berkeley.edu> wrote: > Note that associatedOccurrences is one of the several terms that are meant > to allow lists of relationships between resources to be captured in a single > field. Others include associatedMedia, associatedReferences, > associatedSequnces, and associatedTaxa. The main purposes of these fields is > to provide a mechanism to share relationship information in a flat > application profile such as the Simple Darwin Core > (http://rs.tdwg.org/dwc/terms/simple/index.htm). If an application profile > isn't constrained by being flat, then there is a much more robust way to > capture relationships, using the ResourceRelationship class and it's > constituent terms (http://rs.tdwg.org/dwc/terms/index.htm#relindex). However, the values of the description of the relationship (http://rs.tdwg.org/dwc/terms/index.htm#relationshipOfResource) are not controlled, so this still doesn't provide a "community-defined" vocabulary that Bob was asking about. ///ark Web Applications Developer Center for Applied Biodiversity Informatics California Academy of Sciences

5 17

Upcoming TDWG meeting
by Nico Cellinese 02 Sep '10

02 Sep '10

Hi all, we have reserved one full day for a Phylogenetics Standards hands-on activity at the upcoming TDWG conference. We asked for power strips and wireless network and tables that we can sit around and work together. The only thing that's missing right now is what exactly we should target. The options are wide open right now, with the two only major constraints being that (a) we have no funding this year to bring people in who wouldn't otherwise be there, and (b) abstract submission deadline is next Wednesday. Any feedback or ideas, wild or not, that you have would be welcome - send those our way. And BTW currently this workshops seems to be placed on the Wednesday of the conference week, so those of you blitzing the local biosphere will unfortunately have a conflict. Cheers, Nico & Hilmar <><><><><><><><><><><><><><><><><><><><> Nico Cellinese, Ph.D. Assistant Curator, Herbarium & Informatics Adjunct Assistant Professor, Department of Biology Florida Museum of Natural History University of Florida 354 Dickinson Hall, PO Box 117800 Gainesville, FL 32611-7800, U.S.A. Tel. 352-273-1979 Fax 352-846-1861 http://www.flmnh.ufl.edu

6 8

Re: [tdwg-phylo] Upcoming TDWG meeting
by Arlin Stoltzfus 27 Aug '10

27 Aug '10

Is anyone else interested? If there is interest, I'll start a planning document (TDWG phylo twiki?). Arlin On Aug 27, 2010, at 2:45 PM, Dan Rosauer wrote: > Hi Arlin and others > > I think that idea 1 below is a really valuable topic to address. > The ability to link tree tips to other sources of data by taxon name > or identifier is a threshold step for automating a whole range of > analyses and displays. For example, the software I work on, > Biodiverse, links phylogenies to species location data for > visualisation and analysis. It would be great to have it running > automatically online, linking (for example) trees from treebase to > distributions from GBIF. To do this (and many other things) however > we need a better solution to the taxon matching problem you describe. > > cheers > Dan > > From: tdwg-phylo-bounces(a)lists.tdwg.org [mailto:tdwg-phylo-bounces@lists.tdwg.org > ] On Behalf Of Arlin Stoltzfus > Sent: Friday, August 27, 2010 11:27 AM > To: tdwg-phylo(a)lists.tdwg.org > Subject: Re: [tdwg-phylo] Upcoming TDWG meeting > > I'm sending this reply to only the tdwg-phylo list (sending to > everyone seems like overkill). > > Here are two ideas based on the use of phylogenies: > > 1. For various reasons, its important to be able to associate > valid species sources or other universal identifiers (e.g., NCBI > gis) with the human-readable OTU identifiers used in tree files, but > this typically isn't done and it's not always easy. The goal of > this project is to enable ordinary phylogenetics & systematics users > to use current standards (Newick, NHX, phyloxml, ...) to associate > species names (possibly other tax ids) with phylogenies in their > usual workflows. The focus is on developing short-term tools and > strategies that might lead to better long-term solutions. In some > cases, its just a matter of knowing how to use the file format > properly, possibly aided by better tools for data input. For users > whose workflows rely on Newick, we would need a way to keep a > separate mapping of OTU ids and tax ids, along with tools to > interconvert or translate to one of the other formats (this could be > as simple as an Excel spreadsheet or as complex as a web service > that maintains your mapping and does the translation for you). > > 2. There is a huge variety of tree viewers. To some extent, users > need this variety due to their having different feature sets. But > users shouldn't have to choose the viewer based on data format > restrictions. The goal of this project is to improve the usability > of tree viewers. Assess the interoperability (standards > compatibility) of tree viewing software, develop strategies to > improve it, and get started on any strategies that can be > implemented. Its not possible to modify viewers whose source code > is unavailable, but there may be ways to work around this with > scripts and translation tools. > > Arlin > > On Aug 26, 2010, at 9:40 PM, Nico Cellinese wrote: > > > Hi all, > > we have reserved one full day for a Phylogenetics Standards hands-on > activity at the upcoming TDWG conference. We asked for power strips > and wireless network and tables that we can sit around and work > together. The only thing that's missing right now is what exactly we > should target. The options are wide open right now, with the two > only major constraints being that (a) we have no funding this year > to bring people in who wouldn't otherwise be there, and (b) abstract > submission deadline is next Wednesday. > > Any feedback or ideas, wild or not, that you have would be welcome - > send those our way. > > And BTW currently this workshops seems to be placed on the Wednesday > of the conference week, so those of you blitzing the local biosphere > will unfortunately have a conflict. > > Cheers, > Nico & Hilmar > > > <><><><><><><><><><><><><><><><><><><><> > Nico Cellinese, Ph.D. > Assistant Curator, Herbarium & Informatics > Adjunct Assistant Professor, Department of Biology > > Florida Museum of Natural History > University of Florida > 354 Dickinson Hall, PO Box 117800 > Gainesville, FL 32611-7800, U.S.A. > Tel. 352-273-1979 > Fax 352-846-1861 > http://www.flmnh.ufl.edu > > > > <ATT00001.txt> > > ------- > Arlin Stoltzfus (arlin(a)umd.edu) > Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST > IBBR, 9600 Gudelsky Drive, Rockville, MD > tel: 240 314 6208; web: www.molevol.org > > <ATT00001.txt> ------- Arlin Stoltzfus (arlin(a)umd.edu) Fellow, IBBR; Adj. Assoc. Prof., UMCP; Research Biologist, NIST IBBR, 9600 Gudelsky Drive, Rockville, MD tel: 240 314 6208; web: www.molevol.org

2 1

DwC formal semantics, was Re: dwc:associatedOccurrences
by Bob Morris 24 Aug '10

24 Aug '10

On Tue, Aug 24, 2010 at 9:14 PM, Steve Baskauf <steve.baskauf(a)vanderbilt.edu> wrote: > As I was stuck in traffic this morning I was thinking about my response to > Bob's comments. In retrospect, I should have simply said that indicating > that specimens are duplicates by assigning their dwc:individualID property > to the same URI is really not just one option, but rather that it is the > semantically correct thing to do. If "semantically correct" is meant to be something about formal semantics, I am not yet prepared to believe that the DwC rdf profile is amenable to useful OWL formal semantics as it stands. (It also makes no claims to do so, and for reasons I'm sympathetic to, probably shouldn't). A little about this later. > [... stuff about owl:sameAs and whale sharks] The paper by Halpin and Hays [1] shows that even for Linked Data, owl:sameAs is more complicated than may seem. (The paper also asserts that not much reasoning is presently done on Linked Data, so I suppose any particular use of owl:sameAs for anything but machine reasoning may in practice be harmless for present Linked Data tools.) My understanding from studying it is that dwcterms.rdf makes no pretense to be an OWL ontology, nor do its authors claim that. It uses rdf and rdfs with close to no formal semantics restrictions. Put another way, it is about as open world as it could get and still be valid rdf. Although I at first was annoyed by this(*), I have come to believe that it is probably a boon, because it allows multiple profiles to be built on dwcterms.rdf, using it as controlled vocabulary but allowing formal semantics to be determined by the axioms of the profile. I agree with your opinion "it is wrong to invent some other term to represent a relationship that can be clearly and unambiguously expressed using existing terms", but formal semantics imposes a definition of "unambiguously expressed" and practitioners of one domain may accept a particular unambiguous expression, while those in another don't. Information systems have to be accepted, not merely unambiguous. After I've tried to build a few DwC OWL profiles for distinguishable communities of collections practice, I'll look again at your arguments to see how much commonality I (and more importantly, my informants) think there is lurking in the profiles. I expect that some of these kinds of issues will be on the table at several of the proposed Wednesday/Thursday sessions at TDWG. Hope you're there. (*)A good example is this: wrestle dwcterms.rdf into Protege 4 and then go looking for dwc:basisOfRecord. You won't find it listed as a Property, and unless you understand the whole rdf stack, you'll be mystified why Protege is merely unhelpful, not broken, in this case. Bob [1] "When owl:sameAs isn’t the Same: An Analysis of Identity Links on the Semantic Web", Harry Halpin and Patrick J. Hayes http://events.linkeddata.org/ldow2010/papers/ldow2010_paper09.pdf -- Robert A. Morris Emeritus Professor of Computer Science UMASS-Boston 100 Morrissey Blvd Boston, MA 02125-3390 Associate, Harvard University Herbaria email: morris.bob(a)gmail.com web: http://bdei.cs.umb.edu/ web: http://etaxonomy.org/mw/FilteredPush http://www.cs.umb.edu/~ram phone (+1) 857 222 7992 (mobile)

1 0

dwc:associatedOccurrences
by Bob Morris 24 Aug '10

24 Aug '10

http://rs.tdwg.org/dwc/terms/index.htm#associatedOccurrences carries this description: associatedOccurrences Identifier: http://rs.tdwg.org/dwc/terms/associatedOccurrences Class: http://rs.tdwg.org/dwc/terms/Occurrence Definition: A list (concatenated and separated) of identifiers of other Occurrence records and their associations to this Occurrence. Comment: Example: "sibling of FMNH:Mammal:1234; sibling of FMNH:Mammal:1235". For discussion see http://code.google.com/p/darwincore/wiki/Occurrence Details: associatedOccurrences My questions: a. Are the names of the associations, and/or the syntax of the value meant to be community defined? b. If no to a. , where are those definitions? If yes, Have any communities defined any names and syntax? I am especially interested in "duplicate of" in the case of herbarium sheets." c. (May share an answer with b.) Is there any use being made by anyone in which associatedOccurrences is designed to have machine-readable values. If yes, where? Thanks Bob -- Robert A. Morris Emeritus Professor of Computer Science UMASS-Boston 100 Morrissey Blvd Boston, MA 02125-3390 Associate, Harvard University Herbaria email: morris.bob(a)gmail.com web: http://bdei.cs.umb.edu/ web: http://etaxonomy.org/mw/FilteredPush http://www.cs.umb.edu/~ram phone (+1) 857 222 7992 (mobile)

4 6

Replying to all doesn't
by Mark Wilden 24 Aug '10

24 Aug '10

It seems incorrect to me that doing "Reply to all" on this list doesn't actually reply to all (i.e., the list). The only way I see to actually "reply to all" is to remember to manually edit the To: line to put in tdwg-content. Granted, inadvertent "replies to all" when just "reply" was intended can be annoying and even embarrassing. However, it does seem that if you explicitly "reply to all," you should do just that. ///ark Web Applications Developer Center for Applied Biodiversity Informatics California Academy of Sciences

2 2

dwc:associatedOccurrences
by Mark Wilden 23 Aug '10

23 Aug '10

On Mon, Aug 23, 2010 at 12:07 PM, Steve Baskauf <steve.baskauf(a)vanderbilt.edu> wrote: > Bob, > It seems to me that the most semantically clear way to indicate in a > machine-readable way that two herbarium sheets are duplicates would be to > assert that they have the same dwc:individualID. That makes sense for expressing "duplicate of" in a machine-readable way, but what about other associations? For example, Is there a definition somewhere for "reminds me of" or "kinda like"? ///ark Web Applications Developer Center for Applied Biodiversity Informatics California Academy of Sciences

1 0

TDWG 2010 - Cloudy forecast
by John Wieczorek 22 Aug '10

22 Aug '10

Dear all, This year at the TDWG meeting there will be a session on Hardware and Infrastructure. In preparation for that I am interested to know from the community at large if there are particular questions or concerns about public cloud computing solutions such as Amazon Web Services, AppScale, and Google AppEngine. Cheers, John

1 0

Re: [tdwg-content] [tdwg-tag] time and space namespaces in Darwin Core
by Bob Morris 12 Aug '10

12 Aug '10

FWIW, timestamps extracted from EXIF data that a camera put there are typically no more than +- 12 hours accurate, because most devices don't record and/or stamp the timezone. My Android X seems to, but my Canon PowerShot SD750 does not. Your extractions are going to need to add it based on your knowledge about the timezone at the time and location of the bioblitz. Alas, it gets worse, because many people fail to reset their cameras or phones to the local time. To make any kind of educated guess about what time the timestamp \actually/ represents may require knowledge of the device capabilities, what the timezone is where the picture was taken and what it was in the timezone the device thinks its in. The latter might be knowable from specs of the device, e.g. if it can be discovered from those specs that the camera knows its time from a network it is connected to, and if you can deterimine that it actually was connected. But for consumer cameras, this is probably hopeless, and you need metadata from the camera owner. Curiously, the errors from this are not a range, but an enumeration, because timezones worldwide differ from one another by an integral multiple of 1/2 hour. Field biologists of my acquaintance simply keep their cameras always set at GMT. Then at least they know that all their pictures have comparable times. For the bioblitz, participants might consider agreeing to set the cameras to a common time. Aside from the accuracy of hand setting the current time, you would then mainly face social problems about the accuracy of the time: (a) can and will the participants actually do this with the devices they carry; (b)how much will they curse the bioblitz when they forget to set the timezone back to what they intend and (c) do they care whether a picture they took of a pollinator in Massachusetts apparently at high noon, actually was taken in Massachusetts at a time corresponding to high noon in Berlin. At the very least you probably should ask each contributor to record the time on their camera at specified local time each day. All accuracy assertions are about fitness for use. It's not the case that data without accuracy assertions are unfit for any use whatsover. This is because scientific statements are always qualified by either "to the best of current knowledge" or "if we accept the model X into which we put the data". For example, a taxonomic determination may or not be location dependent to the best of current knowledge. For those which aren't, and for the use case "taxonomic determination", geo accuracy is irrelevant. To the best of current knowledge. Bob Morris On Wed, Aug 11, 2010 at 9:52 PM, joel sachs <jsachs(a)csee.umbc.edu> wrote: > On Mon, 9 Aug 2010, Javier de la Torre wrote: > >> Hi, >> >> Ok. That being said, I dont want anybody to die!, > > Me neither. > > I've copied in the tdwg-bioblitz group, which at some point got dropped > from this discussion. If anyone is interested, the full discussion can be > found at http://lists.tdwg.org/pipermail/tdwg-tag/2010-August/thread.html > > For the bioblitz, I think we can do the following: > > i. Since GPS uses WGS84, any smartphone app that's getting coordinates > from the phone's built in GPS can correctly label the coordinates "geo:lat", > and "geo:long". The semantics of the location columns in the Google Fusion > Table will be "WGS84". (see (iii) for the exceptions.) When we publish DwC > from the Fusion Table, we can and should use DwC:decimalLatitude, > DwC:decimalLongitude, and DwC:geodeticDatum (set to WGS84). > > ii. We should record uncertainty. GPS uncertainty > varies with the weather, whether the user is > moving, availability of WAAS, etc. So developers should ensure that > uncertainty is captured each time their app makes a measurement. We'll add > an uncertainty column to the Fusion table. (It will be interesting to see > the range of uncertainty measures in the observations.) > > iii. If someone does precision surveying using a local datum, instead > of WGS84, she must take care that the column names for lat and long in > her Fusion Table are not the same as the column names in the master table. > Thus, when the data is merged, her coordinates won't end up in the columns > with the implied WGS84 semantics. > > Can we agree on that? > > Many thanks! > Joel. > > > > > > why dont we do the same as with dates. We have a verbatimLatitude and > verbatiumLongitude already, why those people dont use that? They should only > use DecimalLatitude if they know they have WGS84. If they use them > incorrectly, well, thats happening all day on the network of GBIF data > providers, and I dont think DWC can changed much on that. What we need is > better tools for them to publish their data, no overcomplicate the standard > just to avoid people using it wrong. >> >> What I want is to help developers using data. If our data will not >> correctly get displayed on a map we have an issue. I would say that >> considering the defacto standard of WGS84 for coordinates we will find lot >> of wrong maps out there because developers think that this is all WGS84 >> (they also dont know what this is), they will just throw them into Google >> Maps and they will be wrong, even if providers set the geodeticDatum. >> >> Probably this discussion is about where to push, the data provider or the >> developer. Beacuse the developer has to deal with thousands of providers, I >> think he has a worst job than the provider, plus is the last on the chain of >> data transformation. We dont want Pumas dissapearing because developers >> didnt handle SRS transformations that he didnt even knew. >> >> Finally, SRS I dont think are standarized, look at the reference you give >> (http://spatialreference.org/) and you will see that you can Upload your >> own. Ok I am a provider and decide to use my own SRS that I have created (or >> more normally, something is wrong) and upload it there... there is no tool >> that will resolve SRS automatically to do transformations. >> >> Now, if the provider knows what an SRS is, which Darwin Core force them to >> declare, I think they should might be able to actually transform previously >> to WGS84 and place their own stuff in Verbatium. >> >> Finally, I am a developer, get data from 100 providers, some got really >> wrong the SRS, how am I gonna know which ones? Now the provider has a good >> tool, visualize his data in Google Maps for example and discover that the >> locations look wrong. I think the second is a much easier place to resolve >> the issue. >> >> But I am a developer and maybe biassed. >> >> Javier de la Torre >> www.vizzuality.com >> >> On Aug 9, 2010, at 4:46 PM, John Wieczorek wrote: >> >>> The reason is simple, we want to help data publishers. It doesn't help >>> data publishers if they can't publish what they have - it would mean there >>> is no room for data improvement tools. That would be sad. Worse, most people >>> haven't a clue what a datum is, or how it can ruin your whole day (or life, >>> in at least one sad case of a crashed helicopter in Patagonia). Given this >>> naiveté, people would simply put whatever geographic coordinates they have >>> into geo:lat/lon and no one would have any way to know that they are >>> incorrect. >>> >>> Note that Darwin Core offers data publishers options to publish event >>> information with year, month, day, startDayOfYear, endDayOfYear, and >>> verbatimEventDate in addition to eventDate and eventTime - same philosophy. >>> >>> On Mon, Aug 9, 2010 at 7:26 AM, Javier de la Torre <jatorre(a)gmail.com> >>> wrote: >>> I am not sure I understand why we can not set DWC fields to conform to >>> WGS84 and then use what everybody else is using. >>> >>> For example in eventDate DWC conforms to ISO 8601, why dont we do the >>> same for location... it would allow to simplify it quite a lot and be more >>> compliant with other standards-existing apps, etc. >>> >>> Just an idea. >>> >>> Javier de la Torre >>> www.vizzuality.com >>> >>> On Aug 9, 2010, at 4:13 PM, John Wieczorek wrote: >>> >>>> The partially good news is that if enough information >>>> (dwc:geodeticDatum) is given in a Darwin Core-based record, geo:lat/lon can >>>> be determined from it. More disturbing to me is that anyone would think >>>> geo:lat/lon alone is sufficient for any application, as it carries no notion >>>> of uncertainty and therefore fitness for use. Add >>>> dwc:coordinateUncertaintyInMeters (or even dwc:coordinatePrecision if you >>>> must) to the mix and I would be much happier. >>>> >>>> >>>> On Sun, Aug 8, 2010 at 11:26 PM, <Garry.Jolley-Rogers(a)csiro.au> wrote: >>>> Hi Jim, >>>> Thanks. Had this aside to read in detail later. I think John is >>>> right... As same value with different constraints mean different >>>> interpretations are possible and seems to be the key thing. How are the >>>> values to be interpreted. >>>> >>>> G >>>> >>>> -----Original Message----- >>>> From: Jim Croft [mailto:jim.croft@gmail.com] >>>> Sent: Monday, 9 August 2010 4:12 PM >>>> To: Alexander, Paul (PI, Black Mountain); Harvey, Paul.W (PI, Black >>>> Mountain); Jolley-Rogers, Garry (PI, Black Mountain); Cawsey, Margaret (CES, >>>> Crace); Greg Whitbread >>>> Cc: tuco(a)berkeley.edu >>>> Subject: Fwd: [tdwg-tag] time and space namespaces in Darwin Core >>>> >>>> Did you catch this thread on tdwg-tag? It is an almost exact mirror >>>> of the conversations we have be having in the taxon profile space, but >>>> involving the specimen locational data. >>>> >>>>> From John's comments it would appear he is not prepared to accept the >>>> >>>> geo: and dwc: lat/long as 'exact match' because, although they are the >>>> same values, they have different constraints (or more precisely one >>>> one has a constraint and one doesn't). >>>> >>>> I wouldn't have picked it but this looks like a case for 'closematch'. >>>> >>>> jim >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: John Wieczorek <tuco(a)berkeley.edu> >>>> Date: Mon, Aug 9, 2010 at 3:56 AM >>>> Subject: Re: [tdwg-tag] time and space namespaces in Darwin Core >>>> To: joel sachs <jsachs(a)csee.umbc.edu> >>>> Cc: tdwg-bioblitz(a)googlegroups.com, tdwg-tag(a)lists.tdwg.org >>>> >>>> >>>> There is actually no equivalency between dwc:decimalLatitude and >>>> geo:lat because geo:lat is specified to represent the latitude in the >>>> WGS84 spatial reference system and dwc:decimalLatitude has no such >>>> such restriction. >>>> >>>> On Fri, Aug 6, 2010 at 10:08 AM, joel sachs <jsachs(a)csee.umbc.edu> >>>> wrote: >>>>> >>>>> On Fri, 6 Aug 2010, Hilmar Lapp wrote: >>>>> >>>>>> Shouldn't the RDF for DwC link DwC:lat to geo:lat (using some subtype >>>>>> or better yet equivalency relation)? And shouldn't hence Linked Data >>>>>> browsers be able to use DwC:lat in the same way as geo:lat? >>>>>> >>>>> >>>>> Yes. But no Linked Data browser I'm aware of applies >>>>> owl:equivalentProperty assetions before rendering the data. (In fact, >>>>> most >>>>> do no reasoning at all.) I agree that, whatever our default display, >>>>> it should include the appropriate mapping statements, either via an >>>>> rdfs:seeAlso or similar link, or directly in the document. >>>>> >>>>> >>>>> Joel. >>>>> >>>>> >>>>>> -hilmar >>>>>> >>>>>> On Aug 6, 2010, at 11:01 AM, joel sachs wrote: >>>>>> >>>>>>> All, >>>>>>> >>>>>>> When representing observation records in RDF, there are advantages >>>>>>> to using Dublin Core and Geo (http://www.w3.org/2003/01/geo/ >>>>>>> wgs84_pos#) >>>>>>> namespaces where possible. For example, if we use DC:date, and >>>>>>> geo:lat, geo:long, instead of DwC:eventDate, DwC:lat, and DwC:long, >>>>>>> then Linked Data browsers can automatically map the records, plot >>>>>>> them on a timeline, etc. >>>>>>> >>>>>>> My question is: What are the disadvantages to doing this? (For >>>>>>> example, is this going to break someone's DwC validator?) >>>>>>> >>>>>>> Thanks - >>>>>>> Joel. >>>>>>> >>>>>> >>>>>> -- >>>>>> =========================================================== >>>>>> : Hilmar Lapp -:- Durham, NC -:- informatics.nescent.org : >>>>>> =========================================================== >>>>>> >>>> >>>> _________________ >>>> Jim Croft ~ jim.croft(a)gmail.com ~ +61-2-62509499 ~ >>>> http://www.google.com/profiles/jim.croft >>>> 'A civilized society is one which tolerates eccentricity to the point >>>> of doubtful sanity.' >>>> - Robert Frost, poet (1874-1963) >>>> >>>> Please send URIs, not attachments: >>>> http://www.gnu.org/philosophy/no-word-attachments.html >>>> >>>> _______________________________________________ >>>> tdwg-tag mailing list >>>> >>>> tdwg-tag(a)lists.tdwg.org >>>> http://lists.tdwg.org/mailman/listinfo/tdwg-tag >>> >>> >> > > _______________________________________________ > tdwg-tag mailing list > tdwg-tag(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-tag > > -- Robert A. Morris Emeritus Professor of Computer Science UMASS-Boston 100 Morrissey Blvd Boston, MA 02125-3390 Associate, Harvard University Herbaria email: ram(a)cs.umb.edu web: http://bdei.cs.umb.edu/ web: http://etaxonomy.org/FilteredPush http://www.cs.umb.edu/~ram phone (+1) 857 222 7992 (mobile)

1 0

Proposed Darwin Core term additions and changes: individualRemarks and establishmentMeans
by Steve Baskauf 11 Aug '10

11 Aug '10

In http://code.google.com/p/darwincore/issues/detail?id=70 I proposed addition of the class Individual to Darwin Core. In the discussion of that proposal, the question was raised as to which existing DwC terms should be a part of this class if it were added. After considerable thought and some work in developing RDF representations for Individuals, I believe that the term establishmentMeans should be a member of the proposed class. It has also become clear to me that if the class is introduced, there is a need for the term individualRemarks which would serve a parallel purpose to other xxRemarks terms in DwC. I have provided implementation examples in the recommendations, which can be found at http://code.google.com/p/darwincore/issues/detail?id=80 and http://code.google.com/p/darwincore/issues/detail?id=81 If you would like to discuss these proposals, please post on the tdwg-contents list or add comments to the Google Code wiki. I have cross-posted to the tdwg-tag list, but I think any discussion would be better held on the tdwg-content list, so please post there. Steve Baskauf -- Steven J. Baskauf, Ph.D., Senior Lecturer Vanderbilt University Dept. of Biological Sciences postal mail address: VU Station B 351634 Nashville, TN 37235-1634, U.S.A. delivery address: 2125 Stevenson Center 1161 21st Ave., S. Nashville, TN 37235 office: 2128 Stevenson Center phone: (615) 343-4582, fax: (615) 343-6707 http://bioimages.vanderbilt.edu

1 1