- tdwg-content - lists.tdwg.org

What is dwc:basisOfRecord for?
by Steve Baskauf 03 Nov '10

03 Nov '10

OK, I know that this sounds like a stupid question, but I really want somebody who was involved in the development and maintenance of the current DwC standard to tell me how the term dwc:basisOfRecord is supposed to be used (not what it IS - I've seen the definition at http://rs.tdwg.org/dwc/terms/index.htm#basisOfRecord)? I would like for the answer of this question to be separated from the issue of what the Darwin Core type vocabulary (http://rs.tdwg.org/dwc/terms/type-vocabulary/index.htm) is for. I re-read the lengthy thread starting with http://lists.tdwg.org/pipermail/tdwg-content/2009-October/000301.html which talked a lot about basisOfRecord and its relationship to other ways of typing things. I don't want to re-plough that ground again, but I couldn't find the post that stated what the final decision was. I remember that there was a decision to NOT create the recordClass term which was the subject of much discussion. I guess my confusion at this point is with the inclusion of both "Occurrence" and "PreservedSpecimen" in the same list. Let's say that I have a flat database where I include metadata about the Occurrence (such as dwc:recordedBy) and the specimen (such as dwc:preparations) in the same line. What is the basisOfRecord for that line? I would guess that the "basis of the record" was the specimen. But the line in the record also represents an Occurrence. It seems like there is a lack of clarity as to whether basisOfRecord is supposed to indicate the type of the record (which would be an Occurrence record) or whether it's supposed to indicate the kind of evidence on which the record is based (which would be PreservedSpecimen). There have been various times where I've seen a database record that includes basisOfRecord and it seems to be inconsistently applied. I can see how the Darwin Core type vocabulary could be useful - it pretty much lays out useful values that one could give for rdfs:type. But basisOfRecord as a term is confusing me. Steve -- 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

4 8

Treatise on Occurrence, tokens, and basisOfRecord
by Steve Baskauf 02 Nov '10

02 Nov '10

I have been dreading trying to write this post which I have promised (or threatened depending on if you have enjoyed or been annoyed by the previous lengthy thread) for some time. I have dreaded it because this is a complicated subject and not one that is amenable to terse messages. However, after the previous conversation with Rich et al., I feel for the first time that I have the questions (not answers!) clearly in my mind. So rather than starting off rambling about LivingSpecimens and establishmentMeans as I had planned, I'm going to start by laying down several principles that have come into clarity in my mind after the previous conversation and the attempt to map things out in a diagram. I will apologize in advance for failure to use the correct database or IT technical terms when I'm in unfamiliar territory. Until there is a consensus about how we deal with the "tokens" we use to document Occurrences, I'm not sure that what I have to say about those other topics will make sense. PRINCIPLES (derived from earlier discussion) 1. We have a number of kinds of "things" (which I will henceforth refer to as "resources") that are useful for describing and organizing metadata that we collect in our attempts to document biodiversity. For many of these types of resources, we have defined classes to categorize the terms that can be used to describe the properties of resources that are instances of that class. Describing the class helps us to understand the type of resources that constitute instances of that class. 2. A conscious decision was made to avoid formally defining rdfs:domain for Darwin Core terms. This decision was made to provide flexibility in the way the terms can be used and to avoid the situation where semantic clients would draw incorrect or silly conclusions about what kind of things resources are. However, this decision does not excuse us from thinking carefully about whether a term can be appropriately applied to a resource that is a member of some class (e.g. should we say that a digital photograph has a scientific name?). Placing a term within a class is a suggestion that the term would appropriately be applied as a property of an instance of a class. 3. When users want to "flatten" and simplify their databases, they tend to eliminate one-to-many (1:M) relationships in favor of one-to-one (1:1) relationships. The result of that is differences like we saw in http://bioimages.vanderbilt.edu/pages/rich-diagram1.gif (which allows 1:M relationships between Occurrences and Events and between Events and Locations) and http://bioimages.vanderbilt.edu/pages/rich-diagram2.gif (which "atomizes" every Occurrence by considering it to have its own separate eventTime and Location information). A. There is nothing intrinsically "right" or "wrong" about either of these approaches, because they each have their own advantages. The 1:M approach is more efficient, but results in a more complicated database, while the 1:1 approach results in a simpler database but may require repeating some or many term values in the records. B. The choices that users make in these situations is the cause of much of the disagreement about whether a certain class should exist or not since the people taking the 1:1 approach "collapse" the relationship diagram and eliminate classes they don't need while people who take the 1:M approach need instances of the class to act as nodes to connect their "many" resources to some other thing. C. This collapsing of the diagram is also the reason for some disagreement about whether a term belongs in a certain class or not. In the example above, 1:1 people would say that eventDate is a property of an Occurrence, while 1:M people would say that eventDate is a property of an Event. D. The choice of users on this issue influences their decision about whether or not to create resources that are instances of classes and hence to assign them identifiers. If users take the 1:M approach, they need identifiers for resources that are acting as connecting nodes so that they can make reference to that resource in the metadata of the many things they are connecting to it. If users take the 1:1 approach, they probably will skip creating explicit resources (and their corresponding identifiers) for resources of the class that they are "collapsing" out of the diagram). 4. I would propose that the "right" relationship diagram is not necessarily one that caters to a certain "right" philosophical point of view. Rather, the "right" diagram is the one that allows users to define the relationships that they need for the organization of their metadata in the simplest manner, and which provides the most clarity about what resources of various kinds are, and how they are connected. A. "Right" as I have defined it above depends on how broadly applicable the relationship diagram is intended to apply. An individual person or organization with limited interests may have a relationship diagram that is simpler than the diagram shown at http://bioimages.vanderbilt.edu/pages/rich-diagram1.gif or might choose to add classes for other things that are their personal interest. An organization interested focused on different issues or with broader interests might opt for many more or different classes that would be connected to those shown in the diagram. B. Given what I just said in A, what is "right" for Darwin Core is going to be defined by the needs of the Darwin Core constituency. At the TDWG meeting, John Wieczorek made a statement which I will paraphrase as "in order for a term to make it into Darwin Core, at least two people had to want it". I'm not sure to what extent he was joking about this, but it makes the point that one must consider community needs before saying that a certain part of the "diagram" is necessary. I think that the reason that Rich and I were so quickly able to come to a consensus on the organization of the left side of the diagram is because he realized that there was a significant part of the DwC constituency that needed a way to group occurrences (i.e. needed Individuals) and I realized that there was a significant part of the constituency that needed to group multiple Events at a Locality and multiple Occurrences at an Event. So in evaluating alternative conceptual systems for organizing resources, the question has to be asked as to the extent that an alternative allows broad segments of the DwC constituency to organize their metadata in an efficient and conceptually sensible way. If one alternative is more broadly applicable and conceptually clear than another, then that alternative is better regardless of the philosophical underpinnings of the argument. 5. The last point is one that has run as an undercurrent through various TDWG threads but which may not have been explicitly stated in this particular thread. That is that there should be a separation between what a resource IS and what we want to use a resource FOR. To use technical terms, we need to separate the "type" of a resource from its fitness of use. A digital image IS a digital image. It might be used FOR documenting that an organism was at a particular location at a particular time, but it could be used to illustrate a character, as a part of a visual key, as media for an educational presentation, as art, and probably many other things that aren't popping into my mind at the moment. I believe that much of the confusion about "what is an Occurrence" comes from a failure to make this distinction. THE ISSUE OF THE TOKEN Earlier in the thread of "What is an Occurrence", there was a general consensus that an Occurrence often had a "thing" that was associated with it that served as evidence that a taxon representative (i.e. Individual) occurred at a particular Location at a particular time. In my Biodiversity Informatics paper, I called this thing a "representation", but I now believe that "token" is a better term and will use it hereafter. There also seemed to be a consensus that an observation was simply an Occurrence that did not have an associated token. (This is with the understanding that observation is being narrowly defined as a type of Occurrence, with a definable time and location, as opposed to what I called the "checklist" definition which indicated that some undefined taxon representative was present in some defined geographical area at an indefinite time.) In one of my earlier posts, I pleaded for somebody to tell me whether there was an assumption that the token was considered a part of the Occurrence or whether it was a separate thing. I did not get any responses, which I'm construing to mean that people weren't sure about this. At the present, I now have a clearer idea of the general principles I outlined above, and also have the "Rich" diagram for modeling relationships, so I'm going to again pose this question, but in what I hope is a clearer way. I have re-made the earlier diagram as Rich suggested, using triangles rather than arrows. The wide side of the triangle is the "many" side of the relationship and the point is the "one" side. As before, I'm deferring on the right side of the diagram (to the right of Identification) to the taxonomists for now, so let's keep that out of the discussion for the moment. I have also clarified the diagram by coloring in the actual DwC classes to distinguish them from selected terms that fall within those classes (non-colored boxes) and which can be used as properties of resources that are instances of the class. The two alternatives that I'm discussion are: http://bioimages.vanderbilt.edu/pages/token-assumed.gif which I will refer to as the "assumed token" model and http://bioimages.vanderbilt.edu/pages/token-explicit.gif which I will refer to as the "explicit token" model. I believe that historically the assumed token model has been the one which most people have had in mind. Before the new DwC standard, we had specimens and we had observations. In order to avoid redundancies in terms for those two types of "things", a combined "thing" called "Occurrence" was created. An Occurrence that was an observation didn't have a token and an Occurrence that was a specimen had a physical or living specimen as its token. That's all pretty simple and sensible and we see evidence of this kind of thinking on the descriptions given http://rs.tdwg.org/dwc/terms/index.htm . A record for an Occurrence has a thing called its dwc:basisOfRecord that presumably describes the kind of token (if any). So if the token were a preserved specimen, we would say that [Occurrence] basisOfRecord [PreservedSpecimen]. If there were no token we would say [Occurrence] basisOfRecord [HumanObservation] or [Occurrence] basisOfRecord [MachineObservation]. Referring back to the assumed token diagram, in the case of a specimen there is no explicit reference to the specimen as a separate entity. The terms related to the specimen, such as preparations and disposition are just plopped into the Occurrence class which implies that they are properties of the Occurrence itself. There seems to be a general consensus that other kinds of tokens can be used to document an Occurrence. However, the way that the current Darwin Core terms are designed and placed within classes are very inconsistent as to how they handle types of tokens other than specimens. According to the instructions at the top of http://rs.tdwg.org/dwc/terms/index.htm, a camera trap bird sighting should have [Occurrence] basisOfRecord [MachineObservation]. It is not clear how one is supposed to handle the actually metadata for the image that serves as the token. Unlike specimens where the token's metadata terms are placed in the Occurrence class, I guess in the case of an image one is supposed to use associatedMedia to link the so-called MachineObservation to the image record. If DNA were extracted, one would link the sequence to the Occurrence using associatedSequences (although it's not clear to me what the basisOfRecord for that would be - "TookATissueSample"?). But what does one do for other kinds of tokens, like seeds or tissue samples - create terms like associatedSeed and associatedTissueSample? I think that the ResourceRelationship terms were supposed to handle this problem, but I have yet to see an example of exactly how this was supposed to work. As an attempt to resolve this confusion in my mind, I wrote the Biodiversity Informatics paper that I've promoted frequently on this list (https://journals.ku.edu/index.php/jbi/article/view/3664). In that paper, I take the basic assumed token model and broaden it in an attempt to make the assumed token model work for all kinds of tokens. Because I assumed that each occurrence has a single token, I "collapsed the diagram" and connected the properties of the token directly to the Occurrence resource (as was modeled when specimen properties were placed within the Occurrence class). If there were several tokens for a given Individual, I "flattened" the records by creating a separate Occurrence resource for each token. The model was generalized further by allowing secondary Occurrence records where the token was not derived directly from the organism but rather derived from a primary Occurrence record. In complicated circumstances such as those found in a botanical garden where a seed or cutting might be collected from a tree with subsequent generation of a LivingSpecimen which might have a PreservedSpecimen collected from it and a DigitalStillImage taken of the preserved specimen. You can see examples of the complex types of situations I tried to handle at http://bioimages.vanderbilt.edu/pages/conceptual-scheme-insect.gif and http://bioimages.vanderbilt.edu/pages/conceptual-scheme-botanical.gif I created my own terms (like sernec:derivativeOccurrence and sernec:derivedFrom) to describe the connections among the individual and the various layers of Occurrences. Does this system work? Yes, but there are a number of problems associated with it. The first problem is related to Principle 4 above. In order for this system to work, there needs to be a consensus in the DwC community about several things. One is that each Occurrence must have only one token. If we are going to "type" Occurrences by their basisOfRecord (and the acceptable values for basisOfRecord are officially DwC types, see http://rs.tdwg.org/dwc/terms/type-vocabulary/index.htm), then an Occurrence can't have two values for basisOfRecord. It is clear from the discussion we've had that people would like to consider a single Occurrence to be able to have multiple tokens as documentation. The second problem is that there needs to be a consensus that a secondary Occurrence can exist at all (i.e. can you call the image of a specimen "an Occurrence"?). It is clear to me from the discussion that when people are thinking about what an Occurrence means, they have in mind the documentation of the time and place of the Individual in its environment. In a previous communication, John Wieczorek clarified that terms describing Occurrences like recordedBy and eventDate should only apply to primary occurrences and that it would not be appropriate to use them as properties of what I'm calling a secondary occurrence (such as the image of a specimen). So I dealt with this by creating a distinction between Occurrences that document the distribution of a taxon (using the term sernec:documentsDistribution) and those that don't. This is something like the old validDistributionFlag, but I defined documentsDistribution specifically as having a value of "true" only for Occurrences that were derived directly from the Individual (gray arrows in the two diagrams from the paper). But I think that the worst "crime" of the system I suggested is violation of Principle 5 above. By asserting an unvarying 1:1 relationship between the Occurrence and its token and by collapsing my relationship diagram to not explicitly include a resource that is the token itself, I am confusing the USE of an Occurrence (to demonstrate that a representative of a taxon was present at a particular Location at a particular time) which what the token IS (a dead organism in a jar or glued to paper, an electronic representation of photon patterns, a series of characters representing a nucleotide sequence). So I'm charging myself with this "crime", pleading guilty, and accepting my sentence, which is to admit that the system I suggested in the Biodiversity Informatics paper is "wrong" based on the principles I outlined above. What this amounts to is an acceptance of the "rightness" of the explicit token model (in the sense that I defined "right" in Principle 3 above). However, if I'm going to make this admission, I demand that the other guilty parties also confess, namely people who want to assert that Occurrences have properties that actually are properties of specimens. If we are going to have a system that actually works, we can't straddle the fence and say that the assumed token model is correct for specimens and that the explicit token model is correct for every other kind of token. If we accept the explicit token model, then specimen will have to come off of it's throne and be a token like all of the other ways that we provide evidence that an Occurrence happened. If we accept the explicit token model, then as a biodiversity informatics resource type "observation" will have to disappear into a puff of nothingness just like the "luminescent ether", "centrifugal force", and other kinds of things that we thought we needed to have to explain things but which turned out to be unnecessary when we figured out more basic explanations. A human observation will simply be an Occurrence that doesn't have a token (which is what I've heard some people say all along). If we allow the Occurrence/token relationship to be a one-to-many relationship rather than one-to-one, then HumanObservation is just the one-to-zero case of the more general one-to-many. For those of you who like the idea of a "machine observation", that is just an Occurrence with a token that is whatever type of resource that the machine produces (electronic data file, image of the organism, image of a graph, or whatever). ADVANTAGES OF RECOGNIZING TOKENS EXPLICITLY If we accept the explicit token model over the assumed token model, a number of problems get solved. Just as was the case with Events, people who want to flatten things out by having only one token per Occurrence can do so. For example, if I want to atomize things by defining my Occurrence to have taken place during an Event that lasted only the one second within which my camera shutter clicked, I can do that and have only a single token associated with that Occurrence. On the other hand, if others want to define their Occurrence as taking place over the time over which they photographed, collected a leaf tissue sample, and then collected a branch of a tree for an herbarium specimen, then they can do that and associate all of those tokens (one or more images, the tissue sample, and the preserved specimen) with the single Occurrence. Another important benefit will come down the line when we actually try to develop RDF templates. Right now it is not exactly clear (at least to me) how properties should be divided up among resources that are being described in the RDF. Based on the assumed token model, I have been including the metadata for the token within the container element for the Occurrence. This leads to some of the kind of odd assertions that people have been objecting to, such as [Occurrence] dcterms:rights ["(c) 2002 Steven J. Baskauf"] or [Occurrence] preparations ["skin"]. In the explicit token model, dividing metadata up appropriately among separate Occurrence and token resources makes more sense, e.g. [Occurrence] recordedBy ["Joe Curator"] [image] dcterms:rights ["(c) 2002 Steven J. Baskauf"] [specimen] preparations ["skin"] If we wanted to be really explicit about this, we probably should have a separate class for PhysicalSpecimens and separate the terms that describe specimens from those that describe Occurrences in general. There might be some difficulty in doing this because there are some terms that might be hard to decide about, like catalogNumber. I don't really think the catalogNumber is a property of the Occurrence, because it makes more sense to me to say [specimen] catalogNumber ["12345"] than [Occurrence] catalogNumber ["12345"] Realistically, I can't see this kind of separation ever happening, given the amount of trouble it's been just to get a few people to admit that Individuals exist. It is just too hard to get motion to happen in the TDWG community. As a practical matter, people who "compress" the system (which we admit happens and make concession to in Principle 3) by having record tables where a single row contains the metadata for both the Occurrence and the token (i.e. treat it as a 1:1 relationship) will simply have a column heading for catalogNumber and not care whether the catalogNumber applies to the Occurrence or the token. It's the people who want to do the more complicated stuff like simultaneously keep track of multiple tokens per Occurrence (like several images, a sound recording, and a specimen), people who want to write RDF, or people who want to merge databases containing many types of tokens who will have to pay attention to this distinction. Physical specimens would really be the only kind of class we would have to create because there already is a rich vocabulary for media items that is separate from DwC (i.e. the MRTG schema) and there are probably also vocabularies for stuff like tissue samples and DNA sequences (although I'm not familiar with them). TYPING Bob has warned us about the dangers of asserting that a term always applies to a certain type of resource by asserting that the term has an rdfs:domain . However, we should not avoid attempting to assert that a resource is itself of a certain type. Describing the "type" of a resource is an important part of letting potential users assess the possible fitness of use of that resource. For example, you can collect DNA from a preserved specimen but not from an image. You can include an image in a print journal article but not a sound recording. You can create build a range map from Occurrences, but not from DNA samples. In RDF, one of the basic properties that should be described about every resource is its rdfs:type . In the generic Linked Data world, you can pretty much use anything that you want as an rdfs:type . If you decide to use something obscure, then the danger is that nobody else will have any idea what kind of thing you are describing. The Draft TDWG GUID Applicability Statement recommendation 11 says that "Objects in the biodiversity informatics domain that are identified by a GUID should be typed using the TDWG ontology or other well-known vocabularies in accordance with the TDWG common architecture." So in our community, we can't just type resources any way we want. But exactly how we SHOULD type things isn't clear. There isn't any functioning TDWG ontology at the moment. I have found it useful to use the DwC class as the rdfs:type in my attempts to write RDF. That works pretty well for things that have DwC classes. But if we follow the explicit token model, we need to have some consensus on what we will use as the rdfs:type for the tokens. At this point it looks to me like it would make sense to have the convention that for tokens one uses either a dcterms:type or a Darwin Core type (i.e. one of the types listed at http://rs.tdwg.org/dwc/terms/type-vocabulary/index.htm, although as I already noted, there is no need for HumanObservation in the case of describing a token because human observations don't have tokens). There isn't any sort of "collision" here of the sort that happened right after the adoption of the Darwin Core Standard when we tried to merge the Dublin and Darwin Core types (see http://www.keytonature.eu/wiki/MRTGv08_Type_term_inconsistent_with_DwC and http://lists.tdwg.org/pipermail/tdwg-content/2009-October/000301.html with many following responses for the gruesome details) since rdfs:type doesn't demand any particular type vocabulary. I'm not entirely happy with this approach because for digital still images the logical type would be dctype:StillImage, which doesn't give any indication as to whether the image is film or digital, but I guess at this point in the 21^st century most consuming applications will probably just assume digital anyway. So (assuming that Individuals become a DwC class) I guess I don't really see that there is any problem in using the current Darwin Core classes to indicate the rdfs:type of every kind of resource that we would be reasonably likely to assign GUIDs to EXCEPT for tokens. Typing of tokens could be done using a combination of Darwin Core and Dublin Core types. What I'm left scratching my head about is basisOfRecord. When I subscribed to the assumed token model (i.e. when I wrote the Biodiversity Informatics paper), I thought I knew what basisOfRecord meant. It meant the kind of token that backed up an Occurrence. So when I wrote RDF for a specimen (as in http://bioimages.vanderbilt.edu/rdf/examples/lsu000/0428.rdf) I used the "hand grenade" approach to typing. I lobbed every kind of "typing" that I knew of at the Occurrence record for a specimen: [Occurrence] rdfs:type [dwc:Occurrence] [Occurrence] dwc:basisOfRecord [dwctype:PreservedSpecimen] and [Occurrence] dcterms:type [dctype:PhysicalObject] Under the explicit token model, I would just use [Occurrence] rdfs:type [dwc:Occurrence] for the Occurrence and [specimen] rdfs:type [dwctype:PreservedSpecimen] for the specimen itself. If I also took an image at the same time and wanted to say that it was part of the same Occurrence as the specimen, I would use [image] rdfs:type [dctype:StillImage] Under the explicit token model, I really can't see any use for dwc:basisOfRecord . Despite the resolution of the "train wreck" involving dcterms:type that we narrowly avoided after the adoption of Darwin Core, the definition still says "the specific nature of the data record - a subtype of the dcterms:type." I think this is clearly wrong because I think we established that it was NOT a subtype of dcterms:type in that discussion that I referenced above. So what is basisOfRecord??? What is "the data record" of which we are describing the nature? If it's the Occurrence, then I think the consensus that I'm hearing in the discussion is that an Occurrence data record shouldn't have as its type any of the dwctype terms except for dwctype:Occurrence. So what are all of the other terms like PreservedSpecimen for??? Under the explicit token model, what we really need is NOT basisOfRecord. What we need is some term like "dwc:tokenID" if you like the Darwin Core IDREF style or if you prefer the style of the Linked Data community "dwc:hasToken". In both cases, the object of the term would be an identifier for the token that's associated with a subject Occurrence. This term could be applied from zero (for observations) to many times to an Occurrence. People who want to flatten everything out will just ignore this term and cram all their metadata for the Occurrence, token, Event, and Location onto one line in their metadata table. People who are going to use any kind of one-to-many relationships at all will have to figure out how to handle that anyway and won't be daunted by having more than one dwc:tokenID per Occurrence. In the spirit of the complicated resource relationship diagrams from my paper, one could link primary tokens (like specimens) to secondary tokens (like specimen images) by using dwc:tokenID as well. Any kind of token (primary, secondary, tertiary, ad infinatum) could be linked to the occurrence that it supports with dwc:occurrenceID. WHAT DOES THIS DEMAND OF US? OK, I've now gone on for eight pages of text explaining the rationale behind the question. So I'll return to the basic question: is the consensus for modeling the relationship between an Occurrence and associated token(s) the assumed token model: http://bioimages.vanderbilt.edu/pages/token-assumed.gif or the explicit token model: http://bioimages.vanderbilt.edu/pages/token-explicit.gif ? If we accept the assumed token model with all of its warts, then for consistency's sake, we must create dwctype terms for each of the types of tokens that people would reasonably want to use as evidence for Occurrences (and my proposal for adding DigitalStillImage as a Darwin Core type stands). We must also resign ourselves to assigning a separate occurrence to each token that users want to use to document the presence of a taxon at a time and place. We also must accept having goofy-sounding statements like [Occurrence] dcterms:rights ["(c) 2002 Steven J. Baskauf"] If we accept the explicit token model, then we need to either dump basisOfRecord or come up with some rational explanation for what it actually means (and my proposal to add DigitalStillImage as a Darwin Core type becomes irrelevant). We also need to create some kind of term like dwc:tokenID that will allow connections to be made between Occurrence records and their tokens. For people who want to flatten out their Occurrence records and put the tokens together with the Occurrence (i.e. "compress the diagram" to get rid of the token resource), and who feel some need to indicate the type of the token that they are using, let them use any appropriate term from the Dublin Core or Darwin Core types as a value for rdfs:type. Until we make one of these choices or the other and "fix" Darwin Core to work in a consistent way, we are just going to continue to misunderstand each other because each person will just "know an Occurrence when they see it". In the interest of space, I am going to defer on explaining my opinions about LivingSpecimen and establishmentMeans. Those explanations are contingent on the conclusion that we reach on this issue. Steve -- 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

17 71

"Individual" use case
by Dean Pentcheff 02 Nov '10

02 Nov '10

Count me in as another late entry to this discussion, lurking under the rumbling flight paths of the VLPs (Very Large Postings). Here's a potential case to consider in the whole "how to file all the parts" issues that seem to be arising. It's a parent/child scheme that we're implementing for our marine invertebrate specimen database. We think we are being reasonable in the way we thought of this. We hope that this concept could be accomodated by DwC. That's the sum of the contribution for consideration: we hope DwC can/will cope with this. It may well be that it happily does so under all of the "Individual" interpretations that are bouncing around. But hey, we thought we'd toss it in just to make sure. With marine invertebrates, we very often find ourselves subsampling collected things (yes, "thing" is deliberately vague to avoid misusing any heavy-baggage words). It is intrinsic to the nature of the collections. Things often arrive as unsorted lots (think of a jar full of coral rubble in 95% alcohol, sitting on our shelf). We want to have a record for that jar in our database, so it gets one, with a recordID. Months later, we sort the jar to phylum level, and each of those jars gets a record, each with a recordID, and those jars go on a shelf. We treat those records as children of the unsorted-lot-record, and they each have a pointer back to that unsorted-lot parent record. Then we later sort one of those phylum-level jars into species jars. Those, in turn, each get a record with a recordID, and point to their parent phylum-level-jar record. And so forth down to individuals in jars, and tissue samples of individuals, and DNA extracts of those tissues. To complete the picture: many specimens do, of course, come in simply as an individual in a jar. Those just get a record, and that's that: no parent, no child (no child yet... until there's a tissue sample). Key points: 1. We never know how many levels of subsorting there will be. That differs from the "preparation" orientation of many vertebrate collections (for example), where there's a predefined set of preps that can come from each collected individual. We very often don't start with individuals. 2. Each thing, whether it comes in the door directly or is derived from something that did, gets a first-class catalog record, and the sole unifying feature that gets us the full information on a thing are the parent-child relationships of the data records. Information has to continue to reside in those records and be accessible from the "children" (an example would be a transfer to a different preservative when pulling one individual into a specimen jar from a lot jar: you need to know the preservative this thing is in now, and you also need to know what preservative its parent thing was in). 3. One field of each record has to document whether the item still exists: a thing may be completely subdivided into subparts leaving nothing left over to put back on the shelf. But in that case, we still keep the data record since it's still the parent of the subsorted things and still holds the relevant historical information. So one day when we push these data out into the Wild World in a DwC context, the thing we'd like to see accomodated is the ability of systems outside our own walls to resolve back up that chain of subsorting to build the whole information set for a thing, including the relevant information from its logical "parents". OK, now we'll be delighted to hear that this scheme was obviously accomodated all along, or alternately, that this whole concept is a pretty dumb way of cataloging our holdings. -Dean -- Dean Pentcheff Research Associate, Natural History Museum of LA County pentcheff(a)gmail.com dpentche(a)nhm.org

3 2

Updated TaxonConcept Occurrence Examples
by Peter DeVries 02 Nov '10

02 Nov '10

I have updated a number of the examples. The RDF representation creates, or makes statements about several separate entities. http://ocs.taxonconcept.org/ocs/f522444a-2dd9-400e-be59-47213ef38cb9.html(S… to Bottom) * Now includes a way to document the original occurrence and id labels Here is the RDF http://ocs.taxonconcept.org/ocs/f522444a-2dd9-400e-be59-47213ef38cb9.rdf TXN_FCT < http://lsd.taxonconcept.org/describe/?url=http://ocs.taxonconcept.org/ocs/f…> *The Occurrence*: http://ocs.taxonconcept.org/ocs/f522444a-2dd9-400e-be59-47213ef38cb9#Occurr… TXN_FCT < http://lsd.taxonconcept.org/describe/?url=http://ocs.taxonconcept.org/ocs/f…> URIburner < http://linkeddata.uriburner.com/about/html/http/ocs.taxonconcept.org/ocs/f5…> Sindice < http://sig.ma/search?pid=3e0bb912d2ab43e0efd7baa0bbcd1a4e > *The Individual * http://ocs.taxonconcept.org/ocs/f522444a-2dd9-400e-be59-47213ef38cb9#Indivi… TXN_FCT < http://lsd.taxonconcept.org/describe/?url=http://ocs.taxonconcept.org/ocs/f…> *An Identification * http://ocs.taxonconcept.org/ocs/f522444a-2dd9-400e-be59-47213ef38cb9#Identi… TXN_FCT < http://lsd.taxonconcept.org/describe/?url=http%3A%2F%2Focs.taxonconcept.org…> *The Species Concept* http://lod.taxonconcept.org/ses/ICmLC.html TXN_FCT < http://lsd.taxonconcept.org/describe/?url=http://lod.taxonconcept.org/ses/I…> Area geo:44.86528100,-87.23147800;u=10 < http://lsd.taxonconcept.org/describe/?url=geo:44.86528100,-87.23147800;u%3D…> Also there seem to be several OWL validators, some which are for OWL 1 others for OWL 2 OWL 1 http://www.mygrid.org.uk/OWL/Validator OWL 2 http://owl.cs.manchester.ac.uk/validator/ Updated the ontologies, but they are not 100% yet. Beware of Protege !!!, You can create things that look correct and validate in Protege but the actual .owl file is not correct. http://lod.taxonconcept.org/ontology/txn.owl Respectfully, - Pete --------------------------------------------------------------- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base <http://www.taxonconcept.org/> / GeoSpecies Knowledge Base <http://lod.geospecies.org/> About the GeoSpecies Knowledge Base <http://about.geospecies.org/> ------------------------------------------------------------

1 0

newbie comments on Individual
by Nate Flesness 02 Nov '10

02 Nov '10

This is a tough list to join - lots of specialized vocabulary and concepts (its purpose of course) - I've been "lurking" awhile, and this is the first time I think I understand and might have something small to add from the live collections point of view. Speaking from 30+ years at ISIS working with biodiversity data from 800+ institutions (zoos, aquariums, etc) on live animal individuals and groups, I'd expand Steve Baskauf's comment to say people need BOTH the ability to handle individual animals (a wolf) and ALSO the situation Where your data does not distinguish individuals but you track a group identity and some kind of count (a wolf pack... we do that, and/or by life stage, and/or by sex). Some live fish can be practically tracked as individuals, and sometimes obviously not because there are ~5000 in that tank. Some of our groups are too big to count individuals even as estimates (beehives, ant colonies), so we change the units and count colonies. I hope this was faintly relevant and look forward to meeting more of you in person when opportunity allows, Nate Flesness Director of Science International Species Information System (ISIS) www.isis.org<http://www.isis.org>

2 1

Request for withdrawal of proposal to move dwc:establishmentMeans to proposed the DwC class Individual
by Steve Baskauf 01 Nov '10

01 Nov '10

In my previous understanding of Occurrence in which a single token was incorporated as a part of an Occurrence, I considered an Individual to have ceased to exist and to have become an Occurrence of type LivingSpecimen when it was collected to be part of a collection (e.g. zoo). Given this understanding, I felt that there were few or no cases where the establishmentMeans of an Individual would change (excluding its capture and incorporation in a collection) and therefore it made sense for having a single establishmentMeans value for the individual. However, under the apparent consensus opinion that the token documenting an Occurrence is a separate entity, I no longer believe that there is any purpose in recognizing an entity called "LivingSpecimen". A living specimen is simply an individual with curation information. The token for an Occurrence that involves the collection of a living specimen is the Individual itself (in the case of removal of the entire organism) or a different Individual (i.e. in the case where a new individual is propagated vegetatively from the Individual being documented by the Occurrence). Given this understanding, the establishmentMeans of an Individual can change over time, so it is not possible for every Individual to have a single value for establishmentMeans. The consensus that seems to have emerged from the tdwg-content discussion is that dwc:establishmentMeans is a complex thing that describes the relationship of an Individual to a Location that can change over time. I do not see how establishmentMeans is a property of an Occurrence - in fact it is not clear to me exactly how one applies establishmentMeans as a property to an instance of any existing DwC class. But in any case, there does not now seem to be any advantage to moving it from the class Occurrence to the proposed class Individual, so I officially withdraw my proposal if that is possible. Alternatively, the TAG could take a vote and vote the proposal down, but I think that would be a waste of time. Steve -- 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

2 1

Request for vote on proposal to add DigitalStillImage as a dwc:type
by Steve Baskauf 31 Oct '10

31 Oct '10

The recent discussion on the tdwg-content email list has clarified my understanding about the community consensus on the nature of an Occurrence. In my previous view that each Occurrence had a single token that provided evidence for the Occurrence, I felt that it was necessary to have a term in the Darwin Core type vocabulary for each type of token that could serve as evidence for an Occurrence and which could serve as a controlled value for dwc:basisOfRecord. On the basis of this understanding, I proposed adding DigitalStillImage as a dwc:type. However, given the apparent consensus that the documenting token is a separate entity from the Occurrence and that there may be multiple tokens associated with a single Occurrence, I no longer see any need for adding DigitalStillImage to serve as a controlled value for basisOfRecord, since still images that are tokens will be a separate resource from Occurrence and can simply be rdf:type'd as dcterms:StillImage . (In fact, I no longer believe that basisOfRecord itself serves any useful purpose - I'm still waiting for someone to show me a case where it is necessary for it to exist as a term.) I'm not actually withdrawing my request, because if there is actually a purpose for basisOfRecord, then DigitalStillImage should be a value for it. People who want to use basisOfRecord will need it. But given my current understanding of an Occurrence, I would vote against my own proposal (if I were voting, which I'm not). Anyway, unless there is a desire for further discussion of basisOfRecord, I feel like the discussion on tdwg-content of adding DigitalStillImage to the DwC type vocabularly has progressed far enough for the TAG to move on to the voting stage. Steve -- 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 0

Re: [tdwg-content] Treatise on Occurrence, tokens, and basisOfRecord [SEC=UNCLASSIFIED]
by Richard Pyle 28 Oct '10

28 Oct '10

Thanks, Julian -- I somehow missed Stan's post (among a flurry of other emails - both from this list, and from other sources). Sorry about that, Stan! So, after now having read Stan's post, I do agree that the "who and how" (I'm leaving out the "what they did", to avoid people mistaking it for the "what they saw") -- that is, the "action" (in my terms) of the Event -- should, indeed, be regarded as part of the Event, and not part of the Occurrence (although I still maintain it could legitimately be interpreted either way). I should also take this opportunity to mention MUSE and FishGopher as being among the very early efforts to organize this sort of information in a form that could be distributed over the proto-Net. Aloha, Rich > -----Original Message----- > From: Julian H [mailto:humphries@mail.utexas.edu] > Sent: Thursday, October 28, 2010 1:09 PM > To: Richard Pyle > Cc: tdwg-content(a)lists.tdwg.org > Subject: Re: [tdwg-content] Treatise on Occurrence, tokens, > and basisOfRecord [SEC=UNCLASSIFIED] > > > As Stan said in an earlier message today: > > "Back to the issue of event definition: If Event is defined > as just the conjunction (association, intersection, join) of > space and time, there is nothing to tell you why this > particular interval is of interest." > > In other words the who and how and what they did that made > the event of interest. > > julian > > > At 02:30 PM 10/28/2010, Richard Pyle wrote: > > > Yeah, some act took place at that place and time. In the > context of > > > Occurrence, probably an act of sampling or collecting, and so one > > > should expect metadata documenting that act (who, how, etc) > > > >As I alluded to in my previous post, it's not clear to me > whether the > >who, how, etc. are intrinsic properties of the Event, or if > the "Event" > >simply represents the single coordinate in 4-D space-time; and the > >other stuff is more a function of the Occurrence (i.e., more > metadata > >about documenting the tuple of Event+Individual). I can see > rational > >arguments either way. My inclination is that the word "Event" goes > >beyond merely the space-time coordinate, and implies some sort of > >"action". As such, my inclination is to define the "Event" as more > >than just the 4D space-time coordinate, and include who, > how, etc. as part of the "action" of the Event. > > > >As is probably obvious, I haven't throught this through extensively > >yet, so I reserve the right to change my mind. > > > >Rich > > > > > >_______________________________________________ > >tdwg-content mailing list > >tdwg-content(a)lists.tdwg.org > >http://lists.tdwg.org/mailman/listinfo/tdwg-content >

1 0

Painted Lady Butterfly in from within the LOD Cloud via URIburner
by Peter DeVries 28 Oct '10

28 Oct '10

Painted Lady Butterfly in from within the LOD Cloud via URIburner http://bit.ly/aCLXmF The Occurrence RDF http://ocs.taxonconcept.org/ocs/a71fda68-024a-4020-a34c-64dce7935e5f.rdf <http://ocs.taxonconcept.org/ocs/a71fda68-024a-4020-a34c-64dce7935e5f.rdf>The Species Concept RDF http://lod.taxonconcept.org/ses/dwAmr.rdf <http://lod.taxonconcept.org/ses/dwAmr.rdf>I had added a urn for the individual so that individuals can be tracked between several occurrences. This SPARQL Query Which you can run on any endpoint that has the data set loaded will show the occurrences of this species. Here is the query embeded in a URL: (Toggle "Visualization" to get the map) < http://lsd.taxonconcept.org/isparql/view/?query=PREFIX%20txn%3A%20%3Chttp%3… > If that does not survive your email client, here is the bit.ly link http://bit.ly/crqr6G This will also run on the LOD cloud. http://bit.ly/aBBFCA (but you don't have to toggle the visualization) - Pete --------------------------------------------------------------- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base <http://www.taxonconcept.org/> / GeoSpecies Knowledge Base <http://lod.geospecies.org/> About the GeoSpecies Knowledge Base <http://about.geospecies.org/> ------------------------------------------------------------

1 0

Re: [tdwg-content] practical details of recording a determination What is an Occurrence?
by Kevin Richards 28 Oct '10

28 Oct '10

I can't help but feel we are getting into a much more complicated area of biodiversity ( or any observation oriented field for that matter ) and that there must be other ontologies or models that we could follow or reuse. Our strength at TDWG is obviously the more biodiversity specific details such as taxonomy, invasiveness, etc. I might have an investigation of possible models to reuse - unless someone has already done this and has a suggestion. Kevin Sent from my HTC ----- Reply message ----- From: "Richard Pyle" <deepreef(a)bishopmuseum.org> Date: Thu, Oct 21, 2010 8:11 pm Subject: [tdwg-content] practical details of recording a determination What is an Occurrence? To: "'Steve Baskauf'" <steve.baskauf(a)vanderbilt.edu> Cc: "tdwg-content(a)lists.tdwg.org" <tdwg-content(a)lists.tdwg.org> I see dwc:establishmentMeans as being very clearly a property of "Individual At Place" (again, scoping "Individual" up to at least population). The closest thing we have to that in the diagram1 is Occurrence. The only hitch is that Occurrence isn't exactly "Individual At Place", so much as "Individual At Event[=Place+Time]" Some people have suggected that dwc:establishmentMeans is a function of Time as well as Place, in which case it is very clearly (to me) a property of Occurrence. Rich ________________________________ From: Steve Baskauf [mailto:steve.baskauf@vanderbilt.edu] Sent: Wednesday, October 20, 2010 3:25 PM To: Richard Pyle Cc: tdwg-content(a)lists.tdwg.org Subject: Re: [tdwg-content] practical details of recording a determination What is an Occurrence? Well, I also feel pretty good about most of that diagram, but I'm still struggling with the whole "token" thing. I feel the need to discuss basisOfRecord=LivingSpecimen which is the most complicated case and is also related to the previous discussion about dwc:establishmentMeans as well as my proposal to move it to the proposed Individual class. It is also related to another issue that I haven't broached here but which is discussed in my paper - "Occurrences" that aren't directly derived from an individual. I'm beginning to think that part of what I wrote there (in the paper) was wrong, but I'm not sure what the alternative is. That issue will probably come up if I comment about what Cam wrote in his email. So there may be more to hash out, but I can't handle it today because I've got too many other things to do. I've been mentally composing what I hope is a lucid presentation, but it hasn't hit the keyboard yet. Steve I have to say, this has been about the most productive (if volumunous) list-discussion I've had in...well...maybe ever. It seems we've both been equally persuasive, and equally willing to concede. How rare that happens in an internet forum! I'm not sure there's anything left that we disagee about. If the "diagram1" seems to resonate with everyone as the most "normalized" ER diagram we'll likely ever need, and if we can somehow accommodate flexibility in RDF for collapsing attributes to different classes (but only from the "one" side to the "many" side) -- then we might have achived the elusive Holy Grail of biodiversity informatics: true consensus. Thanks for your great feedback and for challenging my statements. I need that! Likewise! Aloha, Rich . -- 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 _______________________________________________ tdwg-content mailing list tdwg-content(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content ________________________________ Please consider the environment before printing this email Warning: This electronic message together with any attachments is confidential. If you receive it in error: (i) you must not read, use, disclose, copy or retain it; (ii) please contact the sender immediately by reply email and then delete the emails. The views expressed in this email may not be those of Landcare Research New Zealand Limited. http://www.landcareresearch.co.nz

5 9