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):
1) 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.
2) 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:
1) 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/%3E <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? We will have to recreate our schemas inside the binding or we can somehow, like I am showing, import directly our schemas?
I have the schemas that you sent already to make them validate if you want them.
Javier.