[Tdwg-tag] GML application schema for TDWG
Javier de la Torre
jatorre at gmail.com
Wed Dec 28 16:04:18 CET 2005
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"/>
>> <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.
>
More information about the tdwg-tag
mailing list