[GeoSciML] [ExternalEmail] Re: pattern to use for decoupling packages in OGC type modular implementation

Rob.Atkinson at csiro.au Rob.Atkinson at csiro.au
Thu Aug 16 21:55:53 EDT 2012

You have two very different concerns - publishing the semantics in the abstract model and describing implementations. Tooling is probably required to relate implemented structures to these definitions, (i.e. an online Feature Type Catalogue exploiting semantic technologies).

What we have found necessary in the hydrology domain is to complete the separation from implementation to abstract, then use a mapping idiom to associate implementation classes to abstract classes explicitly. This is necessary for two reasons - to support real-world platforms that can handle only one aspect of the abstract model at a time (i.e. topology or polygon boundaries for watersheds), and to support linking pre-existing implementations to common identifiers based on the abstract model.

In our case we need to show how simplified structures (i.e. geometry of waterbodies) relate to more object-oriented and topologically connected constructs in the abstract model.

[cid:image003.png at 01CD7C6F.3FAD52B0]

Using a UML idiom isn't necessary if you push your models into RDF-land, but in the absence of stable infrastructure and tooling to do that the model mapping in UML seems the best bet, and we should be able to compile this to some sort of RDF form for processing.

There are some experimental capabilities for all this, including HTML doco linking mapped elements to underlying abstract model definitions in the SolidGround toolset.

If anyone wants to pursue this further, contact me. In the meantime, the discussions around URL-rewriting for multiple vocabulary formats we've had with Steve's team is related to the task of creating these enriched form on online Feature Type Catalogue building out from Simon's work on SISSVoc and SKOS and OWL encoding of the ISO General Feature Model. Complex stuff, but may provide a solution to the dilemmas y'all face.

Rob Atkinson

From: geosciml-bounces+rob.atkinson=csiro.au at lists.opengeospatial.org [mailto:geosciml-bounces+rob.atkinson=csiro.au at lists.opengeospatial.org] On Behalf Of Simon.Cox at csiro.au
Sent: Friday, 17 August 2012 11:32 AM
To: steve.richard at azgs.az.gov
Cc: geosciml at lists.opengeospatial.org
Subject: [ExternalEmail] Re: [GeoSciML] pattern to use for decoupling packages in OGC type modular implementation

There is a lot of sense to that.
What I proposed in my mails in June was to go straight to the pattern below and implicitly to put the 'complete' model aside.
But I recognize that there are merits in having the complete model for view as an abstract model, perhaps being less picky about cardinalities and omitting 'nillable' concerns altogether.
The question then would be how to link from the implementation model to the abstract model, which presumably acts as the 'canonical' view and would have a lot of semantic description embedded.
Do you have explicit dependencies from each class or even attribute and association in the implementation view back to the abstract model?
If not, then they will certainly drift apart ...

From: Steve Richard [mailto:steve.richard at azgs.az.gov]
Sent: Friday, 17 August 2012 3:51 AM
To: Cox, Simon (CESRE, Kensington)
Cc: A mailing list for GeoSciML
Subject: pattern to use for decoupling packages in OGC type modular implementation

Simon-here's what we're contemplating as a pattern to reduce dependencies in GeoSciML and generate a more modular implementation. Current thinking is to make GeosciML v3 schema an abstract specification, and then use a pattern like this to generate modular implementation:

[cid:image001.png at 01CD7C6C.BEF9B340]

Any thoughts?

Stephen M Richard
Arizona Geological Survey
416 W. congress #100
Tucson, AZ
AZGS: 520-770-3500
Office: 520-209-4127
FAX: 520-770-3505

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20120817/1e918809/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 21665 bytes
Desc: image001.png
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20120817/1e918809/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.png
Type: image/png
Size: 80472 bytes
Desc: image003.png
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20120817/1e918809/attachment-0001.png>

More information about the GeoSciML mailing list