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

[Carlo Cipolloni]

Dear All,

concerning the agenda of Friday afternoon; please let me know which task
will be proposed I think we would be in some of them.

Another important notice to be consider is I’m one of the person that
organize the next INSPIRE Conference in Italy (Florence) in June 2013,
because I’m ISPIRE Italian National Contact Point, so I think is a great
opportunity to own community to organize special session or workshop,
therefore if you have suggestion or proposal they will welcome.

Cheers,

 

Carlo

 

  _____  

Da:
geosciml-bounces+carlo.cipolloni=isprambiente.it at lists.opengeospatial.org
[mailto:geosciml-bounces+carlo.cipolloni=isprambiente.it at lists.opengeospatia
l.org] Per conto di Simon.Cox at csiro.au
Inviato: venerdì 17 agosto 2012 03:32
A: steve.richard at azgs.az.gov
Cc: geosciml at lists.opengeospatial.org
Oggetto: 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:

 



 

Any thoughts?

Thanks

steve 

 

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/d1cb9c4e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 22085 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20120817/d1cb9c4e/attachment.gif>