October 2010 - tdwg-tag - lists.tdwg.org

Re: [tdwg-tag] RDF N3
by Kevin Richards 18 Nov '10

18 Nov '10

I like the sound of the 'compactness' of the format, but I worry that there is a lack of tools that support the format (ie browsers, mainly). It is quite nice to naturally navigate the rdf world with a standard browser. But for transfer standards, I suppose this wouldn't matter. Kevin Sent from my HTC ----- Reply message ----- From: "Bob Morris" <morris.bob(a)gmail.com> Date: Sun, Jan 24, 2010 12:08 PM Subject: [tdwg-tag] RDF N3 To: "Technical Architecture Group mailing list" <Tdwg-tag(a)lists.tdwg.org> Let's make N3 be the recommended RDF representation. It is way more compact and human readable than RDF/XML. We could even specify a normative conversion tool if necessary. -- Robert A. Morris Professor of Computer Science (nominally retired) 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)617 287 6466 _______________________________________________ tdwg-tag mailing list tdwg-tag(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tag ________________________________ 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

4 4

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

02 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 proposals to add Individual as a Darwin Core class and to add the term individualRemarks as a term within that class
by Steve Baskauf 31 Oct '10

31 Oct '10

I am pleased with the significant and thoughtful discussion that has taken place on the tdwg-content email list regarding the relationships among Occurrences, Individuals, and other entities that are a part of the community's thinking about biodiversity metadata and the way that those metadata are structured. It appears from the discussion that there is widespread acceptance of the idea that Individual as a concept has a place in the structuring of biodiversity metadata and that there is some consensus of what "Individual" means (i.e. an entity ranging from actual biological individuals to small coherent populations that can reliably be asserted to represent a single taxon). Whether that acceptance and consensus constitutes a compelling need for adding two new terms (the class dwc:Individual and dwc:individualRemarks) to the Darwin Core standard or not is the point of a TAG "vote". Given the discussion that has occurred, it seems to me that there are two reasons why there is an actual need for those terms. One reason is that if members of the Darwin Core constituency intend to structure their metadata in a fully normalized manner that includes grouping Occurrences by Individuals (and it appears that there are at least several who intend to do this), the term dwc:individualRemarks is needed to provide a means indicate the nature of the individual (i.e. is it a biological individual, clonal individuals, a small population, etc.?) and the class dwc:Individual is needed as the category within which to put individualRemarks so as to indicate that individualRemarks is a property of Individuals. The second reason for explicitly recognizing Individual as a class is that it would place a term representing the concept of "Individual" within a "well-known vocabulary". I feel that would be critical for facilitating the ultimate development of a recommendation for the representation of Darwin Core as RDF. At this point, it is not clear to me that there are any other existing DwC terms that should be moved to a new Individual class. Originally, I suggested that individualCount should be placed in that class, but I no longer think so. Counting the number of individuals is really something that happens when an Occurrence takes place and a small cohesive group of a single taxon (e.g. wolf pack or plant population) could have an individualCount that changes over time. As was discussed earlier in on the email list, the xxxxxxID terms probably really belong in the Record-level terms category rather than being listed within particular classes. So I don't believe that dwc:individualID should be in the proposed class either. As I detailed in my Biodiversity Informatics paper, an Individual is really an entity that serves primarily as a node that allows the grouping of other resources (namely Occurrences and Identifications). As such, it really has few (or no) properties that can be known outside of Occurrences. Thus I would like to "call the question" on the issue of the proposal. I would suggest that the issue of adding the class dwc:Individual and the term dwc:individualRemarks within it be addressed in a single vote, since there little point in having one term without the other. I would also hope that those on the TAG who choose to vote would review the list discussion carefully first. Given that the question of "what exactly is an Individual?" came up a few times after that question was clearly answered in the thread is an indication that some people entered the thread later on without the benefit of having read some of the earlier posts. 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 3

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-tag] [tdwg-content] Idea for Discussion, Differentiating between "type's" of identifiers
by Blum, Stan 08 Oct '10

08 Oct '10

Hi Steve, Sorry, I missed your message below (as well as your response to Roger) before I sent my reply about the utility of an RDF guide for DwC. Obviously, I think it’s a great idea. To do this within the “normal” TDWG process, this should be done as a Task Group. I could help you draft a charter for that, which would then need to be reviewed by the TAG and Exec. Once approved, we would put the charter up on the web site, and do our best to provide any other resources that would help speed the task. I don’t mean to slow you down. The Charter doesn’t have to be elaborate. It’s function is to let others in TDWG and beyond know that this task is proceeding, who to contact, how to get involved, etc. It also gives you the backing of the TDWG community. Let me know if you’d like to pursue this. -Stan On 10/7/10 7:41 AM, "Steve Baskauf" <steve.baskauf(a)vanderbilt.edu> wrote: I agree that it is best to avoid a proliferation of terms and I agree that it is best to keep Darwin Core technology independent to the maximum extent possible. However, I think that the case of facilitating HTTP URIs is a special one because of the requirements of GUIDs/Persistent Identifiers. Both the TDWG and GBIF guidelines such as they currently stand say that GUIDs must be resolvable, that in their resolution they must return RDF, and that the RDF has to be in an XML format. Like it or not, that is what we have. Given the amount of time that it seems to have taken to settle on that much, I think it is best for us to decide to live with it, warts and all, rather than re-opening the discussion and delaying the implementation of GUIDs for another five years. Given that assumption, there needs to be within Darwin Core some way to support this particular "technology" (Linked Data, RDF/XML) even if we don't do "special" things to support other technologies such as LSID, DOI, etc. The point is well taken that most of those other technologies have mechanisms for turning their identifiers into URIs and the aforementioned guidelines lay out how owl:sameAs can be used within the RDF to associate the non-HTTP-resolvable forms with the URIs. Based on my admittedly limited experience with trying to write RDF using Darwin Core terms, I think that in most cases there already exists appropriate terms for getting the job done. What may be lacking is concrete examples and community consensus on what terms to use for what. I also think that there are probably some "ID" terms where it isn't really very important (from an RDF point of view) that there exist both a URI form and a text string form. I'm thinking of something like dwc:identificationID, which is mostly likely to be needed to allow a machine to make a connection between some resource and its identification. The machine isn't going to care if there is a human-readable version. In contrast, something like dwc:collectionID is likely to need both a URI version (e.g. proxied version of the BCI LSID) for the machines and a string version (the name of the collection as it would be displayed) for humans. I think that trying to make example/template RDF for various types of resources will help make it clear in which cases one version (URI), the other (string), or both are actually necessary. I "volunteered" a couple weeks ago to have a go at writing an RDF guide for Darwin Core. I am still willing to do this, although I'm still getting caught up at work from being at the TDWG meeting. However, next week we have fall break and I will make it a priority to come up with a draft which can be the subject of discussion. As a part of this process, I think it would be good to create one or more "boilerplate" RDF files for the various kinds of resources that are likely to be identified with GUIDs (e.g. Occurrences, Taxa, etc.). This can also be a subject of discussion and I think it will help to clarify what will meet the actual needs that we have discussed in this thread. I have a pretty clear picture of what I think Occurrence RDF should look like. I'm going to have to depend on Pete and others to deal with the taxonomy part. Steve Markus Döring wrote: Steve, Pete, Id like to draw your attention on a basic DarwinCore design pattern. Dwc has the goal of being technology independent by simply providing a list of abstract terms one can use in various arenas such as xml, rdf, xhtml, csv etc. And even within those there might be various ways of using them (e.g. we have a normalised and a simple flat xml schema), thats why we should have a guideline for each of them on how to use them. We are missing such a guideline for rdf currently, hence this debate. Whether scientificName is a literal string or some complex object shouldnt matter - its defined to be a scientific name. Such a dwc rdf property could either hold a literal string or a url to some name rdf:resource (potentially with a rdfs:label). With the introduction if many ID terms we have diluted that idea a little already in my mind. We could have as well used scientificName in xml to hold some identifier for that name. All URNs tell you what they are by their urn prefix (not necessarily how to resolve them), so you can easily detect a UUID, LSID, http(s) url, ftp, doi and apply the conventional resolution mechanism. The hardest problem are the local ids and other plain identifers. For those mainly we created the ID terms (at least in my mind). I am feeling rather uncomfortable discussing the introduction of specific dwc terms for each type of id. Maybe we should remove all id terms in dwc and use the specific guidelines to specify these? At least if you really think having all those id terms for rdf is a good thing I would feel much more comfortable going down this route instead of diluting dwc by adding more and more rather redundant terms. The abstract concept is key to a dwc term, not the actual data type fo rced by the technology you are using it with. Would you want several date terms for various date formats? In fact we do that already to some degree (eventDate, eventTime, year, month, day, verbatimEventDate) and I always felt this is not a good idea. There are also a number of verbatimXXX terms in dwc which also contradict this pattern. Talking about new dwc terms - in the examples given properties like "hasScientificName" is not strictly the correct dwc term, which is simply scientificName. I think it would be fine to have the convention in the rdf guidlines to use hasDwcTerm instead of dwcTerm, this is exactly what an rdf guideline is for. On the flip side I am sure this only applies to some terms, recordBy for example is likely to remain as it is. Its unclear to me what is best to do really. Always stick to the original dwc terms? Refine them through some rdfs or owl schema and define the relation to the original term? Should we still use the same namespace in this case? As an rdf beginner even after a few years exposed I wonder if we cant simply stick to the non ID terms and use them either as literals or with a uri pointer. As in the rdf world a resolvable http is really required for resource relations to work, why not simply mandate this in the guidelines? If you only happen to have non resolvable uris like lsid or dois the guidelines should be asking you to use proxied versions, knowing it will break rdf frameworks and lod conventions otherwise. On the resolving side one could always include such urns with owl:sameAs (or sth alike) I believe. But how many non resolvable ids with no matching http counterpart are really out there yet? - Markus On Oct 6, 2010, at 9:02, Peter DeVries wrote: Hi Steve, You are probably right that it might be best to use rdfs:Label, but I am thinking we might be able to get the same result my defining the string variants as subproperties of rdfs:Label. This would make them an rdfs:Label but a special kind of rdfs:Label. This is one of those things that I would test with Sindice and URIburner to see if they interpret these correctly. This would require a live vocabulary that Sindice could look at to determine that hasScientificName is to be treated as a rdfs:Label. - Pete On Mon, Oct 4, 2010 at 10:41 AM, Steve Baskauf <steve.baskauf(a)vanderbilt.edu> <mailto:steve.baskauf@vanderbilt.edu> wrote: Although this specific example deals with taxonomic name identifiers, it is related to a previous discussion on this list about how we should use the dwc:xxxxxID terms and other terms (such as recordedBy and identifiedBy) that could have either a string (literal) or URI form. Although I don't really want to see an unnecessary proliferation of Darwin Core terms, I think that in the interest of clarity (particularly where RDF is involved) there either should be multiple terms that make it clear what form of identifier is expected, or else there should be an understanding that in RDF the default for such a term is a URI which would then have an rdfs:Label property which was the string form. I think the former would be preferable to the latter. I came to this opinion when trying to write RDF describing an herbarium specimen. The collector should be the dwc:recordedBy property of the specimen. Optimally, there would be a database in which known collectors were assigned URIs so that "Glen N. Montz", "Glen Montz", "G. N. Montz", etc. would all be different labels for the same resource. However, realistically, I'm not going to drop what I'm doing to set up such a database (even if I were capable of doing it, which I'm not). So I ended up just writing it as <dwc:recordedBy>Glen N. Montz</dwc:recordedBy> even though I knew it wasn't probably the best thing. In a large Occurrence database that was compiled from the RDF created by a lot of people, there might end up being a mixture of strings and URIs for dwc:recordedBy properties of the specimens. It seems to me like it would be better to have properties like dwc:recordedBy for strings and dwc:recordedByURI for a corresponding URI (and I suppose dwc:reco rdedByLSID if anyone wants to use it). Of course, this would require a number of term additions to DwC and clarification in the DwC documentation that the generic version was intended for strings. With respect to the example <dwc:hasScientificNameLSID rdf:resource="urn:lsid:catalogueoflife.org:taxon:24e7d624-60a7-102d-be47-00304854f810:ac2010"/> I think you are right that (with the possible exception of rdfs:seeAlso) there is an expectation that an rdf:resource attribute will be a resolvable URI that produces RDF. So <dwc:hasScientificNameLSID>urn:lsid:catalogueoflife.org:taxon:24e7d624-60a7-102d-be47-00304854f810:ac2010</dwc:hasScientificNameLSID> is probably better. Steve Peter DeVries wrote: I have been thinking about the following pattern. In part after looking at the GBIF vocabulary. I am not sure if it is even a good idea but might be worth some discussion. For those fields that have both a string and "ID" form maybe the following pattern might be useful hasScientificName = string form hasScientificNameURI = Resolvable LOD compliant identifier hasScientificNameLSID = LSID identifier which could be resolvable once you add the "http:proxy" <http:proxy> etc. This allows all three forms to be included if desired, it also provides a hint as to how the field should be interpreted or resolved. One group could also provide a mapping service so that each record does not need to include all three forms, but would allow systems to find the matching LSID for a given URI or vs. versa. My concern was that it would be difficult to infer how a scientificNameID should be interpreted by other systems. Is this an LSD, is it a URI, is it a UUID etc. ? This impacts the structure of the RDF. * Note that the actual identifiers might not be correct, the example below is more about the form of the RDF * For instance, I don't think it is probably correct to see the COL LSID as just a namestring * Also in this example the GNI name does not exactly match the string name <dwc:hasScientificName>Puma concolor (Linnaeus 1771)</dwc:hasScientificName> <dwc:hasScientificNameURI rdf:resource="http://gni.globalnames.org/name_strings/6c3dc35f-d901-5cc5-b9c8-ad241069b9f8" <http://gni.globalnames.org/name_strings/6c3dc35f-d901-5cc5-b9c8-ad241069b9f8> /> <dwc:hasScientificNameLSID rdf:resource="urn:lsid:catalogueoflife.org:taxon:24e7d624-60a7-102d-be47-00304854f810:ac2010"/> Some system may choke on the LSID form assuming that it uses a standard resolution mechanism So it might be best to use this form <dwc:hasScientificNameLSID>urn:lsid:catalogueoflife.org:taxon:24e7d624-60a7-102d-be47-00304854f810:ac2010</dwc:hasScientificNameLSID> - Pete ---------------------------------------------------------------- Pete DeVries Department of Entomology University of Wisconsin - Madison 445 Russell Laboratories 1630 Linden Drive Madison, WI 53706 TaxonConcept Knowledge Base / GeoSpecies Knowledge Base About the GeoSpecies Knowledge Base ------------------------------------------------------------

2 1

Re: [tdwg-content] What RDF is (Was Re: Idea for Discussion, Differentiating between "type's" of identifiers)
by Markus Döring 07 Oct '10

07 Oct '10

I am wondering if this discussion and similar rdf, lsid topics should continue on tdwg-tag rather than tdwg-content. We might bore quite a few people... On Oct 6, 2010, at 17:13, Peter DeVries wrote: > Some people might find the N3 serialization useful. > > It simply lists the subject, predicate and object followed by a period. > > It is somewhat easier to interpret, and can be easy to make. You can even create this with apps like FileMaker Pro. > > You can then take this N3 form and convert it to RDF using online tools or standard libraries. > > Many if not most of the triple / quad stores can read in the n3 form directly. > > Here is an example that links a species concept to a geographical location. (in both directions) > > <http://sws.geonames.org/6255149/> <http://lod.taxonconcept.org/ontology/txn.owl#hasExpectationOf> <http://lod.taxonconcept.org/ses/iLCOZ#Species> . > > <http://lod.taxonconcept.org/ses/iLCOZ#Species> <http://lod.taxonconcept.org/ontology/txn.owl#isExpectedIn> <http://sws.geonames.org/6255149/> . > > - Pete > > On Wed, Oct 6, 2010 at 9:51 AM, Bob Morris <morris.bob(a)gmail.com> wrote: > On Wed, Oct 6, 2010 at 8:53 AM, Peter DeVries <pete.devries(a)gmail.com> wrote: > >[...] > > I think part of the problem we are having is that people are not recognizing > > how different RDF is from straight XML. > > ... > > It's way worse than that. RDF is not XML at all. RDF/XML is merely a > serialization of RDF It's not even the most human readable > serialization. In fact it is one of the \worst/ for humans who need to > figure out what triples are actually in play. It is so ubiquitous > only because there are more tools that can process RDF/XML than any of > the other RDF serialization syntaxes (syntices???). The persistent > myth that human readability is an advantage of XML pretty much ignores > all the use cases that humans have for reading something. It's about > as readable as Lisp. Indeed, a Lisp loving colleague said of XML on > the occasion of its first W3 recommendation : "I get it. It's Lisp > with pointy brackets." > > 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) > > > > -- > ---------------------------------------------------------------- > Pete DeVries > Department of Entomology > University of Wisconsin - Madison > 445 Russell Laboratories > 1630 Linden Drive > Madison, WI 53706 > TaxonConcept Knowledge Base / GeoSpecies Knowledge Base > About the GeoSpecies Knowledge Base > ------------------------------------------------------------ > _______________________________________________ > tdwg-content mailing list > tdwg-content(a)lists.tdwg.org > http://lists.tdwg.org/mailman/listinfo/tdwg-content _______________________________________________ tdwg-content mailing list tdwg-content(a)lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-content

5 7