GML for Biocollections Data

1
GML for Biocollections Data

• Phillip C. Dibner
• Ecosystem Associates

2
GML Versions of Darwin Core Schemas

• geospatialGML.xsd has been posted on the TDWG
  site since early July
• Replicates the content of geospatialWithDiGIRv1.4,
  xsd
• Also 3 GML geometric properties with values
  describing point, point radius, and polygonal
  locations
• There is also a darwincoreGML.xsd, based on
  darwincoreWithDiGIRv1.4,xsd
• Both schemas validate

3
geospatialGML.xsd
WithDiGIR
GML
4
DiGIR vs. GML Encoding - Type
GML --
-- DiGIR
5
DiGIR vs. GML Encoding - Syntax
6
Beyond the Encoding
There are other considerations and challenges to
working with GML as currently constituted, e.g.,
integrating other models.
The encoding?
These are mostly restrictions imposed by the
encoding in XML Schema, not GML itself.
GML is actually an information model - a set of
abstractions - concepts - about what the items we
are representing are -- as much (more?) as it
is any particular representation of those
concepts.
Its current incarnation uses technology that was
sufficiently expressive and sufficiently mature
to do the job when GML was created.
Similarly, we should develop a clear notion of
the abstractions we are modeling.
Express them as an encoding-neutral information
model.
The typical means of expression UML.
(This model is not current or complete, and is
included for illustration only)
7
(Aside Some Notes About GML)

• There is no standard UML expression of the whole
  of GML (that Im aware of).
• But - it is designed to be independent of
  encoding. Is it?
• - An earlier version was encoded in RDF.
• OGC has conducted experiments converting UML
  Application Schemas (conformant to ISO DIS
  19109).
• Proof against technology change

8
(Aside to the Aside)
With proper consideration, the same longevity can
be available to Darwin Core. This approach also
supports offering datasets concurrently through
multiple protocols (DiGIR, WFS, )
Darwin Core Lists
DiGIR Provider Engine
Single Darwin Core Datastore
Darwin Core GML
WFS
9
Some considerations and points of opinion
10
1. geospatialGML.xsd includes
collectionRecord.xsd, making for a nice
reflection of the flat structure obtainable with
base and extension schemas proposed for Darwin
Core, in one object

Elt. 1 Elt. 2 Elt. 3 Elt. n
dc w/ DiGIR
Elt. 1 Elt. 2 Elt. 3 Elt. n
dcGML
. . .
. . .
Elt. n1 Elt. n2
Elt. n1 Elt. n2
geo w/ DiGIR
geospGML
. . .
. . .
but XML Schema requires included and
including schema documents to have the same
namespace. Point 1 They should have the same
namespace.
11
2. GML as one element in a non-conforming schema
(e.g., GML element of ABCD Gathering type)
GML field
12
We need an insertable geospatialGML object.
and it should not drag along information that
is already contained in the including schema.
13
Why do this?
Not directly interoperable with OGC services
but useful nonetheless. Leverages the info
model, e.g.
14
so a geospatialGML object that can be dropped
into other schemas is a useful thing. But - we
dont want to be maintaining two versions of
geospatialGML.xsd
Point 2 keep darwincoreGML and its extensions
independent of one another where possible.
The cost you will have to create another
object if you want the features of more than one
of them. (Chances are youll be doing that
anyway.)
The benefit flexible basis for further
extensions and application schemas.
15
Point 3 theres a lot of expressive power in
the conceptual model expressed by GML. Use it,
dont duplicate it.
A couple of specific implications There are
several definitions of temporal objects in
darwincoreGML.xsd. They are easy for humans to
read, but gmlTimeInstant has greater expressive
power, and by (overrideable) default depends on
another well-conceived and broadly-supported
standard ISO-8601. (I believe this may have
been addressed already.) Spatial notions like
longitude, latitude, and geodetic datum are
represented as explicit elements in
geospatialGML.xsd. They duplicate information
contained in the GML objects defined later in the
file, and less powerfully. Get rid of them.
16
Point 4 develop a consistent model upon
which additional taxonomic, ecological,
biological, and environmental application schemas
can be built.
One namespace Meaningful names, with a prefix
that represents the affinities of the component
schemas darwincoreGML.xsd gt
dcCollectionRecord.xsd geospatialGML.xsd gt
dcGeospatial.xsd Others in kind. One top
file that includes them all, e.g.,
dcDarwinCore.xsd
17
Recommendations

• Do Clarify and refine our information model.
• Do Experiment and debate.
• Do Seriously consider the notions expressed in
  the past few slides.
• Do Use (and where necessary extend) existing GML
  spatial and temporal base types.
• Do Explore harmonization with the emerging
  Common Observation Model.
• Combines Observations Measurements
  recommendation with SensorML
• Recognizes and models the fundamental nature of
  observation as a process
• Do Inform and engage the GML community, in
  particular, the architects of GML. They know
  about us, they are interested, and they have some
  experience with subtleties that we are likely to
  face.

18
Recommendations

• Dont rush to adopt the GML version as its been
  developed to date. Its not ready.
• Dont let this stop us from moving forward with
  current mature proposals.
• Perfection wont arrive, not even later.
• With careful consideration, we can transform
  on-the-fly to maintain compatibility between
  current and possible future expressions and
  underlying models for Darwin Core.
• The world is waiting.

19
Acknowledgements
This work has been supported by
a major development effort funded by