Flip and all,
Thanks for that explanation. I can add a point of clarification that might help people's understanding of the intention of the "uncertainty radius." I think the stumbling block for most people is perfectly reflected in the succinct definition Flip has given as an example,
"It is intended instead to include the true collection locality with 100% certainty."
In fact, the uncertainty radius as we presented it specifically makes no claim to include the true collection locality - it promises only to interpret the primary data consistently. The primary data can be inaccurate. One clear shortcoming of the paper, in retrospect, is that it did not provide a succinct definition of the attribute "uncertainty radius" we were promoting. I would like to venture such a definition now:
"The point-radius method (per Wieczorek et al.) describes the sources and rules for combining uncertainties found in the spatial interpretation of textual, descriptive locality data encountered in natural history occurrence data. The 'uncertainty radius' defined by this method is the minumum horizontal linear distance needed to describe a circle, projected onto a geoid, within which lies the entirety of the physical location it is meant to encompass. The uncertainty radius does not establish the verity of the primary data upon which it is based."
Once you get deep into the georeferencing business you find that there are a number of additional pieces of information about process and source information from which the end user can benefit. Such is the experience behind the numerous concepts in the proposed geospatial extension to DwC2. It's also the reason why I proposed the unified packaging of geospatial information.
I would like to register my support for Flip's recommendation that the point-radius representation (including the metadata beyond the coordinate, coordinate reference system, and distance) be included as the least common denominator geometry in any geospatial schema we develop.
John
On 1/9/06, Phillip C. Dibner pcd@ecosystem.com wrote:
Javier,
Happy New Year, and thanks for your thoughtful reply (below). I do think we have a good understanding.
I've started to answer your email several times, but realized each time that I might not be addressing your real question. So, for clarification: you say that the one thing you need is item 1 in your email below, the geospatial extension. Is the file that I sent you when I first replied a close approximation to your needs?
In more detail, and to put things in terms of existing technology, if we were to recast the files I sent you so that they conform to GML 2, and permit using only one geometry per feature, would that satisfy your requirements for a GML application schema (for Darwin Core)?
As to the data to be incorporated in an application that uses just a single geometry per feature, I suggest defining the location as a point with a net uncertainty radius - as a possibly degenerate circle. As I think I said in my original response to your inquiry, we should require all implementations to support this, to provide a least common denominator that would be accessible to all client and server implementations. I do believe that a polygonal locational description should be in the schema, but as an option. If a polygon is available, then a centroid and net uncertainty radius can be computed from it.
The "net uncertainty radius" mentioned above refers to the method originally proposed by John Wieczorek and others ("The point-radius method for georeferencing locality descriptions and calculating associated uncertainty," INT. J. GEOGRAPHICAL INFORMATION SCIENCE VOL. 18, NO.8,DECEMBER 2004, 745–767), and proposed as the georeferencing method to be used in DarwinCore 1.4. It's a bit controversial, I think mostly because it is an unfamiliar notion: the uncertainty radius as he defines it is not a traditional statistical error radius. It is intended instead to include the true collection locality with 100% certainty. I think a few simple modifications to the definition might make it more comprehensive and more broadly acceptable.
I'm actively working on this now, along with several related issues, and I'll be pleased to stay in touch about progress.
Please let me know if this message has provided any assistance.
Thanks and best regards, Flip
On Dec 28, 2005, at 7:04 AM, Javier de la Torre wrote:
Dear all,
First of all Merry Christmas! Have a nice holidays Flip.
Ok. I think I am starting to understand you better, I am a little bit ashamed that I did not attend the Geospatial session last TDWG on Saturday, I feel I am a little bit behind on the discussion, would be great to get the minutes from this discussion.
Here are some thoughts divided in two different discussions we are holding here (sorry if I repeat what you say but I want to be sure I understand the discussion):
- You are having here a very high Architecture discussion on how to
proceed with modeling in the TDWG community. I fully agree with you in the domain-driven design paradigm that TDWG must take, and your proposal for a GML-like thing is interesting, although I am still very new to it so I can not well comment on it. In any case this discussion must be taken in the TAG mailing list, as Stan suggested, so I would not like to continue discussing on this here.
- The second discussion is what I am, right now, more interested in
for my project. How can we share our collection data (ABCD and Darwin Core concepts) using WFS and therefore GML. This is interesting for me because I would like to create services on top of this. In this case what I would like to have is a GML application schema, that I can use with WFS (and again we can not be totally blind of the status of the art of Open Software for it, for example Geoserver does not support GML 3) that contains a good geospatial definition of the location of an specimen (that is the geospatial type you have created) plus a good definition of the specimen itself as properties of this featuretype (that would be ABCD or DWC if you want to be simpler). So, apart on how TDWG continues with its modeling process, I think we can already start working with OGC standards with our schemas. And I do not mean including GML inside ABCD or DWC, but to create a GML application schema that make use of ABCD or DWC to define the properties of a FeatureType, that is a collection record. Sumarizing this is what we need:
- a good geospatial set of concepts that describe the localization of
a collection record and how this has been obtained, etc. (your geospatial extension) 2) a set of concepts to describe this CollectionRecordType, properties of this FeatureType, and for this we created ABCD and Darwin Core. 3) a GML application schema that defines a CollectionRecordType from the GML AbstractType and that use the two previous "schemas" to define the geometry of the type and the properties of it.
So the 3th one is what I called the ABCD-Geospatial-GML-Binding or DWC-Geospatial-GML-Binding depending on what do you use to describe the CollectionRecord.
So if I consider what is missing for me right now is only the 1st point. How to properly described the geometry-georeferenciation of a CollectionRecord. The GML application schema to glue the pieces for WFS is something, right now unfortunately, that is going to be application specific.
So what I would like to concentrate the discussion is on the geospatial extension, if we should use serveral geometries, how we document georeferenciation, accuracy, etc. This is something a lot of people is asking for, I mean, this is fundamental to consider the creation of a database or to start a georeferenciation project, and I know because in my department they are going to start georeferencing a lot of specimen data and I don´t know what to propose them to store and how in the database.
At the end I think I am agreeing with you on that the geospatial extension should be totally independent, am I?
Thanks for the patience, I know I am repeating a lot of things, but I still do not understand totally what is the purpose of this geospatial group and I am also very new to GML and OGC.
Best regards,
Javier.
On 27/12/2005, at 19:25, Phillip C. Dibner wrote:
Javier,
Here's a quick response to your notes and those from some others. Apologies for the delay - I started the following quite a while ago, but was overcome by holiday events. In fact, I will remain fairly constrained between now and the New Year, and will be away from email for a few more days. Still I wanted to send something.
Taking a very important comment from your earlier reply:
Then I don't understand how the schemas had been created. I do not see the connection between dcCollectionRecord and the geospatial. I would add the geospatial schema to the list of imports of collection record and add a new element of type Geospatial to it.
You are right - there is a complete separation of Geospatial from CollectionRecord. The reason for doing this is that a growing number of extensions to Darwin Core have been proposed. The original way that I incorporated the geospatial extension was exactly as you have suggested. However, I changed my mind when I found out that several additional extensions had been proposed. It is desirable to combine the extensions with the Darwin Core base in any combination that the application might require. This is very cumbersome if they include one another. Therefore, I strongly believe they should be as independent as possible. I If the definitions are separate, they can be combined as required into more complex schemas for other purposes. The entire suite of adopted schemas would share a single namespace, distinguishing them as the suite of objects defined and adopted by TDWG. I made this point in St. Petersburg, (and also at the GML Working Group meeting more recently in Bonn). GML itself uses this pattern. Like GML, we could create a master file that includes all the others.
We may wish to define some standard abstract type from which all objects in the TDWG set of schemas inherit. It would be a very simple - and abstract - extension of gml:AbstractFeatureType, to give all of our adopted schema documents a common heritage.
We should also keep in mind that the GML information model and its encoding in XML schema are two different things. We should maintain the same notion: our information model is not the same thing as its encoding in GML-compliant XML schema. I favor expressing our model in ISO GML, as expressed in https://www.seegrid.csiro.au/twiki/bin/view/Xmml/UmlGml.
Note also that we do not really need to use GML's implementation as XML Schema except where we want to serve our data using WFS. (We may wish to, but that is a separate discussion. Please see below.) And if we do want to use WFS as currently defined, and thus avail ourselves of all the off-the-shelf software that supports it, we must have an expression of our concepts in GML as currently specified. That's the only technology available for this. Again, however, our information model need only be consistent with it, and encodable in such a form. It does not need to be defined by this form (and due to some of the restrictions of XML Schema, I think it should not be).
In St. Petersburg I also talked about the value of having a small snippet of GML to add to the existing ABCD or DarwinCore-for-DiGIR schemas, as you have suggested. That may be a good thing to have, but it is a separate discussion. If we make these definitions, we should have a fairly clear idea of what we'll want to use them for. The schemas with extensions of this sort cannot be served by a WFS. They may, however, be parsed, and the relevant portions analyzed by some specialized geospatial extension to DiGIR (or other) clients, or by adjunct geospatial packages that understand GML.
Again, this is just a quick response, hastened all the more by the fact that I have to depart for a few days. I will engage much more fully in this discussion after the New Year, which I hope is a happy and enjoyable occasion for all of you.
Very best regards, Flip
On Dec 20, 2005, at 7:58 AM, Javier de la Torre wrote:
Hi Flip,
I've been playing a little bit more with the schemas. Here are some ideas:
I think I am still not understaind the way you would like to implement the schemas, but here is an idea on how to do it for ABCD and for Darwin Core:
The main idea is to create a CollectionRecordType in a document called something like abcd2.06_gml_biding.xsd or dwc2_gml_binding.xsd What this schema does is to create an element called CollectionRecordType that extends the AbstractFeatureType of GML and that includes two elements in a sequence: Unit or Record of type "abcd:Unit" or "dwc:Record" and another element called Geospatial of type "tdwg_geo:GeospatialType". The schema imports GML, ABCD, and your Geospatial schema.
We only create the binding between our actual schemas and GML and then we add also a GeospatialExtension to them.
Here is an example:
<?xml version="1.0" encoding="UTF-8"?>
xsd:schema..... <xsd:import namespace="http://www.opengis.net/gml " schemaLocation="http://schemas.opengis.net/gml/3.1.1/base/gml.xsd%22/http://schemas.opengis.net/gml/3.1.1/base/gml.xsd%22/
<xsd:import namespace=" http://www.tdwg.org/schemas/abcd/2.06"schemaLocation="http://www.bgbm.org/TDWG/CODATA/Schema/ABCD_2.06/ ABCD_2.06.XSD"/> <xsd:import namespace="http://www.tdwg.org/schemas/geo_spatial/1.0
"
schemaLocation=" http://gis.grinfo.net/resources/ dcGeospatial_javi.xsd"/> <xsd:complexType name="CollectionRecordType"> xsd:complexContent <xsd:extension base="gml:AbstractFeatureType"> xsd:sequence <xsd:element name="Unit"
type="abcd:Unit"/>
<xsd:element name="Geospatial"type="tdwg_geo:GeospatialType"/>
</xsd:sequence> </xsd:extension> </xsd:complexContent> </xsd:complexType> <xsd:element name="CollectionRecord" type="CollectionRecordType"substitutionGroup="gml:_Feature"/>
</xsd:schema>
I do not like it specially like this... Is not possible to extend something from two types in XML schema no? this is why I have to repeat CollectionRecord and then Unit...
I don't know. In any case now I think I understand that what you want is to separate the extension from the binding, is that correct?
Phillip C. Dibner Ecosystem Associates (650) 948-3537 (650) 948-7895 Fax